夜雨聆风别再只学提示词了：AI 编程正在进入「循环工程」
过去两年，很多人学习 AI 编程的方式，基本停留在一个动作上：
写一个更好的 prompt。
你告诉 AI：“帮我看这个仓库”“修这个 bug”“补一组测试”“解释这段代码”。它返回结果，你再继续追问、纠正、补充上下文。
这当然有效。
但这个模式有一个上限：你始终是那个不断发号施令的人。
你发现任务，你拆解任务，你判断结果，你决定下一步。AI 只是被你一轮一轮推动的工具。
而现在，一个更值得关注的变化正在出现：
真正有价值的能力，正在从“会不会写提示词”，转向“会不会设计一个能持续运行的工作循环”。
这就是最近 Addy Osmani 提到的 Loop Engineering，可以翻译成「循环工程」。
它不是一个新工具，而是一种新的工作方式。
什么是循环工程？
循环工程的核心很简单：
不再由人反复提示 AI，而是设计一个小系统，让这个系统去提示 AI、检查 AI、记录状态，并决定下一步。
也就是说，人从“每一步都亲自操作”，变成“设计这套运行机制”。
举个普通开发场景。
以前的做法是：
1. 你打开项目。 2. 你找昨天失败的测试。 3. 你把错误贴给 AI。 4. AI 改代码。 5. 你跑测试。 6. 失败后再继续问。
循环工程的做法是：
1. 每天早上自动扫描 CI、issue、最近提交。 2. 把值得处理的问题写入一个 triage 文件。 3. 对每个问题开独立 worktree。 4. 一个 agent 尝试修复。 5. 另一个 agent 负责审查。 6. 测试通过后记录结果。 7. 未解决的问题留到下一轮继续处理。
你仍然负责判断重要问题，但你不需要再亲自推动每一个机械步骤。
这就是关键差别。
提示词工程关注“这一次怎么问”。
循环工程关注“这个系统如何反复发现问题、处理问题、验证问题”。
一个可靠循环需要六个部件
Addy 的文章里提到，Codex 和 Claude Code 这类工具已经逐渐具备类似的基础能力。具体名字可能不同，但能力结构接近。
一个可用的循环，通常需要六个部件。
1. 自动化：让任务自己浮上来
循环的第一步，不是执行，而是发现。
很多工作并不需要你每天手动检查。
比如：
• 昨天 CI 哪些失败了？ • 最近有哪些 issue 没人处理？ • 哪些 PR 卡在 review？ • 哪个模块最近被频繁修改但缺少测试？ • 哪些日志里出现了新的错误模式？
这些都适合交给自动化。
自动化的价值，不是让 AI 随便乱跑，而是把“值得人注意的工作”筛出来。
好的自动化应该有两个结果：
• 有价值的问题进入收件箱。 • 没有发现的问题自动归档。
这样人看到的不是一堆噪音，而是一批需要判断的候选任务。
2. Worktree：让并行不变成混乱
只要多个 agent 同时改一个仓库，冲突就会出现。
这和多个工程师同时改同一个文件没有区别。
所以循环工程里，隔离环境很重要。
Git worktree 的价值就在这里：每个 agent 在自己的独立目录、独立分支上工作。它们共享同一个仓库历史，但不会互相覆盖文件。
这件事听起来不性感，但很关键。
因为一旦并行执行变成文件互相踩踏，整个循环就会失去可信度。
并行不是让更多 agent 一起冲进去。
并行是先设计好隔离边界，再让它们工作。
3. Skills：把项目知识写成可复用说明
很多 AI 编程失败，并不是模型不会写代码。
而是它每次都像第一次进入项目。
它不知道：
• 项目怎么启动。 • 哪些目录不能动。 • 测试命令是什么。 • 哪些设计决策不能轻易改。 • 过去踩过哪些坑。 • 什么样的输出才算合格。
如果这些信息只存在人的脑子里，每一轮对话都要重新解释。
这就是意图债。
Skill 的作用，是把这些项目约定写下来，让 agent 每次执行任务时能读取同一套规则。
它不是为了让提示词变长，而是为了减少重复解释。
对长期循环来说，Skill 是复利资产。
没有 Skill，循环每次都重新猜。
有了 Skill，循环每次都站在上一轮经验之上。
4. Connector：让循环接触真实工具
只会读本地文件的循环，能力是有限的。
真正的工作往往分散在很多地方：
• GitHub • Linear 或 Jira • 数据库 • Slack • 内部 API • 文档系统 • 监控平台
Connector 的意义，是让 agent 能安全地读取和调用这些工具。
这一步会把 AI 从“代码助手”推进到“工作流节点”。
它不只是告诉你应该怎么做，而是可以在合适权限下：
• 读取 issue。 • 更新任务状态。 • 生成 PR。 • 查询接口。 • 写入日报。 • 把结果发到指定渠道。
当然，权限边界必须清楚。
能读什么、能写什么、哪些动作必须人工确认，都应该明确设计。
循环工程不是让 AI 获得无限权限，而是让它在可控边界内完成可重复动作。
5. Sub-agent：让执行者不要审判自己
一个常见问题是：
写代码的 agent，很容易相信自己写得没问题。
这不是道德问题，而是结构问题。
如果同一个模型既负责实现，又负责判断实现是否合格，它天然容易放过自己的错误。
所以，一个更稳的循环，应该拆分角色：
• 一个 agent 负责探索和实现。 • 一个 agent 负责审查和验证。 • 必要时再有一个 agent 负责安全、性能或文档检查。
这类似工程团队里的 maker 和 reviewer 分离。
在自动化循环里，这个分离更重要。
因为循环可能在人不盯着的情况下运行。你需要一个独立的检查环节，减少“看起来完成了”的假完成。
但这里也有成本。
Sub-agent 会消耗更多 token 和时间。所以它不应该滥用。
适合用在：
• 涉及生产风险的修改。 • 大范围重构。 • 安全相关代码。 • 用户可见行为。 • 需要严格验收标准的任务。
6. Memory：让循环记得自己做过什么
长期运行的循环，必须有外部记忆。
原因很简单：单次对话会结束，模型上下文会丢失，自动化任务会分多次运行。
如果没有外部记忆，下一轮循环不知道上一轮：
• 试过什么。 • 哪些失败了。 • 哪些通过了。 • 哪些问题需要继续。 • 哪些决策已经定了。
这个记忆不一定复杂。
可以是一个 Markdown 文件，可以是一个任务看板，也可以是一个数据库表。
关键是它必须在单次对话之外存在。
对循环来说，memory 是脊柱。
没有它，每一轮都像失忆。
有了它，循环才能接着上一次往前走。
一个最小可用循环长什么样？
把上面的部件组合起来，一个很实用的最小循环可以这样设计：
每天早上，一个自动化任务运行。
它调用项目的 triage skill，读取昨天的 CI 失败、open issue、最近提交和错误日志。
然后，它把候选问题写入一个 triage.md 文件。
对每个值得处理的问题，它新建一个独立 worktree。
一个 agent 尝试修复。
另一个 agent 根据项目 skill、测试结果和验收标准做 review。
如果通过，就生成 PR 或写入变更记录。
如果失败，就把失败原因写回 triage.md，下一轮继续。
这个循环并不神秘。
它只是把开发者每天重复做的动作，拆成一套可执行系统。
重点不是“AI 自动写了多少代码”。
重点是：任务发现、执行、验证、记录、下一步，这五个环节是否闭合。
闭合之后，AI 才不是一次性助手，而是一个可持续运行的工作流。
循环工程不会取消工程师
这里必须说清楚一件事。
循环工程不是让工程师消失。
它只是把工程师的工作重心往上抬了一层。
以前你主要做的是：
• 亲自写代码。 • 亲自复制错误。 • 亲自跑命令。 • 亲自整理上下文。
以后你更多要做的是：
• 定义什么问题值得处理。 • 设计循环如何运行。 • 明确验收标准。 • 设置权限边界。 • 审查关键输出。 • 维护项目记忆。
这不是更轻松，而是更高杠杆。
也更危险。
因为一个设计不好的循环，会更快地产生错误结果。
如果人完全不理解系统，只是按下“开始”，那不是自动化，而是把认知外包。
真正要学的不是更多提示词
提示词仍然重要。
但如果只停留在提示词，能力上限会很快到来。
下一阶段更值得训练的是：
• 如何把重复工作拆成循环。 • 如何为 agent 写清楚项目规则。 • 如何设置可验证的完成条件。 • 如何让不同 agent 分工。 • 如何设计不会失控的权限。 • 如何让结果沉淀到外部记忆。
这类能力，比单个 prompt 更难，也更接近工程本身。
因为你不是在问 AI 一个问题。
你是在设计一个系统，让它能不断处理一类问题。
结尾
AI 编程的杠杆点正在变化。
过去，很多人比拼的是谁更会问。
接下来，更大的差距可能来自：谁更会设计循环。
一个人可以用循环更快处理自己真正理解的工作。
另一个人也可以用同样的循环，逃避理解，制造更多自己无法维护的结果。
工具看不出这两者的区别。
工程师必须看得出来。
所以，值得记住的不是“让 AI 替你工作”。
而是：
设计循环，但不要退出工程。
让 AI 运行流程，但人必须继续负责判断。
这才是循环工程真正有价值的地方。
