AI已经能很快写出一个功能，谷歌却把一个步骤专门放在写代码之前，让另一批没参与讨论的AI先来挑毛病。他开源的插件叫大象鲸鱼模型，一个保留项目上下文，一个不继承此前聊天。为什么开发工具越会记事，审查时反而需要主动断开记忆？答案关系到代码交给别人以后还能不能被正确理解。

10月22日Google Open Source Blog公布了这个插件，英文简称EGM。名字里虽然有模型，它实际交付的是软件设计与审查流程，没有发布新的基础模型权重。开发者继续使用已有的AI工具插件，帮助组织不同角色的工作。他关心的是生成之前怎样做决定，以及决定能不能被独立检查。

这个问题很容易被代码生成速度盖住。团队提出一个需求，AI迅速写出一批文件，界面能打开演示也能跑。但换一个使用条件系统可能不知道该怎么处理。问题可能来自实现，也可能在最初需求里就没有说清。如果错误方向已经扩散到多个模块，修改成本就会超过最早补写几条规则的成本。

长时间聊天还会积累另一种麻烦：人和AI讨论过许多细节，后来就默认某些事情不必再解释。文档里的一个简短结论在原对话里有完整来由，新接手的人却看不到。双方说已经达成共识不代表这份共识已经离开聊天窗口。工程要能够交接，就需要把关键前提留下来。

意见把这两类工作分开：大项保留项目历史参与需求讨论并整理设计；金鱼从新的上下文开始只根据拿到的文件和引用材料审查。人类继续决定取舍并在批准以后让编码工具实现。他尝试用这种安排，让设计讨论中的默认前提更早显露出来而不必等代码完成后再发现理解不同。

金宇并非什么都不能看，他需要设计文档也可以读取其中引用的源码或明确给出的材料。他缺少的是先前共同讨论形成的熟悉感。审查者如果必须翻遍旧聊天才能明白一句话问题就已经出现了。一个能交接的方案应当把实施所需的关键条件写在可以找到的地方。

可以设想一个消息回调功能，平台要把事件送到客户系统。正常情况下发过去并得到成功回应就结束。但客户暂时没有回应怎么办？同一事件发了两遍怎么办？事件先后顺序变了怎么办？这些问题没有一个必须等写代码才能提出，却会直接影响数据结构和业务行为。

设计阶段把它们摆出来后面的实现才有共同依据。这里不能要求AI凭空决定所有业务规则：失败后允许重试多久？重复事件会不会造成重复扣费？取决于系统用途和风险。模型可以列出方案与后果，最终责任仍属于做决定的人。

如果开发者只说按最佳实践处理可能会把本该明确选择的规则交给实现阶段临时猜测。所以大项阶段首先要把问题问清：需求的使用者是谁？什么情况算成功？哪些事情本次不做都值得讨论。排除范围尤其重要，一个看似小的功能很容易在不断补充要求后变成跨系统改造。

没有停止条件AI越能生成团队越容易接受超出本次目标的工作，最后却不知道怎样验收。设计还要保留没有采用的方案：某种存储方式为什么被放弃？某个接口为什么暂时不扩展？这些理由能够帮助后来的人判断限制是否仍然有效。

只留下最终答案容易让人误以为所有约束都来自技术本身，业务变化以后有依据的取舍可以重新讨论。缺少记录的取舍就只能重新拆。接下来才把共识写成规格，这里需要的是能够支持决定和实现的内容而非尽可能厚的文档。

每一节最好回答具体问题：正常行为怎样发生？异常行为怎样结束？哪些状态能够被观察？文档如果只重复可靠高效和可扩展，读者仍然不知道系统在失败时应该做什么。形容词不能承担接口约定，同一个词也可能隐藏不同理解。

可靠送达有人理解为不断重试直到成功，有人理解为重试失败后能够查询。前者需要考虑持续占用资源，后者需要设计失败记录和人工处理入口。双方都觉得自己听懂了实际实现却可能完全不同。设计文档应把这种分歧变成可以确认的行为，避免带进代码继续沿着回调例子看。

客户处理成功但成功回应在途中丢失，发送方就可能以为失败。如果随后重试接收方需要知道这是不是同一个事件。设计阶段因此可能要确认事件标识、有效期和重复处理规则。这里讨论的是一个假设场景，目的在于说明需求如何影响结构而不是宣称插件已经自动解决了这类故障。

在考虑客户系统长时间不可用队列会持续积累，允许积累到什么程度？是否影响其他客户？恢复后怎样处理历史事件都需要明确。一个功能在演示里只发送一条消息往往看不到这些问题。审查者如果能够改变条件来提问就可以帮助团队检查方案究竟覆盖了正常路径还是也考虑了失效后的行为。

数据保留多久也可能成为设计决定，排查需要历史记录但长期保存又会增加成本并可能涉及隐私要求。不同业务不应直接套同一个答案，人类需要提供适用规则设计者再把它落实为明确条件。这样AI的价值体现在把决定的后果展开帮助做选择而不只是快速生成一套默认配置。

EGM的理解测试很适合检查这类问题：一个没有参与讨论的审查者尝试根据文档复述系统的目标与结构。如果复述与设计者预期不同就能定位歧义。这个动作看起来朴素，却比让模型回答有没有问题更具体。理解是否一致有了能够逐项比较的对象设计者也更容易知道该补哪一段。

复述的很流畅仍然不代表理解一定正确，AI可能用熟悉的工程模式补齐空白让不完整的文档显得完整。因此审查结果需要回到原文检查每个关键判断依据在哪里。一个判断如果来自尝试推断而不是文档应当被标出来，否则设计遗漏可能只是从一个模型的默认前提转移到另一个模型的默认前提。

这也解释了为何新上下文不等于绝对客观，同一种基础模型仍可能分享相近的知识和错误倾向。换个聊天窗口无法消除全部共性，金鱼的作用是减少对前面对话的依赖为检查增加一个角度。它能发现什么仍受到输入质量和模型能力限制，独立上下文是一项设计条件不能包装成审查永不漏错的证明。

进入批判审查以后不同角色会从不同角度检查方案：设计是否存在矛盾？模块关系是否合理？表达是否留下歧义都可以分别检查。分工的好处是让问题更集中，代价则是可能收到互相冲突的意见。多个审查者都提出意见并不自动构成一个可以执行的决定，仍然需要有人判断轻重与适用范围。

假设一个审查者要求增加缓存另一个担心数据过齐，两边的意见可能都合理也可能都不适合当前规模。团队需要根据真实目标选择不能把所有建议机械的加进方案。审查系统的价值在于帮助看见此前没有充分考虑的后果，把每个建议都落实反而可能让原本简单的功能变得难以维护。

发现问题以后还要分清缺陷与偏好，需求之间冲突可能阻止实现命名是否好看未必值得拖延项目。某个模型偏爱特定架构也不能因为写成了审查报告就获得优先权。意见应该指向文档位置说明影响和依据，越能具体解释的问题越容易被复核也越不需要依赖审查者的气势。

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

当前工作流还安排了整体检查和实施准备检查，前者帮助确认文档没有在局部修改中偏离原目标。后者关注实施所需的信息是否明确：一个方案可能逻辑上成立却没有说清具体改哪里，编码工具因此仍会临时决定接口和结构。实施计划要减少这种无意义的自由发挥但也不必在高层设计里提前写完所有代码。

高层设计和详细计划各有用途，前者让人理解系统为什么这样组织后者让实施者知道工作如何落地。把大量函数细节塞进开头可能掩盖重要取舍，计划只写几个抽象目标又无法支持执行。两层之间需要能够对应：读者看完理由以后可以继续找到相关模块，实施者也能知道某项约束来自哪里。

现有项目还需要检查设计与代码的实际关系：文档可能描述旧接口代码已经改过，也可能实现时新增了条件却没有更新说明。EGM的漂移报告关注这种偏离但偏离不必然等于错误，有时是合理调整有时确实遗漏了要求。报告提供线索结论要结合版本和改动理由判断，这使得规格不再只是写完以后归档的文件它需要随系统变化保留适用版本和重要决定。

维护文档也有成本，最有效的做法通常是聚焦关键边界而非把每一行实现重复写一遍。文档应帮助读者理解和检验系统不能变成与代码并行却长期不一致的第二套想象。真正的新上下文也是使用条件，官方环境说明要求宿主能够创建独立子代理没有相应能力时审查应停止。

让同一个对话里的AI声称现在已经忘记前文无法提供同样的隔离，判断支持程度要检查实际工具能力不能只看产品名字。客户端能安装插件也不自动说明每项审查已经完成验证，仓库列出了不同开发环境的支持情况同时保留了部分验证缺口。这种区分有实际意义：安装成功、角色隔离正常和端到端流程通过是不同测试团队采用时应该核对自己要使用的部分，不把其他环境的成绩直接套过来。

公开文档写出限制反而有助于决定先试哪个场景哪些工作仍需要人工接手。代码采用Apache2.0许可让开发者能够在相应条款下使用与修改，但开源许可不等于支持合同。项目也注明它不是Google正式支持的产品运行它仍然依赖已有模型和开发环境，调用费用也不会因插件免费公开就消失。

评估成本时应把审查增加的调用和人的处理时间一起计算，这个成本问题决定了适用范围。跨模块功能如果走错方向返工可能很贵提前审查就更有价值，一个边界清楚的小修复完整流程却可能比修改本身还费时。项目也建议这类工作采用正常编码流程，把工具用在错误场景既会增加负担也容易让团队误以为所有设计审查都只是形式主义。

团队可以先拿一个实际功能试行，记录审查发现了什么修正花了多久哪些建议最终没有采用。重点观察是否更早发现了昂贵问题而不止统计产出了多少页文档，报告数量容易增长问题是否减少需要证据。若没有这种反馈审查流程也可能像代码生成一样只是把产出速度提高了。

通过审查之后测试依然要做，文档约定的行为需要落实到实现测试则检查实际程序是否遵守。两者可以互相提供依据却不能互相替代：一个规格写的很清楚的重试机制也可能在实现里漏掉边界条件，一组全部通过的测试也可能遗漏需求没有明确的情况。设计和验证需要形成对应关系可观察性也应该进入方案：如果错误发生了却没有留下可查询状态用户和运维人员就难以判断下一步该做什么。

设计可以说明哪些结果需要记录哪些异常需要通知以及谁有权介入，这类信息会影响上线后的处理成本值得在编码前讨论。否则功能完成以后团队可能还得补建一套用于理解功能的工具。上线和回退也需要与设计对应：新旧版本可能在一段时间内同时存在接口变化就需要兼容安排，若发现问题回退后数据能否继续被旧版本理解也是实际问题。

EGM不能代替团队决定部署方式但设计审查可以把这些条件提早摆出来，软件能够在开发环境工作距离能够被稳妥更新仍有不同要求。验收条件最好能让争议有终点：这些响应足够快，不同人可能有不同标准写明如何测量在哪些负载条件下检查就更容易判断。

标准应来自真实需求不能让AI为了显得严谨随手编造数字，审查的任务包括指出这里还缺决定而不是替负责人填入一个看似精确却没有依据的承诺。还有没有足够证据的问题，审查者若没有权限读取相关文件就应说明哪些判断无法验证。

没有看到异常与已经证明没有异常强度不同，报告把已检查待确认和无法访问分开团队才知道后续还要补什么。一个总是给出完整答案的代理可能比一个明确留下证据缺口的代理更难用于可靠交接。人类批准也需要有内容：负责人应知道哪些约束已经确定哪些风险仍然存在哪些部分没有验证。

只在报告末尾点通过并不会自动建立系统理解，AI可以整理大量材料但承担结果的人仍要看得懂决定。把批准变成一项形式动作会让整套流程最重要的责任环节落空，权限边界同样值得保留。设计审查需要读哪些文件应围绕任务设置不必因为代理数量变多就扩大无关访问。

项目资料中也可能含有不应发送给外部服务的内容，团队应依据自己的数据规则配置环境。这里讨论的是采用自动化工具的一般要求不能把插件的工程方法当成已经覆盖全部安全与合规问题的证明。不同审查者拿到的材料还应当可以追踪：文档引用了某个文件后来文件变化审查结论可能已经不适用。

保留版本和来源能帮助判断问题是否解决以及为什么同一份方案在两次审查中得到不同意见，否则团队会把输入变化误认成模型反复无常或者把旧报告误当成当前保证。规范越多也越需要控制迭代边界，审查不应无限寻找能够提出的所有问题而应围绕目标和风险收敛。

一个意见已经得到解释如果没有新证据就没有必要换种说法重复提出，把问题分级记录处理结果并明确结束条件才能避免设计阶段变成没有终点的讨论。严谨与迟迟不交付并不需要绑定在一起，这个方法对初学者有一个潜在帮助能把模糊要求转成更具体的问题。

但初学者也更容易把条理清楚的报告当成权威，模型提出的架构术语可能很专业未必适合当前规模。使用者应逐项追问后果尤其是新增依赖和运维负担，工具可以帮助理解不能以术语密度替代判断。有经验的工程师则可以把它当成遗漏检查：熟悉系统的人容易认为某些限制人人都懂外部读者却可能完全不知道。

新上下文的复述能够指出交接缺口帮助把经验写成可使用的约定，但资深判断仍然需要在场因为成本组织能力和实际故障经验很难仅从一份设计草稿完整恢复。Google称数千内部工程师采用了这套插件这说明它并非只有概念展示，不过采用人数与效果不是同一个指标。

到底节省多少返工增加多少审查成本仍然需要按项目统计，当前公开材料不足以承诺统一提升比例。谨慎使用这些数字能够避免把值得试验的方法吹成已经证明适用于所有团队的标准，答案EGM更深一层的变化是让设计本身成为AI开发的重要交付物。

代码可以快速生成关键取舍如果没有留下系统理解就会越来越依赖少数人的记忆，文档把决定变成能被讨论和质疑的对象。新上下文审查在检查它是否足够独立这条路线有机会降低交接成本也要求团队认真维护决定与实现的关系。它与让一个模型反复自查也有区别：同一对话已经共同接受了某种解释继续询问还有没有问题可能只在既有框架里打转。

新审查者至少能够从不同的输入起点重新理解，这个差异值得利用但仍要记得模型之间的相似盲点可能保留。方法应与测试和真实使用结合而不能成为新的信任捷径，插件能帮助组织工作无法决定团队究竟要造什么。一个需求可能技术上可行商业上却不值得，一项设计可能足够完整却超出维护能力这些判断需要目标与资源信息不能由审查通过自动推出。

把AI用在澄清后果和检查一致性上能够给人更好的决定依据，最终决定仍然需要有人负责。采用这种方法之后值得关注的成果可能很不显眼：某个歧义在开工前消失，某个不必要依赖没有进入系统后来接手的人不必重新翻找聊天。这些收益不像一次生成大量代码那么容易展示却可能影响长期维护，评价工具时应允许这些结果进入账本同时也诚实记录额外时间避免只挑有利证据。

Google这次公开提供了一种把设计与独立理解衔接起来再检查实施准备的方法，它没有改变程序必须接受检验的事实也没有免除人的责任。它提醒开发者AI写得越快越应该确认前面的决定站得住，一个工程方案真正准备好了需要让没有参加讨论的人也知道要做什么、为什么这样做以及怎样判断做对了。