Elephant-Goldfish Model:Google AI 開發流程，先想清楚再動手寫

你叫 AI 寫程式，它二話不說就動手。寫完你一看，方向偏了。你叫它改，它改完又說「完成了」，你一跑，壞的。

如果你點頭了，我先講一句可能會顛覆你認知的話：

AI 寫不好 code，通常不是因為它笨，是因為它在該停的時候沒有停。

大多數程式助手的操作模式是：你給指令 → 它立刻開始寫。問題是，當你要做的是一個需要架構決策的功能（例如「加一個 webhook 失敗後的重試機制」），直接跳到實作階段就像蓋房子不畫藍圖。

Google 的工程師們早就遇到這個問題了。他們的做法很直觀：先花時間把規格寫清楚，讓 AI 在寫程式之前就知道每一步要做什麼。 這個方法叫做 Elephant-Goldfish Model（縮寫 EGM），現在已經以開源外掛的形式開放給任何人使用。

EGM 是什麼？大象與金魚的分工

EGM 的核心概念來自 Dave Rensin 的文章《Elephants, Goldfish, and the New Golden Age of Software Engineering》。他提出了一個比喻：

大象（Elephant） 記得專案的一切。它讀過你的程式碼、了解架構、知道之前的決策。它的任務是「思考」：跟開發者討論需求、探索限制、寫出規格文件。

金魚（Goldfish） 什麼都不記得。它看不到你和大象的對話，只能看到最終的設計文件和原始碼。它的任務是「挑毛病」：用全新的角度檢查設計有沒有漏洞、假設清不清晰、能不能直接照著實作。

你坐在中間，負責做決定。

⚠️ 先講一句：EGM 不是要你每個功能都走一遍流程。如果是個小 bug 修復，直接讓 AI 改就好。它適合的是「需要設計決策」的複雜功能——那些寫錯了代價很大的部分。

這個分工的關鍵在於金魚看不到你的對話。一般情況下，AI 助手會記得你之前的討論，所以在審查自己的設計時很難跳出框架。但 EGM 的金魚是獨立啟動的子代理（subagent），它只有設計文件和程式碼兩樣東西，沒有任何前情提要。這讓它能發現一些你和大象都忽略的盲點。

安裝：一行指令搞定

EGM 支援多個 AI 程式助手，安裝方式略有不同。以下是主要平台的安裝指令：

Claude Code

claude plugin marketplace add google/elephant-goldfish-model
claude plugin install egm@egm

OpenAI Codex

codex plugin marketplace add google/elephant-goldfish-model
codex plugin add egm@egm

Antigravity

agy plugin install https://github.com/google/elephant-goldfish-model

安裝完之後，開啟一個新的工作階段（session），這樣插件才能正常載入。如果你用的是 Claude Cowork 或 ChatGPT Work，官方文件有額外的設定說明。

專案在 GitHub 上是 google/elephant-goldfish-model，Apache 2.0 授權。官方聲明它「不是 Google 的正式支援產品」，也就是說這是內部工具的外放，品質有保證但不會跟隨某個特定產品的版本排程。

核心流程：從想法到規格文件

EGM 的工作流程由三個核心技能組成，它們分別對應開發的不同階段：

第一步：Brainstorm（腦力激盪）

/egm-brainstorm 給我的專案加上 webhook 失敗重試機制

這個指令會讓你跟大象對話。它不會立刻開始寫程式，而是先問你一系列問題：

• 你的 webhook 是什麼時候觸發的？
• 失敗的情況有幾種？網路錯誤、伺服器錯誤、還是超時？
• 重試的間隔是多久？
• 如果重試了五次還是失敗怎麼辦？

這些問題聽起來很基本，但大多數人根本不會想到要回答。大象會根據你的回答逐步澄清需求，最後產出一份 concepts_brief.md。這就是概念簡報，記錄了你們討論過的所有決策。

過程中，金魚也會被啟動來檢查你的概念。它有七個不同的角度，每個都獨立運作，幫你找出潛在的問題。

第二步：Draft（撰寫設計文件）

/egm-draft

這個指令會把概念簡報變成一份正式的設計文件，存放在 docs/designs/ 目錄下。它不會一次寫完整個文件，而是每個區塊寫完都會暫停（等你確認後才繼續下一段）。

設計文件包含幾個核心部分：

• 功能概述：這個功能要解決什麼問題
• 使用者旅程（Critical User Journeys）：主要的操作流程
• 技術方案：具體怎麼實作
• 替代方案比較：考慮過的其他做法，以及為什麼沒有選它們

這種逐段確認的機制很重要。一般情況下，AI 會一次寫完整個文件然後假設你都同意，但設計決策往往需要反覆調整，分段確認讓你可以在早期就修正方向。

第三步：Review（金魚審查）

/egm-review docs/designs/你的設計文件.md

這是 EGM 最獨特的部分。金魚審查會啟動多個獨立子代理，每個子代理從不同的角度檢查設計文件：

• 簡化檢查：有沒有更簡單的做法？專案裡是不是已經有類似的功能了？
• 新手視角：完全不了解你的人讀這份文件能看懂嗎？
• 規模測試：如果這個功能被大量使用，會有什麼問題？
• 清晰度檢查：一個 AI 模型能不能直接照著這份文件實作？

審查分為五個階段（編號 5 到 9），每個階段專注不同的檢查項目。金魚會給出大量回饋，YouTube 影片提到「這些子代理會給你很多筆記，這就是第三個角色——你——出現的原因」：取你認為有用的，忽略其餘的。

審查完成後，設計文件的狀態會從「審查中」改為「已提案（proposed）」，然後你就可以讓 AI 開始實作了。

進階技能：Bootstrap、Resolve 和 Drift

Bootstrap：為現有專案建立上下文

如果你的專案已經存在一段時間，金魚可能不了解你的架構。/egm-bootstrap 會自動掃描整個專案目錄，為每個資料夾產出 README 文件，從底層開始逐層向上彙整。

這個過程是遞迴的：先處理最底層的資料夾（描述每個檔案的功能），然後往上處理父資料夾（摘要子資料夾的 README），最後產出一份根目錄的 README 作為整體架構地圖。

Drift Report：檢查規格與程式碼是否一致

功能實作完成後，程式碼會繼續演進，但設計文件可能還停留在舊狀態。EGM 提供了一個 drift report 技能來掃描這種偏差：

/egm-drift-report

它會比對 docs/designs/ 下的規格文件和實際程式碼，列出所有不一致的地方。可以把它當成定期維護的一部分來執行。

實測時的觀察

實際操作 EGM 時，有幾件事值得注意：

安裝後的 Claude Code 設定檔。EGM 安裝時會在 .claude/ 目錄下建立設定檔。其中有一行關於「Claude Code 的子代理不能啟動自己的子代理」的說明。不過實際測試發現 subagent 是可以再啟動 subagent 的，所以如果你在這行看到這個限制，讓 Claude 自己修正就好。

金魚需要子代理能力。如果你的 AI 程式助手無法建立獨立子代理，EGM 的金魚審查就無法執行。安裝前請確認你的環境支援 subagent。

不是每個功能都需要走完整流程。官方文件反覆強調：小 bug 修復直接讓 AI 改就行，不需要經過 brainstorm → draft → review 的完整流程。EGM 設計給的是「需要架構決策」的功能，那些一旦寫錯就很難修正的部分。

你才是最終決策者。金魚會給你一堆意見，但哪條該採納、哪條該忽略，是你來判斷。

跟其他開發流程的比較

你可能聽過類似的概念，例如 spec-driven development（規格驅動開發）、test-driven development（測試驅動開發），或者 TDD。它們的差別在哪？

TDD 的核心是「先寫測試再寫程式」，關注的是行為驗證。EGM 的核心是「先寫設計文件再讓 AI 實作」，關注的是架構思考。兩者不衝突，你可以在 EGM 產出設計文件後，再用 TDD 的方式實作。

跟一般的 prompt engineering 相比，EGM 的不同在於它把「思考過程」結構化了。一般情況下你給 AI 一個 prompt 就等結果，但 EGM 要求你先經過 brainstorm（澄清需求）、draft（設計方案）、review（外部審查）三個階段，每一步都有明確的輸出文件。這就像是你跟一個團隊合作：先腦力激盪、再寫提案、再找其他人審查、最後才實作。

最後說兩句

EGM 最吸引我的地方是它對「AI 助手過度自信」這個問題的回應。程式助手最大的問題不是能力不足，而是在該停下來思考的時候直接開始寫。EGM 的大象和金魚分工，本質上是強制 AI 先想清楚再動手，而且讓一個「沒有前情提要」的金魚來檢查你的想法有沒有漏洞。

這不是萬能解方。小功能直接讓 AI 改就好，不需要繞一圈。但對於需要架構決策的複雜功能，花時間走一遍 EGM 流程，往往比寫完一半發現方向錯了再重來要省得多。

所有資訊來自 google/elephant-goldfish-model GitHub 專案、egm.dev 官方網站，以及 Dave Rensin 的原始文章《Elephants, Goldfish, and the New Golden Age of Software Engineering》。資料截止 2026 年 10 月。

延伸閱讀：

• Claude Code 資深工程師紀律：幫它裝一套工作紀律（一行指令）
• Claude Skills 做設計：Frontend Design、Canvas、UI/UX Pro Max
• DeepSeek Harness：一行裝好、任何模型都吃的 Claude Code 開源替代