Loop Engineering 不等于让 Agent 放飞自我

最近 Loop Engineering 很火。

很多人把它理解成：我给 AI 一个目标，然后用 /goal 或 /loop 让它自己循环开发、自己修 bug、自己验证，最后交付一个功能。

这个理解不能说错，但我觉得只理解到这里，很容易把 Loop Engineering 用偏。

尤其是在真实业务系统开发里，很多问题不是“代码能不能写出来”，而是：

这个功能到底解决什么问题？
边界应该收在哪里？
哪些动作不能自动化？
页面交互是否符合使用习惯？
后端接口和前端体验是否一致？
文档、代码、验收标准是否对齐？

这些问题，不是让 Agent 多跑几轮就一定能解决的。

我现在的开发方式，本质上已经是一种 Loop

以我开发一个内部 DevOps 平台功能为例，我通常不会一上来就让 AI 写代码。

我的流程一般是：

先聊清楚要做什么
→ 讨论这个功能解决什么问题
→ 明确前后端怎么实现
→ 反复修正边界和细节
→ 形成 SDD（设计说明文档）
→ 最后按 SDD 开发
→ 验收和微调

这个过程往往会对话很多轮。

看起来这不像大家说的 /loop，但本质上它也是一种 loop，只不过它不是“Agent 自己循环”，而是：

人主导的需求与设计收敛 loop

AI 在这个过程中负责帮我推演方案、补全遗漏、整理结构、形成文档；而我负责判断方向、边界、体验和取舍。

最终形成的 SDD，其实就是这个 loop 的状态沉淀。

这也是为什么后续开发往往可以一次性做得大差不差。因为真正困难的部分，已经在前面的讨论 loop 里解决了。

如果换成 Boris Cherny 的思维，会有什么不同

Boris Cherny 那句被反复引用的话，大意是：他不再直接 prompt Claude，而是让 loops 去 prompt Claude，自己的工作变成写 loops。

这句话很容易被误解成：

我不用思考了；
我只要给一个大概目标；
剩下让 Agent 自己跑完。

但我更愿意把它理解成另一件事：

他不是减少思考，而是把自己的思考方式工程化。

普通 prompt 思维是：

帮我实现这个功能。

Boris 式 loop 思维更像是：

请建立一个实现这个功能的工作循环：
1. 读取目标和上下文；
2. 拆分任务；
3. 每轮只推进一个最小闭环；
4. 改完后验证；
5. 验证失败就分析和修复；
6. 如果发现需求不清楚或实现冲突，就停下来汇报；
7. 达到停止条件后输出结果。

也就是说，他真正设计的不是某一次 prompt，而是一条“生产线”。

如果把这个思路放到一个内部业务系统功能开发场景里，对比会更直观：

方式	我现在的 SDD 工作流	Boris 式 loop 思维
起点	我先和 AI 多轮讨论，把需求聊清楚	先定义一个能持续澄清、执行、验证的 loop
人的角色	人参与每轮判断，推动需求收敛	人设计规则、边界、检查点和停止条件
AI 的角色	辅助分析、整理方案、生成 SDD、实现代码	在 loop 内自动分解任务、执行、验证、修复
文档作用	SDD 是讨论后的沉淀	SDD 是 loop 的输入、轨道和验收依据
风险控制	靠多轮人工确认避免跑偏	靠上下文、验证器、预算、停止条件避免跑偏
适合阶段	需求不清楚、方案要权衡时	目标明确、可以自动验证时

所以两者不是对立关系。

我现在的方式更像是：

人亲自参与 loop，让需求和设计收敛。

Boris 的方式更像是：

人把这个 loop 设计出来，让 Agent 在规则内持续推进。

前者适合复杂业务功能的早期设计，后者适合目标明确之后的执行、验证和重复推进。

真正要学的不是“我不管了，让 AI 自己跑”，而是：

我能不能把自己反复做的判断，变成 Agent 可以遵守的循环规则？

这才是 Loop Engineering 最有价值的地方。

不同高手眼里的 Loop Engineering

Loop Engineering 现在之所以容易让人困惑，是因为不同人其实在讲不同层面的东西。

他们说的都是 loop，但关注点不完全一样。

人	关注点	我理解的核心
Boris Cherny	Agent 自己 prompt Agent	人不再写每一步 prompt，而是设计能持续工作的 loop
Peter Steinberger	仓库维护和自动调度	让 Agent 定时醒来，发现问题、分派任务、推进 repo
Addy Osmani	工程基础设施	loop 需要 automation、worktree、skills、plugins、sub-agents 支撑
Andrew Ng	产品开发反馈环	loop 不只是写代码，还包括开发者反馈和真实用户反馈
Claire Vo	管理者视角	设计 loop 像 onboarding 一个员工，要定义岗位、权限和汇报机制
Armin Ronacher	谨慎和可理解性	loop 很强，但长期系统不能变成人类看不懂的技术债工厂

Boris 的视角最激进。

他看到的是：

我不直接 prompt Agent；
我设计一个会 prompt Agent 的系统。

Peter 的视角更像仓库管家。

他关心的是：

Agent 能不能定期检查 repo；
能不能发现卡住的 PR；
能不能把问题分派到不同线程；
能不能持续推进那些不用人每次手动提醒的任务。

Addy 的视角更工程化。

他提醒大家：一个 loop 要稳定运行，不能只靠一句 prompt。它需要隔离的工作区、项目知识、工具连接、子 Agent、自动化触发和验证机制。

Andrew Ng 的视角更产品化。

他把 loop 从 coding 扩展到产品开发：AI 可以在代码层面快速迭代，开发者可以在体验层面快速反馈，真实用户的反馈又会进入下一轮产品判断。

Claire Vo 的比喻最接地气。

她把 loop 看成“给一个员工设计工作”。这会逼我们想清楚：

这个 Agent 的岗位是什么？
它能做什么？
它不能做什么？
它什么时候汇报？
它遇到不确定情况应该升级给谁？

Armin Ronacher 则提供了很重要的反方提醒。

他并不是反对 Agent 或 loop，而是在提醒：如果一个系统长期由 Agent 持续修改，但人逐渐看不懂它，最后可能得到的不是生产力，而是更难维护的技术债。

这些观点放在一起看，会发现 Loop Engineering 其实不是一个单点技巧，而是一组分层能力：

Boris 关心：谁来提示 Agent。
Peter 关心：谁来持续推进仓库。
Addy 关心：loop 运行需要哪些工程设施。
Andrew 关心：代码 loop 如何进入产品反馈 loop。
Claire 关心：Agent 在组织里扮演什么角色。
Armin 关心：人类是否还能理解和负责这个系统。

而我的实践更接近一种：

SDD 驱动的 human-at-the-right-loop。

也就是：

需求和设计阶段，人必须在 loop 中；
实现和验证阶段，Agent 可以更多进入 loop；
最终体验和工程边界，仍然要回到人来判断。

所以我不会把 Loop Engineering 理解成“人退出流程”。

我更愿意把它理解成：

人从重复 prompt 中退出；
但进入更高层的目标、边界、验证和责任设计。

SDD 是 Loop 的轨道，而不是形式主义文档

我越来越觉得，SDD 最大的价值不是“写一份文档”，而是给 Agent 一个清晰轨道。

没有 SDD 的时候，Agent 很容易这样工作：

理解一个大概目标
→ 自己脑补很多实现
→ 写出一版代码
→ 功能可能能跑
→ 但边界、交互、风格不一定对

有 SDD 以后，它的工作方式会变成：

按明确目标实现
→ 只改范围内的东西
→ 遇到冲突先停下来
→ 根据验收条件验证
→ 输出变更和验证结果

这两者差别很大。

前者是让 Agent 自由发挥，后者是让 Agent 在设计好的循环里执行。

所以我理解的 Loop Engineering，不是简单地把任务丢给 AI，然后人退出现场。

更合理的方式是：

人负责设计 loop 的目标、边界和停止条件；
Agent 负责在这个范围内循环执行、验证和修复。

真正适合自动 loop 的，是 SDD 之后

在我的场景里，最适合引入 loop 的阶段不是一开始，而是 SDD 之后。

比如可以这样：

按 SDD 实现功能
→ 运行相关测试
→ 如果失败，自动修复
→ 再次验证
→ 最多循环 3 次
→ 如果发现 SDD 和现有代码冲突，停止并报告

这才是适合业务系统开发的 loop。

它不是：

我说个大概，Agent 自己想办法做完

而是：

我已经想清楚了目标和边界，Agent 负责高效执行和验证

这两种方式差别非常关键。

前者容易跑偏，后者能提效。

我的主要返工点，其实不是功能，而是前端审美

现在我遇到的情况是：功能逻辑通常能一次性做出来，真正需要返工的更多是前端页面。

比如：

页面布局不够顺眼；
按钮位置不符合习惯；
表格密度不对；
信息层级不清晰；
和已有页面风格不一致；
不同运行时页面没有保持一致的交互体验。

这说明功能 SDD 已经比较有效，但 UI 验收标准还可以继续加强。

所以相比让 Agent 更自由地跑，我更想补一个：

UI / Design Acceptance Loop

也就是在 SDD 里额外明确：

页面参考哪个已有页面；
按钮放在哪里；
表格操作区怎么设计；
加载态、空状态、错误态怎么展示；
哪些页面需要保持一致；
什么样的视觉效果算不通过。

这样前端返工就可以前置，而不是等代码写完以后再靠感觉调整。

我不认为 Loop Engineering 的目标是让人消失

很多关于 Loop Engineering 的讨论，容易给人一种感觉：以后人只要提目标，剩下全交给 Agent。

我觉得这在真实工作里不太成立。

尤其是复杂系统开发，人的价值不是敲代码，而是判断：

什么值得做；
做到什么程度刚刚好；
哪些边界不能突破；
什么体验才算好用；
什么方案长期可维护。

这些判断很难完全交给 Agent。

所以更现实的模式不是 human out of the loop，而是 human at the right loop。

人不需要盯着每一行代码，但要站在更关键的位置：

需求 loop：人主导
设计 loop：人主导，AI 辅助
实现 loop：AI 主导
验证 loop：AI 先跑，人最终验收
审美 loop：AI 对齐参考，人做最终判断

这可能才是目前最稳的工程实践。

我会怎么改进自己的工作流

如果要把 Loop Engineering 放到我的实际开发里，我不会推翻现在的方式，而是做几个小升级。

第一，继续保留多轮需求讨论。

这个阶段不应该省。因为它决定方向。

第二，让 SDD 不只描述功能，也描述验收标准。

尤其是 UI、交互、权限边界、异常状态和页面一致性。

第三，把 SDD 后的实现交给 Agent 循环。

让它自动开发、测试、修复，但必须限制范围和次数。

第四，增加一个只读 Review Loop。

开发完成后，让 Agent 检查：

有没有超出 SDD 范围；
有没有遗漏权限；
有没有破坏已有页面一致性；
有没有文档和代码不一致；
有没有明显的交互问题。

第五，把高风险动作留给人工确认。

比如生产环境操作、发布链路、CI/CD 配置、权限变更，这些不应该随便自动化。

第六，把成熟流程固定成可复用 loop。

比如内部平台功能开发可以逐步沉淀成几类固定循环：

需求澄清 loop：只负责把问题、边界和验收标准说清楚。
SDD 生成 loop：把讨论结果整理成可执行文档。
实现验证 loop：按 SDD 开发、测试、修复，但不扩大范围。
UI 对齐 loop：对照已有页面风格检查布局、密度和交互。
Review loop：只读检查是否偏离 SDD、是否遗漏权限和文档。

这样做不是为了让人退出流程，而是为了让人从重复提醒中抽身出来，把精力放在真正需要判断的地方。

总结

我现在对 Loop Engineering 的理解是：

Loop Engineering 不是让 Agent 自己无限跑；
而是把目标、边界、验证和停止条件设计清楚。

对于我的工作来说，最有价值的不是“全自动开发”，而是：

SDD 前，人和 AI 反复收敛问题；
SDD 后，AI 按明确轨道循环实现和验证；
最终由人判断产品体验和工程边界。

所以，我不会为了追 Loop Engineering 这个概念，放弃现在的 SDD 工作方式。

相反，我觉得 SDD 本身就是一种很好的 loop 状态沉淀。

真正要改进的是：把实现验证、UI 验收、代码 Review 这些后置环节，也设计成更清晰的 loop。

一句话总结：

不要把“想清楚要做什么”交给 loop；
要把“按想清楚的方案反复实现、验证、修正”交给 loop。

这才是我认为更适合真实业务开发的 Loop Engineering。