开篇——我被一个 buzzword 追上了2026年6月Loop Engineering突然在硅谷AI圈刷屏了。先是Boris ChernyClaude 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。每完成一个 featureretro 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 有三条硬性准入规则必须全部满足才存 memoryNon-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 共享同一个 sessionreview 会被 dev 的思维过程污染——它会不知不觉跟着 dev 的叙述走。独立上下文强制 review 保持不相关性。第二review gate 是真的会阻断的。大多数 CI/CD 所谓的gate是纯 advisory——失败了你手动 override 就过去了。这里的 gate 是硬阻断review 返回后orchestrator 提取 和 的阻断计数任一项 0 →跳过本轮 QA直接打回 devdev 必须处置所有阻断项修复 修复或白名单延后 才能进入下一轮这里有一个容易被忽略的设计阻断时跳过 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-Labs/claude-ship**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 把每次修复变成系统的永久记忆。其他 agentclarify、architect、qa、third_party_review等你觉得嗯我现在真的需要这个了再加。先写好 CLAUDE.md。所有 agent 的有效性取决于项目上下文的准确度。花一个小时写一份好的 CLAUDE.md比花一天调 agent prompt 更值。把第一个 feature 的 memory 当投资不是成本。第一个 feature 跑完retro 可能什么都存不进去——因为三条准入规则很严。正常。第二个、第三个 feature 开始memory 才会慢慢积累。前三个 feature 的循环看起来性价比不高但它们是在给第四个及之后的 feature 种地。这套体系的设计目标从来不是完美——第一节就说了第四节列了五个没解决的缺陷。设计目标是今天比昨天强一点明天的 feature 比今天的 feature 少踩一个坑。六个月下来它做到了。