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

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

这不仅仅是一句口号。

过去两年里，我们与 AI 编程袋里的交互模式大致是这样的：你写提示 → AI 执行 → 你读结果 → 你再写提示。

袋里是工具，你全程掌控它，一轮接一轮。

但眼下，另一种新范式已经越来越清晰了——循环工程（Loop Engineering）。

它不再依赖人手动推进每一轮，而是先搭起一个小型系统，让它自己去发现工作、拆分任务、核查结果、记录进度，再判断下一步该怎么走。

说白了，重点已经不只是“写提示词”，而是“把提示词放进一套能运转的系统里”。

上图已经把这两种范式的差异讲得很直白了：

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

循环工程的核心变化

核心变化只有一个：从“人工逐轮驱动”，转向“系统自主循环”。

在这个过程中，人的角色并没有消失，而是发生了转移。

• 过去：你负责推进每一步
• 现在：你负责设计机制、设定边界、审查产出

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

Addy Osmani 提出了一个极简框架："一个循环需要五个东西，再加一个地方记住东西"。

这六个组件构成了循环工程的完整基础设施：

组件	在循环中的角色	如果缺失会怎样
自动化（Automations）	定时触发，发现和分类任务	循环不会启动，一切需要手动
工作树（Worktrees）	隔离并行功能，避免冲突	多个袋里互相覆盖代码
技能（Skills）	固化项目知识，每次运行读取	每次从零推导项目约定
插件/连接器（Plugins）	连接 GitHub、Linear、Slack 等真实工具	循环只能告诉你该做什么，不能替你做
子袋里（Sub-agents）	实现与验证分离	写代码的人自己审查自己的代码
状态存储（State）	跨会话记忆进度	每天重新开始，重复已完成的工作

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

左侧三个「基础设施组件」为中央子袋里提供支撑，右侧状态存储实现跨会话记忆。

虚线箭头代表反馈闭环。状态文件中的信息会反哺给下一轮自动化触发，形成持续改进的飞轮。

六大组件分别解决什么问题

• 自动化（Automations）：让循环能够自己启动，而不是等你手动触发
• 工作树（Worktrees）：让多个任务并行执行，同时避免代码互相污染
• 技能（Skills）：把项目经验和约定写下来，避免每次从头推导
• 插件/连接器（Plugins）：把循环接入真实工作流，而不只是停留在建议层面
• 子袋里（Sub-agents）：让实现和验证分离，降低自我审查失真
• 状态存储（State）：让系统跨会话持续记住已经做过什么

两种关键的循环原语

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

• /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，六大组件的映射几乎一致：

组件	Codex（OpenAI）	Claude Code（Anthropic）
自动化	Automations 选项卡、/goal	cron 定时、/loop、/goal、hooks
工作树	内置每线程工作树	git worktree、--worktree 标志
技能	Agent Skills（SKILL.md）	Agent Skills（SKILL.md）
插件	Connectors（MCP）+ 插件分发	MCP 服务器 + 插件
子袋里	TOML 定义在 .codex/agents/	定义在 .claude/agents/
状态	Markdown 或 Linear	Markdown（AGENTS.md）或 Linear

两者都使用 SKILL.md 和 MCP。

为其中一个编写的技能和连接器，通常可以直接在另一个中使用。

循环解决不了的三个问题

循环改变了工作方式，但它不会删除你。

Addy Osmani 在文中用了大量的篇幅提醒读者：随着循环变得更强，三个问题反而变得更加尖锐。

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

无人值守运行的循环，也在无人值守地犯错。

将验证子袋里与制造子袋里分离，正是为了让循环的"完成了"这句话更有意义。

但即便如此，"完成"只是一个声明，不是证明。

2. 理解债务（Comprehension Debt）

循环越快地发布你没有亲手写的代码，"代码库里存在的东西"和"你实际理解的东西"之间的差距就越大。

一个顺畅的循环，只会让理解债务增长得更快。

除非你主动阅读循环产出的每一行代码。

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

当循环自动运行，很容易就不再有自己的判断，只是接受它给出的一切。

Addy 将这称为认知投降。

这一点尤其值得警惕。

两个人可以构建完全相同的循环，但得到完全相反的结果：

• A 用它在深刻理解的工作上加速
• B 用它来完全避免理解工作

循环不知道区别——你知道。

我的思考

在我看来，"循环工程"这篇文章之所以重要，不在于它提出了什么全新的技术。

六大组件大多已经在现有产品中存在。

它的价值在于提供了一个认知框架，让你从"提示技巧"的思维层面，升级到"系统设计"的思维层面。

几个值得深思的点：

第一，杠杆点在转移

一年前要构建类似的循环，你需要写一堆 bash 脚本并持续维护。

现在这些组件直接内置于产品中。

门槛降低意味着更多人会开始尝试，但也会更多人陷入"认知投降"。

第二，工程师的角色不会消失，但会升级

循环设计比提示工程更难，而不是更容易。

你需要同时具备：

• 系统思维（设计循环）
• 领域知识（编写技能）
• 工程判断力（审查结果）

这不是"按下开始按钮等结果"的工作。

第三，Token 成本是隐形门槛

文中提到的子袋里模式——每轮都有独立的探索、实现、验证袋里——意味着 Token 消耗可能是传统模式的数倍。

这对个人开发者和小团队来说是一个现实约束。

第四，直接提示仍然有效

不要把循环工程教条化。

有些场景下，直接提示袋里反而是最高效的方式。

循环工程是工具箱中的一件新工具，不是要替换所有旧工具。

总结

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

构建循环，但仍然做个工程师。

不是像只负责按下"开始"按钮的人，而是像一个打算继续深刻理解代码的人。

袋里会遗忘，仓库不会——你设计的循环、编码的技能、写入的状态文件，这些才是跨越时间和会话持久存在的东西。

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