Loop Engineering 怎么落地：三层循环 vs 四种命令

吴恩达老师发了条长推文，把 AI 编程的“循环“拆成三层：分钟级的 AI 自检、小时级的开发者决策、天级的用户反馈。

后面没多久，ClaudeDevs 官方发了一篇更长的文章，把循环分成四种：Turn-based、Goal-based、Time-based、Proactive，每种给了对应的命令。

很多人以为让 AI 自动跑起来，就算掌握了 Loop Engineering。对比两篇文章你会发现，这只用上了第一层，而且用得还不到位。

两个视角看同一件事

这两篇文章讲的是同一件事，但切入角度不同：

吴恩达老师的视角：从产品开发角度，按时间尺度分三层（分钟/小时/天），每层的决策者不同（AI/你/用户）。这是方法论框架。

ClaudeDevs 的视角：从工具使用角度，按触发方式和停止条件分四种循环，每种给了对应的 Claude Code 命令。这是落地工具。

两者的共同点是：都在强调**“谁在决策、何时决策、如何停止”**。

区别是：前者告诉你为什么要分层、每层的价值在哪；后者告诉你具体敲什么命令、怎么写验证标准。

把两者结合起来看，你会得到一套完整的落地方案。

三层循环 vs 四种命令：映射关系

先看两者的对应关系：

这个映射关系不是我瞎配的，是从两篇文章的描述中提炼出来的。下面逐层展开。

第一层：智能体编码循环

吴恩达老师怎么说：

AI agent 写代码、测试、持续迭代，直到代码无 bug 且符合规格。这个循环每几分钟就跑一轮。

他举了个例子：上周末给女儿做打字练习 app，coding agent 连续干一个小时，中间自己用浏览器反复检查，不用他插手。

ClaudeDevs 怎么说：

对应的是 Goal-based loop，用 /goal 命令。核心是定义可验证的停止条件，让一个独立的 evaluator 判断目标是否达成。

/goal 让首页 Lighthouse 分数达到 90 或以上，最多尝试 5 次

ClaudeDevs 特别强调：不要让写代码的 agent 自己判断“做好了没“，它会对自己太友善。要有独立的验证。

两者结合的落地方案：

第一层的核心是：给 AI 一个它不在场时也能判定对错的验证标准。

对比两种写法：

错误用法： /goal 帮我把这个模块的测试补全 （什么叫“补全“？AI 自己说了算，容易糊弄） 正确用法： /goal 给 OrderService 补单元测试 覆盖率必须到 80% 以上，跑 mvn test 全绿才算完成 每加一个测试用例，必须真实断言业务结果，不许只断言 not null 跑不过就自己看报错改，改到全绿为止

ClaudeDevs 还给了一个更细的方案：用 SKILL.md 编码你的验证步骤

从 ClaudeDevs 推文里提取的一个前端验证模板：

name: verify-frontend-change description: 验证任何 UI 变更

验证前端变更

不要仅凭编辑成功就报告 UI 变更完成。像人类审查者一样验证：

1. 启动 dev server 并在浏览器中打开编辑的页面
2. 直接与变更交互。对于新控件（按钮、输入框、开关）：点击它，确认预期的状态变化，截图前后对比
3. 检查浏览器控制台：零新错误或警告
4. 使用 Chrome Devtools MCP，运行性能追踪并审计 Core Web Vitals

如果任何步骤失败，修复问题并从步骤 1 重新运行，不要交回部分验证的工作。

一条能直接抄进 CLAUDE.md 的约束，专门防第一层的“伪完成“：

完成标准

• 声称“已完成“前，必须实际运行验证命令并贴出输出
• 禁止用占位实现、TODO、“后续补充“注释冒充完成
• 单元测试必须断言真实业务结果，不接受只断言非空

第一层的本质：你定义“什么叫做好了“，AI 跑到真的做好为止。

第二层：开发者反馈循环

吴恩达老师怎么说：

开发者审查当前产品，引导 coding agent 改进。这个循环运作在几十分钟到几小时之间。

他说了一句我很认同的话：去年很多开发者（包括他自己）都在给 coding agent 当 QA，手动找 bug 再让 agent 修。但 agent 越来越能自测，这部分时间大幅减少了，人腾出手来做产品决策：做什么功能、UI 哪里要改、用户流程顺不顺。

他特别强调：人类的价值不是“品味“，是**“上下文优势”**，你比 AI 多知道用户是谁、业务怎么跑、这个产品到底要解决什么。

ClaudeDevs 怎么说：

对应的是 Turn-based loop + SKILL.md。

Turn-based loop 就是你每次发 prompt，Claude 自己跑一轮（收集上下文、采取行动、检查工作、必要时重复），然后交还给你。你审查结果，写下一个 prompt。

ClaudeDevs 的建议是：把你手动检查的步骤编码成 SKILL.md，让 Claude 能检查更多自己的工作。关键是让 Claude 能“看到、测量或与结果交互“，检查越量化，自验证越容易。

两者结合的落地方案：

第二层的核心是：把模糊的愿景翻译成 AI 能执行的 spec。

他说的三个具体动作，可以用 ClaudeDevs 的 SKILL.md 落地：

动作 1：把模糊的愿景翻译成可执行的 spec

你脑子里“这个页面要更清爽“是没法执行的，得落成“卡片间距加到 16px、移除次要按钮、主操作放右下角“。

这个翻译过程没有命令能替你按，但你可以把翻译结果写进 CLAUDE.md 或任务开头，而不是只在脑子里。

动作 2：看到实现后回头改 spec

AI 做出来的东西经常会让你发现自己原本想错了。这时候要更新 spec，而不是在对话里打补丁。补丁会丢，spec 会留下。

动作 3：反复踩同一个坑时，把它固化成 eval

他的建议：如果系统总在某类问题上翻车，就为它建一组评估集。这组 eval 会喂回第一层，变成 AI 每轮自检的标准。

ClaudeDevs 的实现：写成 SKILL.md，下次遇到同类任务直接调用。

第二层的本质：你不是在验证代码对不对（那是第一层 AI 的活），你是在验证方向对不对、标准全不全。

第三层：外部反馈循环

吴恩达老师怎么说：

向朋友、alpha 测试者或生产环境的 A/B 测试收集反馈。这些通常很慢，几小时到几天甚至几周。

这层解决一个前两层解决不了的问题：你和 AI 一起闭门造的东西，用户到底买不买账。

他说这是很多工程师成长为产品角色时最难的部分，既要埋头把愿景落地（弥合愿景和 spec 的差距），也要抬头看用户反馈来演化愿景。只顾构建会闭门造车，只顾收集反馈会永远在调研、出不了东西。

ClaudeDevs 怎么说：

对应的是 Time-based loop 和 Proactive loop。

• /loop：按时间间隔重跑一个 prompt，适合检查外部系统（PR 评审、CI 失败、Slack 消息）

/loop 5m 检查我的 PR，处理评审意见，修复失败的 CI

• /schedule（research preview）：把循环移到云端，不依赖本地电脑

ClaudeDevs 还给了一个更复杂的组合例子：

/schedule 每小时：检查 project-feedback 频道的 bug 报告 /goal: 不要停止，直到本次运行发现的每个报告都被分类、处理并回复 修复 bug 时，使用 workflow 在并行 worktrees 中探索三种解决方案，并让 judge 对它们进行对抗性审查

这个例子组合了：/schedule（定期触发）+ /goal（定义完成标准）+ dynamic workflows（并行探索）+ auto mode（无需人工确认）。

两者结合的落地方案：

第三层的核心是：定期检查外部系统或用户反馈，用数据驱动第二层的决策。

具体场景：

• 定期检查用户反馈：/schedule 每天: 检查用户反馈渠道，提取关键问题

• 定期看数据：每周看用户行为数据（留存、转化、使用路径），调整产品愿景

• 定期回顾：把用户反馈定期（每周或每两周）回顾一次，而不是只在出问题时才看

第三层的本质：让真实用户的行为数据告诉你，产品愿景是对的还是该调整了。

自查：你卡在哪一层

对照下面这张表，看你现在在哪：

多数人在第三行：第一层跑得挺熟，但第二层做得薄，第三层几乎没有。

从两个视角总结落地方案

把吴恩达老师和 ClaudeDevs 的内容结合起来，你会得到一套完整的落地路径：

方法论层面（吴恩达老师）

理解三层循环的嵌套关系：

• 第一层决定执行质量，但不决定方向

• 第二层决定方向，需要人类的上下文优势

• 第三层决定产品是否解决真问题

越往外的循环越慢，但越决定成败。第一层跑得再快，方向错了也是白跑。

工具层面（ClaudeDevs）

掌握四种循环命令的使用场景：

循环类型 你交出什么 何时用 用什么命令 Turn-based 检查工作 你在探索或做决策 自定义验证 skills Goal-based 停止条件 你知道什么叫做好了 /goal Time-based 触发时机 工作发生在项目外或按时间表 /loop, /schedule Proactive prompt 工作是定期的且定义清晰 以上所有 + dynamic workflows

落地路径

如果你还在手动粘报错（第一层都没上）：

• 学会用 /goal 命令，给 AI 一个能自动验证的完成标准

• 把“跑 mvn test 全绿“、“build 通过”、“lint 无警告“这类自动化验证加到每个任务的结尾

• 在 CLAUDE.md 里加上“禁止占位实现“的约束（上面有能直接抄的模板）

如果第一层跑得挺熟，但经常跑偏（缺第二层）：

• 把愿景落地为可执行的 spec，写在 CLAUDE.md 或任务开头，别只在脑子里

• 每次审查实现时，问自己两个问题：方向对不对？标准要不要补？

• 反复踩坑的地方，写成 SKILL.md 固化下来（参考上面的前端验证模板）

如果前两层都在转，但从不看真实数据（缺第三层）：

• 找几个真实用户试用，哪怕只是发给朋友

• 如果已经上线，用 /loop 或 /schedule 定期检查用户行为数据（留存、转化、使用路径）

• 把用户反馈定期（每周或每两周）回顾一次，调整产品愿景

三层循环里，第一层是工具能帮你的，第二层和第三层是工具替不了的。

吴恩达老师用“上下文优势“解释为什么第二层必须是人：你比 AI 更懂用户、更懂业务、更懂这个产品要解决什么问题。ClaudeDevs 给了具体方案：用 SKILL.md 把你脑子里 AI 不知道的东西，一条条编码进去。

对照上面那张自查表，看你卡在哪一层。卡在第一层就先把 /goal 用熟，卡在第二层就多花时间写 SKILL.md 固化标准。你现在在哪一层？

Hi，我是 爱学习的Niko。17 年程序员老兵，现在每天用 AI 写代码。这里分享学习和使用 AI 的经验、技术思考、踩过的坑、实用工具和 SKILL。关注我，一起学习。