Loop Engineering
某大厂面试官：“你在项目里怎么用 Claude Code 写代码的？”
我说：“写好 Prompt，等它回复，然后根据结果再调整 Prompt，来回几轮搞定。”
面试官笑了笑：“那你有没有试过，连 Prompt 都不自己写，让 AI 帮你写？”
我愣住了。
他接着说：“Claude Code 的作者 Boris Cherny 已经不写 Prompt 了，他只写 Loop。让 Loop 去指挥 AI，AI 自己搞清楚该干什么。”
那一刻我才意识到，自己还在跟 AI 一对一聊天的时候，高手已经在做自动化流水线了。
一、你跟 AI 的聊天方式，该升级了
先回忆一下你现在是怎么用 AI 写代码的：
打开 Claude Code 或 Codex → 写一段 Prompt → AI 跑起来 → 看结果 → 不满意再改 Prompt → 再跑 → 循环……
这个流程有什么问题？你全程卡在中间。AI 每次停下都得等你，你是整条生产线的瓶颈。
就像工厂里，机器干完一个零件就停下来等操作工按按钮，效率能高吗？
2026 年 6 月，AI 圈炸出一个新概念：Loop Engineering（循环工程）。它的核心思想只有一个：
别亲手写 Prompt 了，去设计一个循环，让循环替你去写 Prompt。
OpenClaw 创始人 Peter Steinberger 的原话是：“别再搞 coding agent 了，去设计能提示 agent 的 loop。”
Claude Code 作者 Boris Cherny 说得更狠：“我已经不给 Claude 写提示词了，我有 Loop 在跑，它们自己决定该干什么，我的工作是写 Loop。”
你看，大佬们已经不陪你玩"写好 Prompt"的游戏了。
二、AI 工程的四次范式跃迁
回顾过去三年，你以为自己在"升级模型"，其实一直在升级工程方式：
| Prompt Engineering（2023） | 写好提示词 | 提示词工程师 | “请你扮演一个……” |
| Context Engineering（2024） | 喂够上下文 | 知识搬运工 | RAG、长文档注入 |
| Harness Engineering（2025） | 搭执行骨架 | 架构师 | 工具注册、权限、观测 |
| Loop Engineering（2026） | 设计自循环 | 流水线设计者 | 让 AI 自己 Prompt 自己 |
Prompt Engineering 时代：跟 AI 一锤子买卖。你问一句，它答一句。质量全靠你那句 Prompt 写得好不好——说白了就是"玄学调参"。
Context Engineering 时代：发现光有好 Prompt 不够，得给 AI 喂足够的背景信息。RAG 火起来了，向量数据库也开始普及。
Harness Engineering 时代：AI 不只回答问题，开始执行任务了。你得给它配工具、定权限、看日志。这一步相当于给 AI 搭了个"脚手架"。
Loop Engineering 时代：你不再站在流水线上按按钮。你设计好一整条自动化流水线，AI 自己在里面转——发现问题、分配任务、执行、检查、继续。
Google Cloud AI 总监 Addy Osmani 在最近的长文中把这个概念系统化了。他说得很直白：Loop Engineering 就是你不再当"操作工"，而是当"工厂主"。
三、Loop 的六块积木
一个能真正跑起来的 Loop，由 5+1 块积木拼成：
积木一：自动化（Automation）
这是 Loop 的起搏器。
- 定时触发（cron）：每天早上 9 点自动启动检查 CI 失败记录
- 事件触发（hook）：有新 Issue 创建时自动启动分析
- 目标触发（/goal）：设定一个目标，“不达目标不罢休”，跑完一轮自动判断"完成了吗？"——没完成继续跑
没有自动化，Loop 就不是 Loop，只是一串手动执行的任务。
积木二：工作树（Worktree）
当多个 Agent 同时改代码，冲突怎么办？
Git worktree 的思路：给每个 Agent 配独立工位。在同一个仓库里切出独立的 worktree，Agent A 的修改完全碰不到 Agent B 的文件。互不干扰，各干各的，最后再合并。
积木三：Skill（技能包）
Skill 是你对项目所有要求的持久化存储：
- 代码风格规范
- 架构约定
- 踩过的坑
- 测试要求
Agent 每跑一圈就读一次 Skill，不用你每次都重新讲一遍。Skill 就是 Loop 的长期记忆。
积木四：插件和连接器（Plugins & Connectors）
一个只能读文件的 Loop 叫小 Loop，能操作真实工具的才是大 Loop。
通过 MCP 协议，Agent 可以：
- 读 Issue Tracker
- 查数据库
- 操作 CI/CD
- 发 PR、更新工单
连接器决定了 Loop 的"手脚"能伸多远。
积木五：子 Agent（Sub-agents）
这是 Loop 里最关键的一步——把"干活"和"检查"拆成两个人。
让写代码的 Agent 给自己打分？太容易放水了。正确做法：
- Agent A：负责写代码、修 Bug
- Agent B：独立 Agent，配不同指令（甚至不同模型），专门审查 Agent A 的工作
/goal 命令的精髓就在这：用一个独立 Agent 判断"目标完成了吗"。
+1：记忆层（Memory）
最简单也最容易被忽略的一块。
Loop 跑着跑着，Agent 会忘。上下文窗口装不下所有历史。所以需要一个磁盘上的状态文件——Markdown、Linear 看板、任何活在会话之外的东西——记录"什么做了、什么没做、什么失败了、下一步干啥"。
Agent 会忘，文件不会。
四、一个真实的 Loop 长什么样
Addy Osmani 展示了他自己每天在用的一个 Loop，看完你就懂了：
每天早上 9:00，一个定时任务自动启动。
它调一个"分诊" Skill——像个急诊护士翻病历——翻昨天的 CI 失败记录、Open Issue、最近的 commit。翻完后，把发现的问题写进 Markdown 文件。
对每个值得修的问题 → 自动开一个独立 worktree → 派 Agent A 起草修复方案 → 派 Agent B（配项目规范和测试）审查方案 → 过了 → 连接器自动开 PR、更新工单。
搞不定的 → 放进 Triage 收件箱等人处理。
全程串起来的是一条状态文件，记录什么试过、什么通过、什么还开着。明天早上从今天停下的地方继续。
从发现问题到分配、修复、审查、开 PR——一个字都不用敲。
五、三个大坑：Loop 越强，你越危险
Addy Osmani 在讲完 Loop 的构成后，花了同样篇幅讲三个坑。这很说明问题。
坑一：验证还是你的活
别以为"AI 说完成了"就等于真的完成了。"完成了"是声明，不是证明。
子 Agent B 审查过 ≠ 代码没问题。发布前你还是要亲自确认——就像老板签合同之前还是要自己看一眼。
坑二：理解债务会滚雪球
Loop 产出速度越快，你真正能理解的代码就越少。
代码不是你写的，你没参与过程，出问题时你连从哪下手都不知道。这叫理解债务——一个丝滑的 Loop 只会让它膨胀得更快。
除非你愿意认真阅读 Loop 产出的东西，而不是闭眼接收。
坑三：最舒服的姿势最危险
当 Loop 自己在那撒欢跑，你很容易被诱惑——直接收下它给的一切结果，不再思考，不再判断。
Addy 管这个叫"认知投降"。
设计 Loop 是解药还是毒药，取决于你是用判断力设计 Loop 来提效，还是用 Loop 来逃避思考。
同一个 Loop，两个人用：
- 一个人用它加速自己透彻理解的工作
- 另一个人用它避开理解工作本身
Loop 分不清。你自己要分清。
六、怎么开始你的第一个 Loop
说了这么多，来点实际的。你可以在 Claude Code / Codex / OpenClaw 上起步：
Level 1：从 /goal 开始
最简单的 Loop 入口。告诉 AI 你的目标，让它自己判断"完成了吗"：
/goal 把这个项目的所有 TypeScript 文件加上 JSDoc 注释
Agent 会自己跑、自己检查、自己继续——直到目标达成。
Level 2：加上 hook 自动化
在 Claude Code 里，stop hook 是天然的 Loop 触发器。Agent 每完成一轮 → hook 自动触发下一轮决策。
// .claude/settings.json
{
"hooks": {
"Stop": [
{
"matcher": "",
"command": "node scripts/decide-next.js"
}
]
}
}
Level 3：搭完整流水线
把六块积木拼起来：
Loop Engineering 不是什么神秘的黑科技。它的本质就是：把你从流水线上解放出来，让你去设计流水线本身。
但别忘了 Addy 最后的提醒：
“搭好你的 Loop，但别忘了直接给你的 Agent 写 Prompt 仍然有效。关键是找到正确的平衡。”
Loop 替你省掉的是繁琐的重复操作，不该替你省掉的，是作为工程师的参与感和判断力。
Boris Cherny 说"我的工作是写 Loop"——这句话不是在说工作变少了，而是在说工作的难点变了。
Loop Engineering 是大势所趋，学它、用它，但要保持思考。做一个还在思考的工程师，而不是只会按"开始键"的人。
