谷歌EGM插件:先写需求文档,再让智能体写代码

2026 年 10 月 22 日，Google Open Source Blog 发文介绍开源插件 Elephant-Goldfish Model（简称 EGM）。仓库在 GitHub：github.com 上的 google/elephant-goldfish-model，许可 Apache 2.0。它不是新发布的基座大模型，而是一套「先设计、再评审、最后才写代码」的智能体工作流插件。我对照了官方博客与 getting started 文档，未在自己环境实测。

01

PART

大象和金鱼分别干什么

ELEPHANT VS GOLDFISH

博客用两个隐喻：

Elephant（大象）：上下文很长的会话，负责共创架构与意图，这里规定不写代码，只讨论取舍、记下微决策。

Goldfish（金鱼）：无历史包袱的新会话，专门对着规格说明书找漏洞、挑边角，避免和「设计者」共用同一批盲点。

目标写得很直白：你希望按回车之后，模型第一次就写出你真正想要的代码——前提是规格已经写清楚。官方把这种转向概括成「Design is the new code」：在 AI 写代码越来越快的时候，人要守住的是系统设计与判断，而不是和模型比谁敲得快。

02

PART

插件自动化的三阶段

THREE PHASES

公开文档里的核心命令（不同宿主可能有前缀，如 /egm:）：

/egm-brainstorm：澄清概念，拉起多视角 Goldfish 压测想法，产出结构化概念简报。

/egm-draft：把想法写成 Markdown 设计文档（问题定义、技术方案、备选、改哪些文件的实现计划等）。

/egm-review：在全新零上下文会话里做理解复述、对抗式评审、实现就绪检查；反馈很多，文档建议你只吸收有用的部分。

之后仍强调 Human Review：设计文档走人工评审；实现阶段再让智能体按文档施工。另有 /egm-drift-report 用于设计与代码是否漂移的巡检，文档建议可当作周常维护项。

03

PART

能接到哪些工具

SUPPORTED HOSTS

getting started 写明可作插件用于 Antigravity、Claude Code、Claude Cowork、OpenAI Codex、ChatGPT Work 等（以仓库 Harnesses 说明为准）。博客称该插件源自 Google 内部工程实践，现已开源；「每天有多少 Googler 在用」是官方叙述，我无法独立审计。站点 egm.dev 亦有产品介绍入口，细节以仓库 README 为准。

04

PART

出海小团队怎么用才不形式主义

PRACTICAL USE

中等以上功能：先 /egm-brainstorm 再草稿，别一上来让模型直接改生产目录

简单 typo 或一行配置：文档自己也说不必强行走完整设计流

设计目录建议落在 docs/designs/，并保留人类可读的索引

对抗评审的长反馈要筛选，不要整段糊进实现提示

已有老仓库可用引导类命令自底向上生成 README，但仍要人审

和「先写测试再写代码」类似，EGM 把设计文档当成可评审的中间产物。许可是 Apache 2.0，二次分发与修改按许可证履行义务即可。

写设计文档时，我建议至少固定五块：背景与非目标、成功标准、方案与备选、接口与数据、分步改动的文件清单。Goldfish 评审若复述不清，优先改文档而不是催实现。团队协作时，把设计文档开成拉取请求，让另一个人在智能体之外再看一遍——官方流程本就把 Human Review 写进去了。对出海产品，还要在规格里单列：多语言文案、时区、支付与隐私字段，避免实现阶段才补洞。

05

PART

我的建议

MY TAKE

EGM 解决的是「智能体写得快、规格却糊」的问题，不是保证零缺陷。规格里要把文件路径、接口、失败态写死，评审才有靶子。请在所在地区合法可用的前提下使用相关智能体宿主。安装与命令以 GitHub 仓库和 Google Open Source Blog 原文为准；本文未跑通一遍完整评审。与其追新模型名，不如先逼自己把「要改哪些文件、成功长什么样」写进一页设计。

文档与代码漂移时，先决定以哪边为准：产品决策变了就改设计，实现偷懒了就改代码，最怕两边各改一半。周常跑一次漂移报告，成本通常低于线上返工。