Loop Engineering 里，人到底该干什么

上周有个读者问我："你前两篇讲 Loop Engineering 讲得挺好，但我有个困惑——循环跑起来之后，我还有什么用？"

这个问题问到点上了。

很多人理解 Loop Engineering 的方式是"让 AI 自己跑，我去喝咖啡"。你确实不该再坐在屏幕前一轮一轮地发提示词，那是在用人力模拟循环。但循环跑起来不等于你可以消失。无人值守地运行，就是无人值守地出错。

今天聊清楚一件事：Loop Engineering 里，人的角色到底是什么？

角色没消失，只是移动了

以前你的工作是：写提示词 → 看输出 → 改提示词 → 再看输出。你是中间那个传话筒。

现在你的工作是：定义目标 → 设计循环 → 审查结果 → 处理循环搞不定的事。

角色转变

中间那些机械性的"执行-检验-重试"，交给循环。你只管入口和出口。

但要求其实更高了。你在入口定义的东西，会被循环放大执行几十次。一个模糊的目标，循环会帮你把模糊放大成灾难。

循环需要知道什么时候停下来。如果你给它的停止条件是"把这个功能做得更好"，它会永远跑下去，因为"更好"永远可以再好一点。

可验证的停止条件长这样：

不可验证的停止条件长这样：

Claude Code 的 /goal 命令之所以有效，是因为它强制你把目标写成一个可以被独立子 Agent 判断"是否达成"的条件。写代码的 Agent 不给自己打分，另一个 Agent 来判断。但那个判断用的标准，还是你在最开始定义的。

这一步没有人可以代替你。

好的循环设计里有一条规则：重试两到三次之后，优雅失败，把问题交还给人。

Addy Osmani 在他的 Loop Engineering 文章里说得很直接：

"任何循环无法处理的事情都落入分诊收件箱等我处理。"

升级流程

你的收件箱会收到什么？需要上下文判断的模糊需求（"这个 PR 要不要合"），涉及不可逆操作的确认（"要删除这张表吗"），循环连续失败、需要人来诊断的异常。

这些不是循环的失败，是循环把真正需要人判断的问题筛出来了。比你盯着每一步要高效得多。

循环说"完成了"，不等于真的完成了。

Addy 的原话是："你的工作是发布你确认能运行的代码。"这条不会因为有了循环而改变。循环帮你生成代码，但你要为发布负责。

这里有一个很现实的风险：理解力债务。循环跑得越快，你没亲手写的代码越多，你真正理解的代码和实际存在的代码之间的差距就越大。当生产环境出问题，你面对的是数千行你从未读过的逻辑。这个差距不会因为你跑了循环就自动缩小，它只会随着时间和代码量膨胀。

所以循环产出的东西，你至少要读。不一定每行都懂，但你要知道它在干什么。

判断标准：操作可逆 + 结果可验证 + 失败代价低。满足这三条，基本可以放心。

判断框架

CI 失败自动分诊和修复。 循环读取 CI 失败记录，派一个子 Agent 起草修复方案，再派第二个子 Agent 对照测试审查那份草案。测试通过就自动开 PR。注意是开 PR，不是合代码——PR 本身就是检查点。循环做了 90% 的工作，你花 5 分钟看一眼就够了。

代码风格和 lint 自动修复。 这类任务有明确的机器可验证标准：lint 规则通过就是通过。循环可以在每次提交后自动跑，发现问题自动修，修完自动验证。即使修坏了，下一次提交会暴露问题。

测试覆盖率监控和补全。 循环定期扫描代码库，找到没有测试覆盖的函数，自动生成测试用例草稿，提交 PR。同样是"提交 PR"不是"直接合并"。循环负责发现和起草，人负责最终确认。

共同点是：循环的自主范围被框在了一个人可以快速审查的产出物上（通常是一个 PR）。它不是在替你做决定，是在替你做准备。

每次设计循环时问自己：

不是每个步骤都要跑一遍这五条。但当你犹豫"这个该不该让循环自己跑"的时候，拿出来过一遍。

Boris Cherny 说"我的工作是写循环"。

不是看循环跑。是写循环。设计它，约束它，在它搞不定的时候接管它。循环跑得再快，你停止思考的那一刻，它放大的就不再是你的判断力了。