Convergo让 AI 写代码的循环真正收敛一个为 AI 编程代理设计的插件核心思想很简单plan → review → build而且必须能终止。不会无限循环下去浪费你的 token 和耐心。先说说问题现在用 AI 写代码已经很常见了。流程通常是这样你告诉 AI 要做什么AI 写出一版代码代码需要审查发现一堆问题AI 修复这些问题修复又引入新问题需要再次审查循环…这个循环能不能收敛说实话很多时候不能。这就是 Convergo 要解决的问题。为什么循环会发散你看过那种情况吗AI 修了一个 bug引入了两个新的。reviewer 又发现了AI 又修但修的方式是打补丁而不是解决根本问题。几个回合下来代码变得越来越大、越来越模糊但离完成却越来越远。Convergo 的文档里有一段很精准的描述缺失的一个不变量横跨八个表面应该变成一次方案修复而不是八轮局部补丁。这是问题的核心——AI 的 review 循环发散不是因为 AI 不努力而是因为反馈没有正确的路由。代码层面的 bug 被当成代码问题修复了但它的根因可能是方案设计的问题。结果 worker 在不断打补丁而根本问题从来没有被触及。Convergo 怎么做Convergo 是一个插件可以装到 Claude Code、Codex、Cursor、OpenCode 等多个 AI 编程代理里。它不是什么底层技术革新而是一套精心设计的游戏规则。规则一反馈走归集不直接改代码这是最重要的规则。当 review 发现问题时worker 不能直接开始改。它必须先对每条发现做分类代码 bug→ worker 负责修方案缺口plan gap→ 停下来退回给 planner约定缺口contract gap→ 停下来等人做决策系统设计缺陷→ 停下来升级处理过时问题→ 标记无效缺少决策→ 停下来等人决定worker 只修自己该修的。方案层面的问题不能用代码补丁来糊弄。规则二发现要有证据不是感觉Reviewer 返回的每条发现都要有清晰的格式P0 ~ P3严重等级明确的置信度高 / 中 / 低关联代码行高置信度发现必须能引用具体代码行低置信度的发现除非是关键问题否则直接丢弃P3风格级别的发现永远不会被发出——风格问题归工具管不归 review 循环管规则三退出需要冷启动的审查者这是最巧妙的设计。修复之后原来的 reviewer 会做一次回归检查——但这不是退出的条件。退出条件是一个全新的、从零开始的 reviewer session读了一遍完整的 diff报告说没有阻塞性问题。这个新 session 没有看过之前的讨论没有历史记忆纯粹靠代码和方案来下判断。如果三个回合后还是没有拿到干净的冷启动审查通过循环停止所有问题升级给你。规则四最多三回合循环有硬上限——三回合。三回合内拿不到干净的审查结果停止并升级。已经判定无效的发现不能在没有新证据的情况下重新阻塞后续回合这叫 “adjudication ratchet”。实际跑一次是什么样假设你要让 AI 实现一个限流功能。用 Convergo 的流程大概是这样1. /cvg-plan-loop → AI 写方案review 方案修改方案再次 review 直到通过 2. 你亲自审查方案 → 确认方案里的决策是你想要的 3. /cvg-build-loop → worker 按切片实现TDDreview 代码修复再次 review 4. 最终冷启动审查通过 → 完成看一个具体的例子来自 Convergo 文档做了简化orchestrator 记录初始 commit创建 worktree 启动一个 WORKER session 并交给它方案 worker 按切片逐个实现TDD每个切片一个 commit 记录实现说明给 reviewer → 实现完成。测试覆盖41 个测试通过。已知缺口无。 orchestrator 启动一个全新的 REVIEWER session reviewer 读方案 diff派发出正确性/测试子审查者 合并它们的 JSON 发现 → 未就绪。F1P1重试路径丢失了限流请求头。 F2方案从未决定突发行为——约定缺口。 orchestrator 将发现原样返回给**同一个** worker session worker 先归集再修复F1 是代码问题 → 修复 F2 是约定缺口 → 停下来报告而不是打补丁糊弄过去 你 决定突发行为应该怎么做 worker 完成修复 → 新的 commit reviewer 同一个 session聚焦复查修复 → 通过 orchestrator 再启动一个**全新的** REVIEWER session reviewer 新 session完整第一次审查 → 已就绪。无阻塞问题。两个 P2 备注。 orchestrator 退出循环初始 commit → 最终 commit发现历史P2 清单交给你注意几个关键设计worker 从不绕过缺失的决策review 反馈回到同一个有上下文的 session最终退出判断永远来自一个没见过之前代码的审查者。混合循环让合适的模型干合适的活这是 Claude Code 专属的功能也是一个很有意思的工程优化。Convergo 做了一个明确的分工预设角色用什么模型为什么方案设计Claude Fable方向决策Fable 的判断力最好方案审查Codex (GPT-5.5)查漏补缺属于执行类工作代码实现Codex (GPT-5.5)所有迭代消耗都在这里代码审查Codex (GPT-5.5)同上最终退出审查Claude Fable放行与否的关键判断为什么要这样分因为模型经济学——Fable 的配额有限但判断力强适合花在刀刃上GPT-5.5 在 Codex CLI 上几乎免费适合做大量迭代。还有一个细节在混合模式里Codex 的审查通过不会直接退出——它升级到 Fable 做一次最终审查。只有 Fable 也通过循环才真正结束。Codex 审查没通过正常走回修复流程。Fable 审查没通过同样走回修复流程但下一轮又从 Codex 开始。有哪些技能Convergo 打包了 11 个技能slash commands命令用途可用平台/cvg-plan读 issue 和代码库写切片方案所有/cvg-plan-review审查方案所有/cvg-plan-review-feedback处理方案审查意见所有/cvg-work按切片实施TDD所有/cvg-code-review审查代码实现所有/cvg-code-review-feedback处理代码审查意见所有/cvg-plan-loop编排完整方案循环Claude Code Codex/cvg-build-loop编排完整开发循环Claude Code Codex/cvg-hybrid-plan-loop混合方案循环Fable CodexClaude Code 专属/cvg-hybrid-build-loop混合开发循环Fable CodexClaude Code 专属cvg-multi-session内部多会话协议不直接调用前六个技能是基础技能在任何支持的平台上都能用。带loop的编排技能需要真正的子会话能力Claude Code 的 background agent 或 Codex 的 thread。适用场景Convergo 适合正确性关键、需要可审查的编码工作。不适合快速原型和一次性脚本。团队在做代码审查严格的项目时Convergo 的 bounded loop 设计能省很多事——它不是在帮你写代码而是在帮你确保写完的代码能通过同事的审查。但要注意成本。一次 build-loop 大概是一个 worker session 每轮一个冷启动 reviewer每个 reviewer 派发 2-3 个子审查者 回归审查 最终审查。文档里说的很坦诚大概比直接告诉 AI 帮我实现多花一个数量级的 token。和其他方案的关系Convergo 是 Compound Engineering 的一个 fork。Compound EngineeringEveryInc 出品已经提出了 plan-first、review-everything 的正确框架。Convergo 在此基础上加的是让循环保证能终止的那些规则。创始人做了很清晰的区分CE 把 plan-first, review-everything 的形状做对了Convergo 让循环能终止。写在最后Convergo 不是那种让你哇的炫酷产品。它没有花哨的 UI没有魔法般的 demo。它是一套纪律——一套你写代码时本该遵守但经常忽略的纪律现在由工具强制执行的纪律。在 AI 编程代理越来越强大的今天怎么保证 AI 写的代码是对的这个问题变得越来越重要。Convergo 的答案是让一个独立的、没有看过之前代码的 session 来做最终判断。这不正是人类代码审查一直在做的事情吗项目地址github.com/gomilesf/convergoSources:Convergo - GitHubCompound Engineering Plugin - GitHub