Google 大象金鱼模型：先审方案，再让 AI 写代码

13 分钟阅读 · 2026年11月2日
最近审核 2026年11月2日

你让 AI 智能体“加一个 CSV 导出”，它可能直接开始写代码，却没问谁能导出哪些数据。这些决定没有消失，只是等你看代码时，才发现智能体替你做了选择。

Google 的 Elephant-Goldfish Model（EGM，大象金鱼模型）是一款在实施前评审软件设计的开源插件。掌握项目背景的智能体起草规格，新会话中的评审者检查文档有没有说清楚，工程师负责取舍并批准设计。功能中仍有重要决定尚未明确时，这套流程能把它们提前摆出来。

Google 于 2026 年 10 月 22 日宣布开源 EGM，并表示数千名工程师每天用它交付生产代码。这是 Google 报告的使用情况，不能据此推算缺陷减少了多少。

资料核查日期：2026年11月2日。我们查阅了 Google 的公告及仓库版本 403d8881，没有在客户项目中运行 EGM。以下功能设计、成本计算与试点方案均为说明性示例。

大象金鱼模型 EGM 是什么？

EGM 通过隔离对话历史，把设计与评审分开。项目 README 将项目背景交给 Elephant，将独立文档评审交给 Goldfish，将架构决定留给人。EGM 提供智能体技能和操作指令，没有发布新的语言模型权重。

各角色读取哪些材料，承担什么责任
角色	可用上下文	责任
Elephant（大象）	需求、架构、讨论内容和已记录的决定。	追问方案，编写设计。
Goldfish（金鱼）	设计文档、评审指令及相关引用材料，不继承此前的设计对话。	找出隐含假设、表达歧义和实施风险。
工程师	产品目标、约束和评审发现。	作出取舍，承担责任，批准规格。

“大象”并不意味着无限记忆。起草技能明确考虑了新会话接手的情况，要求智能体从简报中重新读取被否决的备选方案。上下文靠书面决定传递。我们的编程智能体仓库上下文指南进一步解释了这类交接需要哪些工程工作。

“不写代码”也有具体范围。EGM 执行指令禁止在设计阶段修改生产实现，但允许在 Markdown 或临时草稿中编写明确标注的示例代码。接口示例可以帮助确定方案，生产实现仍留到设计获批之后。

brainstorm、draft 和 review 怎么衔接？

EGM 把讨论整理成另一场会话也能理解的规格。官方工作流指南给出了核心顺序，也允许团队按需要单独使用某项技能。

egm-brainstorm：讨论需求与备选方案，让新会话中的评审者质疑构想，再将达成共识的方向写入 concepts_brief.md。
egm-draft：逐节编写 design_draft.md，说明问题、现有系统、拟议改动和实施计划。
egm-review：分阶段检查设计，再由你决定在批准之前处理哪些发现。

人工批准后，让编程智能体实施计划中一段范围明确的工作。已批准的规格应纳入版本控制，通常放在 docs/designs/。如果你正在选择更完整的规格工作流，可以参考我们的 GitHub Spec Kit 生产应用指南。

EGM 的五个评审阶段各查什么？

当前 EGM 评审技能分五个阶段检查架构方向、文档理解、设计质量、多余复杂性和实施准备情况。表中的 CSV 导出问题是示例，不是实际运行评审得到的结果。

当前评审顺序与可能发现的问题
阶段	核心问题	问题示例
1. 初次全局检查	方案能否借助现有系统解决实际问题？	新增导出服务重复实现了发票模块已有的查询逻辑。
2. 理解检查	新读者能否复述方案及现有行为？	文档使用“账户”，却没有区分用户账户和租户。
3. 设计质疑	设计、假设或依赖会在哪些情况下失效？	请求可以选择租户，却没有验证用户是否属于该租户。
4. 中途全局复查	修正意见是否引入了可以避免的架构？	有明确数据量上限的导出被加上了队列和对象存储流程，却没有证据说明其必要性。
5. 实施就绪检查	实施者能否直接动手，而不用自行补做设计决定？	计划没有写明超出行数上限时的行为，也缺少现有授权方法的签名。

理解检查的评审者必须分别复述方案，以及文档所描述的现有系统。无法解释某个章节，就属于阻断项。如果复述与你的本意不同，应检查文档漏写了哪一层关系。

评审可以逐阶段暂停，也可以汇总成一份报告。实施就绪意见供工程师判断，并不授予发布权限。

为什么要两次检查过度设计？

第二次全局检查有必要，因为批评本身也可能增加复杂性。Zoom Out 标准要求拒绝为假想需求增加的功能，避免过早引入基础设施，并复用已有组件。详细评审结束后，还要核对修改后的设计是否仍围绕原来的问题。

例如，评审者追问“如果导出增长到几百万行怎么办”，这个问题值得回答。是否需要任务队列，要看产品需求、现有基础设施和实测执行边界。明确的数据量上限可能足以满足当前需求；更大的导出需求则可能需要后台处理。

我们的要求是：每个新增组件都应解决已观察到的约束或已经确认的需求。被否决的方案也要记录理由，否则下一位评审者可能重新打开同一场讨论，设计变得更大，问题却没有解决得更好。

设计示例：限定租户范围的 CSV 导出

导出规格需要写清谁能读取哪些记录、文件包含什么，以及触及限制时如何响应。下面是我们为假设中的 NestJS 应用编写的简化示例，文件名、权限和限制均为假设。交给智能体实施前，必须换成经过核实的仓库信息。

假设应用已有经过认证的租户成员关系、发票数据访问层和经过测试的 CSV 编码器。产品负责人要求同步导出，最多包含 1,000 张发票。这个上限是示例中的产品选择，不是性能测试结果，也不是普遍安全的性能阈值。

“加一个 CSV 导出”尚未回答的决定
决定	规格示例	验收检查
访问权限	要求 `invoices.export` 权限。依据服务端验证的成员关系确定租户，不接受客户端选择租户的参数。	租户 A 的用户不能导出租户 B 的数据；缺少权限时返回 403。
记录筛选	按 UTC 时间筛选 `issued_at`，包含起点，不包含终点。格式错误或起止颠倒时返回 400。	时间恰好等于起点的记录被包含，恰好等于终点的记录被排除。
文件内容	只导出 `invoice_id, issued_at, total_minor, currency`，先按 `issued_at`，再按 `invoice_id` 排序。复用 CSV 编码器。	列顺序和稳定的行顺序符合测试样本；不出现客户备注或其他字段。
数量上限	最多读取 1,001 条匹配记录。超过 1,000 条时，在发送 CSV 响应头或任何文件字节之前，返回 422 和 `EXPORT_LIMIT_EXCEEDED`。	恰好 1,000 条时成功；1,001 条时返回完整错误响应，不产生部分下载。
空结果	返回 200，CSV 只有表头行，没有数据记录。	已获授权但没有匹配记录时，下载文件仍然有效且行为明确。

实施章节还要把这些决定对应到真实代码。文件清单可以按下面的形式起草：

修改 src/invoices/invoices.controller.ts
  GET /api/invoices/export?from=...&to=...
  复用现有认证与权限守卫。

新建 src/invoices/invoice-export.service.ts
  buildCsv(principal: TenantPrincipal, range: ExportRange)
    -> Promise<InvoiceExport>
  InvoiceExport: { filename: string; csv: string }
  在输出响应前完成授权、筛选和数量上限检查。

修改 src/invoices/invoices.module.ts
  使用现有发票依赖注册导出服务。

新建 test/invoices-export.e2e-spec.ts
  验证租户边界、权限、日期、列和数量上限。

这份摘录故意保留了缺口。真实计划还要指出具体守卫与数据访问方法，定义 ExportRange 和错误映射，并确定编码、文件名、缓存响应头及失败行为。新评审者应该指出这些遗漏。仅仅添上看似合理的文件路径，不能让设计变得可执行。

试点时，可以从一份副本中删除租户规则，从另一份副本中删除 1,001 条记录时的处理规则，再询问评审者这些情况下会发生什么。有用的发现应说清缺少哪项决定、会造成什么后果；自行假定一套规则，意味着没有检出遗漏。

什么样的计划才可以开始实施？

EGM 的实施就绪标准要求确定设计选择、列明文件、精确描述改动并给出具体测试。每个增量阶段结束后，项目还应保持可构建、可测试。这是计划的质量目标，不能保证生成代码一次就写对。

核对引用：已有路径、方法和数据结构必须与当前检出的源码版本一致。明确区分新增符号与现有符号。
确定行为：写清适用的授权规则、错误分支和兼容性选择。“适当处理错误”仍然把决定留给实施者。
将需求对应到检查：定义可观察的结果，包括边界和失败情况。只有测试文件名、没有预期行为，还不够。
安排实施顺序：说明阶段间的依赖，以及继续推进前必须通过的检查。

实施完成后，仍要对 AI 生成代码进行独立 QA。规格审得清楚，代码也可能实现错误。

EGM 怎么安装和使用？

先确认编程环境能创建全新上下文的子智能体，再安装完整 EGM 插件。安装与运行环境指南提醒，只复制技能目录会漏掉评审角色和文档标准。以下命令来自我们在 2026 年 11 月 2 日核查的安装文档。

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 CLI

agy plugin install https://github.com/google/elephant-goldfish-model

安装后新开会话。Claude Code 和 Antigravity CLI 使用 /egm: 前缀，例如：

/egm:egm-brainstorm 设计一个限定租户范围的发票 CSV 导出功能。
/egm:egm-draft
/egm:egm-review design_draft.md

依次执行这些工作流步骤，中间按提示回答设计问题。评审时使用智能体实际返回的草稿路径。Codex 中则通过技能选择器选择对应的 EGM 技能。

还要检查运行环境真正开放了哪些能力。核查版本的指南区分 Antigravity CLI、App 和 VS Code 扩展，以及缺少所需委派工具的独立版 Antigravity IDE。Cowork 和 ChatGPT Work 有安装途径，但文档仍记录了验证缺口。

无法创建全新子智能体时，EGM 会停止评审。让同一场对话“扮演金鱼”，不能实现它要求的上下文隔离。

上下文隔离与工具权限是两回事。应检查运行环境对评审者的权限控制，不能把“只做设计”的指令当成文件系统沙箱。

EGM 成本多少，真的能省时间吗？

EGM 源码采用 Apache 2.0 许可证。运行时仍会消耗编程智能体的额度或 API 用量，以及团队的评审时间。仓库也明确说明，它不是 Google 正式支持的产品。

项目测试手册记录了插件结构和部分原生运行路径的检查。这些结果不能证明所有团队的交付时间或漏出缺陷都会减少。官方 FAQ也承认评审可能成为瓶颈，建议衡量有效发现和返工。

可以用一组假设数字算清这笔账：

假设工程时间按每小时 €90 计价。
额外评审 20 分钟，人工成本为 €30；再假设智能体用量花费 €6，总成本为 €36。
如果这套流程避免了后续 45 分钟返工，省下的时间价值为 €67.50，假设净收益为 €31.50。
收支平衡点为 €36 / €90 × 60 = 24 分钟，也就是至少需要避免 24 分钟的工作。

这些是自行设定的输入值，不是 Wavect 报价、EGM 定价或实测节省。换成团队自己的数据时，要计入新增的起草、评审、问题处理和文档维护时间。交付周期应单独记录：即使评审本身很短，等批准等了两天，发布仍会延迟。

团队应该怎样试点 EGM？

我们会选择范围明确、验收标准已知的功能，将 EGM 下的完整交付过程与团队原有做法比较。信任评审结论前，先检查它能不能发现规格中的已知问题。以下是建议的评估方案，其中故意加入了可以验证是否被检出的遗漏。

固定基线：记录仓库和插件版本、运行环境、模型、权限，以及被评审规格的版本。
检查隔离：只在作者对话中放一句无害的测试短语，让评审者依据提供的文档解释设计。出现该短语就说明有泄漏；没出现，只能算初步检查通过，不能证明完全隔离。
植入已知遗漏：分别从导出示例的副本中移除租户规则或超限处理规则。用新会话重复评审，记录检出、漏检和错误发现。
复核评审意见：由工程师判断每条发现属于真正缺失的决定、有用的澄清，还是多余工作。新增依赖或组件前，要求说明理由。
实施并衡量：使用同样的验收检查，比较通过验收的变更、全部人工投入、智能体用量、重新打开的工作及发现的缺陷。重复运行并选择可比较的任务，能减少把一次有利结果误当成稳定收益的风险。

试点前就写好通过条件。对这个示例，可以要求检出预先移除的访问规则和数量限制，批准时没有未决的高影响设计问题，并为额外评审投入设定上限。未达标时，应缩小流程、调整评审指令，或停止在这类任务中使用它。

什么时候值得跑完整流程？

重要设计选择尚未确定，拖到实施后再解决又会付出较高成本时，我们才会使用完整 EGM 流程。行为已经清楚的任务适合更轻的路径。这符合项目按需使用技能的建议；是否保留流程，仍要看团队自己的交付数据。

我们建议的适用条件
工作类型	建议做法	理由
涉及权限或数据边界的新功能	试点完整设计与评审流程。	行为遗漏可能转化为昂贵的实施返工。
横跨现有模块的改动	结合当前源码评审规格。	兼容性和职责归属需要明确决定。
已有详细规格	从相关评审阶段开始。	重写有用的文档本身收益有限。
有精确失败测试的小修复	沿用正常修复、测试与评审流程。	预期行为可能已经确定。
尚未验证的产品想法	先验证用户需求，再细化实施。	设计自洽不能证明客户需求存在。

我们的建议

先选一个能明确列出未决问题的功能。用 EGM 把这些决定整理成可评审的材料，控制实施范围，再衡量新增评审是否值回成本。保留被否决的备选方案，让下一场会话不用重看整段讨论也能理解取舍。

Wavect 的 AI 工程落地服务可以围绕你的仓库和验收标准设计这样的试点。

实施完成后，EGM 的 drift-report 技能可以对照设计文档与当前源码，报告差异。结合测试结果检查偏离，并据此维护设计。

大象金鱼模型 EGM 常见问题

EGM 是 Google 新发布的大语言模型吗？

EGM 是为编程智能体提供技能、评审角色和文档标准的开源插件，没有新的模型权重。语言模型和工具来自你选择的运行环境。判断是否适合团队时，要评估整套配置，包括模型、权限和评审指令。

Elephant 和 Goldfish 必须使用不同模型吗？

核心要求是隔离对话上下文，Goldfish 不能继承起草设计的那段对话。是否换用另一个模型可以单独评估，但不能替代上下文隔离。两个模型读到同一份不完整规格，也可能漏掉同一个问题，仍需具体的验收检查与人工评审。

能直接评审已有的设计文档吗？

可以。评审技能接受指定文档，也允许选择当前需要的阶段。先确认文档解释了现有系统，并链接了所依赖的源码。如果还没有实施计划，应先评审功能设计，不能把尚未写明的实施细节当成已经完成的工作。

每条评审建议都必须接受吗？

不必。架构决定由工程师负责。结合需求与当前代码核对每条发现，处理问题，或记录选择另一条路径的理由。批评引入多余组件时，第二次全局检查尤其有用。报告更长、架构更复杂，都不能证明结果更好。

新上下文能保证评审没有偏差吗？

新上下文消除了此前对话带来的隐含知识，但不能保证独立推理、材料完整或结论正确。评审者可能共享模型局限，也可能误解同一项需求。使用明确标准，将发现与仓库证据核对，并由人承担重要决定的责任。

实施过程中改变了设计，该怎么处理？

在设计文档中记录需求变化或合理偏离，并关联对应的实现改动。EGM 的漂移报告可以帮助找到文档与源码的分歧。没有发现问题的报告不等于正确性证明；接受变更前，仍需运行验收测试并评审受影响的行为。