开篇------我被一个 buzzword 追上了
2026年6月，Loop Engineering突然在硅谷AI圈刷屏了。
先是Boris Cherny（Claude Code负责人）说："我现在基本不直接prompt Claude了，我写的是循环------让循环去prompt Claude，然后自己决定下一步。"接着Google Cloud的Addy Osmani给这个思路起了个正式名字。然后36kr、钛媒体、智东西这些中文媒体也一窝蜂跟进。
我读这些文章的时候，越看越觉得眼熟。
多Agent协作、maker-checker架构、结构化开发流水线、子agent隔离------突然发现我跑了小半年的东西，终于有个词能概括它了。
现在网上讲概念的已经够多了。所以这篇文章我打算用我的实践直接拆解这套loop工程------它已经实打实在生产环境里跑了半年。每个设计决策背后都有真实的使用痕迹，包括那些最后发现没用的部分。
整套东西已经开源成claude-ship仓库，clone下来跑一条install.sh就能装进~/.claude，之后在任何项目里用/clarify → /architect → /ship → /retro就能跑起来。
第一节：一个人写代码的三个致命弱点
大半年前，我和大多数 AI 辅助编程的人是一样的。起点是 vibe coding------用自然语言描述需求，AI 生成代码，我审查、测试、微调。效率提升是真实的：复杂功能从几天变成几小时，原型验证从几周变成几十分钟。
但效率提升也带来了三个新问题：
第一，确认偏误。 当你和同一个 AI 模型对话时，它会顺着你的思路走。你说"这个设计应该用方案 A"，它说"方案 A 很好，理由如下"。你永远不会知道方案 B 是不是更好------因为没有人挑战你。一个人的头脑风暴，本质上是一个回音壁。
第二，审查疲劳。 初期你对 AI 生成的代码充满警惕，每一行都看。两周后，你开始跳读。一个月后，你只看 diff。三个月后，你只扫一眼关键函数。这不是懒------是人脑的认知经济学：如果 95% 的 AI 生成代码都是对的，你的大脑会自动把审查预算降到 5%。问题是，那 5% 的错误不会自己贴上标签。
第三，记忆蒸发。 三个月前那个诡异的 bug 是怎么修的？当时写了一行注释吗？注释写的是"fix edge case"------这对三个月后的你毫无帮助。一个人的团队，没有同事可以问"你还记得那个问题吗"。每一次遗忘都是一次重新 debug。
这三个问题本质上是人的问题。AI 只是忠实地暴露了单人开发中一直存在、但以前被团队结构掩盖住的弱点。
所以真正的工程设计问题是：能不能用一套系统性的约束，把这些问题关进笼子里？
这就是这套 loop 的起点。
第二节：七步流水线------不是更聪明，是更不蠢
先说整体结构。
七个 agent，每个有独立的人格定义、工具权限、模型分配。输出统一落在 <feature-name>/ 目录下，形成完整的"七件套"：requirements → design → third_party_review → implementation → review → test_report → retro。
每个 agent 的模型分配不是随机的：review 用 Opus（高判断力，慢但准），dev 和 qa 用 Sonnet（快速执行，便宜），clarify 和 architect 用默认模型。这不是"哪个更强用哪个"，是"什么任务需要什么认知特征"。
如果你好奇具体实现，仓库结构很直白------commands/ 是 slash 命令入口，agents/ 是 agent 人格定义，templates/development/ 是八个文档模板，scripts/third-party-review.sh 是跨厂商评审的 headless Claude Code wrapper。一条 install.sh 全装进 ~/.claude。
下面我不会逐一介绍每个 agent------那会变成说明书。agent 定义本身都在仓库 agents/ 目录下，纯文本，读完只需要五分钟。我挑几个最值得展开的设计决策来讲------agent 层的四个放这一节，编排层的单独开一节。
决策一：禁止"顺便问一下"------注意力是串行的，问题也应该是
大多数需求澄清的做法是列一个清单："请回答以下 5 个问题"。效率很高，但质量很低------因为人的注意力是串行的，你回答第 3 个问题时已经在想"什么时候问完"。
我的 clarify agent 有一条硬约束：一次只问一个问题，禁止批量提问，禁止"顺便问一下"。
而且它先读代码再提问。不是问"你们的代码怎么做的"，而是带着代码上下文去问。如果一个问题是代码里能直接回答的，它就不应该出现在对话里。
这个设计是被真实体验逼出来的。早期我让 AI 帮我澄清需求，它一次甩过来七八个问题------我回了前三个，后面全忘了。改成单问循环后，每轮对话深度明显增加，产出的 requirements.md 也更具体可操作。
代价是慢。一个 feature 的澄清可能需要 4-6 轮对话。但这里有一条退出机制：用户随时输入"够了"/"开始设计"，立即终止循环，基于当前信息产出文档。到第 8 轮还没完，系统会主动暂停询问------防止无限追问。
决策二：先猜后看------符合认知科学的代码审查
这是整套体系里我最满意的一个设计。
review agent 的工作流程不是"读代码→找问题"。而是：
- 先不读代码。 只读 design.md 和 implementation.md，基于设计列出 3-5 个最可能的缺陷区域（比如"错误处理可能不全"、"并发场景可能有竞争"）。
- 然后带着这些预测去审代码。
- 记录预测命中的问题，也记录预测未覆盖的问题------后者更重要，说明预判有盲区。
这不是我拍脑袋想的。认知科学里有一个经典发现：如果你先看答案再给出推理，你会高估自己的推理能力。反过来，如果你先给出预测再看答案，校准精度大幅提升。review 的"预提交预测"就是把这条发现工程化了。
更进一步，预测的起点不是 reviewer 的直觉------是 memory 。每完成一个 feature，retro agent 会把 hard-won 的教训存入 memory。下一个 feature 的 review 启动时，先从 memory 里检索相关的历史事故模式，作为预测的候选起点。这意味着系统的审查能力会随着使用次数增长而增长。
决策三：分级阻断 + 低风险即修------不给"以后再说"留后门
review 发现问题后，不是全部丢给 dev 修。分级：
- Critical / Important：阻断循环，必须修复或获得白名单豁免
- Minor / Suggestion：套用"低风险即修"准则
关键在这条准则： / 的问题，如果同时满足四个条件------有客观依据、无副作用（不改公共 API/数据格式/外部行为）、改动量 ≤20 行且单文件、不需要用户确认------必须修。不允许说"这个不重要，先跳过"。
这解决了一个真实问题：reviewer 提了一堆 minor 建议，dev 觉得"不重要"全跳过了。下个 feature 又提同样的建议，又跳过。三个月后，100 个 minor 问题变成了一个不可维护的代码库。"低风险即修"的本质是用低摩擦的执行换零技术债积累。
同时， 的延后理由有白名单------只有四种合法理由：超出 scope、需用户确认、需大重构、与 design 冲突。禁止"后续优化"、"暂时忽略"这种模糊措辞。reviewer 看到这种措辞会标记为 rejected-defer，照样阻断循环。
决策四：不是所有经验都值得存------三条铁律筛掉废话
大多数"总结经验"的尝试最后都变成了废话集合："要写测试"、"注意并发"、"文档很重要"------这些是 Google 一下就能找到的东西，不值得占 memory 空间。
我的 retro agent 有三条硬性准入规则，必须全部满足才存 memory：
- Non-Googleable：网上搜不到。排除所有通识。
- Codebase-Specific：能指到具体文件、错误信息、项目独有的模式。排除泛泛的经验。
- Hard-Won：真实 debug 付出代价的教训。排除顺手写完的功能。
而且 memory 总文件数保持在 5-8 个------有硬上限。新经验要进来，旧的经验要合并或淘汰。防止 memory 膨胀成没人看的档案库。
这三条规则的效果：存进去的每一条 memory，都是真金白银换来的。下一次 review 检索 memory 做预提交预测时，检索到的是高信号信息，不是噪音。
决策五：跨厂商设计评审------抓 Claude 看不到的盲区
review 和 qa 虽然跑在独立 subagent 里，但它们跑在同一个模型家族上。这意味着它们会共享某些训练数据导致的共有偏见------对某些设计模式的偏好、对某些错误类型的钝感。
所以有了 third_party_review：在写任何代码之前，用另一个厂商的模型独立评审 design.md。
实现上通过 headless Claude Code + 切换 ANTHROPIC_BASE_URL 到第三方端点完成------DeepSeek、Kimi 等任何兼容 Anthropic Messages API 的服务都可以。配置一个 provider.env 文件（含 endpoint + key + model），脚本自动拉起独立会话，把 design.md、requirements.md、项目 CLAUDE.md 喂进去，拿到完整评审报告后落盘。
注意这个 agent 的设计定位：建议性，不阻断 /ship 。它不是 gate------是给你另一个视角。一个在 Claude 看来"显然正确"的设计，在 DeepSeek 看来可能有三个你没考虑到的失败模式。看完报告你可以选择回 /architect 修 design，也可以选择接受风险继续 /ship。
第三节：编排层------把 review gate 做成一道真正的闸门
前面四个设计讲的是单个 agent 的决策。但整套体系最关键的工程决策不在任何一个 agent 里------在 /ship 这个编排器里。
/ship 不是一个 agent，是一个状态机。它做的事情看起来很简单：把 dev → review → qa 串成一个循环，绿了就退出。但实现细节决定了这套体系到底是"真 gate"还是"走形式"：
第一，review 和 qa 跑在 subagent 里，不是当前 session。
dev 在本 session 执行------你可以实时看它改了什么代码，随时打断纠偏。但 review 和 qa 用 Task 工具开独立 subagent，拥有隔离的上下文窗口。这意味着 review agent 看到的只有 design.md 和 implementation.md------它看不到你中途改了什么又撤回了什么，也看不到 dev agent 的"内心独白"。它只能基于文档做判断。
这一点很微妙但很重要：如果 review 和 dev 共享同一个 session，review 会被 dev 的思维过程"污染"------它会不知不觉跟着 dev 的叙述走。独立上下文强制 review 保持不相关性。
第二，review gate 是真的会阻断的。
大多数 CI/CD 所谓的"gate"是纯 advisory------失败了你手动 override 就过去了。这里的 gate 是硬阻断：
- review 返回后，orchestrator 提取 和 的阻断计数
- 任一项 > 0 → 跳过本轮 QA，直接打回 dev
- dev 必须处置所有阻断项（修复 ，修复或白名单延后 ），才能进入下一轮
这里有一个容易被忽略的设计：阻断时跳过 QA 是为了省 token。 带着已知缺陷跑 QA 没有意义------QA 只会重复发现同样的问题。先让 dev 修干净，再让 QA 验证。
第三，循环有硬性上限保护。
第 4 轮结束时暂停询问用户------"已经跑了 4 轮，还有 X 个问题没解决，是否继续？"超过 5 轮强制终止，列剩余问题 + 根因分析（设计缺陷 / 实现能力不足 / 需求本身矛盾）。这不代表不信任 agent。真正的目的是防止系统在"接近完成但始终差一点"的状态里无限烧 token。
第四，文档是 agent 之间的接口协议。
所有 agent 的输出严格落在 <feature-name>/ 目录下，形成"七件套"：requirements → design → (third_party_review) → implementation → review → test_report → progress → retro。review.md 和 test_report.md 采用增量追加------多轮循环时新章节插文件顶部，历史内容往下推。不得修改/删除历史章节。
这意味着你可以回溯整个 feature 的决策演进：loop 1 review 发现了什么 → dev 怎么处置的 → loop 2 review 验证了什么 → 最终哪些问题被接受了、哪些被修复了。这套文档不是为了归档。它是给下一个 feature 当 starting context。
第四节：这套体系的真正瓶颈
写到这儿，你可能觉得"这套体系看起来挺完整的"。
不。以下是它目前最诚实的缺陷清单：
第一，loop一多，context window就开始吃紧了。每个agent都要读design.md、implementation.md、上一轮的review.md和test_report.md。两轮还能撑住，三轮以上光是读历史文档就要花掉几万token。review.md我们做了增量追加：新章节插顶部，历史往下推，旧章节不动。这样可追溯性是保住了，但代价是文件越来越长。我现在正在尝试对历史章节做自动摘要压缩，但还没上线。
第二，review和qa有时候会串通。理论上它们是独立的agent，但实际上都跑在同一个模型家族上，有些盲区一模一样。所以才有了third_party_review------换不同厂商的模型做设计评审，专门抓Claude的共有偏见。但这只做到了设计层，代码层的跨模型review还没做。
还有一个更实际的问题：这套流程对简单任务太重。 修一行 typo 不需要经过 clarify → architect → dev → review → qa。我有意识地做了一个判断：小任务不跑完整流水线。什么样的任务算"小"？目前是靠直觉判断。这是下一个要工程化的问题。
第四，retro 到 memory 的闭环还不够紧。 理论上 memory 应该在下一个 feature 的 design 阶段就被引用------architect 读 memory 避免重蹈覆辙。但目前 architect 和 memory 的集成还比较弱，更多是靠 review 阶段的预提交预测来利用 memory。
最后，也是最根本的------这套体系假设你能写清楚 CLAUDE.md。 如果项目的 CLAUDE.md 是空白的或者过时的，所有 agent 都会在错误的上下文中工作。这不是 loop 的问题，但它是 loop 有效的前提------垃圾进垃圾出。
第五节：真正重要的不是代码循环，是进化循环
如果你只记住一件事，记住这个：
这套体系里最重要的循环不是 dev → review → qa 的代码循环。是 retro → memory → 下一个 feature 的 进化循环。
代码循环保证的是这一次 不出错。进化循环保证的是下一次比这一次更强------而且是自动的。
六个月前刚把这套东西拼起来的时候，它就是一个防错流水线------确认偏误、审查疲劳、记忆蒸发，一人开发最常见的三个弱点，各派一个 agent 盯着。那个时候的 memory 是空的，review 的预提交预测全靠"凭直觉觉得哪里容易出错"------命中率大概一半。
六个月后，memory 里存了七条 hard-won 的事故模式。不是"要写测试"这种废话------是"这个项目里 PIT 财务数据的时间对齐逻辑在跨市场时会漂移"、"上次 review 漏掉的类型是异步竞态，因为 design 里没画时序图"。现在 review 启动时，先从 memory 检索相关模式，再列预测清单。命中率从五成提到了七成多。这不靠模型升级------Opus 还是那个 Opus。靠的是：
系统记住了上次在哪摔的，这次先看那个方向。
这就是为什么 memory 准入规则那么严格------不是因为存储贵，是因为噪音会毒化这个进化循环。存了 100 条"注意边界条件"级别的废话，下次检索就是噪音，命中率反而下降。
少而精的 memory 才是进化的燃料，多而杂的 memory 是进化的阻力。
这也是为什么"预提交预测"这个设计是整套体系的灵魂------不是因为它能抓到多少 bug。是因为它创造了一个可度量的校准回路。每次 review 结束，你可以对比预测命中了多少、漏了多少。漏掉的问题类型，就是系统的认知盲区。而认知盲区暴露的那一刻，就是下一次进化的入口。
写到这里，回到开篇那个问题------Loop Engineering 和 Prompt Engineering 的根本区别是什么？
区别不在于有没有循环，在于循环本身会不会学习。
一个没有 memory、没有校准、没有自我改进的死循环，只是一个配置了重试逻辑的脚本。它会把同一个错误重复 N 遍，消耗 N 倍的 token，然后在一个随机轮次碰巧通过。这种循环没有积累------每次都是从零开始。
一个会学习的循环，每一次迭代都在三个维度上积累：
- 知识积累（memory）：上次在哪个类型的缺陷上摔了，存下来，下次优先查。
- 校准积累（预测命中率）：漏掉的问题类型暴露认知盲区，盲区变成下一轮的优先关注区。
- 流程积累 （agent 定义的迭代）：你发现 clarify 一次甩八个问题质量差，就给它加了"一次只问一个"的约束。你发现 建议总被跳过，就给它加了"低风险即修"的规则。每个 agent 的当前定义，都是之前几十轮循环积累下来的设计判断。
这才是 Loop Engineering 真正值钱的地方。它不是在省人力------它是在把每一次开发的经验，包括失败的经验，变成系统的永久升级。六个月前它是一个防错流水线，现在是它自己会进化。
一年后它是什么样，我不知道。但我知道它一定比现在更强------因为每跑一个 feature，它就在三个维度上各长一点点。这不是一次性的效率提升，这是一个复利结构。
结尾------开源不是因为完美，是因为不完美
整套体系已经开源：github.com/Peakstone-L...
bash
git clone https://github.com/Peakstone-Labs/claude-ship.git
cd claude-ship
./install.sh # 拷贝进 ~/.claude，立即可用之后在任意项目里：/clarify <feature> → /architect <feature> → （可选 /third_party_review <feature>）→ /ship <feature> → /retro <feature>。
如果想启用跨厂商设计评审，复制 third-party-review.d/provider.env.example 为 <provider>.env，填上第三方端点信息即可。
开源不是因为我觉得它完美。恰恰是因为它不完美------第四节列的那五个缺陷，每一个都是真实使用中暴露出来的。开源的目的不是"发布最佳实践"，是让更多人用起来，然后告诉我哪里设计错了。和我的量化系统一样------build in public。
如果你已经在用类似的工作流，或者看了这篇文章想试试，有几个快速开始的建议：
- 从 review 和 retro 开始，而不是七个全上。 这两个 agent 的 ROI 最高------review 阻止缺陷进入代码库，retro 把每次修复变成系统的永久记忆。其他 agent（clarify、architect、qa、third_party_review）等你觉得"嗯，我现在真的需要这个了"再加。
- 先写好 CLAUDE.md。 所有 agent 的有效性取决于项目上下文的准确度。花一个小时写一份好的 CLAUDE.md，比花一天调 agent prompt 更值。
- 把第一个 feature 的 memory 当投资，不是成本。 第一个 feature 跑完，retro 可能什么都存不进去------因为三条准入规则很严。正常。第二个、第三个 feature 开始，memory 才会慢慢积累。前三个 feature 的循环看起来"性价比不高"，但它们是在给第四个及之后的 feature 种地。
这套体系的设计目标从来不是"完美"------第一节就说了，第四节列了五个没解决的缺陷。设计目标是今天比昨天强一点，明天的 feature 比今天的 feature 少踩一个坑。六个月下来，它做到了。