Google 开源的 EGM：用「大象 + 金鱼」逼 agent 先设计再写码

一句话

Google 开源了一个叫 EGM（Elephant Goldfish Model，大象·金鱼模型） 的插件，强制你的编码 agent 在写第一行代码之前，先把功能设计清楚。思路极简，但它解决的是长会话里最难自查的那个问题。

三个角色

为什么金鱼有用

你跟 agent 聊一小时，双方都积累了一堆默认共识。文档写出来，你俩读着都通顺——因为缺失的部分你们都已知。

新读者不知道。

所以金鱼会问：「这个 webhook 失败了呢？」「这个词到底啥意思？」——这正是实现阶段会咬你的那个缺口。

安装

# Claude Code
claude plugin marketplace add google/elephantgoldfishmodel
claude plugin install egm@egm

# Codex
codex plugin marketplace add google/elephantgoldfishmodel
codex plugin add egm@egm

⚠️ 必须整包安装，不能只拷 skills 目录。skill 运行时要去读 reviewer persona 和文档标准，只拷 skills 会直接坏掉。

工作流

• /egm:brainstorm — 并行放 6 条金鱼，各用一个视角审你的想法：一个专门当反方（这功能到底需不需要存在？现成库是不是已经解决 90%？），一个算成本与 token 经济性。产出 concepts-brief.md。

• /egm:draft — 把 brief 写成设计文档，逐节写、每节停下等你反馈，不一次性甩给你。

• /egm:review — 5 个阶段：拉远看（是否过度复杂）→ 理解性检查（标出每个没解释的术语）→ 恶意设计批评（架构/扩展性/风险）→ 再拉远 → 实现就绪检查（不许把设计决策留给实现者）。

• /egm:resolve — 逐条过 finding，商定改什么。

• /egm:bootstrap — 自下而上给每个文件夹写 README 再汇总，给大象一张项目地图。

• /egm:drift-report — 对比设计文档与当前代码，指出哪里对不上了，建议每周跑一次。

两条硬规则

1. 禁止恭维。reviewer 不许说你的想法 great / brilliant，必须先讲哪里有问题、哪里危险，并给出最强反方论点。

2. 如果 agent 无法创建全新子代理，EGM 直接中止评审——它不会在同一个上下文里假装评审，因为「同上下文的评审不算金鱼评审」。

代价

EGM 设计上就吃 token：一次 review 起 5～6 个 reviewer，每个都从零读文档和参考代码，改完还要再跑一轮。在 $20 的套餐上很快撞限额，所以更适合放在按量或便宜的 open model 上跑。作者的做法是混模型：Kimi 当大象写文档，GLM 读代码做批评，DeepSeek Flash 跑轻量检查——金鱼换了模型，连盲区都不共享了。

别用在哪

• 小 bug 修复，走正常流程就行

• 本来就是「想清楚了、直接改」的小改动，评审的时间成本划不来

来源

AICodeKing 的视频《Google's NEW EGM Skill Set + Deepseek is ACTUALLY INSANE!》，B 站有中配搬运。仓库 google/elephantgoldfishmodel，Apache 2.0，官方声明不是 Google 正式支持的产品，算团队项目。