你的AI写代码很快，但可能三个循环只跑了一个

“Loop Engineering”（循环工程）这个词最近在硅谷开发者圈子里火了。起因是 Claude Code 的创始人 Boris Cherny 和 OpenClaw 的创始人 Peter Steinberger 都在社交媒体上提到了这个概念，认为”循环”是让 AI agent 能持续迭代、构建软件的核心方法。

随后，吴恩达（Andrew Ng）在自己的 newsletter The Batch 中写了一篇长文，分享了他用 AI 构建产品时总结的3 个关键循环。

这篇内容值得拆解，因为它回答了一个很实际的问题：为什么同样在用 AI 写代码，有人做出了上线的产品，有人还在反复改 bug？

三个循环，三种节奏

吴恩达把 AI 时代的软件开发拆成三个嵌套的循环，每个循环的节奏不同，承担的任务也不同。

Loop 1：Agentic Coding Loop — 代理编码循环

频率：每几分钟一轮

这是最内层的循环。你给 AI agent 一个产品规格（specification），可选附带一组测试数据（evals），然后让 agent 写代码、运行测试、发现问题、修复代码，如此反复，直到代码满足规格。

吴恩达举了个自己的例子：周末他给女儿做了一个打字练习 app，coding agent 可以自主运行大约一个小时——自己写代码、用浏览器检查效果、发现问题再修复，完全不需要他介入。

这个循环在去年底开始爆发。关键突破不是 AI 更聪明了，而是**”闭环”这个思路被广泛接受**——让 agent 自己跑测试、自己判断对错，而不是写完一段就停下来等人审。

Loop 2：Developer Feedback Loop — 开发者反馈循环

频率：几十分钟到几小时一轮

这个循环里，人审视 agent 产出的东西，做更高层的决策。

去年，很多开发者的角色是”AI 的 QA”——手动找 bug，然后让 agent 修。但随着 agent 自测能力增强，人可以从 QA 中解放出来，专注于更重要的问题：功能优先级、UI 方向、用户体验。

吴恩达在这里提出了一个很有意思的观点。很多人把人在这环节的贡献叫”taste”（品味），但他更愿意叫它**”context advantage”（上下文优势）**。

“对于几乎所有我参与的产品，人类比 AI 系统拥有更多的上下文——我们更了解用户，更了解产品运行的环境。”

为什么这个说法更好？因为”品味”听起来像玄学，”上下文优势”则指明了提升方向：帮 AI 补上下文。写更清晰的 spec、提供更好的 evals、给更具体的用户画像，本质上都是在把你脑子里的上下文传递给 AI。

这也解释了为什么这个循环不能完全自动化：只要人类还知道一些 AI 不知道的东西，人就需要在场。

Loop 3：External Feedback Loop — 外部反馈循环

频率：几小时到几周

最外层的循环，也是最慢的。找几个朋友试用、推给 alpha 测试者、上线做 A/B 测试。外部世界的数据回来后，更新你对产品的愿景，愿景驱动规格，规格再驱动 coding agent。

吴恩达特别强调：最难的不是写代码，而是在”构建”和”获取用户反馈”之间找到平衡。

很多工程师出身的创业者会陷入一个陷阱：不停打磨产品，但迟迟不拿给用户看。反过来也有人只顾收集反馈，产品一直没进展。两者都得做。

为什么大部分人卡在 Loop 1？

看完三个循环，你可能已经发现问题了。

大部分人在用 AI 写代码时，只关了 Loop 1，Loop 2 和 Loop 3 几乎是空的。

Loop 1 的陷阱： Agent 能快速产出代码，给人一种”我在高效开发”的错觉。但如果规格本身是错的，agent 跑得越快，你离好产品越远。

Loop 2 的缺失： 很多人不知道怎么把脑子里的”上下文”翻译成 agent 能理解的指令。结果是反复修改 prompt，但每次都没说到点子上。

Loop 3 的恐惧： 把半成品拿给别人看是反人性的。但 Andrew Ng 说得很清楚——外部反馈的延迟越长，你在错误方向上浪费的计算和精力就越多。

一个更深的洞察：知道什么时候停

巧合的是，今天 arXiv 有一篇论文也在讨论类似的问题——只不过讨论的是 AI 模型本身。

斯坦福和缅因大学的研究者发表了 LearnStop（arXiv:2606.30852），研究推理模型”什么时候该停止思考”。他们发现，在开放性数学题上，学习型的停止规则能显著提升效率；但在选择题和极难题上，简单的置信度阈值就够了。

这和 Loop Engineering 是一个镜像问题：

• AI 模型需要知道什么时候停止推理——过早停会出错，过晚停会浪费算力。
• AI Agent 需要知道什么时候停止编码——过早停会交付半成品，过晚停会陷入过度工程。
• 开发者需要知道什么时候停止构建——过早拿出去会丢脸，过晚拿出去会脱离市场。

三类”停止”问题的共同点：没有万能规则，只有对当前情境的判断。

工程师正在变成产品经理

吴恩达在文章最后说了一段话，我觉得是全文最重要的：

“随着 coding agent 加速软件开发，越来越多的工程师开始扮演部分产品经理的角色。”

这不只是趋势预测，而是正在发生的事实。

以前，工程师的核心竞争力是”写出能跑的代码”。现在 AI 能写代码了，工程师的核心竞争力变成了”知道该写什么代码”——这恰恰是产品经理的核心能力。

好消息是，你不需要重新读一个 MBA。三个循环已经给出了路径：

1. 把 Loop 1 跑通——学会写 spec、建 evals、让 agent 自主迭代
2. 在 Loop 2 里做决策——用你的”上下文优势”判断方向，而不是当 QA
3. 尽快启动 Loop 3——把东西拿给真实用户，哪怕只有 3 个人

三个循环，缺一不可。大部分人的瓶颈不在写代码，而在循环 2 和 3。

参考链接

1. Andrew Ng, The Batch - Loop Engineering
2. Andrew Ng 推文原文
3. LearnStop 论文: When Does Learning to Stop Help?