谷歌开源Elephant-Goldfish：用规格驱动开发破解AI编程对话偏见

一位开发者在Reddit上分享了他坚持一年多的习惯：在让Claude写代码之前，先花一整天甚至更长时间，把项目计划写成一份详尽的Markdown规格文件。他最近的一个项目因此避免了架构层面的重大返工——初稿打算用嵌入式Axum mTLS服务器做同步，在写规格的过程中发现改用iroh（QUIC）按Ed25519公钥拨号加mDNS的方案要干净得多，省下了数周的无效代码。

这个习惯背后是一个被广泛忽视的问题：AI编程助手天然存在"对话偏见"。你让它开始写代码，它就会顺着你已有的对话上下文往下写，越写越偏，到第三天你被困在一个150条消息的线程里，修一个bug崩两个功能。谷歌刚刚开源的Elephant-Goldfish Model（EGM）插件，正是冲着这个痛点来的。

对话偏见的本质：模型太擅长迎合你

理解EGM的价值，需要先看清楚问题的根源。大模型在对话中会不断累积上下文，每一个决策都建立在之前的聊天记录之上。这带来一种隐蔽的锁定效应：你在第三轮对话里随口提的一个假设，会成为第二十轮代码生成时不可质疑的前提。模型不会主动挑战你，它更倾向于让对话流畅进行。

这位开发者的应对方式是写规格。规格文件是一个脱离对话的、可独立审阅的产物，它迫使你在动手之前把架构、加密、同步策略想清楚。他在项目里明确锁定了Ed25519/X25519密钥存于操作系统钥匙串（不依赖云账户）、用SQLite outbox触发器配合混合逻辑时钟（HLC）做字段级冲突合并、以及一份签名的团队成员日志在移除成员时轮换vault密钥。这些决策如果放在对话里临时决定，几乎不可能达到同样的严谨度。

EGM把这个流程拆成了两个性格截然不同的角色。

混合逻辑时钟（HLC） 是一种结合物理时钟与逻辑时钟的分布式时间戳机制，常用于需要跨设备同步的本地优先（local-first）应用。它由物理时间分量和逻辑计数器组成：当本地事件发生时，物理分量取当前系统时间，逻辑计数器递增；当收到远程事件时，取两者物理时间的较大值，并保证逻辑计数器大于双方已知的最大值。这样既保留了接近真实时间的可读性，又能在时钟漂移或回拨时维持事件的因果顺序。在SQLite outbox触发器配合字段级冲突合并的场景中，HLC为每条变更打上全局可比较的时间戳，使不同设备对同一字段的并发修改能够按确定规则合并，而无需依赖中心服务器授时。

大象与金鱼：两种刻意对立的工作模式

EGM的设计思路来自Dave Rensin的一篇随笔，核心是用角色分离来对抗对话偏见。

大象（/egm-brainstorm、/egm-draft） 负责长上下文会话，通过访谈的方式向你提问，最终写出一份Markdown规格。它有一条严格规则：不写任何代码。这把规格阶段和实现阶段彻底隔开，避免模型在"想清楚"之前就滑入"写出来"的模式。

金鱼（/egm-review） 则完全相反。它派生出无状态的子代理，这些子代理对你之前的头脑风暴对话零记忆，只冷读你的.md规格和代码仓库，以对抗性评审者的姿态出现，专门挑出边界情况和模糊之处。零记忆是关键——如果评审者读过你的思考过程，它就会继承你的偏见，评审也就失去了意义。

这两者的对立不是噱头。大象的记忆越完整，规格越周到；金鱼的记忆越干净，评审越尖锐。同一个模型通过上下文隔离，被塑造成了两个互不妥协的立场。

子代理（subagent）与上下文隔离 是当前AI编程工具中的一种常见编排模式：主代理负责与用户交互并维护完整对话历史，子代理则由主代理派生，拥有独立的、通常为空的上下文窗口，只接收主代理显式传入的任务描述和文件内容。子代理完成后将结果返回主代理，其内部推理过程不会污染主对话。这种机制的价值在于把“执行者”和“审查者”的认知状态分开——审查者看不到决策的来龙去脉，只能基于产物本身判断，从而避免因了解动机而产生确认偏误。EGM的金鱼角色正是利用子代理的零记忆特性，让评审只依赖规格和代码这两个客观对象。

漂移检测：让代码对规格负责

第三个组件是漂移报告（/egm-drift-report），它把最终代码的diff和.md规格做比对。

这个功能解决的是规格驱动开发里最实际的问题：写了规格，但代码跑偏了。规格写在前面，实现过程中总有各种"顺手改一下"的诱惑，改动累积起来，最终交付的东西和当初想清楚的东西已经不是一回事。漂移报告把这种偏离显性化，让规格从一份写完就束之高阁的文档，变成可以持续校验的契约。

从工程角度看，这三个组件构成了一个闭环：大象产出规格，金鱼用零上下文审视规格，漂移报告用规格审视代码。每一环都在减少对话历史带来的污染。

规格驱动开发（Spec-Driven Development） 借鉴了契约式设计和行为驱动开发（BDD）的思路：在实现之前先以可审阅的文本形式固定接口、数据模型、边界条件和验收标准，后续开发与评审都以这份规格为基准。与传统需求文档不同，规格驱动开发强调规格是“活的契约”——它需要足够具体到能指导代码生成，又要能被工具机械地比对。在AI编程场景下，规格还承担了另一个作用：它把关键决策从易变的对话上下文中抽离出来，成为模型每次生成代码时可以重新读取的稳定事实来源，从而降低长对话中早期假设被无意篡改的风险。

规格驱动开发正在成为工程共识

这位开发者在帖子最后抛出了两个问题：有多少人会在写代码前保留一份project_plan.md？有没有人开始用零上下文的评审子代理来审规格？

这两个问题指向同一个趋势。随着AI编程从"vibe coding"的快速原型阶段走向需要长期维护的工程项目，靠对话即兴推进的局限性越来越明显。规格文件的价值不在于它多正式，而在于它把决策从易变的对话上下文里抽离出来，变成可以反复审阅、可以被独立角色批判、可以被机械比对的静态产物。

EGM的意义可能不在于它本身有多复杂——它本质上是几个围绕Markdown文件组织的提示词工作流。它真正提供的是一种可复制的工程纪律：先想清楚，用零偏见的视角检查，再让代码接受规格的审判。对于已经在用规格文件的人来说，这是一次流程的正式化；对于还在对话里打转的人来说，这或许是一个值得尝试的起点。