# Loop Engineering 里，人到底该干什么

> 循环跑起来之后人的角色是什么？定义完成标准、处理升级问题、审查最终结果——三个必须有人在场的节点，以及判断哪些步骤可以放心交给循环的框架。

- 原文链接: https://laojin.blog/blog/20260618_loop_engineering_human_in_the_loop
- 作者: 老金
- 发布日期: 2026-06-18
- 标签: Loop Engineering, Human-in-the-Loop, AI 协作, Claude Code

---

![Loop Engineering 里，人到底该干什么](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260618/00_cover.png)

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

这个问题问到点上了。

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

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

---

## 角色没消失，只是移动了

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

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

![角色转变](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260618/01_role_shift.png)

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

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

---

## 人必须在场的节点

### 定义"完成"的标准

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

可验证的停止条件长这样：
- `test/auth` 里的所有测试通过，lint 零报错
- 构建命令退出码为 0
- 指定路由返回正确格式，响应时间 < 200ms

不可验证的停止条件长这样：
- "代码质量提升"
- "用户体验更好"
- "优化一下布局"

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

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

### 处理循环升级上来的问题

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

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

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

![升级流程](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260618/02_escalation.png)

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

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

### 最终结果的审查

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

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

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

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

---

## 可以放心交出去的

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

![判断框架](https://pic-1258874139.cos.ap-hongkong.myqcloud.com/laojinblog/posts/20260618/03_decision_filter.png)

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

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

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

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

---

## 判断某个步骤要不要人确认

每次设计循环时问自己：

1. 这个操作可以撤销吗？删数据、发邮件、合代码到主分支——不可逆的需要人确认。
2. 失败的代价是什么？
3. 有没有机器可以验证的成功标准？有就交给循环，没有就需要人。
4. 循环失败后我能快速诊断吗？如果循环的输出是黑盒，你看不懂它在干什么，理解力债务在累积。
5. 这个步骤重复发生的频率高吗？越高频越值得让循环接管。

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

---

## 最后

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

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