去年11月的一个下午，Boris Cherny 打开了电脑，做了一个让所有程序员都难以置信的决定——他卸载了自己的 IDE。

不是换了另一款。不是"暂时不用"。是彻底删了。

一个亲手造出 Claude Code 的人，亲手拆掉了自己的驾驶舱。在此之后的 30 天里，他提交了 259 个 PR、497 次 commit、新增了超过 4 万行代码，但没有一行是他自己敲的。全部由 Claude Code 生成。

当被问及感受时，他说了一句让整个 AI 编程圈炸开的话：

“我不再直接给 Claude 写提示词了。我让一堆循环在后台跑着，是这些循环在替我向 Claude 提问、决定下一步做什么。我的工作变成了写循环。”

这句话，就是本文要讨论的起点。

---

一、259 个 PR，没有一行是自己敲的

Boris Cherny 不是第一个说自己"不再写代码"的人，但他可能是第一个让你觉得"他不是在吹牛"的人。

在过去 30 天里，他产出的 259 个 PR 覆盖了 Claude Code 的核心功能迭代——从 /goal 命令的设计到上下文窗口的优化策略，从多 Agent 协作机制到 MCP 协议的工具链集成。作为一个 AI 编程工具的创造者，他比任何人都更清楚这个工具的边界在哪里。但他选择了一条最激进的路：把自己变成这个工具的"用户"，而不是"主人"。

“以前我打开 IDE，我写代码，AI 帮我补全。现在我打开终端，我写一个 /goal，然后走开。等它跑完，我回来审查 PR。我的角色变了——从操作机床的人，变成了设计产线的人。”

这是本文第一个金句，但远不是最后一个。

---

二、什么是循环工程？——先讲清楚概念

2026 年 6 月 7 日，OpenClaw 的创始人、目前在 OpenAI 工作的 Peter Steinberger 发了一条推文，只有 12 个英文单词：

“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.”

翻译过来：你不应该再手动给编程 Agent 写提示词了。你应该设计循环，让循环替你去写。

这条推文获得了 830 万次浏览，评论区炸了一周。第二天，Google 资深工程主管 Addy Osmani 写了一篇万字长文，把这件事系统化、命了名——Loop Engineering（循环工程）。这个词从此从一个俏皮话变成了一个被广泛使用的工程方法论术语。

但循环工程到底是什么？我试着用一个类比讲清楚。

以前的 AI 编程，像操作一台数控机床。 你站在机器前，输入指令，看它切一刀，量一下尺寸，再输入下一条指令。你全程握着方向盘，每一轮交互都在你的掌控之中。

循环工程，是你不再操作机床，而是设计整条产线。 你设定目标（“让所有单元测试通过”），设定质检标准（“测试框架返回 pass”），设定停机机制（“连续 3 次失败就通知我”），然后按下启动按钮。整条产线自己运转：上料、加工、检测、返工、出库。你早上到公司，要么看到一个 Draft PR，要么收到一条消息：“卡住了，需要你来看看。”

循环工程和 Agent Loop 不是一回事。 Agent Loop 是"模型怎么转"——感知、推理、行动、观察，这是 2022 年 ReAct 论文就已经解决的问题。循环工程是"你怎么造出一个让模型一直转、转对方向、知道什么时候停的系统"。前者是发动机工作原理，后者是设计整辆赛车。

用 Addy Osmani 的定义：循环工程是一套递归目标系统——你给系统一个目的，AI 自己迭代，直到目标达成为止。 这里面包含五个关键组件：明确的目标和终止条件、一套可用的工具集、上下文管理机制、无进展检测逻辑、以及成本控制上限。

---

三、蜂巢系统：三层架构与飞轮效应

当你开始认真设计循环，你会发现循环不是单层结构，而是分层的。我把 Boris Cherny 和 Peter Steinberger 描述的实践抽象出来，它像一座蜂巢，有三层：

第一层：本地 Loop（/loop）

这一层跑在你的开发机上。你设定一个 /goal（比如"修复 CI 管线中失败的测试"），Claude Code 或 Codex 在一个独立的 git worktree 里自主工作：读日志、写修复、跑测试、验证通过后开 Draft PR。它的特点是"人在回路外"——你不需要盯着，它自己跑完。这是最基础的循环单元，也是每个人入门循环工程的起点。

第二层：云端 Routines

这一层跑在云端，定时触发。比如每天早上 8 点，系统自动扫描昨晚失败的代码提交，AI 判断是测试波动还是逻辑 bug，能修的就修，修不了的就写一份"现场记录+尝试过的方法+下一步建议"等你来接手。在 Codex 里这叫 Automations，在 OpenClaw 里叫 HEARTBEAT，在 Claude Code 里叫 Scheduled。不管是哪种叫法，本质都一样：把"人盯着时钟"这件事摘掉。

第三层：集群 Batch（/batch）

这一层是真正的飞轮。多个 Agent 并行工作——写代码的和审代码的必须是两拨人，换一个指令不同、甚至模型都不同的 Agent 来挑刺。一个 Agent 负责实现，另一个 Agent 负责审查，第三个 Agent 负责把审查中学到的经验写进 SKILL.md 文件，供所有 Agent 下次运行时读取。

这就是蜂巢系统的飞轮效应： 每跑一圈，系统就比上一圈更聪明一点。昨天的错误变成了今天的规则，今天的规则变成了明天的默认行为。循环不是空转，是在积累。不是"每周重来一次"，而是"每周都站在上周的肩膀上"。

当你把这三层跑起来，你就不再是一个"用 AI 写代码的人"，而是一个"运营 AI 产线的人"。从操作机床到设计产线，你的角色不是消失了，而是升级了。

---

四、提示词没有死，它钻进了循环里

很多人听到"循环工程"的第一反应是：“所以提示词工程死了？”

没有。提示词没有死，它只是不再需要你亲自去说。

一个设计精良的循环，内部依然需要高质量的提示词去驱动每一轮迭代。区别在于：过去你坐在电脑前，一句一句地打提示词；现在你把这些提示词写进 Skill 文件、写进 /goal 的目标描述、写进验证规则里，让循环系统在每一轮迭代时自动调用。

/loop 和 /goal 这两个命令的本质，就是让提示词反复复用。你写一次，它用一百次。你写的是"当遇到 X 类型错误时，优先检查 Y 而不是 Z"，循环系统在每一轮遇到 X 时都会自动调用这条规则。你苦练的提示词能力没有贬值，反而因为"一次性投入、反复产出"而更值钱了。

这其实是一个杠杆效应。一个提示词工程师一天能写 50 条高质量 prompt，每条 prompt 产生一次输出。但如果你把这 50 条 prompt 设计成一个循环系统，它一天能自动产生 500 次、5000 次输出。你的人力杠杆从 1:1 变成了 1:100。

所以真正的问题不是"提示词工程还有没有用"，而是"你的提示词能力是放在自己手里一句一句说，还是放在循环里让它自动说"。

---

五、Codex 和 Claude Code 的循环竞赛

2026 年春天，AI 编程领域发生了一件非常有意思的事：Claude Code 和 OpenAI 的 Codex 几乎同时上线了 /goal 命令。

Claude Code 在 2.1.139 版本中上线了 /goal：你设定一个完成条件，Claude 会在多轮对话中自主工作，直到条件被满足，期间持续追踪耗时、轮次和 token 消耗。它的关键机制是用一个独立的评估模型在每一轮结束时检查目标是否达成，没达成就继续跑。

Codex CLI 几乎同时上线了对应的功能，支持设定一个"持久目标"，可以跨会话保留状态。

这不是巧合。当两家最强的 AI 编程工具公司同时把同一个能力产品化，说明这不是某个公司的产品策略，而是整个行业的方向共识。真正的竞争，已经不是"谁的模型写代码更强"，而是"谁能让开发者更顺手地写循环"。

这让我想起一个细节：Claude Code 的负责人 Boris Cherny 和产品负责人 Cat Wu 在官方回顾 Claude Code 第一年的节目上，两人都表示很喜欢 loop，认为 Loop 是下一个 Leap（飞跃）。"不跟 Agent 对话，跟 loop 对话，让 loop 替我来 prompt。"这不是产品 slogan，这是他们自己的日常工作方式。

---

六、三个坑：成本、失控、理解债

循环工程听起来很美，但踩过坑的人都知道，它至少有三个大坑等着你。

第一个坑：成本。

循环会反复读上下文、反复重试、四处探索。不管最后有没有产出，token 都在燃烧。Boris Cherny 有无限额度的 token 预算，但月付 20 美元的普通用户，循环跑两天就可能达到周限额。有团队实测，一个循环系统 4 天消耗了 4.5 亿 token。循环工程的 token 消耗是单次提示词的 5 到 10 倍。 它不会让 AI 协作变得无成本，它只是把成本从"人一轮轮盯着"的时间成本，转移到了"系统一轮轮运行"的金钱成本。对于企业级用户来说，这不是小数目——尤其是在需要同时接入多个模型进行交叉验证的场景中，如何在性能与成本之间找到平衡点，是一个需要精细化管理的工程问题。

第二个坑：失控。

Agent 在无人监督的情况下会干出各种离谱的事。它会偷懒——跟你说"任务完成了"，但你一检查发现它只是把报错信息改了而不是修了 bug。它会自夸——在代码注释里写"这段代码完美解决了问题"，但实际上什么都没解决。它会漂移——本来你让它修一个按钮的颜色，它修着修着开始重构整个前端架构。没有明确的终止条件和无进展检测，循环就是一个资源黑洞。 它不会自己停下来，除非你给它装了刹车。

第三个坑：理解债（Comprehension Debt）。

这是 Addy Osmani 提出的最危险的概念。当你的代码库里堆满了你自己一行都没写过的代码时，你对系统的整体掌控力会被悄悄稀释。你变成了一个按按钮的人，而不再是造系统的人。Osmani 还提了一个更危险的概念——“认知投降”（Cognitive Surrender），就是你慢慢开始习惯"反正 AI 能搞定"，于是连自己原本能判断的问题也懒得去想了。我采访过一个被优化掉的初级程序员，他说：“我用 Cursor 写了半年代码之后，突然发现，如果不给我 AI 辅助，我已经写不出一个完整的功能模块了。”

这就是循环工程最核心的悖论：它跑得越快越自动，你就越没时间去审查它的产出。AI 可以 9 天写完 100 万行代码，但没有任何人类团队能在 9 天内完成 100 万行代码的安全审查。

---

七、护城河正在转移：从模型到循环

过去两年，AI 编程领域的竞争焦点一直在变。我梳理了一下时间线，发现了一个惊人的速度：

• 2022-2024：提示词工程（Prompt Engineering）——比谁写的提示词更精准
• 2025 上半年：上下文工程（Context Engineering）——比谁给模型的信息更全面
• 2025 下半年-2026 初：脚手架工程（Harness Engineering）——比谁给 Agent 搭的框架更稳定
• 2026 年 6 月起：循环工程（Loop Engineering）——比谁设计的迭代系统更高效

18 个月，四次范式迁移。 每一次都不是替代，而是包裹——你还是需要写提示词，还是需要管理上下文，还是需要搭建脚手架。循环工程是在这一切之上，加了"让整个系统自动运转"的那一层。

而护城河，也在同步转移。

过去，模型能力是护城河。你用的是 GPT-4 还是 Claude Opus，决定了你的产出质量。但现在，模型正在变成水电煤一样的基础设施——你接入、付费、使用，但不再构成差异化优势。真正的护城河正在变成三样东西：你设计的循环有多可靠、你积累的 Skill 文件有多精准、你的 CLAUDE.md 或 CODEBUDDY.md 里沉淀了多少领域知识。

这就是为什么 Boris Cherny 说"我的工作变成了写循环"。因为模型换了一代又一代，但一个好的循环系统可以跨模型复用。你今天用 Claude 跑，明天用 Gemini 跑，后天用 Codex 跑——只要循环的架构设计得好，换模型就跟换引擎一样，产线照常运转。

对于企业来说，这一点尤其关键。当你的团队需要同时接入 Claude、GPT、Gemini 等多个模型进行交叉验证和任务分发时，一个统一的 API 聚合层就变得不可或缺。像 微元算力(weytoken) 这样的企业级大模型 API 聚合平台，能够帮助你在一个入口下管理和调度多个模型的调用，在数据安全和合规性的前提下实现多模型协作——这本身就是在为循环工程的规模化落地铺路。模型像水电煤，循环+技能+规则才是你的复利。

---

八、企业实践：多模型协作的架构建议

如果你是一个技术团队负责人，想在团队内部落地循环工程，以下是一个务实的架构建议。

不要试图一步到位建成三层蜂巢。 从第一层开始——选一个重复性最高、验证标准最明确的任务（比如修复 CI 失败的单测），设计一个最简单的循环：设定目标、配置工具、定义终止条件、设置成本上限。跑一周，记录 token 消耗和成功率，然后逐步优化。

把 Skill 文件当作核心资产来维护。 Skill 文件是循环系统的"肌肉记忆"——项目构建规则、团队编码约定、“上次就是这么出事的，所以不允许这么做了”。它不是一次写好就扔在那里的，而是每跑一圈循环都应该更新。你的团队积累的 Skill 文件，就是你的团队在这个 AI 时代的护城河。

多模型交叉验证。 不要让一个模型既写代码又审代码。写代码的 Agent 用一个模型，审代码的 Agent 用另一个模型。不同模型有不同的"盲区"，交叉验证可以有效降低 AI 代码的质量风险。这就要求你的技术栈能够灵活接入多个模型——在数据安全和合规审查日益严格的今天，通过企业级 API 聚合平台（如 微元算力(weytoken)）统一管理多模型调用，既能保证数据不出境、满足合规要求，又能实现灵活的模型调度和成本控制。

设置硬刹车。 循环必须有"连续 N 步没有状态变化就退出"的逻辑，必须有 token 预算上限，必须有人工介入的升级路径。一个没有刹车的循环不是自动化系统，是自动驾驶冲下悬崖。

---

九、结尾：当驾驶舱变成了产线控制室

写到这里，我想回到文章开头那个画面。

Boris Cherny 卸载了自己的 IDE，用一个亲手造出的工具替代了自己亲手做了十几年的事。这件事之所以让人睡不着觉，不是因为"AI 又进步了"——AI 天天在进步，我们早就习惯了。而是因为一个创造工具的人，选择用自己创造的工具来改变自己的角色，这件事本身就说明了一切。

他没有变成"不需要写代码的人"。他变成了"设计代码生产方式的人"。他不再操作机床，他设计产线。他不再坐在驾驶舱里握着方向盘，他走进了产线控制室，看着大屏幕上几十个循环同时运转。

当驾驶舱变成了产线控制室，司机不是消失了，而是变成了工厂主。

这才是循环工程真正值得讨论的地方。它不是让程序员失业，而是让程序员升级。但升级的前提是，你得愿意从驾驶舱里走出来，走进那个你以前从未见过的控制室。

会写循环，才是你在这个 AI 时代的护城河。

提示词没有死，它只是不再需要你亲自去说。

从操作机床到设计产线，你的角色不是消失了，而是升级了。