---
title: "大象金鱼模型 EGM：设计评审、成本与局限"
canonical: https://wavect.io/zh/blog/elephant-goldfish-model-design-review/
language: zh
description: "Google 大象金鱼模型 EGM 怎么用？了解五阶段设计评审、Claude Code 安装、上下文隔离与局限。通过租户 CSV 导出示例、验收检查和假设成本计算，判断团队是否值得试点。"
image: "https://wavect.io/img/blog/headers/header_elephant-goldfish-model-design-review.png"
author: ["Kevin Riedl"]
published: "2026-11-02"
updated: "2026-11-02"
reviewed: "2026-11-02"
---

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

[**返回**](/zh/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/)

[Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt

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

[**下一篇**](/zh/blog/github-spec-kit-production-guide/)

要点速览

Google 的大象金鱼模型 EGM 让掌握项目背景的智能体起草设计，再由新会话评审文档及引用源码。五个阶段也检查过度设计，工程师批准后才实施。本文依据源码，提供假设中的租户 CSV 导出与试点方案；插件开源，模型用量和评审时间仍有成本，应衡量能否减少返工。

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

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

Google 于 [2026 年 10 月 22 日宣布开源 EGM](https://opensource.googleblog.com/2026/10/introducing-elephant-goldfish-model-plugin.html) ，并表示数千名工程师每天用它交付生产代码。这是 Google 报告的使用情况，不能据此推算缺陷减少了多少。

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

## 大象金鱼模型 EGM 是什么？

EGM 通过隔离对话历史，把设计与评审分开。 [项目 README](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/README.md) 将项目背景交给 Elephant，将独立文档评审交给 Goldfish，将架构决定留给人。EGM 提供智能体技能和操作指令，没有发布新的语言模型权重。

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

“大象”并不意味着无限记忆。 [起草技能](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/skills/egm-draft/SKILL.md) 明确考虑了新会话接手的情况，要求智能体从简报中重新读取被否决的备选方案。上下文靠书面决定传递。我们的 [编程智能体仓库上下文指南](/zh/blog/ai-coding-agents-context-not-intelligence/) 进一步解释了这类交接需要哪些工程工作。

“不写代码”也有具体范围。 [EGM 执行指令](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/resources/execution_instructions.md) 禁止在设计阶段修改生产实现，但允许在 Markdown 或临时草稿中编写明确标注的示例代码。接口示例可以帮助确定方案，生产实现仍留到设计获批之后。

## brainstorm、draft 和 review 怎么衔接？

EGM 把讨论整理成另一场会话也能理解的规格。 [官方工作流指南](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/docs/getting_started.md) 给出了核心顺序，也允许团队按需要单独使用某项技能。

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

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

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

当前 [EGM 评审技能](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/skills/egm-review/SKILL.md) 分五个阶段检查架构方向、文档理解、设计质量、多余复杂性和实施准备情况。表中的 CSV 导出问题是示例，不是实际运行评审得到的结果。

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

[理解检查的评审者](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/agents/comprehension.md) 必须分别复述方案，以及文档所描述的现有系统。无法解释某个章节，就属于阻断项。如果复述与你的本意不同，应检查文档漏写了哪一层关系。

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

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

第二次全局检查有必要，因为批评本身也可能增加复杂性。 [Zoom Out 标准](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/resources/document_standards/zoom-out-standard.md) 要求拒绝为假想需求增加的功能，避免过早引入基础设施，并复用已有组件。详细评审结束后，还要核对修改后的设计是否仍围绕原来的问题。

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

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

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

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

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

| 决定 | 规格示例 | 验收检查 |
| --- | --- | --- |
| 访问权限 | 要求 `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 的 [实施就绪标准](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/resources/document_standards/implementation-readiness-standard.md) 要求确定设计选择、列明文件、精确描述改动并给出具体测试。每个增量阶段结束后，项目还应保持可构建、可测试。这是计划的质量目标，不能保证生成代码一次就写对。

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

实施完成后，仍要对 [AI 生成代码进行独立 QA](/zh/blog/qa-for-ai-generated-code/) 。规格审得清楚，代码也可能实现错误。

## EGM 怎么安装和使用？

先确认编程环境能创建全新上下文的子智能体，再安装完整 EGM 插件。 [安装与运行环境指南](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/docs/harnesses.md) 提醒，只复制技能目录会漏掉评审角色和文档标准。以下命令来自我们在 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 许可证](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/LICENSE) 。运行时仍会消耗编程智能体的额度或 API 用量，以及团队的评审时间。仓库也明确说明，它不是 Google 正式支持的产品。

[项目测试手册](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/TESTING.md) 记录了插件结构和部分原生运行路径的检查。这些结果不能证明所有团队的交付时间或漏出缺陷都会减少。 [官方 FAQ](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/docs/faq.md) 也承认评审可能成为瓶颈，建议衡量有效发现和返工。

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

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

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

## 团队应该怎样试点 EGM？

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

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

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

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

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

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

## 我们的建议

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

Wavect 的 [AI 工程落地服务](/zh/services/ai-enablement/) 可以围绕你的仓库和验收标准设计这样的试点。

实施完成后， [EGM 的 drift-report 技能](https://github.com/google/elephant-goldfish-model/blob/403d8881d62022490637d740657b33f01e321ea8/skills/egm-drift-report/SKILL.md) 可以对照设计文档与当前源码，报告差异。结合测试结果检查偏离，并据此维护设计。

## 大象金鱼模型 EGM 常见问题

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

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

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

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

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

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

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

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

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

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

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

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

QA 与生产就绪

## 接下来读什么

可靠生产软件所需的测试、审计、维护与加固。

[从这里开始**AI 生成代码的 QA**](/zh/blog/qa-for-ai-generated-code/)

- [LangSmith Trace 保留：采样、评估与成本](/zh/blog/langsmith-trace-retention-sampling-cost/)
- [2026 年奥地利软件开发与 QA 公司：4 家服务商对比](/zh/blog/software-agencies-austria-development-qa/)
- [Ultramarine 1 Flash 文档智能体迁移指南：价格、API 限制与验收测试](/zh/blog/ultramarine-1-flash-api-document-workflows/)
- [Greptile Base、Plus、Apex：如何分配 PR 审查预算](/zh/blog/greptile-base-plus-apex-review-budget/)
- [Arga Labs 与 Archal：有状态智能体集成测试](/zh/blog/arga-vs-archal-agent-integration-testing/)

[下一篇文章**LangSmith Trace 保留：采样、评估与成本**](/zh/blog/langsmith-trace-retention-sampling-cost/)

[**返回**](/zh/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/)

[Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt

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

[**下一篇**](/zh/blog/github-spec-kit-production-guide/)
