# Loop Engineering 怎么落地：三层循环 vs 四种命令
**作者**: Niko爱学习
**日期**: 2026-07-09T04:02:29.000Z
**来源**: [https://x.com/ai_super_niko/status/2075068045610119268](https://x.com/ai_super_niko/status/2075068045610119268)
---
吴恩达老师发了条长推文，把 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
## 落地路径
如果你还在手动粘报错（第一层都没上）：
1. 学会用 /goal 命令，给 AI 一个能自动验证的完成标准
2. 把"跑 mvn test 全绿"、"build 通过"、"lint 无警告"这类自动化验证加到每个任务的结尾
3. 在 CLAUDE.md 里加上"禁止占位实现"的约束（上面有能直接抄的模板）
如果第一层跑得挺熟，但经常跑偏（缺第二层）：
1. 把愿景落地为可执行的 spec，写在 CLAUDE.md 或任务开头，别只在脑子里
2. 每次审查实现时，问自己两个问题：方向对不对？标准要不要补？
3. 反复踩坑的地方，写成 SKILL.md 固化下来（参考上面的前端验证模板）
如果前两层都在转，但从不看真实数据（缺第三层）：
1. 找几个真实用户试用，哪怕只是发给朋友
2. 如果已经上线，用 /loop 或 /schedule 定期检查用户行为数据（留存、转化、使用路径）
3. 把用户反馈定期（每周或每两周）回顾一次，调整产品愿景
三层循环里，第一层是工具能帮你的，第二层和第三层是工具替不了的。
吴恩达老师用"上下文优势"解释为什么第二层必须是人：你比 AI 更懂用户、更懂业务、更懂这个产品要解决什么问题。ClaudeDevs 给了具体方案：用 SKILL.md 把你脑子里 AI 不知道的东西，一条条编码进去。
对照上面那张自查表，看你卡在哪一层。卡在第一层就先把 /goal 用熟，卡在第二层就多花时间写 SKILL.md 固化标准。你现在在哪一层？
> Hi，我是 爱学习的Niko。17 年程序员老兵，现在每天用 AI 写代码。这里分享学习和使用 AI 的经验、技术思考、踩过的坑、实用工具和 SKILL。关注我，一起学习。
## 相关链接
- [Niko爱学习](https://x.com/ai_super_niko)
- [@ai_super_niko](https://x.com/ai_super_niko)
- [7.4K](https://x.com/ai_super_niko/status/2075068045610119268/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [12:02 PM · Jul 9, 2026](https://x.com/ai_super_niko/status/2075068045610119268)
- [7,457 Views](https://x.com/ai_super_niko/status/2075068045610119268/analytics)
- [View quotes](https://x.com/ai_super_niko/status/2075068045610119268/quotes)
---
*导出时间: 2026/7/9 23:17:30*