Loop Engineering 半年实战拆解：自进化的开发系统已开源

2026年6月，Loop Engineering突然在硅谷AI圈刷屏了。 先是Boris Cherny（Claude Code负责人）说：“我现在基本不直接prompt Claude了，我写的是循环——让循环去prompt Claude，然后自己决定下一步。”紧接着，Google Cloud的Addy Osmani给这个思路起了个正式的名字。然后，36氪、钛媒体、智东西这些中文媒体也一窝蜂跟进了。 越看越觉得眼熟。多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，每个有独立的人格定义、工具权限、模型分配。输出统一落在/目录下，形成完整的“七件套”：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的工作流程不是“读代码→找问题”，而是： 1. 先不读代码。只读design.md和implementation.md，基于设计列出3-5个最可能的缺陷区域（比如“错误处理可能不全”、“并发场景可能有竞争”）。 2. 然后带着这些预测去审代码。 3. 记录预测命中的问题，也记录预测未覆盖的问题——后者更重要，说明预判有盲区。 这一设计并非空想，而是基于认知科学的经典发现：如果你先看答案再给出推理，你会高估自己的推理能力。反过来，如果你先给出预测再看答案，校准精度大幅提升。review的“预提交预测”就是把这条发现工程化了。 更进一步，预测的起点不是reviewer的直觉——是memory。每完成一个feature，retro Agent会把hard-won的教训存入memory。下一个feature的review启动时，先从memory里检索相关的历史事故模式，作为预测的候选起点。这意味着系统的审查能力会随着使用次数增长而增长。

决策三：分级阻断 + 低风险即修——不给“以后再说”留后门

review发现问题后，不是全部丢给dev修。分级如下： - ：阻断循环，必须修复或获得白名单豁免 - ：套用“低风险即修”准则 关键就在这条准则：Critical / Important的问题，如果同时满足四个条件——有客观依据、无副作用（不改公共API/数据格式/外部行为）、改动量 ≤20行且单文件、不需要用户确认——必须修。不允许说“这个不重要，先跳过”。 这解决了一个真实问题：reviewer提了一堆minor建议，dev觉得“不重要”全跳过了。下个feature又提同样的建议，又跳过。三个月后，100个minor问题变成了一个不可维护的代码库。“低风险即修”的本质是用低摩擦的执行换零技术债积累。 同时，Critical / Important的延后理由有白名单——只有四种合法理由：超出scope、需用户确认、需大重构、与design冲突。禁止“后续优化”、“暂时忽略”这种模糊措辞。reviewer看到这种措辞会标记为rejected-defer，照样阻断循环。

决策四：不是所有经验都值得存——三条铁律筛掉废话

大多数“总结经验”的尝试最后都变成了废话集合：“要写测试”、“注意并发”、“文档很重要”——这些是Google一下就能找到的东西，不值得占memory空间。 retro Agent有三条硬性准入规则，必须全部满足才存memory： 1. ：网上搜不到。排除所有通识。 2. ：能指到具体文件、错误信息、项目独有的模式。排除泛泛的经验。 3. ：真实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提取Critical和Important的阻断计数 - 任一项 > 0 → 跳过本轮QA，直接打回dev - dev必须处置所有阻断项（修复Critical，修复或白名单延后Important），才能进入下一轮 这里有一个容易被忽略的设计：阻断时跳过QA是为了省token。带着已知缺陷跑QA没有意义——QA只会重复发现同样的问题。先让dev修干净，再让QA验证。 第三，循环有硬性上限保护。 第4轮结束时暂停询问用户——“已经跑了4轮，还有X个问题没解决，是否继续？”超过5轮强制终止，列剩余问题 + 根因分析（设计缺陷 / 实现能力不足 / 需求本身矛盾）。这不代表不信任Agent。真正的目的是防止系统在“接近完成但始终差一点”的状态里无限烧token。 第四，文档是Agent之间的接口协议。 所有Agent的输出严格落在/目录下，形成“七件套”：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，然后在一个随机轮次碰巧通过。这种循环没有积累——每次都是从零开始。 一个会学习的循环，每一次迭代都在三个维度上积累： 1. （memory）：上次在哪个类型的缺陷上摔了，存下来，下次优先查。 2. （预测命中率）：漏掉的问题类型暴露认知盲区，盲区变成下一轮的优先关注区。 3. （Agent定义的迭代）：你发现clarify一次甩八个问题质量差，就给它加了“一次只问一个”的约束。你发现Important建议总被跳过，就给它加了“低风险即修”的规则。每个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 → /architect → （可选/third_party_review ） → /ship → /retro 。 如果想启用跨厂商设计评审，复制third-party-review.d/provider.env.example为.env，填上第三方端点信息即可。 开源不是因为完美。恰恰是因为它不完美——第四节列的那五个缺陷，每一个都是真实使用中暴露出来的。开源的目的不是“发布最佳实践”，是让更多人用起来，然后告诉你哪里设计错了。就像量化系统一样——build in public。 如果你已经在用类似的工作流，或者看了这篇文章想试试，有几个快速开始的建议： 1. 这两个Agent的ROI最高——review阻止缺陷进入代码库，retro把每次修复变成系统的永久记忆。其他Agent（clarify、architect、qa、third_party_review）等你觉得“嗯，我现在真的需要这个了”再加。 2. 所有Agent的有效性取决于项目上下文的准确度。花一个小时写一份好的CLAUDE.md，比花一天调Agent prompt更值。 3. 第一个feature跑完，retro可能什么都存不进去——因为三条准入规则很严。正常。第二个、第三个feature开始，memory才会慢慢积累。前三个feature的循环看起来“性价比不高”，但它们是在给第四个及之后的feature种地。 这套体系的设计目标从来不是“完美”——第一节就说了，第四节列了五个没解决的缺陷。设计目标是今天比昨天强一点，明天的feature比今天的feature少踩一个坑。六个月下来，它做到了。