本文是对 Google 工程师 Dave Rensin 的长文《Elephants, Goldfish and the New Golden Age of Software Engineering》（2026 年 4 月发表于 Medium）的中文解读，不是全文翻译。观点归原作者所有，完整原文请点“阅读原文”。
作者去年夏天为了解决工作上的一个问题，借助 AI 写了个小工具。没想到工具越传越广，几个月后有十多万谷歌员工在用，几十位同事来给它加功能。他说，要在这么快的节奏里接住这么多人的贡献，还守住安全和隐私的底线，没有 AI 编程助手是做不到的。
但他也很快发现了一件可怕的事：用 AI 写得快，也会把错误批量生产出来。 如果垃圾代码产出的速度超过有用代码，项目迟早会被自己压垮。
这篇文章就是他和团队这一年摸索出来的办法，分三部分：普通人怎么用好 AI、程序员怎么用“大象—金鱼模型”写代码，以及他对未来的几个判断。
一、AI 是工具，别把它当玩具
作者先拿“买车”举例。
大多数人的做法是：把自己想到的需求一股脑写进去，开启深度研究，让 AI 出一份“最全面的选车报告”。二十分钟后拿到一份看起来很专业的报告，心满意足。
作者说，这就是把强大的工具当玩具用，拿到的也只是玩具级的结果。问题出在我们没有给机器做足准备。他建议分三步走：
第一步：让 AI 来审问你，而不是替你调研。 告诉它：我的需求肯定有遗漏，请不断追问、质疑我的假设，直到我说停。花 15 到 20 分钟回答它的问题，不同意就和它争，但目的是学东西，不是争输赢。一段话的需求，最后会长成两三页。
如果 AI 开始一味夸你“好主意”，就提醒它：附和我没有帮助，挑战我的想法才有帮助。
第二步：先定好验收标准。 在同一个对话里，让 AI 扮演一个挑剔的事实核查员，和你一起讨论：一份靠谱的报告应该包含哪些证据、哪些引用、哪些链接。又是十几分钟，又是两三页。
第三步：开新会话，把“问题描述”和“评判标准”一起交给深度研究。 这时它知道要回答什么，也知道你会怎么打分，结果会好得多。
作者还强调两点：
- 判断力不能外包。不管做销售、市场还是财务，公司付钱买的都是你的判断。模型能生成看起来像判断的文字，但它还不具备真正的判断力。
- 把成果存下来。问题描述、验收标准、最终报告这三样东西存好就够了，聊天过程大多是噪音。日积月累，你就能“和过去的自己对话”：当初为什么这么决定？新人入职、复盘项目都会轻松很多。
二、大象与金鱼模型
三个顿悟
作者说，这个方法来自三次“原来如此”：
- 一次和 AI 干了一个小时，会话崩了，新会话什么都不记得，只能重新喂几百行代码。如果有一份写清意图和进度的文档，恢复上下文只要 30 秒。
- 上下文恢复了，AI 却开始乱跑：编造 API、做出莫名其妙的架构选择。AI 太想讨好你，没有护栏就会冲下悬崖。
- 开发新功能时他发现，让 AI 理解系统不必读源代码，读设计文档就够了。文档比代码小得多，通过文档给上下文更便宜、更快、也更可靠。
代码正在“消失”
过去，系统的设计决策一半写在设计文档里，一半藏在代码里：人写代码时会留下大量细小的决策痕迹。
现在代码由 AI 来写，这些细小的决策不再由人做出。如果不把它们提前写进设计文档，最后的系统连负责它的人都看不懂。
作者认为，“人逐行审查代码”只是一个过渡阶段：要么 AI 写的代码多到人根本审不完，要么 AI 干脆直接生成二进制。无论哪种，代码都会变得不透明，而那时唯一要紧的就是设计。他的结论是：设计就是新的代码。
大象和金鱼
- 大象：俗话说大象从不忘事。它指的是那个聊了很久、上下文很丰富的 AI 会话，以及它帮你写出的设计文档。所有讨论、取舍和细节都在里面。
- 金鱼：一个全新的、没有任何记忆的会话。你给它什么，它就只知道什么。
整个流程一句话：喂饱大象，用金鱼检验。
阶段一：养大象（先不写代码）
- 加载上下文：开新会话，让 AI 读相关文档或代码，然后复述它的理解。第一分钟理解错了，第十分钟就会写出烂代码，所以要立刻纠正。新项目可以跳过这一步。
- “不许写代码”：程序员爱写代码，AI 也爱写代码，得刻意压住这股冲动。明确告诉它：我们只讨论设计，请提问、质疑我的假设。这样聊 20 到 30 分钟，本质上和“买车”时的审问环节一样。
- 对付讨好：它一说“好主意”，就把它拉回批评者的角色。作者的小窍门是多问一句“你为什么这么认为？”，常常能把它从幻觉里拉出来。
- 让 AI 先出方案：请它用文字和框图写出第一版技术方案，不要代码。一定要让 AI 先提，这样才能看出它是否真正理解问题；如果你先提，它多半只会顺着你，盲点就漏掉了。它说错系统细节时，直接让它去读对应的文件。这个来回可能要几个小时，作者有的讨论持续了两三天。别着急。
阶段二：教大象（写设计文档）
在同一个会话里，一节一节地写一份 Markdown 设计文档，别指望一次生成。作者推荐的结构：
- 问题：三到五句话，讲清楚要解决什么业务问题。
- 技术方案：用少术语的文字讲主要组件和它们的关系，可以配框图。
- 备选方案：讨论过但否掉的思路都写下来，它们会成为以后防止 AI 幻觉和反复争论的护栏。
- 详细实现：最长的一节。要求 AI 列出每一个要新建或修改的文件，以及理由。
这份文档存进代码库，它就是这个功能的“新源代码”。
阶段三：金鱼测试
文档写得好不好，不能问大象，因为大象脑子里装着文档之外的东西。要问金鱼：
- 理解测试：新会话只给文档和它引用的文件，让它讲出这个功能要做什么、系统现在怎么运作。讲不清，就说明文档缺东西，补完再测。
- 挑刺评审：再开一个金鱼，让它扮演资深评审，找遗漏、错误假设和边界情况。作者说大约三成建议很有价值，足够了。反复几轮，直到只剩鸡毛蒜皮。
- 能否直接开工：再开一个金鱼，问它：凭这份文档，你能一次把功能做出来吗？它问什么，就把答案写进文档。最后交给真人审核。
阶段四：带着护栏写代码
到这一步才写代码：把定稿的设计文档交给 AI，让它照计划实现。因为文档列清了每个文件和每处改动，代码质量会高很多。会话崩了也不怕，新开一个，读文档，马上接着干。
代码写完，再让 AI 狠狠挑刺。作者的提示词大意是：“我直觉这段代码很差，请把它批得体无完肤。”还要求它标出连续十行没有注释的地方。反复几轮，直到批评变得无关紧要。
老代码库怎么办：花生和干草
很多人会说：我的代码有几百万行，哪来时间给它补文档？
作者的办法是给大象喂“花生和干草”，也就是小块、高密度的上下文：自底向上，逐层生成 README.md。
- 从最底层的目录开始，分给不同的工程师。
- 让 AI 读目录里的文件，写一份 README：这个目录是干什么的、每个文件做什么。
- 叶子目录只有代码可看，AI 大概会错一半，负责的工程师花五到十分钟改正。
- 往上一层，让 AI 读所有子目录的 README，再加上本层代码，写本层的 README。
- 一层层往上，直到项目根目录。
作者说，不管代码库多大，大约一周就能做完。之后在根目录开会话，只喂这些 README，AI 就能很快抓住主要子系统和设计模式，占用的上下文也少得多。等设计文档覆盖了所有文件，README 删不删都行。
意外收获：新人入职
有了这套 README 和设计文档，新人入职也简单了：把它们放进 NotebookLM 一类的工具，说明新人负责哪块，交给他。他的第一个任务就是用这个笔记本学习系统，为自己的第一个功能写一份能通过金鱼测试的设计文档。写得出来，就说明他已经能上手了。
作者的团队甚至把这个流程开放给懂一点代码的产品经理和项目经理：想要新功能？先写设计文档。交上来的初稿一般七八成是对的，改一两轮就能达标，之后用 AI 写出来的代码也就不会是垃圾。
作者对这一部分的总结是：程序员的工作不再是在编辑器里敲语法，而是意图、架构和设计判断。最终为 AI 的行为负责的是人；如果你看不懂 AI 按你的指令造出的系统，就没法为它负责。把设计当成新的代码，既用上了 AI 的速度，又保住了人的理解。
三、几个“可能不准”的预测
人人都是管理者
作者认为，“带人的经理”和“不带人的个人贡献者”之间的界线今年会变得模糊，因为每个人都会开始管理一批替自己干活的 AI 智能体。
管理的本质，是把你的判断力放大到你一个人做不完的事情上。差的经理事无巨细地规定每一步，也就是微观管理，既不能规模化，也很难得到想要的结果。好的经理讲清目标、护栏和授权范围，也讲清什么情况下必须停下来请示。衡量标准是：你能把视线移开多久，回头一看一切仍然井井有条。能移开的时间越长，你能带的人就越多。
管 AI 智能体也是一样。所以他给个人贡献者的建议很直接：
- 现在就去上一门基础的管理课。公司有新经理培训就报名；没有就看书、看视频、上网课。
- 慢慢加量。新经理一般先带三到五个人，管智能体也可以从这个规模开始，先把姿势练对，再扩大。
专注力是一块要练的肌肉
AI 正在接走写周报、开同步会这类杂活。省下的时间应该用在一直没空做的事上：深度思考、认真设计，也就是没法交给同事或模型的判断。
问题是，现代生活总在打断我们，大多数人没练过长时间专注。作者建议像练耐力一样练：每个工作日先专注 30 到 45 分钟，每周加 5 到 10 分钟，几个月后就能连续专注两小时以上。这段时间也可以拿来和 AI 辩论手头的问题，关键是想到脑子发累。
不会因此少干活
别指望 AI 让你每天只工作几个小时。历史上，工具让一件事变容易后，人们往往不是少做，而是做得更多，因为成本降低了。这就是经济学里的杰文斯悖论。
结语
常有学生和年轻同事担心，AI 会让他们没有长久的职业前途。作者的看法是：日常任务会变，但价值不会消失。你的价值在于积累并用好判断力；在自己的领域里品味越好、越会把它放大，就越抢手。这一点过去如此，以后大概也是如此。
他的最后一句话很有意思，大意是：这条路会难，但难得像一座小山，而不是一座高山。所以，开始走吧。
补充：作者在 2026 年 10 月更新说，谷歌已允许他的团队把内部用来实践这套方法的 AI 编程插件开源，项目地址是 egm.dev。
