一场正在发生的范式转变：Loop Engineering（循环工程）

Anthropic Claude Code 负责人 Boris Cherny 最近说了这样一句话：

开发者工具先驱 Peter Steinberger 也表达过类似观点：

这不仅仅是一句口号。过去两年里，我们与 AI 编程袋里的交互模式是这样的：你写提示 → AI 执行 → 你读结果 → 你再写提示。袋里是工具，你全程掌控它，一轮接一轮。

但眼下，另一种新范式已经越来越清晰了——循环工程（Loop Engineering）。不再是每一轮都靠人手动推进，而是先搭起一个小型系统，让它自己去发现工作、拆分任务、核查结果、记录进度，再判断下一步该怎么走。说白了，重点已经不只是“写提示词”，而是“把提示词放进一套能运转的系统里”。上图其实已经把这两种范式的差异讲得很直白了——

• 左侧旧范式：你作为中央枢纽，手动驱动每一轮交互，带宽消耗大
• 右侧新范式：系统自主循环运行，你的角色转变为"设计循环 + 审查结果"

循环需要什么？六大核心组件

Addy Osmani 提出了一个极简框架："一个循环需要五个东西，再加一个地方记住东西"。这六个组件构成了循环工程的完整基础设施：

下面这张架构图展示了组件之间的协作关系：

左侧三个「基础设施组件」为中央子袋里提供支撑，右侧状态存储实现跨会话记忆。虚线箭头代表反馈闭环——状态文件中的信息会反哺给下一轮自动化触发，形成持续改进的飞轮。

两种关键的循环原语

自动化模块提供了两种核心运行模式：

• /loop：按固定频率重新运行（如每天早上 6 点）
• /goal：持续运行直到你设定的条件为真，每轮运行后由独立的第三方小模型检查是否完成

/goal 的设计哲学很值得玩味——写代码的袋里不负责给自己评分。这种"制衡机制"正是循环能在你不在场时仍然可信的关键。

"袋里会遗忘，仓库不会"

关于状态存储，原文中有一句话让我印象深刻：

袋里每次会话都是"冷启动"的，会遗忘之前的一切。所以循环的进度、尝试记录、审查结果必须持久化到磁盘（Markdown 文件或 Linear 面板）。没有状态存储，循环就像一个每天醒来都失忆的人。

关于技能（Skills）：消除"意图债务"

每次会话一开始，袋里都会先替你把意图里那些没说透的部分补上，然后带着相当笃定的判断继续往下走——这就是所谓的“意图债务”（Intent Debt）。而技能的价值，恰恰在于把这些意图明确写进系统里：比如项目约定、构建步骤，甚至是“这里不能这么做，因为之前出过事故”这类经验，都可以一次性编码下来，让袋里在每次运行时直接读取。没有技能，循环就得一遍遍从零推导项目；有了技能，它才会真正把经验沉淀下来，越用越熟。

一个完整循环的一天

让我们用一个真实场景来串联所有组件。以下是一个生产环境中循环的典型运行流程：

注意中间的并行阶段（06:10）——工作树 A 和工作树 B 同时运行：

• 工作树 A：子袋里负责起草修复代码，读取技能文件遵循项目约定
• 工作树 B：子袋里 B 独立审查代码，不信任子袋里 A 的产出

这就是"实现与验证分离"的核心价值。两个袋里在独立分支上工作，互不干扰。

到了早上 9 点，当你打开电脑时，循环已经完成了大部分工作。你的任务是：

1. 审查已经开好的 PR
2. 处理分类收件箱中循环无法自动完成的复杂事项
3. 更新技能文件，让明天的循环更聪明

工具无关的抽象层

一个关键的洞察：循环的底层结构已经超越了单一工具的边界。无论是 OpenAI 的 Codex 还是 Anthropic 的 Claude Code，六大组件的映射几乎一致：

两者都使用 SKILL.md 和 MCP——为其中一个编写的技能和连接器，通常可以直接在另一个中使用。

循环解决不了的三个问题

循环改变了工作方式，但它不会删除你。Addy Osmani 在文中用了大量的篇幅提醒读者：随着循环变得更强，三个问题反而变得更加尖锐。

1. 验证仍然是你（人类）的责任

无人值守运行的循环也在无人值守地犯错。将验证子袋里与制造子袋里分离，正是为了让循环的"完成了"这句话更有意义——但即便如此，"完成"只是一个声明，不是证明。

2. 理解债务（Comprehension Debt）

循环越快地发布你没有亲手写的代码，"代码库里存在的东西"和"你实际理解的东西"之间的差距就越大。一个顺畅的循环只会让理解债务增长得更快——除非你主动阅读循环产出的每一行代码。

3. 认知投降（Cognitive Surrender）——最危险的陷阱

当循环自动运行，很容易就不再有自己的判断，只是接受它给出的一切。Addy 将这称为认知投降。

这一点尤其值得警惕。两个人可以构建完全相同的循环，但得到完全相反的结果：A 用它在深刻理解的工作上加速，B 用它来完全避免理解工作。循环不知道区别——你知道。

我的思考

在我看来，"循环工程"这篇文章之所以重要，不在于它提出了什么全新的技术——六大组件大多已经在现有产品中存在。它的价值在于提供了一个认知框架，让你从"提示技巧"的思维层面，升级到"系统设计"的思维层面。

几个值得深思的点：

第一，杠杆点在转移。 一年前要构建类似的循环，你需要写一堆 bash 脚本并持续维护。现在这些组件直接内置于产品中。门槛降低意味着更多人会开始尝试，但也会更多人陷入"认知投降"。

第二，工程师的角色不会消失，但会升级。 循环设计比提示工程更难，而不是更容易。你需要同时具备系统思维（设计循环）、领域知识（编写技能）和工程判断力（审查结果）。这不是"按下开始按钮等结果"的工作。

第三，Token 成本是隐形门槛。 文中提到的子袋里模式——每轮都有独立的探索、实现、验证袋里——意味着 Token 消耗可能是传统模式的数倍。这对个人开发者和小团队来说是一个现实约束。

第四，直接提示仍然有效。 不要把循环工程教条化。有些场景下，直接提示袋里反而是最高效的方式。循环工程是工具箱中的一件新工具，不是要替换所有旧工具。

总结

最后，用 Addy Osmani 的那句话作为收尾：

构建循环，但仍然做个工程师。不是像只负责按下"开始"按钮的人，而是像一个打算继续深刻理解代码的人。袋里会遗忘，仓库不会——你设计的循环、编码的技能、写入的状态文件，这些才是跨越时间和会话持久存在的东西。

循环工程不是终点，它是一个工程师在 AI 时代的新起点。