让一条金鱼来审你的设计

你让 AI 写一份设计文档。写完，让它自己审一遍。它说：整体思路很棒，架构清晰，可以动手。

这句话的信息量是零。因为写的和审的是同一个记忆。它记得自己为什么这样设计，记得哪些选项被跳过、为什么跳过。让它重读文档，它读到的不是文档，是自己的回忆录。

Google 九月中开源了一个插件，专治这件事。名字起得直白：elephant-goldfish-model，大象-金鱼模型。到今天 47 天，6458 个 star。装好后两条命令：一条让大象工作，一条让金鱼工作。

大象写，金鱼审

大象是装着全部上下文的那个 agent。项目背景、历史决策、你半夜推翻的三版方案，都在它脑子里。它负责把想法打磨成设计文档。

金鱼是审查者，每次都是一条全新的：零对话历史，零记忆。它只拿两样东西——设计文档，和文档里明确引用的文件。它不知道你为什么这样设计。

这是刻意的。金鱼的健忘恰恰是它的专业能力。你和审查者每共享一个假设，就多一次「一起错」的机会：假设错了，两个人一起错，审查发现不了。

这件事有定量版本。二十一个准确率六成的分类器，错误彼此独立时，多数投票能到 82.6%；错误相关度升到一半，只剩 63.5%；几乎全相关时，退回 60%——集成等于没做。审查是同一道题：审查者和作者的错误越相关，审查越接近空转。金鱼做的事，说到底就是把审查的错误与作者的错误去相关。健忘是手段，不是缺陷。

六道镜头，一套禁令

流程分两段。第一段叫 brainstorm。你说一个半成品想法，大象先把你追问到问题边界清楚为止——一次回答不够就再问，明文禁止抛选择题敷衍。然后同时放出六条金鱼，六个视角：一个唱反调，问这功能真的需要存在吗、现成的库能不能解决九成问题；一个算成本配额，问峰值流量多大、token 预算打不打得住；剩下四个分别盯开发者体验、迁移兼容、可观测性和两年后的技术债——可观测性那条的问题清单里写着「凌晨三点被告警叫醒的 oncall 怎么排查」。意见汇总去重，落成一份概念简报。

第二段叫 review。拿设计文档跑五道审查：先来一道 zoom-out，怀疑论建筑师找过度设计；一道 comprehension，天真读者揪出每个没解释的术语；一道 design critic，敌意设计批评，专攻架构、扩展性和没兜住的风险；再来一道 zoom-out；最后一道 implementation readiness，务实的 tech lead 检查方案有没有把该做的决策留给写代码的人。

每条金鱼的人设文件开头三条是铁律：严格只读，不许改工作区，不许顺手把代码「修好」；零历史心态，把自己当成刚入职的陌生人；不许闲聊。

然后是禁令清单。不许说 brilliant、great、smart、correct、perfect、excellent、spot-on——对用户的任何输入、纠正和决定都不许。不许说 seamless、robust、blazingly fast，连 effortlessly、literally、drastically、obviously 这类副词都点了名。被质疑时不许道歉，「I'm sorry」被明文禁止，直接给修正后的技术逻辑。先说哪里错、缺什么、险在哪，再说优点。每个方案必须主动给出最强反方论证。默认立场是不同意，直到想法在审视下活下来。

这份词表读起来眼熟。过去一年大家给 AI 味列词表，高频词就这些。Google 把词表军备竞赛的成果写成了技能文件里标注 CRITICAL 的条款，连副词都没放过。

没有金鱼，就停止

整个项目最狠的一条规则，写在每份审查技能的委托节里：如果你的工具开不出新的子代理，就停下来，告诉用户——同一上下文里的审查，不是金鱼审查。

不降级，不凑合。宁可没有审查，不在原上下文里演一遍。

这句话值得单独读。同一个上下文里，AI 也能给你输出一份「审查报告」：格式齐全，语气严厉，列一堆「问题」。但那份报告和设计出自同一个记忆，验证者和被验对象共享全部错误来源——那不是审查，是复述。前两天的课里刚好有个反面教材：课程演示的「验证」把噪声手工加进总误差，两列小数点后四位恒等，看起来验证过，其实什么都没验。EGM 的规则反着立：验不了，就停。这一条比五道审查流程加起来都值钱。

它站在哪一层

这个插件不含任何模型，也不训练任何东西。全部内容是七个技能文件、九份审查者人设、一批文档标准模板，外加打包脚本，Apache 2.0。

它站在 harness 层。brainstorm 和 review 有一个硬前提：你的工具得能开「全新上下文的子代理」。Claude Code、Codex、ChatGPT Work、Antigravity 都行，方式各异。所以仓库里没有给每个工具一份改写过的技能文本——只有一份，各家自己把「开个子代理」翻译成自家工具。Codex 没有具名子代理，就让通用子代理先读人设文件再干活。

有个细节值得留意：Google 自家的 Antigravity 独立版 IDE 跑不了金鱼审查，因为它不提供开新子代理的工具。文档为此写了句话：别从产品名推断能力，去查实际的工具清单。

产出纪律也是接口式的：所有简报、草稿、审查报告一律写进文件，明文禁止直接贴在聊天里，聊天流里只给文件路径。

从散文到插件

源头是一篇散文：《大象、金鱼与软件工程的新黄金时代》，作者 Dave Rensin，Google 的 Distinguished Engineer，八月底发在 Medium，九月在密歇根大学 EECS 讲过一场。他把 Google 内部 agent 用法的演进写成寓言：大象扛上下文，金鱼扛审查。然后有人把寓言做成了插件。README 第一行是官方自述：数千名 Google 工程师在内部使用 EGM——这是 Google 自己的说法，没有独立核数——同一页底部照例一行免责：这不是官方支持的 Google 产品。

视频里要剥掉的部分：B 站标题的「联手 DeepSeek」出自片尾推广段，DeepSeek V4.1 Flash 只是博主自家转售套餐里可选的金鱼模型之一；ClinePass 带返利链接，PandaCode 是博主自己的项目，都不在开源插件范围内。视频说「约 2600 star」，那是录制时的快照，今天实抓 6458，一个半月翻了一倍多。

README 对自己的边界说得很直白：小而清楚的 bug 修复，走你正常的工作流，别用这套流程；一次完整审查要烧不少 token，五道金鱼同时放出去是有代价的；审查不替代测试，也不替代人的判断。

九份人设文件，没有一个负责夸你。