一句话看懂
Elephant‑Goldfish Model（后面简称 EGM）是一套插件,给 AI 编码助手加一道“写代码之前先把设计想清楚”的工序。它把这道工序拆成两个角色:一个记得住项目上下文的起草者,一个完全不知道前面讨论过什么的审查者。两者配合,在代码落地前把需求漂移和设计盲点挖出来。
仓库当前 4687 星,当日新增 1582,Fork 285,Open Issues 53,主语言 Python,License 为 Apache-2.0,创建于 2026 年 9 月 13 日。首个标记发布是 v0.1.0。
它解决什么问题
AI 编码助手写代码很快,但前提往往没谈透。开发者随口说一句“加个 webhook 投递功能”,助手就直接动手写实现,等代码出来才发现重试策略、鉴权方式、失败通知这些细节根本没讨论过。返工比不写代码还费时间。
EGM 把这个过程拆成三步:先用 egm-brainstorm 把需求聊清楚,产出一份概念简报;再用 egm-draft 把简报变成设计草案;最后用 egm-review 找一个没见过前面对话的代理,单独审查这份草案。审查者如果带着之前讨论的记忆,容易跟起草者一起忽略同样的假设。换成一个“没有记忆”的角色重新读草案,更容易挑出没写清楚的地方。
这套流程最终把审查通过的设计文档存进 docs/designs/,作为后续实现唯一依据的规格来源,减少代码和最初想法越写越偏的情况。
核心概念速览
Elephant:大象记忆好,这里指能持有完整项目上下文的角色。它读项目文件、看之前的讨论记录,在这个基础上起草需求简报和设计草案。
Goldfish:金鱼记忆短,这里指零上下文的审查子代理。它拿到草案时不知道任何前置讨论,只能靠草案本身的文字判断逻辑是否完整、假设是否说清楚。这种失忆式审查是刻意设计的,目的是模拟一个真正独立的第三方视角。
Skill:插件体系里每个可以单独调用的能力单元,比如 egm-brainstorm、egm-draft、egm-review,各自对应流程里的一步,在插件市场里单独管理和更新。
架构拆解
代码库按功能分成几块。skills/egm-brainstorm 负责和开发者对话,把零散的需求收敛成一份 concepts_brief.md。skills/egm-draft 读这份简报,产出 design_draft.md,过程中会逐段给出反馈,不是一股脑生成完整文档再扔出来。skills/egm-review 用一个新建的、没有历史记忆的代理,分五个阶段检查草案,包括清晰度、遗漏假设、和现有代码的匹配度等。agents 目录下的各类专家代理文件,定义了审查时具体扮演的角色,比如某个代理专注查安全假设,另一个专注查接口兼容性。
流程走向很直接:简报交给草案环节,草案交给审查环节,审查结果再交给 egm-resolve 去处理。scripts/pack_plugin.py 是构建脚本,把各个 skill 的资源打包进插件运行时目录和 ZIP 包,供 Antigravity、Claude Code、Codex 这些平台加载。
整体上这是一条单向流水线,没有分支逻辑,每一步的输出就是下一步唯一的输入。每个环节职责很窄,出问题时容易定位是哪一步出的偏差。
关键实现走读
看一段 scripts/pack_plugin.py 里的打包函数:
def build(root: Path, target: str, output: Path) -> tuple[Path, Path]:
"""Write a new runtime folder and ZIP; refuse unsafe inputs or overwrites."""
root = root.resolve()
folder = output.resolve() / f"egm-{target}"
archive = folder.with_suffix(".zip")
if any(path.exists() or path.is_symlink() for path in (folder, archive)):
raise ValueError("Output folder or ZIP already exists")
if folder == root or root.is_relative_to(folder):
raise ValueError("Output must not contain the source tree")
这段代码在正式写文件之前,先检查目标文件夹和 ZIP 是否已经存在,也检查目标路径是不是源代码目录本身或者源代码目录的子路径。撞上这几种情况,立刻抛异常,不往下执行。
打包脚本会往磁盘写东西,写之前不检查,容易悄悄覆盖掉已有文件,或者把输出目录套进源码目录里形成循环引用。用 resolve() 把路径都转成绝对路径再比较,避免相对路径或者软链接伪装出的路径绕过检查。
如果少了这段校验,重复执行打包命令可能直接覆盖掉之前的发布包而不报错,或者在输出目录设置不当时把源码目录本身当成输出目标,写出一个包含自身的死循环结构,排查起来会很麻烦。这种校验代码量不大,但决定了这个脚本能不能放心反复跑。
动手上手
先在目标平台装插件,三条路径分别对应 Antigravity、Claude Code、Codex:
agy plugin install https://github.com/google/elephant-goldfish-model
claude plugin marketplace add google/elephant-goldfish-model
claude plugin install egm@egm
codex plugin marketplace add google/elephant-goldfish-model
codex plugin add egm@egm
可验证结果:执行完上面任意一组命令后,对应平台的插件列表里应该能看到 egm,说明安装成功。
装好之后在对话里依次调用三个命令:
/egm-brainstorm Add webhook delivery to this project.
可验证结果:应该得到一份梳理过的需求讨论,最终写出 concepts_brief.md。
/egm-draft
可验证结果:基于上一步的简报生成 design_draft.md,过程中会分段给反馈,不是一次性甩出整份文档。
/egm-review design_draft.md
可验证结果:一个新建的审查代理给出清晰度、实现风险方面的具体意见,这些意见不依赖你和 brainstorm、draft 阶段的历史对话。
应用场景
做一个新功能,比如给现有项目加 webhook 投递,用 brainstorm 把权衡方案聊清楚,再用 draft 把结论变成文档,这是 EGM 最直接的用法。
代码写之前先过一遍审查,让没见过前面讨论的代理检查设计是否完整、是否可实现,这一步可以在团队内部评审之前先做一轮,减少明显遗漏被带到人工评审会上。
README 里特别提到,小而清晰的 bug 修复不建议走这套流程,直接用常规编码方式处理就行,EGM 针对的是需要设计决策的改动。
独立分析
零上下文审查这个设计思路本身是站得住的。人在评审自己参与讨论过的方案时,容易被最初的思路框住,看不出那些讨论里默认成立、但实际没验证过的假设。找一个完全没参与讨论的角色重新读文档,相当于用读者视角替代作者视角,这种方法在写作编辑和代码评审里都有先例,EGM 把它做成了可重复调用的流程,而不是每次都要临时找人帮忙看。
和常规编码流程比,EGM 多出来的成本是时间。三步走完才能开始写代码,对于需求本身已经很清楚的任务,这个流程反而拖慢节奏,这也是 README 建议小修复绕开它的原因。它更适合那些说不清楚具体要什么的任务,流程的价值在厘清需求,不在加速编码。
局限与风险
审查环节要求能创建一个全新的、没有历史记忆的子代理会话,如果所在平台不支持这种隔离的会话机制,审查的零上下文效果就打折扣。
审查给出的意见仍然是 AI 生成的,不能替代实际测试和人工判断,草案通过审查不等于代码实现后就没有问题。
发布说明里提到,针对发布 ZIP 包的宿主校验方式目前还没有最终确定,这部分后续可能还会调整。
结论卡片
适合需要在写代码前做设计决策的工程师或团队,尤其是用 Claude、Codex 这类 AI 编码助手且希望流程留痕的场景。只需要修复明确小 bug 的开发者用不上这套流程,直接改代码更快。建议的使用顺序是先跑 brainstorm 和 draft 出草案,再用 review 走一遍审查,最后把通过的文档存进 docs/designs/ 作为实现依据。
原文地址：tools.wflynn.cn/aitools/git…
关注公众号「YourTools」，每天推送 GitHub 趋势与开源工具速报：
