什么是 Loop Engineering？

这两天有句话在 AI 开发圈里传得很猛。

Claude Code 的 Boris Cherny 被转述说：

I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.

翻成人话就是：我已经不再手动 prompt Claude 了。我有一堆 loop 在跑，它们会去 prompt Claude，自己判断下一步该做什么。我的工作是写这些 loop。

很多人看到这句话，第一反应是：好家伙，Prompt Engineering 又过气了？现在要改名 Loop Engineering 了？

先别急着换头像简介。

大多数人以为 Loop Engineering 是“不用再写 prompt，让 AI 自己干”。但真相是：Prompt 没消失，它只是从主角变成了零件。

以前你坐在 Claude 面前，一句一句催它：查一下、改一下、跑一下、再修一下、再验证一下。现在这些动作被写进了一个可以反复运行的系统里。这个系统知道什么时候启动，知道去哪拿上下文，知道能用哪些工具，知道怎么检查结果，也知道什么时候停。

这才叫 loop。

不是你写个 while true，里面塞一句“继续努力”。

那不叫 Loop Engineering，那叫自动烧钱。

先把 Loop Engineering 说清楚

Prompt Engineering 解决的是：这一句话怎么问，模型更容易给出好答案。

Loop Engineering 解决的是：这件事怎么反复做，怎么知道做对了，什么时候该停，出了事谁来接手。

一个真正能跑的 loop，至少有九个东西。

第一，有触发器。什么时候启动？每天早上？CI 挂了？PR 有新评论？还是你手动说“开始”？

第二，有目标。不是“帮我看看”，而是“直到 auth 相关测试全绿，且没有新的 lint 错误”。

第三，有上下文获取。它要读哪些文件、哪些日志、哪些 issue、哪些文档？没有上下文，agent 就是在黑屋里挥刀。

第四，有工具权限。它只能读？能改文件？能跑命令？能开 PR？能发 Slack？权限边界不清，loop 越强越危险。

第五，有执行者。谁负责推进？一个 coding agent，还是多个 subagents 分工？

第六，有检查者。谁判断它做得对不对？测试？独立 reviewer agent？静态分析？浏览器自动化？别让写代码的 agent 自己给自己打满分，人类都不该这么干，AI 更不该。

第七，有状态记录。它今天试了什么，失败了什么，明天从哪里继续？没有状态文件的 loop，本质是每天失忆。

第八，有停止条件。什么时候算完？什么时候应该停？什么时候预算超了必须退出？

第九，有人工接管点。需求不清、权限不足、风险变大、结果互相矛盾，这些时候必须喊人。

你看，Loop Engineering 根本不是“更高级的 prompt 技巧”。

它更像是给 AI 工人搭一条小型生产线：进料、加工、质检、记录、返工、停机，全都要设计。

为什么 Boris 会说“我不 prompt Claude 了”？

这句话最容易被误读。

他说“不 prompt”，不是说自然语言不重要了。恰恰相反，loop 里到处都是 prompt。

只不过这些 prompt 不再靠你一轮一轮手动输入，而是被封装进命令、skill、hook、workflow、schedule 里。

以前你是人肉调度器。

你看 CI 挂了，复制日志，贴给 Claude。Claude 改了，你跑测试。测试又挂，你再贴错误。它又改，你再看 diff。最后你说，行了，提交。

这个过程里，Claude 只是在干活。

你在当胶水。

Loop Engineering 的变化是：把“胶水”写出来。

比如一个 PR babysitter loop 可以这样跑：

PR 一创建，loop 读取 diff、CI log、review comments 和项目规则。如果 CI 红了，它先定位失败原因，只做最小修复，然后跑相关测试。修完以后，另一个 reviewer agent 从安全、回归、可维护性角度审一遍。CI 绿了、评论清空了、没有新失败，它就停。遇到权限问题、需求争议、改动超过风险阈值，它就喊你。

这时候你确实没有每一步都 prompt Claude。

但你写了一个会替你 prompt Claude 的系统。

说白了，Prompt Engineering 是你会不会说话。Loop Engineering 是你会不会带队。

这不是玄学，产品已经长出来了

如果这只是社区发明的新词，那可以先放一边。

但问题是，工具已经在朝这个方向长。

Claude Code 官方文档里有 /loop。它可以在当前 session 里按间隔重复跑一个 prompt，用来轮询部署、照看 PR、检查长任务。你可以写 /loop 5m check if the deployment finished，也可以让 Claude 自己决定下一次什么时候检查。

还有 /goal。你给它一个完成条件，它会跨 turn 继续工作，直到一个小模型判断这个条件已经满足。注意这个设计很关键：干活的是一个模型，判断是否完成的是另一个模型。写作业的人不自己给自己判卷。

还有 hooks。比如 Stop hook 可以在 Claude 准备停下来的时候触发，检查它是不是漏了测试、是不是还有错误、是不是还需要继续。

再往上，是 Dynamic Workflows。Claude 可以为一个复杂任务写 workflow script，在隔离 runtime 里调度多个 subagents。中间结果不会全塞回主对话上下文，而是存在脚本变量里。这个东西已经不太像聊天了，更像一个临时工程调度器。

OpenAI 也把 Codex 的 agent loop 拆开讲过。agent 的底层循环其实很朴素：模型读 prompt，决定要不要调用工具，工具结果再回到上下文里，模型继续判断，直到它输出最终消息。

所以你要分清两层。

第一层，是 agent 自己内部的 loop：推理、工具调用、观察、再推理。

第二层，是你设计的工作 loop：什么时候让 agent 开始，怎么给它上下文，怎么限制权限，怎么复核，怎么记录状态，怎么停。

现在真正值钱的是第二层。

代码正在变便宜，判断正在变贵

为什么这个转向这么重要？

因为 AI coding 的瓶颈正在移动。

Anthropic 在《When AI builds itself》里提到，2026 年 5 月，Anthropic 合入代码中超过 80% 可归因于 Claude。典型工程师每天合入代码量大约是 2024 年的 8 倍。

这个数字你可以怀疑，可以打折，毕竟代码行数不是质量。

但方向很清楚：写代码这件事，正在变便宜。

真正变贵的是判断。

这个需求要不要做？这个错误是不是根因？这个测试绿了能不能代表没问题？这个 PR 看起来能跑，但三个月以后会不会把项目拖进泥坑？这个 agent 说它完成了，你信不信？

以前一个开发者的价值，很大一部分体现在“我能把代码写出来”。

现在这部分价值被模型疯狂挤压。

但另一些价值变得更重要：定义目标、拆任务、给边界、设计反馈、判断风险、验收结果。

你以为 AI 抢的是键盘，真相是它在逼你往上挪一层。

挪不上去的人，就会变成最尴尬的角色：代码不是你写的，系统你也不理解，出事还得你背锅。

这才是最扎心的地方。

一个好 loop 长什么样？

拿一个最普通的场景：每天早上检查项目健康度。

低级做法是写个定时 prompt：

“每天早上帮我检查项目有没有问题。”

听起来不错，实际很容易变成废话生成器。它每天扫一遍，说一些“建议优化测试覆盖率”“建议关注技术债”的正确废话。你看两天就烦了。

高级一点的 loop 会这样设计：

触发器：每天早上 9 点。

上下文：读取昨天的 commits、CI 失败记录、线上 error logs、未解决的 issue、最近合并的 PR。

规则：只读，不改文件；每个发现必须绑定证据；没有证据就不输出。

执行：把问题分成 bug risk、test gap、dependency risk、cleanup candidate。

检查：另一个 agent 反驳每个发现，问三个问题：证据够不够？是不是重复？是不是值得人类今天处理？

状态：把确认过的问题写入 triage.md，带上第一次发现时间、最近一次复现方式、建议 owner。

停止：如果没有高价值发现，只输出一行摘要，不要写小作文。

人工接管：凡是涉及架构方向、线上风险、用户数据、不可逆操作，一律只提建议，不执行。

这才是 loop。

它不是让 AI 更会“说”，而是让 AI 在一个有边界的轨道上持续“做”。

Loop Engineering 的三个坑

第一个坑：没有停止条件。

很多人一听 loop 就兴奋，恨不得让 agent 一直跑。问题是，模型并不知道你的钱包在哪。它会很认真地跑偏，很认真地重试，很认真地把 token 烧成烟花。

一个没有预算上限、没有失败上限、没有停止条件的 loop，不是自动化，是事故预备役。

第二个坑：没有独立验证。

Claude 说“我已经完成了”，这句话不能当验收。

人都会高估自己刚写完的代码，模型更会。尤其是 agent 一路改下来，它的上下文里全是“我为什么这么做”的理由，它天然会替自己的路径辩护。

所以 maker 和 checker 必须分开。写的人负责写，查的人负责查。能用测试就用测试，能用浏览器断言就用浏览器断言，能用静态分析就用静态分析。LLM judge 可以用，但别把它当神谕。

第三个坑：理解债。

这也是最阴的坑。

loop 跑得越顺，你越容易不看。PR 自动开了，CI 自动修了，评论自动回了，文档自动改了。你一开始觉得爽，过一个月发现：项目每个地方都变了，但你不知道为什么。

这叫 comprehension debt。

技术债至少还在代码里，理解债在你脑子外面。它不报错，但它会让你在关键时刻失去判断力。

说白了，loop 可以替你干活，但不能替你理解。

你要是把理解也外包出去，那不是工程进化，那是认知投降。

普通开发者现在该怎么做？

别上来就搞全自动。

真的，别。

如果你现在还在学 Claude Code、Codex、Cursor，不要第一天就幻想“我写个 loop，睡一觉醒来产品上线”。

先从最无聊、最重复、最可验证的任务开始。

比如：

• 每天扫描 CI 失败，生成原因和建议，不自动改。
• 每次 PR 后检查有没有漏测试，不自动提交。
• 每周扫描依赖升级风险，输出清单。
• 每次大改前，让 reviewer agent 反驳方案。
• 每次内容发布前，跑事实核验和风格检查。

第一阶段，只读不改。

第二阶段，小范围改。

第三阶段，才考虑自动开 PR。

这不是保守，这是工程常识。工具越强，越要先画边界。

你要练的不是“怎么让 AI 更听话”，而是“怎么让 AI 在你不盯着的时候也不乱来”。

最后说句扎心的

Loop Engineering 听起来很高级，但它不会自动让你变高级。

同一个 loop，放在两个人手里，结果可能完全相反。

一个人用它把重复劳动抽出去，把验证补上，把状态沉淀下来，让自己有时间思考更重要的问题。

另一个人用它逃避思考：需求不想清楚，边界不写明，验证不设计，出了结果也不看。最后他不是被 AI 替代，是先被自己的懒替代。

这就是 Boris 那句话真正刺人的地方。

“My job is to write loops”不是说工作变简单了。

它是在说，杠杆点变了。

以前你值钱，是因为你能亲手把代码写出来。

以后你值钱，是因为你能设计一个系统，让代码、检查、反馈、修复、记录持续发生，而且你还能判断这个系统什么时候对，什么时候错，什么时候该停。

Prompt 不是没用了。

只是单次 prompt 的时代正在过去。

真正的新工作，是把你的工程判断写进 loop 里。

你不会写 loop，就只能继续当人肉按钮。

你会写 loop，才开始像一个真正指挥 AI 工程队的人。

参考来源

• Addy Osmani: Loop Engineering：https://addyosmani.com/blog/loop-engineering/
• Claude Code Docs: Commands / /loop / /goal / Dynamic Workflows：https://code.claude.com/docs/en/commands
• OpenAI: Unrolling the Codex agent loop：https://openai.com/index/unrolling-the-codex-agent-loop/
• Anthropic: Building Effective Agents：https://www.anthropic.com/engineering/building-effective-agents
• Anthropic: When AI builds itself：https://www.anthropic.com/institute/recursive-self-improvement