大象金鱼模型是什么：设计用深上下文，评审用零上下文
写代码之前，先把设计和评审拆开：带全量项目上下文的 Agent 帮你写规格，另一批零上下文的子 Agent 只看文档和引用源码来挑毛病。Google 开源的 Elephant-Goldfish Model（EGM，Apache-2.0）就是这套插件；README 写明适用于「功能需要先做设计决策」的场景，小而明确的修 bug 继续走你平时的编码流程即可。下文按仓库 README、docs/getting_started.md 与 docs/harnesses.md（查阅日 2026-11-01 北京时间）整理角色分工、安装命令与 brainstorm→draft→review 主流程。同日 GitHub API 星数约 8293★。
说明：仓库写明「This is not an officially supported Google product.」功能与安装以 google/elephant-goldfish-model 与 egm.dev 为准。README 还写到「Thousands of Google engineers use EGM」——这是项目方自述，不是可独立核验的用户普查，文中只作背景引用。
大象写规格，金鱼找盲区
README 开篇一句话：Design with an elephant. Review with a goldfish. 三角色分工如下。
| 角色 | 上下文 | 职责 |
|---|---|---|
| Elephant（大象） | 你的项目、需求与此前决策 | 探索问题并起草规格 |
| Goldfish（金鱼） | 文档及其引用源码，不含先前对话 | 找未写明的假设、含糊需求与实现风险 |
| 你 | 真正重要的目标与约束 | 拍板架构取舍、批准设计、决定做什么 |
金鱼评审必须能拉起全新子 Agent 上下文（和站内 子 Agent 要干净上下文 同一类问题）。若当前 harness 做不到，EGM 会停掉评审。README 也写明：评审不能替代测试和人的判断。思路来自 Dave Rensin 那篇讲大象与金鱼的工程文章；插件把「写规格」和「零上下文挑刺」拆成可安装的技能与子 Agent 人设（skills/ 与 agents/）。
小而明确的修 bug，用你平时的编码工作流；需要先想清楚设计再写代码时，再上 EGM。
怎么装（按 harness 选一条）
要装完整插件，这样技能才能读到评审提示词和文档标准。装完后新开一个会话。
| 环境 | 官方安装命令 |
|---|---|
| Antigravity CLI | agy plugin install https://github.com/google/elephant-goldfish-model |
| Claude Code | claude plugin marketplace add google/elephant-goldfish-model 再 claude plugin install egm@egm |
| Codex | codex plugin marketplace add google/elephant-goldfish-model 再 codex plugin add egm@egm |
Antigravity App / IDE 扩展走 /plugin 或 harnesses 文档；Claude Cowork、ChatGPT Work 的入口也在同一文档。Antigravity 与 Claude Code 里 slash 命令通常带 /egm: 前缀（例如 /egm:egm-brainstorm）；agy CLI 1.4.10 可把未加前缀的名字补全成带前缀命令，1.4.8 不行，稳妥做法是自己写上前缀。Codex 在 skill 选择器里选对应 EGM 技能。Brainstorm 与 Review 都要求会话能创建全新子 Agent。
主流程：brainstorm → draft → review
getting_started.md 强调：主流程不是铁律，技能可以按需乱序取用；别硬套「先设计再写码」去啃一眼就能修的小问题。目标只有两样——代码做你要的事，文档讲清代码为何长成这样。
/egm-brainstorm：澄清概念，再拉起多视角 Goldfish 群（文档写 6-lens），写出结构化concepts_brief.md。/egm-draft：把 brief 或既有笔记写成正式设计文档，按节起草、每节可在对话里反馈，产物如design_draft.md；批准后归档到docs/designs/，并可用SITEMAP.md做索引。/egm-review：在零上下文会话里多阶段评审完整度、清晰度、自洽与可实施性。反馈会很多——挑你认的改，其余可忽略。- 人审：把设计开成 PR 给人看；EGM 不替代同事评审，尤其是产品优先级与长期一致性。
- 实现：让 Agent 按批准后的规格写代码；小错可点修，整段跑偏就改规格再试。实现阶段用什么风格/测试技能，EGM 不强制，可对照站内 编程 Agent 团队实践 写进自己的实现计划。
/egm-brainstorm Add webhook delivery to this project.
/egm-draft
/egm-review design_draft.md
上面是 README 的 webhook 投递示例：讨论失败重试、重复事件等取舍，先落 brief，再起草规格，再交给金鱼。路径以 Agent 返回的草稿路径为准。
技能清单与存量仓库
| 技能 | 用来做什么 |
|---|---|
| Brainstorm | 试想法，写概念 brief |
| Draft | 把 brief / 笔记写成设计文档 |
| Resolve | 消化评审发现并达成修改共识 |
| Bootstrap | 自底向上给已有代码树补 README，建立上下文 |
| Review | 五阶段金鱼评审 |
| Review loop | 按配置跑一组评审者 |
| Drift report | 对比已入库文档与当前源码是否漂移 |
存量仓库可用 /egm-bootstrap：先给叶子目录写 README，再向上汇总，直到根目录有一份地图。人仍应审一遍。可选再做一个 <项目>-elephant 自定义技能，只告诉模型项目是什么、关键路径与设计文档在哪——不必复杂。文档建议把 /egm-drift-report 塞进大约每周一次的维护轮值：发现漂移就由人决定改文档还是改代码。
什么时候用，什么时候跳过
该用：新功能要拍接口边界、失败策略、幂等与一致性；跨模块改动，写完代码再补文档会晚；你想在实现前就把「未写明的假设」逼出来。
该跳过：报错栈明确、改动局部、不存在架构取舍的小修；你已经有人审过的规格，只缺实现；当前环境开不出 fresh 子 Agent，Review 根本跑不起来——这时先别假装「审过了」。
常见坑
- 小 bug 也硬跑全流程：官方明确说可以跳过；浪费上下文窗口和时间。
- 在不能开 fresh subagent 的环境里做 Review：评审会直接停；先对照 harnesses 文档看支持情况。
- 把金鱼意见当圣旨：反馈故意很多，人要做筛选；也不要跳过真人 PR 评审。
- 规格与代码长期不同步：用 drift report；文档与代码只留一份真相。
- 只装半套：技能读不到评审提示与文档标准，流程会空转——按 README 装完整插件。
完成标准
- 能用自己的话讲清 Elephant / Goldfish / 人的上下文边界。
- 在目标 harness 上按 README 装好插件，并知道 brainstorm / draft / review 怎么调用。
- 能判断「要不要上 EGM」：需要设计决策才上，小修直接改。
- 知道批准后的规格放哪（如
docs/designs/），以及何时跑漂移检查。
最后
EGM 把「带上下文写规格」和「零上下文挑刺」拆成两套技能，中间留给人拍板。适合功能设计、接口取舍、跨模块方案；不适合「一眼能修」的改动。从仓库装插件、跑一遍 webhook 示例，比空谈 Spec-Driven Development 更直观。代码与文档见 GitHub 与 egm.dev。
