EGM 实测：设计审查收益未转化为代码提升

EGM 想解决 AI 编程里一个常见问题：聊的时候都懂，写出来却偏了。它让掌握完整上下文的 AI 负责设计，再让没有聊天历史的 AI 挑错。但原文整理的两组独立实验给出的结论更谨慎：设计审查确实能发现问题，代码质量却没有稳定胜过更简单的先规划再实现。

对前端和全栈开发者，这篇值得看的不是新插件的热度，而是一个容易混淆的判断：AI 把方案讨论得更充分，是否就能把功能做对？现有数据没有证明这条链路成立。

为什么要让一个 AI 记住，再让另一个 AI 忘掉

Elephant-Goldfish Model，简称 EGM，把工作拆成「大象设计、金鱼审查」。据原文介绍，Google 于 2026 年 10 月将其开源，采用 Apache 2.0 许可证；首个带版本号的 v0.1.0 发布于 10 月 27 日，截至 11 月 3 日，GitHub 星标超过 10,700。

它针对的是 session context collapse，即长会话中模型逐渐丢失早期约束，开始自行补全需求。生成的代码可能看起来合理，却不符合实际要求。

「大象」保留系统历史、架构、组件边界和用户路径，负责澄清问题、讨论取舍、写设计文档，前期禁止写代码。「金鱼」从空白会话开始，只读设计文档和项目代码，检查方案的漏洞。设计意图是让审查者摆脱前面讨论形成的共同盲点。

下面三条命令把需求讨论、设计成文和审查分开：

1. /egm-brainstorm  先把问题定义清楚，暂不写代码
2. /egm-draft       起草 Markdown 设计文档
3. /egm-review      让一组金鱼开展对抗性审查

要盯住第一行：此时就让 AI 开始实现，会跳过这套流程最想保护的需求讨论。

设计文档需要覆盖问题定义、技术方案、考虑过的替代方案，以及写明实际文件名的实施计划。Google 博客将审查概括为三关：Comprehension Check 检查能否复述方案，Antagonistic Review 寻找边界情况和隐藏依赖，Implementation Readiness Check 检查文件路径、数据结构、函数签名是否足够具体。实际插件则运行五关，原文没有逐一展开新增环节。

插件支持 Antigravity、Claude Code、Claude Cowork 和 OpenAI Codex；ChatGPT Work 可以安装，但开发者仍记录了云端验证缺口。流程还要求人来决定架构取舍，并在实现前批准文档。

文档写得更细，为什么功能还是没做对

第一组实验来自 meabs，2026 年 10 月 23 日在 Codex 上测试一个跨模块优惠码功能，用 16 项隐藏测试验收。

方法	两次通过数	耗时	每轮费用
原生 Codex	4/16、2/16	62–91 秒	0.030–0.032 美元
EGM	3/16、1/16	419–550 秒	0.216–0.294 美元

EGM 的审查确实抓到了遗留折扣规则、优惠码到期时间，以及应当复用的分类服务。但两次实现都只搭出骨架，没有接入购物车价格计算，就宣称任务完成、项目编译通过。

两份文档分别长达 405 行和 132 行，也列出了待修改文件，仍没阻止漏做核心功能。

设计审查通过，不能代替功能验收通过。

不过，这个 pilot 的批准者是 agent，并非 EGM 强调的人类工程师，不能直接代表完整使用方式。后续实验也修正了部分问题。

Follow-up 1 将实现阶段设为 medium effort。两组都能写出约 600–650 行代码，涉及 19–21 个文件，但最终都只通过 4/16：所有运行都沿用了系统原有的折扣行名称，没有满足题目要求。原生 Codex 平均每轮花费 0.10 美元，EGM 为 0.43 美元。

Follow-up 2 换用新的 Claude agent（Opus 5.5）担任批准工程师。EGM 三轮成绩为 16、5、16；plan-first 为 6、13、16，满分均为 16。报告判断，EGM 相比 plan-first 没有可测量的收益，成本却约为五倍。

这里的关键细节是：决定能否通过的「code discount」汇总行名称，没有任何金鱼主动指出。推动成功的是批准者要求把这一验收条件写进文档。

金鱼看得更独立，也可能看得更少

第二组实验来自日本 Claude Code Lab。研究者在税务会计设计文档中预埋 10 个缺陷，比较五种审查方式。

审查方式	得分，满分 10	费用
在原会话中审查	9.5–10	约 0.04 美元
新会话只读文档	7	0.06 美元
自写 subagent 金鱼	6.5–7	0.08 美元
金鱼被明确要求打开引用文件	7.5–8	0.09–0.10 美元
EGM 完整五关	10	0.82 美元

原会话审查耗时 32–39 秒，完整 EGM 用了 3 分 54 秒。EGM 的费用约为新会话审查的 14 倍，最高分也只是追平原会话方案。

而且，10 分并非全部来自金鱼。计分包含了大象在文档末尾附上的对照表；如果只计算金鱼自己写出的批评，得分约为 8。报告注明，第 1、3、5 项涉及大象表格，第 5 项还只是泛泛提及，不能把完整得分都归功于独立审查。

金鱼擅长发现初次阅读会遇到的问题，例如保密责任不清、「11 月期间」含义模糊。但纸质账本里的两名客户、办公室主管批准要求，都藏在之前的对话里。新会话、自写金鱼，以及完整 EGM 中的九条金鱼，都没识别出这些缺陷。

隔离上下文能减少共同盲点，也会隔离没有写进文档的事实。

这个实验里，一个更便宜的改动同样有收益：明确要求审查者打开引用文件，得分就从 6.5–7 提到了 7.5–8。审查效果不只取决于角色数量，也取决于它实际读到了什么。

我的判断

我认可 EGM 把需求讨论和实现分开，也认可让独立审查者验证文档是否自洽。跨模块功能最容易出问题的地方，往往就是默认规则、隐藏依赖和验收口径没有写清。

但现有证据不足以支持「完整 EGM 更划算」。第一组是少量运行，批准者和 effort 设置又发生过变化；第二组测的是预埋缺陷的发现能力，无法直接推导出生产代码的缺陷率。两组实验都不能证明它普遍无效，也没证明它优于 plan-first。

原文转述 Google 有数千名工程师每天使用 EGM 处理生产工作，但没有提供降低多少 bug、节省多少时间的对照数据，也缺少超过一个月的长期使用报告。使用规模不能替代效果测量。

替代方案也要分开看。plan-first 是先规划再实现；原文对 GitHub Spec Kit、OpenSpec 的比较则是，它们更重视文档结构和把规格拆成任务，EGM 更强调无上下文审查。这部分没有同条件实验，应视为方法侧重点的描述。

还有一层来源限制：原文本身由 deepseek-v4.1-flash 经 ollama-cloud、Hermes Agent 生成，并声明有人类监督和质检。这里引用的是作者整理的报告，不能当成本站已复现的结果。

能拿来做什么

• 为跨前端、Node 服务和价格计算的功能先写一份设计文档，把用户可见的名称、计算规则、修改文件和验收条件写具体，再决定是否需要完整 EGM 审查。
• 使用独立 AI 审查时，把业务事实和引用文件一并交给它，并明确要求读取引用内容；不要指望新会话知道旧对话中的约定。
• 将文档批准和实现验收分开。优惠码这类功能要验证实际计算路径与输出，不能用编译通过或 agent 的完成声明代替验收。
• 选一个需要架构讨论的功能，对比 EGM 与 plan-first，记录费用、耗时、返工轮次和漏出的 bug；简单且明确的修复继续用常规流程。