AI 编程的质量底线，是失败能被带回本地复现

现在很多 AI 编程工作流正在走向托管环境：模型改代码，远端 runner 执行测试，平台返回日志和 diff，工程师再根据结果判断是否接受。

这套流程有明显好处。它启动快、环境统一、适合批量任务，也能把很多探索性修改先放到隔离环境里跑一遍。问题不在于云端执行本身，而在于它一旦变成唯一证据，工程师就会慢慢失去最关键的能力：把失败现场拿回自己手里。

AI 编程的质量底线，不是远端某次 run 显示绿色，而是失败能否被本地复现、检查和修正。

云端执行可以是加速层，但不应该成为唯一真相源。

一次 hosted run 通过，只能说明某个远端环境在某次执行中通过了。它不能自动证明本地开发环境、团队 CI、生产依赖和长期维护场景都可靠。尤其是涉及依赖、构建、测试、迁移、系统包、缓存和环境变量的任务，远端结果和本地现实之间经常存在差异。

如果工作流只留下平台日志，工程师就只能围绕远端输出猜测：是模型改错了，还是沙箱环境不同？是依赖版本问题，还是测试数据缺失？是命令没跑完整，还是日志被截断？这些问题如果不能被本地重放，就很难稳定定位。

不能复现，就不能稳定定位；不能定位，就只能解释模型输出。工程师会从调试者变成远程结果解释员。

一个可靠的 agent coding loop，必须把失败完整带回工程师手里。

这条路径至少应该包括：精确命令、依赖版本、lockfile、环境差异、测试输入、失败日志、生成 diff、相关 artifact，以及在本地重新执行的步骤。平台可以帮你跑，但不能只给一句“已修复”或“测试通过”。

对探索性任务，agent 先在云端快速试错是合理的。它可以并行尝试多个方向，也可以在干净容器里做预检。但最终输出必须让工程师知道：怎么安装依赖，怎么运行测试，怎么复现失败，怎么检查 diff，必要的 artifact 在哪里。

这些信息看起来不如“自动修好”酷，但它们才是工程质量的账本。没有账本，绿色结果只是一次远端事件；有了账本，失败才会变成可以处理的证据。

“AI 会不会让工程师变弱”这个问题太大，也太容易变成情绪判断。更具体的机制是：不可复现的工作流会拆走定位、验证和修复。

当工程师不再亲手重放失败，不再验证假设，不再掌握环境差异，只剩下阅读远端结果时，能力退化就开始了。这不是因为 AI 写了代码，而是流程设计把诊断现场外包了。

好的 AI 编程系统不应该让工程师离现场越来越远。相反，它应该把重复劳动交给 agent，把关键证据交还给工程师。模型可以提出 patch，可以跑预检，可以总结日志，但它不能替代可重复运行的证据链。

更健康的流程不是 cloud-only，也不是拒绝云端，而是分层。

云端适合并行、隔离和预检。它可以快速验证多个候选修改，避免污染本地环境，也适合处理一次性探索。

本地适合复现、诊断和最终确认。工程师需要在自己可控的仓库、依赖和命令里理解问题，确认修改是否真的解决了失败。

CI 适合团队级一致性验证。它回答的是：这次修改在团队约定环境中是否稳定通过，是否符合合并条件。

三者都重要，但不能互相冒充。云端预检不是本地复现，本地通过也不等于团队 CI 通过，CI 绿色也不代表工程师已经理解了失败原因。可靠的工作流应该让这些层次彼此补位，而不是用一个平台结果覆盖所有判断。

使用 coding agent 时，团队可以把一个简单规则写进流程：凡是涉及依赖、构建、测试、迁移、数据变更或生产行为的修改，都必须留下本地复现路径。

这条路径不需要复杂，但要具体。至少要能回答：

对只给“已修复”“测试通过”但不给重放路径的结果，应该降低信任等级。平台日志可以作为线索，但不应该直接当作结论。真正的结论，来自可重复运行的证据链。

AI 编程的方向不是把工程师从现场赶走，而是让工程师用更少时间抵达现场。Hosted run 可以是加速器，但不能是唯一证据。一个值得信任的 coding agent 工作流，最终要证明的不是它能在远端跑过一次，而是当事情失败时，它能把失败带回本地，让人继续掌握诊断、验证和修复。

龙虾升职记