大象與金魚模型（EGM）：Google 工程師如何用「脈絡隔離」擋掉 AI 的討好與幻覺

AI 寫程式的速度越來越快，缺乏架構把關的代價也跟著放大。Google Distinguished Engineer Dave Rensin 在 2026 年 4 月發表《Elephants, Goldfish and the New Golden Age of Software Engineering》（後獲 Google Research 出版品頁收錄）。

他在文中指出：AI 若缺乏護欄，就會幫工程師「量產自己的錯誤」（we are mass-producing our mistakes）；它能寫出看似正確的程式碼，也一樣「熱愛寫 code」（AI loves to write code），但缺乏大局判斷，必須主動克制寫碼衝動。

為了把人類的工程判斷塞進 AI 工作流程，他提出大象與金魚模型（Elephant-Goldfish Model，簡稱 EGM），並在半年後由 Google 開源為 google/elephant-goldfish-model：用滿載脈絡的長會話（「大象」）磨出設計文件，再交給零記憶的全新會話（「金魚」）做盲測與實作。

為什麼需要大象與金魚：從三步法到三個頓悟

在進入軟體工程專用的 EGM 之前，Rensin 先給出一套適用於所有知識工作的三步通用法。這套流程體現了 EGM 的核心精神：把 AI 討好傾向轉為敵意審查，並透過多個會話隔離脈絡：

1. 準備就是勝利（Victory Loves Preparation）：開工前先叫 AI 扮演審訊官（interrogator），把需求、背景與限制全部問出來，產出工作描述。Prompt 要求 AI 不斷追問釐清、質疑假設，直到你親口叫停才準結束，把 AI 急著收場的慣性擋在一開始。
2. 信任但驗證（Trust But Verify）：在同會話中切換角色，讓 AI 改扮存疑的專家事實查核者（expert skeptical fact checker），一起討論「成品要出現哪些連結、引用與證據才值得信任」，把「怎樣算做完」收斂成未來審驗時可據以評分的驗收標準。
3. 收割（Profit）：開立全新會話執行深度研究並產出成品，再交回驗收者對照標準嚴格檢驗。整套流程只保留三項資產——工作描述、驗收標準、最佳成品，其餘對話紀錄「都只是 token 噪音」（the rest turns out to be mostly token noise）。

The company decides our value by the quality and impact of the judgment we consistently demonstrate.

（公司是以我們持續展現的判斷品質與影響力，來決定我們的價值。——Dave Rensin）

2025 年夏天起，Google 內部基於其 AI 代理開發環境 Google Antigravity 與 Gemini 將這套思路做成工程工具。將通用法升級為軟體工程專用的 EGM，源於實戰中的三個頓悟（aha moments）：

• 會話會死，只有設計文件能救命：AI 會話當機後一切歸零，唯獨設計文件能可靠地把工作狀態留到下一次會話——「讀這份文件與它引用的程式碼，告訴我們進度到哪」，幾十秒就能重回現場。
• AI 天生急於討好（eager to please）：沒有嚴格護欄時，模型會順著使用者的偏見附和，每一步都必須刻意防範諂媚（sycophancy）。
• sizeof(docs) 遠小於 sizeof(code)：把人類的架構與設計判斷前移到文件裡，槓桿遠大於事後在龐大程式碼暴風雪（code blizzard）中逐行審查。Rensin 將此濃縮為一句口號：「設計就是新的程式碼」（Design is the new code）。

依據這三個觀察，並借用英文俗諺「大象永不遺忘、金魚只有數秒記憶」的對比，EGM 定義了兩個核心角色與一句口訣——「餵飽大象，再用金魚測試它」（Feed the Elephant; test it against the Goldfish）：

EGM 四階段九步驟：這套方法怎麼運作？

EGM 將軟體開發拆成四個階段、共九個步驟。每個階段的 prompt 與規則，都是為了對抗特定的 AI 失效模式：

 +-- 階段一：養大象（Growing the Elephant）
 |   - 步驟 1：載入完整脈絡（Context Loading）
 |   - 步驟 2：宣告 no-code 規則（The "No Code" Rule）
 |   - 步驟 3：「Why do you think that?」反諂媚
 |   - 步驟 4：讓 AI 先提第一版技術方案
 v
 +-- 階段二：教大象（Teaching the Elephant）
 |   - 起草四段式自足設計文件
 v
 +-- 階段三：金魚協定（Goldfish Protocol）
 |   - 步驟 5：理解／回講測試（The Comprehension Test）
 |   - 步驟 6：批評者審查（Critic Review）
 |   - 步驟 7：實作就緒檢查與真人批准
 v
 +-- 階段四：實作（Implementation）
     - 步驟 8：全新會話照單施工（Coding with Guardrails）
     - 步驟 9：「兇惡」審查者撕碎檢查（The "Mean" Code Review）

階段一：養大象（Growing the Elephant，禁止寫碼）

第一階段的目標是把現有系統脈絡餵給長會話，並在動手前把設計空間摸透。Rensin 與 Gemini 的設計會話常以二至三天計，包含前四個關鍵操作：

1. 步驟 1：載入完整脈絡（Context Loading）：先把相關程式碼、架構與需求餵進去。
2. 步驟 2：宣告 no-code 規則（The “No Code” Rule）：明確下令禁止寫任何程式碼，防止 AI 跳過思考直接輸出實作。
3. 步驟 3：用「Why do you think that?」打斷諂媚（The Sycophant Challenge）：只要 AI 附和你的想法，或給出看似合理的結論，就追問「你為什麼這樣想？」（Why do you think that?），逼模型亮出推論依據，拆穿順著話尾接龍的討好行為。
4. 步驟 4：讓 AI 先提第一版技術方案（The First Draft Technical Proposal）：先亮出自己的方案，AI 就會順著既有框架走，容易錯過自己的盲點。讓 AI 先提案，才能逼出意料之外的解法或誤區。

階段二：教大象（Teaching the Elephant）

討論收斂後，要求大象將共識迭代寫成一份結構化的設計文件。為了確保文件能獨立承載所有判斷，EGM 強制採用固定四段結構：

1. Problem（問題定義）：控制在三到五句話內，精準定義要解決什麼問題。
2. Technical Plan（技術方案）：少用行話，並附上 方塊圖（block diagram） 說明系統互動。
3. Alternatives（被排除的替代方案）：明確記錄哪些路線被否決、為什麼不採納。這段內容是防止未來會話產生幻覺的護欄，而不只是事後備忘。沒有這道護欄，新會話很容易重新採用早已否決的錯誤方案。
4. Detailed Implementation（詳細實作清單）：逐一列出每一個會動到的檔案與修改理由。Rensin 強調這一段極為關鍵（critical），因為它讓寫碼會話不必猜測要動哪些檔案、為什麼動，照清單施工即可。

階段三：金魚協定（Goldfish Protocol）

設計文件寫完後，大象會話的任務暫告一段落。接下來進入 EGM 最具代表性的機制——脈絡剝奪審查。大象因為參與了兩三天的討論，腦中補齊了太多言外之意；只有零記憶的金魚，才能檢驗這份文件是否自足。

每道測試都必須開啟全新的獨立會話，且只餵給它那份設計文件：

1. 步驟 5：理解／回講測試（The Comprehension Test）：要求金魚只閱讀設計文件，就向你解釋整個系統與變更計畫。只要金魚講錯、漏講或需要猜測，就代表文件寫得不夠清楚——回頭修改設計文件，再換一隻新金魚重測。
2. 步驟 6：批評者審查（Critic Review）：開新會話要求金魚挑出設計文件的漏洞與矛盾。Rensin 估計金魚提出的批評中，約有 30% 的建議極有價值，能抓出大象與作者共同忽略的盲點。
3. 步驟 7：實作就緒檢查（Implementation Readiness Check）與真人審查：開新會話詢問金魚，文件提供的資訊是否已經具體到可以直接動手寫碼，還是有未定義的介面與邊界條件。通過三道金魚測試後，最終閘門仍由人類工程師與同事親自審閱、批准（human/peer review），批准後設計文件才算定稿。

階段四：實作（Implementation）

有了通過三道金魚測試與真人批准的設計文件，寫碼反而變成最機械化的步驟：

1. 步驟 8：全新會話照單施工（Coding with Guardrails）：開啟全新的寫碼會話，第一句指令直接下達：「Read this design doc... Follow the plan exactly」（讀這份設計文件……完全照計畫做）。因為設計文件已逐一列出涉及檔案與計畫，若寫碼會話中途崩潰，只要新開會話、交回設計文件，讓它讀完文件與其引用的所有檔案，馬上就能接關繼續寫。
2. 步驟 9：「兇惡（mean）」審查者撕碎檢查（The “Mean” Code Review）：程式碼寫完後，再開一個全新會話做 code review，並換上 Rensin 稱為 「mean」（兇惡） 的敵意審查 prompt，外加強制檢查註解密度（任何連續十行沒有註解的程式碼都必須被標記）：

I have a strong intuition that this code is of poor quality. Please tear it to shreds and tell me all the ways it sucks.

（我強烈懷疑這段程式碼品質很差。請把它撕碎，告訴我它爛在哪。——Dave Rensin 的兇惡審查者 prompt）

從方法到工具：google/elephant-goldfish-model 開源 Plugin

2026 年 10 月，Google 在 Dave Rensin 發文公告後正式開源 google/elephant-goldfish-model（入口網站 egm.dev）。專案名稱雖帶有「Model」，但它實質上是一套擴充套件，把上述四階段九步驟封裝成一組 Markdown 規則、九個審查者 persona 檔與七個 /egm-* skills。

除了 Google 內部的 Antigravity，官方也原生支援 Claude Code 與 Codex 等具備 subagent 能力的環境直接載入執行：

成效檢視與採用建議：哪些零件值得現在拿來用？

檢驗 Rensin 的主張，可以分出哪些是可落實的工程洞見，哪些需要根據情境打折：

• 證據侷限：全文未引用計量研究或對照實驗。前文提及的批評者「30% 建議有價值」、bootstrap「一週完成」皆屬作者個人估計；外部評析也點出實務上最可能的失敗案例——把多份綠燈審查當成核可、省略真人 pull request，官方文件為此兩度告誡。
• 已知盲點：如 Digital Applied 的外部評析，便指出一個原文未提的漏洞——如果大象與金魚跑在同一個底層模型上，兩者會共享模型層級的盲點與知識缺口。做金魚審查時，換用不同家族的模型會比同模型自審更可靠。
• 適用邊界：全套 EGM 的前期投入重（設計會話以天計、真人審查前就有三道金魚測試把關）。官方 repo 明確限定，它適合需要設計決策的功能變更，能一次修好的簡單 bug 不必硬套設計先行流程；本文進一步推論，跨服務、變更半徑大、可逐檔列舉的工作（如基礎設施遷移、拓撲變更、IAM 重構）最合適，探索性除錯則不合用。

即便你的日常任務不需要每次都跑完四階段九步驟，EGM 有三個核心零件幾乎零門檻，值得直接拆進現有的 Agent 工作流程：

1. 金魚回講測試（成本最低、報酬最高）：寫完任何重要文件（migration plan、runbook、架構設計或長 prompt），開一個全新的 AI 會話，只餵文件並叫它把計畫講給你聽。金魚講不順或猜錯的地方，就是文件的破洞。
2. no-code 設計會話 ＋ 讓 AI 先提案：面對複雜變更時，先下令禁止寫碼，並忍住別先講出你的解法。讓 AI 先提第一版方案，再追問「Why do you think that?」，把自己的盲點逼出來。
3. 在設計文件加入 Alternatives 與「逐檔清單」：把設計文件當成會話崩潰時的重啟資產（crash bootstrap）。記錄「被排除的方案」能防止新會話重蹈覆轍；列出「異動檔案清單」，則為寫碼 agent 劃出明確的改動邊界。

Rensin 在文末給管理者一個簡單的衡量標準——敢不敢轉頭不看（look away）：敢離開一段時間、回頭時事情仍在秩序之中，才算把員工帶起來了；他說的員工，就是 AI agent。

套在變更上也是同一件事：如果你的變更重要到讓你不敢放手讓 Agent 自己跑，那就值得在寫出第一行程式碼之前，先把大象餵飽、再用金魚測過一遍。