AI 写代码前，先让“金鱼”读懂方案

你和 AI 聊了很久，终于觉得需求说清楚了。可一开始写代码，问题又冒出来：“这里为什么覆盖了原文件？”“没找到日期，怎么随便填了一个？”

讨论过，不等于写清楚了。双方都记得的背景，很容易被省略在说明书之外。Google 开源项目“大象—金鱼模型”（Elephant-Goldfish Model，简称 EGM）提供了一种值得借鉴的分工：让熟悉背景的 AI 起草方案，再让没有前置聊天记忆的 AI 检查方案。〔项目说明〕

先用一张菜谱理解它

熟练的厨师写“炒熟即可”，自己当然知道火候。第一次下厨的人却会问：多大的火？大约多久？怎样才算熟？这些问题并不多余，它们暴露了菜谱里没写出来的知识。

在这个比喻里，“大象”保留项目背景，和你讨论目标、限制与取舍，再把结果写成方案；“金鱼”不带着之前的聊天记忆，只读方案和其中明确引用的必要资料，检查一个新接手的人能不能理解、哪里容易出错。最后仍由人决定接受哪些建议。动物名称只是分工的比喻。〔官方介绍〕

一句“按日期给照片改名”，藏着多少问题？

下面是为讲解虚构的小例子。假设要做一个照片改名工具，需求只有一句：“把照片按日期改名。”熟悉讨论的 AI 可能直接开工，但第一次读这句话的人会追问：

• 日期取拍摄时间，还是文件的修改时间？
• 照片没有拍摄时间时，是跳过，还是采用其他规则？
• 两张照片得到同一个名字，能不能覆盖？
• 改到一半失败了，怎样找回原来的名字？

回答之后，说明书就可以变得具体：使用拍摄时间；缺失时跳过并列出原因；重名时补序号且禁止覆盖；先生成新旧文件名对照表，确认后执行，保留对照表用于恢复。

这段补充没有增加炫目的功能，却减少了让执行者猜测的地方。真正运行时，还要用测试照片验证重名、缺失日期和中途失败等情况。

让另一个 AI 检查什么？

项目文档中的审查包含理解检查、寻找设计漏洞，以及确认是否具备实施条件等环节。普通学习者可以先把注意力放在三个问题上：〔审查文档〕

1. 能不能复述？请它只依据文档说明目标、输入和结果。复述错了，先检查文档有没有歧义。
2. 哪里会失败？请它给出具体的反例，指出文档哪句话没有交代处理方式。
3. 能不能动手？请它列出仍需猜测的信息，以及怎样判断实现是否正确。

把有效的问题带回原方案补清楚，再检查一次。关键是给审查者独立的上下文；在原来的聊天里说一句“现在请扮演金鱼”，仍然带着之前的讨论，达不到同样的隔离条件。

也要知道什么时候停

这套方法适合需要权衡的功能设计。改一个明确的错字，通常不值得走完整流程。官方工作流也强调按实际需要使用，并保留人的审阅。〔工作流指南〕

独立审查能帮助发现遗漏，仍然可能漏掉错误，不能替代实际测试。一个好练习是：拿走聊天记录，让新读者仅凭说明书讲清楚“要做什么、什么不能做、怎样算完成”。讲不清楚的地方，就是下一次需要补上的理解。

好的方案，要让第一次读它的人，也知道下一步该怎么做。