又一顶级插件火了,数千名Google工程师在用:让一个失忆的AI来审你的设计.

大家好，我是Bite。

最近逛技术网站，看到一个案例：一个公司做支付对账，agent 写了个失败重试方案，自己审自己，结论是"设计合理"。上线三天，同一笔订单被扣了两次钱。重试必须幂等这件事，文档里一个字没提。

看完之后我就琢磨，这个问题出在哪里。我的判断是它不是没能力发现，它是记得自己为什么那么写，所以觉得那么写挺对。

今天就推荐一个插件：EGM。Google出品，它就是专门来想解决类似问题。它的办法有点反常：换个失忆的来审。

它在干什么

写代码之前，先让一个记性很好的 agent 把设计写下来，再让一群"失忆"的 agent来挑刺。

大象拿着项目的全部上下文历史决策、代码结构、踩过的坑负责起草。金鱼只拿到那份文档和文档里引用的源码，看不到你们前面聊了什么。那些"大家都心里有数、但没人写下来"的假设，才会被拎出来：重试几次、超时多久、失败了算谁的。

官方文档里写着 "Thousands of Google engineers use EGM"，仓库挂在 google 组织下，作者也是 Google 的人。但同一份官方文档末尾还有一行：不是官方支持产品。

两句不矛盾：公司里有人在用，和公司为它背书，是两回事。写选型汇报建议照抄这个口径。

理论底子来自 Google 工程师 Dave Rensin 的同名文章，不是拍脑袋攒的提示词。

三个值得借鉴的设计

1、评审者的权限是被剥夺过的。

金鱼的 persona 文件开头三条硬约束：严格只读（没有任何写文件、编译代码的工具，"不要试图修复或重构"）、无状态心态（把文档当刚入职的新人读）、不寒暄。

只读这条是关键。会写代码的评审者，审着审着就开始动手改，改着改着就把自己的理解塞进去了那还是自己审自己。

更狠的是 brainstorm 技能里那串禁令：不许说 great、brilliant、smart、perfect；不许道歉；必须先说问题再说优点；不许复述你的框架；每条建议要附反论；只有扛过检验才允许同意。

一个被明确禁止夸你的评审者，和一个默认礼貌的助手，问出来的东西不是一回事。

2、五个阶段，外加一道"只准再审一次"的刹车。

/egm-review 跑五道关，编号从 5 到 9：

两处细节值得说。Zoom Out 那位被要求真的去代码库里搜：设计每提一个新模块，得先查有没有现成的，有就建议复用。Comprehension 那位用"复述法"：先用自己的话把文档讲一遍，讲不出来直接判 Blocker——官方给的理由很到位，列术语清单抓不住"词都定义了、但段落接不上"的文档，复述能抓住。

然后是刹车：1-Audit Convergence Cap，每阶段重审上限 1 次。挑完一轮毛病、你改完，它只再审一次就往下走。做过评审的人看到这条会笑，这才是防止流程变成形式主义的关键。

3、设计文档是要进仓库的，还要定期查漂移。

批准后的规格落到 docs/designs/，跟着代码一起提 PR。之后每周跑一次 /egm-drift-report，比对文档和当前源码，谁飘了改谁，由人定。

这个仓库自己就是证据。docs/designs/architecture.md 顶上写着作者、状态、日期，末尾的Alternatives Considered记了两条被否掉的路线，其中一条是"在同一线程里串行跑评审"，否掉的理由是：上下文会严重退化，模型会替自己的错误辩护

它拿自己那套流程，写了自己那份架构文档。

更进一步的是 AI_POLICY.md：改动超过 100 行非测试代码、或动了 skills/、agents/ 里 3 个以上核心文件，必须先走一遍 EGM 设计流程——先拿 design-ready，再用 /egm-brainstorm、/egm-draft、/egm-review 写出设计文档 PR 拿 pr-ready，最后才轮到实现 PR。还堵了个口子：不许把功能拆成两个 60 行 PR 绕过门槛。

工具能约束流程，制度才能约束人。这一步比七个技能本身有意思。

安装与配置

它是一套插件，按手上的 agent 选一条：

# Antigravity CLIagy plugin install https://github.com/google/elephant-goldfish-model# Claude Codeclaude plugin marketplace add google/elephant-goldfish-modelclaude plugin install egm@egm# Codexcodex plugin marketplace add google/elephant-goldfish-modelcodex plugin add egm@egm

整包装，别只拷 skills/。 官方专门警告过：技能运行时要读 agents/ 的评审人设和 resources/document_standards/ 的评分标准，只装 skills 目录，跑起来是残的。

装完新开会话，四步走：

/egm-brainstorm 给这个项目加 webhook 投递/egm-draft/egm-review design_draft.md

brainstorm 先跟你把需求问清楚，同时开六个视角轰一轮：YAGNI（非做不可吗）、成本与配额、UX 与开发者体验、迁移与兼容、可观测性、长期技术债。

draft 逐节写，每节停下来等意见。review 交给金鱼，出一堆报告，挑你认的改。

另外四个技能可以单用：resolve（逐条处理评审意见）、bootstrap（给老代码库补文档）、review-loop（按配置的评审组跑）、drift-report（查漂移）。

谁适合上

• 做接口契约、幂等、权限模型这类"想错一次改半年"的设计
• 老代码库要补设计文档：bootstrap 先把 README 树铺出来，Elephant 才有上下文
• 团队想把设计文档从可选变成流程：直接抄 AI_POLICY.md 那套阈值和标签

存在的问题

1、你的 agent 得开得出新 subagent，否则评审直接停。

不是"能力弱一点降级运行"，是硬停。官方写得很直白：harness 没有 subagent 工具，评审技能会停下来告诉你——同一个上下文里跑的评审，不叫金鱼评审。活例子就在支持列表里：Antigravity IDE 独立版明确标着 Not supported，因为它不暴露 invoke_subagent。App 和 VS Code 扩展版可以，独立版不行。先确认手上是哪个。

2、它不是 Google 官方支持产品。

官方文档结尾那句就是字面意思。代码归 Google 组织，用的人也在 Google，但出问题没有官方支持通道。

3、反馈量是真的大。

官方自己写：评审会给你相当多的反馈，"取你认为相关的，忽略其余的"。噪音得自己筛，文档糙一点，一轮几十条不奇怪。

4、它的测试记录诚实到有点扎心。

TESTING.md 逐条记着各家 agent 的实测，通过的和没通过的都留着：Claude Cowork 跑到 Stage 8 被用量限制打断，最终产物、Stage 9 和隔离子进程输出都标了"未验证"；Antigravity 那次 16 个原生评审跑了、五份报告都在、代码一行没写，但交互式审批和 synthesizer 嵌套没测；omp 那栏写着"社区验证，非 fixture 运行"。

把失败写进记录值得尊敬，但也说明：各家 agent 上的完整链路，还没全部跑通验证。

个人观点

这项目真正有价值的地方不在七个技能，而在一句能被抄走的话：评审者不该记得自己为什么那么写。

我们花很多时间教 AI 写得更像人，却很少想它该怎么"忘"。上下文是资产，也是包袱，同一个线程里，它替你辩护的力度和替你挑错的力度，往往是反的。EGM 把两件事拆给两个角色，用一份文档当传递介质，再用"只读"和"禁夸"绑住评审者的手脚。

这设计不新鲜，代码评审、红蓝对抗、审计岗，本质都是"换个没包袱的人来看"。它只是把这套制度翻译成了 agent 能执行的规则。

至于要不要现在上：当方法论学，现在就能用；当生产流程压，再等几个版本。 0.1.0、五天前才发头一个 release、强依赖 subagent 能力——不致命，但足够你在生产里踩坑。

如果只想先试一件事，建议把"禁止夸我"那几条抄进自己的提示词。零成本，当天就有感觉。

大部分 skill 在教 agent 做事，它在教 agent 怎么反对你。