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

2026年6月，Loop Engineering在硅谷AI领域掀起热潮。 先是Boris Cherny（Claude Code负责人）分享：“我现在很少直接给Claude下指令了，而是编写循环——让循环去驱动Claude，并自主决定下一步。”紧接着，Google Cloud的Addy Osmani为这一思路正式命名。随后，36氪、钛媒体、智东西等国内科技媒体也纷纷跟进报道。 越看越觉得似曾相识。多智能体协作、maker-checker架构、结构化开发流水线、子Agent隔离——原来自己在过去近半年的实践中，已经摸索出一套高度相似的解决方案。 如今，网上讲解概念的文章已经足够多了。因此，本文打算通过实际经验来直接拆解这套Loop工程——它在生产环境中已稳定运行半年。每个设计决策背后都蕴含着真实的使用痕迹，包括那些最终被证实无效的部分。 整套方案已开源为claude-ship仓库，克隆后运行一条install.sh命令即可安装到~/.claude目录，之后在任何项目中，通过/clarify → /architect → /ship → /retro命令即可启动运行。

第一节：单人开发的三大致命局限

大半年前，和大多数借助AI进行编程的开发者一样，我的起点是vibe coding——用自然语言描述需求，AI生成代码，接着审查、测试、微调。效率提升是实实在在的：复杂功能的开发时间从几天缩短到几小时，原型验证从几周缩短到几十分钟。 然而，效率提升也带来了三个新的棘手问题。 第一，确认偏误。当你与同一个AI模型持续对话时，它会倾向于顺应你的思路。你说“这个设计应该采用方案A”，它就会回应“方案A非常棒，理由如下”。你永远不会知道方案B是否更为优越——因为没有人会对你提出质疑。一个人的头脑风暴，本质上就是一个回音室。 第二，审查疲劳。最初，你对AI生成的代码充满警惕，每行都仔细审视。两周后，你开始跳读。一个月后，你只看代码差异。三个月后，你只扫一眼关键函数。这并非懒惰——而是人脑的认知经济学规律：如果95%的AI生成代码是正确的，你的大脑会自动将审查预算降至5%。问题是，那5%的错误并不会自动贴标签。 第三，记忆蒸发。三个月前那个诡异的bug是如何修复的？当时写下一行注释了吗？注释可能只写了“修复边缘情况”——这对三个月后的你毫无帮助。作为单人开发者，没有同事可以询问“你还记得那个问题吗”。每一次遗忘都意味着一次重新调试。 这三个问题本质上是人的问题。AI只是忠实地暴露了单人开发中一直存在、但以往被团队结构所掩盖的弱点。 因此，真正的工程设计挑战是：能否通过一套系统性的约束，将这些弊端有效管控起来？ 这就是这套循环系统的起点。

第二节：七步流水线——目标不是更聪明，而是更少犯错

首先来看整体架构。 七个智能体（Agent），每个都拥有独立的人格定义、工具权限和模型分配。输出统一存放在/目录下，形成完整的“七件套”：需求文档 → 设计文档 → 第三方评审 → 实现代码 → 代码审查 → 测试报告 → 回顾总结。 每个智能体的模型分配并非随意：审查环节使用Opus（判断力强，速度慢但精准），开发和测试环节使用Sonnet（执行快速，成本低廉），需求澄清和架构设计环节使用默认模型。这并非“哪个更强就用哪个”，而是“什么任务需要什么样的认知特性”。 具体实现上，仓库结构非常清晰——commands/是斜杠命令的入口，agents/是智能体的人格定义，templates/development/是八个文档模板，scripts/third-party-review.sh是跨厂商评审的headless Claude Code封装器。一条install.sh命令即可将所有内容安装到~/.claude目录。 下面我不会逐一介绍每个智能体——那会变成冗长的操作手册。智能体的定义本身都在仓库的agents/目录下，是纯文本文件，阅读完只需要五分钟。我挑选了几个最值得展开讨论的设计决策来讲解——智能体层面的四个决策放在这一节，编排层面的单独开一节。

决策一：禁止“顺便问一下”——注意力是串行的，问题也应该是

大多数需求澄清的做法是列出一份清单：“请回答以下5个问题”。这种方式效率看似很高，但质量却很低——因为人的注意力是串行的，你在回答第3个问题时可能已经在想“什么时候才能问完”。 需求澄清智能体（clarify Agent）有一条硬性约束：一次只问一个问题，禁止批量提问，禁止“顺便问一下”。 而且它会在提问前先读取代码。不是问“你们的代码是怎么实现的”，而是带着代码上下文去提问。如果一个问题在代码中就能直接找到答案，那它就不应该出现在对话中。 这个设计是被真实体验逼出来的。早期通过AI协助澄清需求时，它经常一次性甩过来七八个问题——我回答了前三个，后面的就全忘了。改成单次提问循环后，每轮对话的深度明显增加，最终产出的需求文档也更具体、更可操作。 代价就是慢。一个功能的澄清可能需要4到6轮对话。但这里设置了一条退出机制：用户随时可以输入“够了”或“开始设计”，立即终止循环，基于当前已有信息生成文档。如果到了第8轮还没结束，系统会主动暂停询问——防止无止境地追问下去。

决策二：先预测后审查——符合认知科学的代码审查

这是整套体系中最令人满意的设计之一。 代码审查智能体（review Agent）的工作流程并非“阅读代码→查找问题”，而是： 1. 首先不读代码。只阅读设计文档和实现文档，基于设计内容列出3到5个最有可能存在缺陷的区域（例如“错误处理可能不完善”、“并发场景可能存在竞争条件”）。 2. 然后带着这些预测去审查代码。 3. 记录预测命中的问题，同时也记录预测未能覆盖的问题——后者更为重要，这说明预判存在盲区。 这一设计并非凭空想象，而是基于认知科学中的经典发现：如果你先看到答案再给出推理过程，你会高估自己的推理能力。相反，如果你先给出预测再看到答案，校准精度会大幅提升。审查环节的“预提交预测”就是将这一发现工程化的具体实践。 更进一步，预测的起点并非审查者的直觉，而是记忆。每完成一个功能，回顾智能体（retro Agent）会将来之不易的经验教训存入记忆库。在下一个功能开启审查时，系统会先从记忆库中检索相关的历史事故模式，作为预测的候选起点。这意味着系统的审查能力会随着使用次数的增加而不断提升。

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

审查发现的问题，并非全部丢给开发智能体（dev Agent）去修复。而是进行分级处理： - 严重 / 重要：阻断循环，必须修复，或者获得白名单豁免 - 轻微 / 建议：适用“低风险立即修复”准则 关键就在这条准则：对于严重和重要级别的问题，如果同时满足四个条件——有客观依据、无副作用（不改变公共API、数据格式或外部行为）、修改量不超过20行且仅涉及单个文件、无需用户确认——就必须立即修复。不允许说“这个问题不重要，先跳过”。 这解决了一个实际问题：审查者提出了许多轻微建议，但开发人员觉得“不重要”就全部跳过了。下一个功能又提出同样的建议，又再次跳过。三个月后，100个轻微问题累积成了一个难以维护的代码库。“低风险立即修复”的本质，就是用低摩擦的执行来避免技术债务的积累。 同时，严重和重要问题的延期理由有明确的合法清单——只有四种合法理由：超出本次开发范围、需要用户确认、需要大规模重构、与设计文档冲突。禁止使用“后续优化”、“暂时忽略”这类模糊措辞。审查者看到这种措辞会将其标记为rejected-defer，同样会阻断循环。

决策四：并非所有经验都值得记录——三条铁律过滤无效信息

大多数“总结经验”的尝试最终都变成了废话集合：“要编写测试”、“注意并发问题”、“文档很重要”——这些都是通过Google就能找到的通用建议，不值得占用记忆空间。 回顾智能体（retro Agent）设定了三条硬性准入规则，必须全部满足才能存入记忆： 1. 非Google可查：网上无法直接搜索到。排除所有通识性内容。 2. 项目特有：能够指向具体的文件、错误信息或项目独有的模式。排除泛泛的经验。 3. 来之不易：是在实际调试中付出过代价才获得的教训。排除那些顺手完成的功能。 而且记忆文件的总数保持在5到8个——设有硬性上限。新的经验要进入，旧的经验就需要合并或淘汰。这可以防止记忆库膨胀成无人问津的档案库。 这三条规则的效果：存储进去的每一条记忆，都是真金白银换来的。当下一次审查环节检索记忆库进行预提交预测时，检索到的是高信号的信息，而不是噪音。

决策五：跨厂商设计评审——发现Claude无法识别的盲区

review和qa虽然运行在独立的子智能体中，但它们都基于同一个模型家族。这意味着它们会共享某些由训练数据导致的共同偏见——对某些设计模式的偏好、对某些错误类型的迟钝。 因此就有了third_party_review：在编写任何代码之前，使用另一个厂商的模型来独立评审设计文档。 具体实现上，通过headless Claude Code并结合切换ANTHROPIC_BASE_URL至第三方端点来完成——DeepSeek、Kimi等任何兼容Anthropic Messages API的服务都可以使用。配置一个provider.env文件（包含端点、密钥和模型名称），脚本会自动启动一个独立会话，将设计文档、需求文档、项目CLAUDE.md文件输入进去，获取完整的评审报告后保存到本地。 请注意这个智能体的设计定位：它提供的是建议，并不会阻断/ship流程。它不是一个关卡——而是为你提供另一个视角。一个在Claude看来“显然正确”的设计，在DeepSeek看来可能存在三个你未曾考虑过的失败模式。阅读完报告后，你可以选择回到/architect环节修改设计，也可以选择接受风险，继续/ship流程。

第三节：编排层——将审查关卡打造成真正的闸门

前面四个设计讲述的是单个智能体的决策。但整套体系最关键的工程决策并不在任何单个智能体中——而是在/ship这个编排器里。 /ship并非一个智能体，而是一个状态机。它做的事情看起来很简单：将开发→审查→测试串联成一个循环，全部通过就退出。但实现的细节决定了这套体系究竟是“真正的闸门”还是“流于形式”。 第一，审查和测试环节运行在子智能体中，而不是当前会话中。 开发环节在当前会话中执行——你可以实时看到它修改了什么代码，随时可以中断并纠正方向。但审查和测试环节使用Task工具启动独立的子智能体，拥有独立的上下文窗口。这意味着审查智能体只能看到设计文档和实现文档——它看不到你在中途改了什么又撤回了什么，也看不到开发智能体的“内心独白”。它只能基于文档来做出判断。 这一点很微妙但至关重要：如果审查和开发共享同一个会话，审查过程就会被开发的思维过程“污染”——它会不知不觉地顺着开发的叙述走。独立的上下文强制审查保持客观性。 第二，审查关卡是真的会阻断流程的。 大多数CI/CD所谓的“关卡”纯粹是建议性的——失败了你可以手动覆盖就过去了。这里的关卡是硬性阻断： - 审查返回后，编排器提取严重和重要问题的阻断计数 - 有任何一项大于0 → 跳过本轮测试，直接打回开发环节 - 开发必须处理所有阻断项（修复严重问题，修复或通过白名单延期重要问题），才能进入下一轮 这里有一个容易被忽略的设计：阻断时跳过测试是为了节省令牌。带着已知缺陷进行测试没有意义——测试只会重复发现同样的问题。先让开发把问题清理干净，再让测试去验证。 第三，循环设有硬性上限保护。 第4轮结束时系统会暂停询问用户——“已经运行了4轮，还有X个问题未解决，是否继续？”超过5轮则强制终止，并列出剩余问题及根本原因分析（设计缺陷、实现能力不足、还是需求本身存在矛盾）。这并不代表不信任智能体。真正的目的是防止系统在“接近完成但始终差一点”的状态下无限消耗令牌。 第四，文档是智能体之间的接口协议。 所有智能体的输出严格存放在/目录下，形成“七件套”：需求文档 → 设计文档 → (第三方评审) → 实现代码 → 审查报告 → 测试报告 → 进度记录 → 回顾总结。审查报告.md和测试报告.md采用增量追加的方式——多轮循环时，新章节插入文件顶部，历史内容向下推移。不得修改或删除历史章节。 这意味着你可以回溯整个功能开发的决策演进过程：第1轮审查发现了什么 → 开发是如何处理的 → 第2轮审查验证了什么 → 最终哪些问题被接受了、哪些问题被修复了。这套文档不是为了归档。它是为下一个功能提供起始上下文。

第四节：这套体系的真正瓶颈

读到这儿，你可能会觉得“这套体系看起来挺完整的”。 不。以下是它目前最坦诚的缺陷清单。 第一，循环次数一多，上下文窗口就开始变得紧张。每个智能体都需要读取设计文档、实现文档、上一轮的审查报告和测试报告。两轮还能撑住，三轮以上光是读取历史文档就要消耗数万令牌。审查报告采用了增量追加：新章节插入顶部，历史内容向下推移，旧章节保持不变。这样可追溯性虽然保住了，但代价是文件变得越来越长。我们正在尝试对历史章节进行自动摘要压缩，但尚未上线。 第二，审查和测试有时会“串通”。理论上它们是独立的智能体，但实际上都运行在同一个模型家族上，有些盲区一模一样。所以才有了第三方评审——换用不同厂商的模型来做设计评审，专门捕捉Claude的共同偏见。但这只做到了设计层面，代码层面的跨模型审查还没有实现。 还有一个更实际的问题：这套流程对于简单任务来说过于繁琐。修复一行拼写错误不需要经过需求澄清→架构设计→开发→审查→测试这套完整流程。我们有一个判断标准：小任务不运行完整流水线。什么样的任务算“小”？目前是靠直觉判断。这是下一个需要工程化解决的问题。 第四，从回顾到记忆的闭环还不够紧密。理论上，记忆应该在下一个功能的设计阶段就被引用——架构智能体读取记忆以避免重蹈覆辙。但目前架构智能体和记忆的集成还比较弱，更多是依靠审查阶段的预提交预测来利用记忆。 最后，也是最为根本的——这套体系假设你能够编写清晰的CLAUDE.md文件。如果项目的CLAUDE.md是空白的或过时的，所有智能体都会在错误的上下文中工作。这不是循环本身的问题，但它是循环有效的前提——垃圾进，垃圾出。

第五节：真正重要的不是代码循环，而是进化循环

如果只记住一件事，请记住这个： 这套体系里最重要的循环并非开发→审查→测试的代码循环，而是回顾→记忆→下一个功能的进化循环。 代码循环保证的是这一次不出错。进化循环保证的是下一次比这一次更强——而且是自动进行的。 六个月前刚把这套东西拼凑起来的时候，它就是一个防错流水线——确认偏误、审查疲劳、记忆蒸发，这是单人开发最常见的三个弱点，各派一个智能体盯着。那个时候记忆库是空的，审查的预提交预测全靠“凭直觉感觉哪里容易出错”——命中率大概只有一半。 六个月后，记忆库里存储了七条来之不易的事故模式。不是“要编写测试”这种废话——而是“这个项目里PIT财务数据的时间对齐逻辑在跨市场时会漂移”、“上次审查漏掉的类型是异步竞态，因为设计文档里没有画时序图”。现在审查启动时，系统会先从记忆库检索相关模式，再列出预测清单。命中率从五成提高到了七成多。这并非依赖模型升级——Opus还是那个Opus。靠的是： 系统记住了上次在哪里摔过，这次优先查看那个方向。 这就是为什么记忆准入规则如此严格——不是因为存储成本高，而是因为噪音会毒化这个进化循环。如果存入了100条“注意边界条件”级别的废话，下次检索时就是噪音，命中率反而会下降。 少而精的记忆才是进化的燃料，多而杂的记忆是进化的阻力。 这也是为什么“预提交预测”这个设计是整套体系的灵魂——不是因为它能捕捉到多少bug，是因为它创造了一个可度量的校准回路。每次审查结束时，你可以对比预测命中了多少、遗漏了多少。遗漏的问题类型，就是系统的认知盲区。而认知盲区暴露的那一刻，就是下一次进化的入口。 写到这里，让我们回到开篇那个问题——Loop Engineering和Prompt Engineering的根本区别是什么？ 区别不在于有没有循环，而在于循环本身会不会学习。 一个没有记忆、没有校准、没有自我改进的死循环，只是一个配置了重试逻辑的脚本。它会把同一个错误重复N遍，消耗N倍的令牌，然后在某个随机轮次碰巧通过。这种循环没有积累——每次都是从零开始。 一个会学习的循环，每一次迭代都在三个维度上积累： 1. 知识积累（记忆）：上次在哪个类型的缺陷上摔了，存储下来，下次优先检查。 2. 校准积累（预测命中率）：遗漏的问题类型暴露认知盲区，盲区变成下一轮的优先关注区域。 3. 流程积累（智能体定义的迭代）：你发现需求澄清一次甩出八个问题质量差，就给它加了“一次只问一个”的约束。你发现重要建议总被跳过，就给它加了“低风险立即修复”的规则。每个智能体的当前定义，都是之前几十轮循环积累下来的设计判断。 这才是Loop Engineering真正有价值的地方。它不是在节省人力——它是在把每一次开发的经验，包括失败的经验，变成系统的永久升级。六个月前它是一个防错流水线，现在它自己会进化。 一年后它会是什么样，我不清楚。但我知道它一定比现在更强——因为每运行一个功能，它就在三个维度上各自增长一点点。这不是一次性的效率提升，这是一个复利结构。

结尾——开源不是因为完美，是因为不完美

整套体系已经开源：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，填上第三方端点信息即可。 开源不是因为完美。恰恰是因为它不完美——第四节列出的那五个缺陷，每一个都是在实际使用中暴露出来的。开源的目的不是“发布最佳实践”，而是让更多人使用起来，然后告诉你哪里设计错了。就像量化系统一样——在公众面前构建。 如果你已经在使用类似的工作流，或者看了这篇文章想尝试一下，这里有几个快速开始的建议： 1. 从审查和回顾开始，而不是七个全上。 这两个智能体的投资回报率最高——审查阻止缺陷进入代码库，回顾将每次修复变成系统的永久记忆。其他智能体（需求澄清、架构设计、测试、第三方评审）等你觉得“嗯，我现在真的需要这个了”再加。 2. 先编写好CLAUDE.md。 所有智能体的有效性取决于项目上下文的准确度。花一个小时编写一份好的CLAUDE.md，比花一天调整智能体提示词更有价值。 3. 把第一个功能的记忆当作投资，而不是成本。 第一个功能运行完后，回顾可能什么都存不进去——因为三条准入规则很严格。这很正常。从第二个、第三个功能开始，记忆才会慢慢积累。前三个功能的循环看起来“性价比不高”，但它们是在为第四个及之后的功能播下种子。 这套体系的设计目标从来不是“完美”——第一节就说了，第四节列了五个尚未解决的缺陷。设计目标是今天比昨天强一点，明天的功能比今天的功能少踩一个坑。六个月下来，它做到了。