核心机制：为何审查需要“断舍离”

谷歌在10月22日通过Open Source Blog公布了一款名为大象鲸鱼模型（Elephant-Whale Model, EGM）的开源插件。需要明确的是，EGM并非发布新的基础模型权重，而是提供了一套软件设计与审查流程的工具。其核心逻辑在于将代码生成前的决策过程与后续的独立检查分离开来，旨在解决AI生成的代码虽然速度快，但往往缺乏可交接性的问题。在传统的开发模式中，开发者倾向于让AI工具保留长期的聊天记忆以维持上下文连贯性，但这会导致审查者难以独立理解系统架构。EGM通过引入两个角色来解决这一矛盾：一个负责保留项目历史的大象（Elephant），另一个则从全新上下文开始的金鱼（Whale）。大象参与需求讨论并整理设计，而金鱼仅根据拿到的文件和引用材料进行独立审查。这种机制强制将关键前提从对话窗口中剥离出来，确保任何新接手的人都能在不依赖“共同记忆”的情况下理解系统。

“AI已经能很快写出一个功能，谷歌却把一个步骤专门放在写代码之前，让另一批没参与讨论的AI先来挑毛病。”

这种设计背后的深层原因是工程交接的本质要求。如果错误方向已经扩散到多个模块，后期的修改成本将远超早期补写规则的成本。长时间聊天会积累一种隐性负担：人和AI讨论过许多细节，后来就默认某些事情不必再解释。文档里的一个简短结论在原对话里有完整来由，但新接手的人却看不到。双方说已经达成共识不代表这份共识已经离开聊天窗口。工程要能够交接，就需要把关键前提留下来。EGM试图让设计讨论中的默认前提更早显露出来，而不必等代码完成后再发现理解不同。金鱼并非什么都不能看，它需要设计文档，也可以读取其中引用的源码或明确给出的材料，但它缺少的是先前共同讨论形成的熟悉感。审查者如果必须翻遍旧聊天才能明白一句话，问题就已经出现了。一个能交接的方案应当把实施所需的关键条件写在可以找到的地方。

设计阶段：从模糊需求到明确边界

在代码生成之前，EGM强调通过大象角色厘清业务规则和技术约束。以消息回调功能为例，平台要把事件送到客户系统，正常情况下发过去并得到成功回应就结束。但如果客户暂时没有回应怎么办？同一事件发了两遍怎么办？事件先后顺序变了怎么办？这些问题没有一个必须等写代码才能提出，却会直接影响数据结构和业务行为。设计阶段把它们摆出来，后面的实现才有共同依据。这里不能要求AI凭空决定所有业务规则，失败后允许重试多久、重复事件会不会造成重复扣费，取决于系统用途和风险。模型可以列出方案与后果，最终责任仍属于做决定的人。如果开发者只说按最佳实践处理，可能会把本该明确选择的规则交给实现阶段临时猜测。

因此，大象阶段的首先任务是把问题问清：需求的使用者是谁？什么情况算成功？哪些事情本次不做，都值得讨论。排除范围尤其重要。一个看似小的功能很容易在不断补充要求后变成跨系统改造，没有停止条件。AI越能生成团队越容易接受超出本次目标的工作，最后却不知道怎样验收。设计还要保留没有采用的方案，某种存储方式为什么被放弃、某个接口为什么暂时不扩展。这些理由能够帮助后来的人判断限制是否仍然有效。只留下最终答案容易让人误以为所有约束都来自技术本身，业务变化以后有依据的取舍可以重新讨论。缺少记录的取舍就只能重新拆解。

“设计文档应把这种分歧变成可以确认的行为，避免带进代码。”

接下来才把共识写成规格。这里需要的是能够支持决定和实现的内容，而非尽可能厚的文档。每一节最好回答具体问题：正常行为怎样发生？异常行为怎样结束？哪些状态能够被观察。文档如果只重复可靠、高效和可扩展，读者仍然不知道系统在失败时应该做什么。形容词不能承担接口约定，同一个词也可能隐藏不同理解。例如“可靠送达”，有人理解为不断重试直到成功，有人理解为重试失败后能够查询。前者需要考虑持续占用资源，后者需要设计失败记录和人工处理入口。双方都觉得自己听懂了，实际实现却可能完全不同。继续沿着回调例子看，如果客户处理成功但回应在途中丢失，发送方可能以为失败并重试。接收方需要知道这是否是同一个事件。设计阶段因此可能要确认事件标识、有效期和重复处理规则。这里讨论的是一个假设场景，目的在于说明需求如何影响结构。在考虑客户系统长时间不可用时，队列会持续积累，允许积累到什么程度、是否影响其他客户、恢复后怎样处理历史事件都需要明确。一个功能在演示里只发送一条消息，往往看不到这些问题。审查者如果能够改变条件来提问，就可以帮助团队检查方案究竟覆盖了正常路径还是也考虑了失效后的行为。

审查机制：独立上下文与复述验证

EGM的核心理念在于利用“金鱼”角色的新上下文来检查设计文档的一致性。理解测试很适合检查这类问题：一个没有参与讨论的审查者尝试根据文档复述系统的目标与结构。如果复述与设计者预期不同，就能定位歧义。这个动作看起来朴素，却比让模型回答有没有问题更具体。理解是否一致有了能够逐项比较的对象，设计者也更容易知道该补哪一段。复述的很流畅仍然不代表理解一定正确，AI可能用熟悉的工程模式补齐空白让不完整的文档显得完整。因此审查结果需要回到原文检查每个关键判断依据在哪里。一个判断如果来自尝试推断而不是文档，应当被标出来。否则设计遗漏可能只是从一个模型的默认前提转移到另一个模型的默认前提。这也解释了为何新上下文不等于绝对客观，同一种基础模型仍可能分享相近的知识和错误倾向。换个聊天窗口无法消除全部共性，金鱼的作用是减少对前面对话的依赖为检查增加一个角度。它能发现什么仍受到输入质量和模型能力限制，独立上下文是一项设计条件，不能包装成审查永不漏错的证明。

进入批判审查以后，不同角色会从不同角度检查方案：设计是否存在矛盾？模块关系是否合理？表达是否留下歧义都可以分别检查。分工的好处是让问题更集中，代价则是可能收到互相冲突的意见。多个审查者都提出意见并不自动构成一个可以执行的决定，仍然需要有人判断轻重与适用范围。假设一个审查者要求增加缓存，另一个担心数据过期。两边的意见可能都合理也可能都不适合当前规模，团队需要根据真实目标选择。不能把所有建议机械地加进方案。审查系统的价值在于帮助看见此前没有充分考虑的后果，把每个建议都落实反而可能让原本简单的功能变得难以维护。发现问题以后还要分清缺陷与偏好，需求之间冲突可能阻止实现。命名是否好看未必值得拖延项目。某个模型偏爱特定架构也不能因为写成了审查报告就获得优先权，意见应该指向文档位置说明影响和依据。越能具体解释的问题越容易被复核也越不需要依赖审查者的气势。

“一个总是给出完整答案的代理，可能比一个明确留下证据缺口的代理更难用于可靠交接。”

项目提供处理审查结果的工具，帮助把问题带回设计讨论。这里仍需要人选择是接受或修改意见还是保留现有取舍。被否决的意见也可以留下理由避免下一轮反复争论。审查结束的标志应当是重要问题已经得到处理或者风险被明确接受。报告文件生成成功只能说明产生了报告不能说明系统已经准备上线。

实施与验证：从文档到代码的闭环

当前工作流还安排了整体检查和实施准备检查。前者帮助确认文档没有在局部修改中偏离原目标，后者关注实施所需的信息是否明确。一个方案可能逻辑上成立却没有说清具体改哪里，编码工具因此仍会临时决定接口和结构。实施计划要减少这种无意义的自由发挥，但也不必在高层设计里提前写完所有代码。高层设计和详细计划各有用途：前者让人理解系统为什么这样组织，后者让实施者知道工作如何落地。把大量函数细节塞进开头可能掩盖重要取舍，计划只写几个抽象目标又无法支持执行。两层之间需要能够对应。读者看完理由以后可以继续找到相关模块，实施者也能知道某项约束来自哪里。

现有项目还需要检查设计与代码的实际关系。文档可能描述旧接口代码已经改过，也可能实现时新增了条件却没有更新说明。EGM的漂移报告关注这种偏离。但偏离不必然等于错误，有时是合理调整有时确实遗漏了要求。报告提供线索结论要结合版本和改动理由判断。这使得规格不再只是写完以后归档的文件，它需要随系统变化保留适用版本和重要决定。维护文档也有成本最有效的做法通常是聚焦关键边界而非把每一行实现重复写一遍。文档应帮助读者理解和检验系统，不能变成与代码并行却长期不一致的第二套想象。

“真正的新上下文也是使用条件，官方环境说明要求宿主能够创建独立子代理。”

没有相应能力时审查应停止。让同一个对话里的AI声称现在已经忘记前文无法提供同样的隔离。判断支持程度要检查实际工具能力不能只看产品名字。客户端能安装插件也不自动说明每项审查已经完成验证。仓库列出了不同开发环境的支持情况同时保留了部分验证缺口，这种区分有实际意义。安装成功、角色隔离正常和端到端流程通过是不同测试团队采用时应该核对自己要使用的部分。不把其他环境的成绩直接套过来，公开文档写出限制反而有助于决定先试哪个场景。哪些工作仍需要人工接手。代码采用Apache2.0许可让开发者能够在相应条款下使用与修改，但开源许可不等于支持合同。项目也注明它不是Google正式支持的产品。运行它仍然依赖已有模型和开发环境，调用费用也不会因插件免费公开就消失。评估成本时应把审查增加的调用和人的处理时间一起计算。

适用场景与团队实践建议

这个成本问题决定了适用范围。跨模块功能如果走错方向返工可能很贵提前审查就更有价值。一个边界清楚的小修复完整流程却可能比修改本身还费时。项目也建议这类工作采用正常编码流程，把工具用在错误场景既会增加负担也容易让团队误以为所有设计审查都只是形式主义。团队可以先拿一个实际功能试行，记录审查发现了什么修正花了多久哪些建议最终没有采用。重点观察是否更早发现了昂贵问题而不止统计产出了多少页文档。

报告数量容易增长，问题是否减少需要证据。若没有这种反馈审查流程也可能像代码生成一样只是把产出速度提高了。通过审查之后测试依然要做，文档约定的行为需要落实到实现。测试则检查实际程序是否遵守两者可以互相提供依据却不能互相替代。一个规格写的很清楚的重试机制也可能在实现里漏掉边界条件，一组全部通过的测试也可能遗漏需求没有明确的情况。设计和验证需要形成对应关系。可观察性也应该进入方案，如果错误发生了却没有留下可查询状态用户和运维人员就难以判断下一步该做什么。设计可以说明哪些结果需要记录哪些异常需要通知以及谁有权介入，这类信息会影响上线后的处理成本。值得在编码前讨论否则功能完成以后团队可能还得补建一套用于理解功能的工具。

“AI写得越快，越应该确认前面的决定站得住。”

上线和回退也需要与设计对应。新旧版本可能在一段时间内同时存在，接口变化就需要兼容安排。若发现问题回退后数据能否继续被旧版本理解也是实际问题。EGM不能代替团队决定部署方式，但设计审查可以把这些条件提早摆出来。软件能够在开发环境工作距离能够被稳妥更新仍有不同要求，验收条件最好能让争议有终点。这些响应足够快不同人可能有不同标准。写明如何测量在哪些负载条件下检查就更容易判断，标准应来自真实需求不能让AI为了显得严谨随手编造数字。审查的任务包括指出这里还缺决定而不是替负责人填入一个看似精确却没有依据的承诺。

还有没有足够证据的问题，审查者若没有权限读取相关文件就应说明哪些判断无法验证。没有看到异常与已经证明没有异常强度不同，报告把已检查待确认和无法访问分开团队才知道后续还要补什么。人类批准也需要有内容，负责人应知道哪些约束已经确定、哪些风险仍然存在、哪些部分没有验证。只在报告末尾点通过并不会自动建立系统理解，AI可以整理大量材料但承担结果的人仍要看得懂决定。把批准变成一项形式动作会让整套流程最重要的责任环节落空。

结论

EGM插件通过引入“大象”与“金鱼”的双角色机制，强制将设计决策从长期的对话上下文中剥离出来。其核心价值不在于生成代码的速度，而在于通过独立的新上下文审查设计文档，从而暴露歧义、明确边界并确保方案的可交接性。这种方法的本质是让设计本身成为AI开发的重要交付物，通过复述验证和漂移报告等手段，确保关键前提被显式记录而非隐含在聊天记录中。

然而，EGM并非万能药。它不能代替团队决定商业价值或技术选型，审查结果仍需人类工程师进行最终判断和取舍。开源许可不等于支持合同，且独立上下文审查存在模型盲点和输入质量依赖。团队应谨慎评估成本收益，将其应用于高风险、跨模块的复杂场景，而非所有小修小补。最终目标是让没有参加讨论的人也能知道要做什么、为什么这样做以及怎样判断做对了，从而降低长期维护成本并提升工程可靠性。