Google EGM 是什麼？大象寫規格、金魚來找碴，讓 AI 先想清楚再寫 code

安安～我是ChiYu～

假設你丟給 Coding Agent 一句：「幫我新增會員管理 API。」

幾分鐘後，Controller、Service、DTO、資料庫 migration 全部長出來了，連測試都順手補好。速度快得很舒服，直到驗收時才發現：它假設每個會員一定有 Email，可是系統其實要支援手機號碼登入。

更麻煩的是下一步。我們很自然會在同一個對話裡說：「幫我 review 一下剛剛的設計。」問題是，這位審查者剛剛才親手做出「會員一定有 Email」這個假設。它很可能沿著同一個假設檢查下去，然後告訴你一切看起來都很合理。

Google 在 2026 年 10 月 21 日開源的 Elephant-Goldfish Model（EGM） ，處理的就是這個死角：讓記得整個專案的「大象」寫規格，再讓完全沒看過那段對話的「金魚」來找碴，最後由人決定要蓋什麼。

EGM 不是新模型：它是一套裝進 Coding Agent 的 Plugin

先把最容易誤會的地方講清楚。EGM 不是新的 AI 模型，也不是程式語言或 Web Framework。它是一個 Plugin，裡面裝的是：

• 7 個 Skills：從需求探索、撰寫規格、審查、處理審查意見，到檢查文件和 code 有沒有對上。
• 9 個 Persona：放在 agents/ 資料夾，定義每一位審查者（Goldfish）的角色和規則。
• 文件標準：放在 resources/document_standards/，是審查者拿來評分的 rubric。

EGM 不帶自己的模型，用的是你手上那套 Coding Agent 的模型和權限。官方 架構文件 把它定位成一種 Spec-Driven Development（SDD，規格驅動開發）的實作，名字和核心想法來自 Dave Rensin 的文章 Elephants, Goldfish, and the New Golden Age of Software Engineering 。

README 寫著「數千名 Google 工程師在使用 EGM」，這是官方自己的說法。同一份 README 也寫明：這不是 Google 正式支援的產品。 專案採 Apache 2.0 授權，可以商用、修改和散布，但不要把它當成 Google 的商業產品或技術支援承諾。

大象記得一切，金魚什麼都不記得：EGM 的三個角色

EGM 的名字其實就是它的分工。README 把角色拆成三個：

大象的優點是記性好，缺點也是記性好。官方架構文件列出四種沒有結構的 AI 開發常見失敗：

1. Hallucination Cascades & Context Pollution：同一條對話一路從訪談、設計寫到 code，猜測和偏見會不斷累積，模型最後是在幫自己的錯誤假設背書。
2. Premature Implementation：官方叫它「Weeds Syndrome」，Agent 還沒想清楚架構，就先在附近的檔案動手寫。
3. Chat Dump Fatigue：好幾頁的規格和審查意見全倒進聊天視窗，人難讀，也拖累模型的上下文表現。
4. Documentation Drift：專案初期寫的設計文件，隨著 code 演進慢慢失真。

金魚的價值就在它「什麼都不記得」。它在全新的上下文裡讀規格，只能看文件本身、文件裡引用的檔案，以及你另外指定的閱讀清單（官方稱為 GoldfishContext）。開頭那個 Email 假設如果沒寫進規格，金魚就不會「自然知道」，只會問：「登入方式到底有哪些？」

不過「金魚」也有它的極限，這點要先講清楚：

• 獨立上下文不等於獨立模型。 金魚通常跟大象用同一個模型，相同的盲點還是可能一起漏掉。
• 上下文隔離不等於檔案系統隔離。 官方的 Claude Code 文件直接寫明，這是 context 和工具的隔離，審查者仍然讀得到它有權限讀的檔案。
• 審查不代表正確。 README 也說了，審查不能取代測試，也不能取代人的判斷。

開不了乾淨的子代理，EGM 寧可停下來

讀完官方文件，我覺得 EGM 最有誠意的設計，是它對「假裝審查」的態度。

每個需要金魚的 Skill 裡都寫著同一句規則：如果執行環境沒有可以開子代理（subagent）的工具，就停下來告訴使用者，因為在同一個上下文裡做的審查，不算 Goldfish 審查。

各家工具開子代理的方式不一樣，EGM 也逐一寫了對應規則：

• Codex：用原生的 spawn_agent。如果工具參數有 fork_context，每一位金魚都要明確設成 false；如果是 fork_turns，就設成 "none"，避免把父對話帶進去。
• Claude Code：EGM 為每位審查者準備了 adapter，只開放 Read、Grep、Glob 三種唯讀工具，並用 omitClaudeMd: true 排除專案和使用者層級的 CLAUDE.md。官方要求 Claude Code 2.1.271 以上，更舊的版本不能當成已驗證的隔離環境。

有一說一，這條規則比聽起來重要。環境開不了子代理時，最省事的做法是讓同一個 Agent 換幾種口吻「模擬」多位審查者，照樣交出一份看起來很完整的報告。EGM 直接把這條路堵死，寧可停下來告訴你做不到。

EGM 完整流程：從一個想法走到可以實作的規格

官方的 Getting Started 把主要流程叫作 Core Loop，但也特別強調：這不是處方，Skill 可以不照順序用，簡單的 bug 修正也不必硬走設計流程。

我把官方文件提到的步驟整理成一張圖：

%%{init: { 'theme': 'base', 'themeVariables': { 'primaryColor': '#fffdf8', 'primaryBorderColor': '#9a6337', 'primaryTextColor': '#24211d', 'lineColor': '#91887d', 'edgeLabelBackground': '#f7f3ec', 'tertiaryColor': '#f0e9df' }}}%%
flowchart TD
    X("既有專案") -.->|"egm-bootstrap 補 README 地圖"| B
    A("功能想法") --> B("egm-brainstorm<br/>大象追問<br/>六個 Goldfish 視角審查")
    B -->|"concepts_brief.md"| C("egm-draft<br/>逐段撰寫、逐段核准")
    C -->|"docs/designs/FEATURE.md"| D("egm-review<br/>五個 Goldfish 審查關卡")
    D -->|"審查報告"| E("egm-resolve<br/>大象分類審查意見")
    E -->|"修正後重審，每關最多一次"| D
    E --> F("人類 PR Review<br/>核准設計")
    F --> G("Coding Agent 依規格實作<br/>測試、Code Review、CI")
    G --> H("egm-drift-report<br/>定期比對文件與 code")

    classDef start fill:#f0e9df,stroke:#cbbca9,color:#635b52
    classDef skill fill:#fffdf8,stroke:#9a6337,stroke-width:1.5px,color:#24211d
    classDef human fill:#e7eeeb,stroke:#4f6f69,stroke-width:1.5px,color:#24211d
    classDef work fill:#fffdf8,stroke:#cbbca9,color:#24211d
    class X,A start
    class B,C,D,E,H skill
    class F human
    class G work

圖裡最容易被忽略的是「人類 PR Review」這一格：EGM 的 Core Loop 明確包含「把設計文件發 PR 給另一個人看」。它想加強的是人的審查，不是把人拿掉。

另外，EGM 對實作階段刻意不表態。官方說每個團隊的 coding style、測試策略、效能工具都不同，請把自己的 Skills 寫進實作計畫。換句話說，EGM 管的是「動工前的規格」，動工後的品質關卡還是要靠你原本的流程。

Brainstorm 與 Draft：先被追問，再一段一段寫規格

egm-brainstorm：先回答開放式問題，才輪到金魚上場

egm-brainstorm 的規則有點反直覺：在問題沒問清楚之前，禁止開子代理，也禁止丟出「A、B、C 選一個」的選擇題。大象要用開放式問題連續追問好幾輪，例如：

• 這個功能要解決什麼具體的痛點？
• 誰會用它？有什麼 SLA 或不能違反的條件？
• 現在怎麼處理這件事？為什麼不夠好？
• 成功要怎麼衡量？

等你確認「工作假設」寫對了，才會派出六個視角的金魚同時檢驗：

結果會寫進 concepts_brief.md，而不是倒在聊天視窗裡。

這裡還有一組很有意思的規則：EGM 明文禁止 Agent 拍馬屁。不能稱讚使用者的想法 great、brilliant、smart，就算想法不錯，也要先講哪裡有問題、缺什麼、風險在哪，再談優點。

egm-draft：一段一段寫，架構選擇交給人

egm-draft 會把 brief 轉成 design_draft.md，順序是 Overview 與 Goals、Technical Plan、Alternatives Considered，最後才是 Detailed Implementation Plan。每寫完一段就停下來，等你核准或提出修改，才往下一段走。

Detailed Implementation Plan 的要求特別嚴格：

• 要列出每一個會新增、修改或刪除的檔案，包含文件、schema、設定和測試檔。
• 每個檔案都要附上改什麼、為什麼要改。
• 不准寫實作 code，只能寫 pseudocode、API 或 schema。
• 目標是只看這份計畫就能實作，不必在動工時再做重大決策。

另一條規則叫 Owner Decides Architecture：當設計有不只一個說得通的答案，例如資料模型、元件邊界或儲存方式，Agent 最多提出三個選項，每個都寫清楚機制、取捨和會失敗的情境，然後交給你選。它不能排名、不能標預設值，就算你說「你幫我挑一個」，它也要把取捨重講一次，再請你自己決定。

最後，草稿會存到 docs/designs/<FEATURE>.md，有 SITEMAP.md 的話一併登錄。存檔前，大象還會用 Zoom Out 標準自我檢查一次，看看有沒有偏離根本問題、過早優化或重複造輪子。

egm-review 的五個關卡：大方向、讀不讀得懂、設計、再拉遠、能不能動工

egm-review 是整套 EGM 的主角。它會先找到 ## Detailed Implementation Plan 這類標題，把文件切成兩段：前面是功能設計（官方叫 FeatureRange），後面是實作計畫（DetailedRange），然後依序跑五個關卡。

關卡編號從 5 開始，是因為 Skill 的第 1 到 4 步用來確認目標檔案、選擇模式和切分文件。

這個順序很有道理。先看大方向（是不是太複雜、有沒有重複造輪子），再找一個「剛加入專案的新人」確認看不看得懂，接著才讓「刁鑽的架構評審」挑設計毛病。設計改過之後，再拉遠看一次有沒有越改越複雜，最後由「務實的 Tech Lead」確認實作計畫的檔案路徑、函式簽章和測試案例，是否具體到不必再做設計決策。

執行模式有四種：

• 每關結束都停下來確認的互動模式。
• 一口氣跑完，最後產出 consolidated_review_report.md，依 🔴 Blocker、🟡 Major、🟢 Nit 排序。
• 只審功能設計，跑完第 8 關就停。
• 只審實作計畫，直接跳到第 9 關。

每一關修正後最多只能重審一次。超過之後，剩下的問題會被記成已接受的取捨，流程繼續往下走。這個上限很實際，不然大象和金魚可以永遠吵下去。

官方也先打了預防針：審查刻意會給出大量意見，挑你覺得相關的處理，其他的可以忽略。

egm-resolve：作者想反駁審查意見，也得拿出證據

審查意見回來後，egm-resolve 會讓大象把每一條意見分成四類：

• PROPOSE FIX：意見成立，提出精確的修改內容。
• CONTEST：意見不正確，但必須引用審查者讀得到的證據，例如某個檔案和 symbol，或文件裡記錄過的決策。
• ESCALATE：意見不正確，但證據在審查者讀不到的地方，例如團隊慣例或口頭決定。這類要交給人判斷，不能自己修掉。
• DECLINE：只是 Nit，記錄下來但不修。

接下來這幾條規則，很有工程味：

• 「這是故意的」不算證據。拿不出可以檢查的證據，就只能 ESCALATE 或接受修正。
• 不要只為了讓審查者滿意而補文件。補充內容要是人類讀者需要的；如果只有零上下文的子代理需要，就 ESCALATE。
• 看不懂的問題不能反駁。新的讀者看不懂，就代表文件少寫了東西。
• 不能自己調整嚴重程度。覺得 Blocker 其實只是 Nit，要用 CONTEST 說明理由。
• 最後一句寫得很直白：文件是你寫的，你想反駁，不代表審查者錯了。

分類結果會寫進 goldfish_review_report.md，你可以一次套用所有修正、逐條討論，或直接跳過。處理完之後，設計文件再發 PR 給同事審查。

Bootstrap 與 Drift Report：舊專案補地圖，新規格防漂移

前面講的都是新功能。EGM 另外有兩個 Skill，處理接手舊專案和文件長期維護的問題。

egm-bootstrap 由下而上替專案補 README。官方把它叫作「Peanuts and Hay」：最底層的資料夾先產生 README（Peanuts），說明每個檔案的介面、不變條件和副作用；再往上一層一層彙整成上層 README（Hay），最後在根目錄得到整個系統的架構地圖。

它的限制也寫得很清楚：只寫文件、不改程式碼，不會幫你 git commit。如果專案已經有人工維護的 README，可以改用 EGM.md 這類檔名，避免蓋掉原本的內容。官方同樣提醒，產出的文件還是要人看過。

egm-drift-report 則拿設計文件和目前的 code 比對，專找四種落差：

• 文件寫了、code 卻沒有的功能。
• 少了欄位的資料模型。
• 原本規劃是動態邏輯，實際卻寫死數值。
• 實作改用了文件沒提過的架構或套件。

報告只列不一致的地方，寫進 {YYYY-MM-DD}_DRIFT_REPORT.md。要改文件還是改 code，由人決定。官方建議每週跑一次，但它不會自動讓文件永遠保持同步。

把七個 Skills 放在一起看：

在 Codex 與 Claude Code 安裝 EGM：指令不同，叫用方式也不同

我在 〈Codex 省 Token 卻又慢又卡〉 那篇寫過，AI Agent 現在要雙修。EGM 剛好是同一套 Skills 和 Persona 給多種工具共用，不會替每個工具各自維護一份 fork。

Codex 的安裝指令：

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

Claude Code 的安裝指令：

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

Google 自家的 Antigravity 則是：

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

裝完之後要開一個新的工作階段。接下來要注意，三種工具叫用 Skill 的方式不一樣：

• Antigravity：直接輸入 /egm-brainstorm、/egm-draft、/egm-review。
• Claude Code：要加上 Plugin 前綴，例如 /egm:egm-brainstorm。
• Codex：從 Skill 選單選擇對應的 EGM Skill，不是輸入 slash command。

以 Claude Code 為例，官方 README 的第一次試用流程長這樣（webhook delivery 是官方範例）：

/egm:egm-brainstorm Add webhook delivery to this project.
/egm:egm-draft
/egm:egm-review design_draft.md

egm-review 後面接的檔案路徑，請用大象實際回報的草稿位置。

另外有三個容易踩的坑：

1. 一定要裝完整的 Plugin。 只把 skills/ 複製過去的安裝方式會讓 EGM 壞掉，因為 Skill 執行時要讀 agents/ 的 Persona 和 resources/ 的文件標準。
2. 產出檔案的位置可以指定。 brief、草稿和報告預設寫在工作目錄。想集中管理的話，在 AGENTS.md 或 CLAUDE.md 加一行 EGM artifact directory: .dev/docs，不想進 Git 就把該資料夾加進 .gitignore。
3. 裝好不代表能跑完整流程。 官方的 Codex 文件寫得很直接：安裝或偵測到 Plugin，不等於整套流程都能跑。開始審查前，先確認目前的工作階段真的能開出全新上下文的子代理。

目前各工具的支援狀態，官方是這樣分級的：

如果你主要用的是 Codex 的桌面介面，要特別注意：官方文件列的是 Codex CLI 的安裝指令，沒有另外說明桌面 App 的行為。我的建議是裝好後先拿一份小文件試跑 egm-review，確認 Skill 選得到、子代理開得出來，再拿去審真正的專案。

拿 .NET 帳單查詢 API 想一次：EGM 會先逼你回答哪些問題

下面用一個虛構案例，看 EGM 在動工前會把問題攔在哪裡。假設專案是 .NET 8 Web API、Vue 3、EF Core 和 SQL Server，要新增「客戶帳單查詢」：

GET /api/customers/{customerId}/invoices

直接交給 AI 開發，它很可能先建 Controller、Service、DTO 和查詢，權限與錯誤處理晚點再補。走 EGM 的話，問題會提早一批一批浮出來：

• Brainstorm 階段，Migration 視角可能會問：多租戶的資料隔離規則是什麼？Cost 視角可能會問：帳單量大的客戶，分頁查詢會不會打爆資料庫？
• Draft 階段，實作計畫要列出 Controller、Business Service、Repository 各自要動哪些檔案，DTO 的分頁、排序、日期與金額格式都要寫死，不能留給實作時再決定。
• Comprehension 關卡，「新人」金魚可能會指出：文件寫了「作廢帳單不顯示」，卻沒定義什麼狀態叫作廢、已開立和未開立又怎麼處理。
• Implementation Readiness 關卡，「Tech Lead」金魚可能會要求補上驗收案例：無資料、無權限、分頁邊界、無效參數，以及跨租戶查詢必須失敗的測試。

上面這些是我依各關卡的職責推想的範例，不是 EGM 實際跑出來的報告。

我覺得這個做法最有價值的地方，不是讓 AI 寫出更多 code，而是在改 code 之前，先把那些最容易造成返工的問題找出來。

EGM 省下的是返工，花掉的是時間與 Token

依照它的設計，我覺得 EGM 有四個明顯的優點：

1. AI 不容易直接動手改架構。 先確認需求和修改範圍才進入實作，適合有既有架構、有多人協作規範的專案。
2. 設計審查不再依賴原本的對話。 金魚在新的上下文裡讀規格，大象和審查者比較不會共用同一個錯誤假設。
3. 設計文件可以進版控。 規格放在 docs/designs/，搭配 PR 審查，需求和架構決策都有紀錄可以追。
4. 對舊系統也有用。 egm-bootstrap 和 egm-drift-report 可以幫忙建立專案地圖、找出文件落差。

代價也很明確：

1. 流程成本高。 小功能也走完整的探索、設計、多位審查者和修正，速度只會變慢。
2. Token、子代理呼叫和等待時間都會增加。 一次完整的 egm-review 會派出好幾位金魚，實際成本要看模型、上下文長度和你用的方案。
3. 審查意見會有雜訊。 不同金魚可能重複提同一件事，或把合理的取捨當成缺陷。
4. 規格本身還是可能錯。 規格通過審查，不代表實作正確，單元測試、整合測試、資安檢查和 Code Review 一樣都不能少。
5. 多了要維護的文件。 團隊要決定哪些設計文件長期保留、誰負責更新。

官方 FAQ 對效率的回答相當克制：設計和審查要花時間，對小而清楚的修改不一定划算；對不確定或影響大的修改，則可能因為提早發現缺漏而減少返工。它還補了一句：跑完 EGM 流程本身，不能證明生產力有提升。 要比較的是總時間、有用的審查意見數量和返工次數。

我的導入建議：小修直接做，中型功能 Draft + Review，高風險才全跑

我不建議一開始就要求所有工作都走完整的 EGM 流程。比較穩的做法是分級導入：

• 小型修改：修 bug、調欄位、簡單的 UI 調整，直接用 Codex 或 Claude Code，搭配測試就好。EGM 官方也說小而清楚的 bug 修正照平常的流程做。
• 中型功能：新增 API、調整資料模型、跨多個 Service 的業務流程，先用 egm-draft 寫規格，再用 egm-review 讓金魚審。
• 高風險修改：身分驗證、RBAC、帳單計算、金額處理、資料遷移、跨系統整合，才從 egm-brainstorm 開始跑完整流程，再進入實作和測試。

試行時，建議挑一個中型功能，記下開發時間、審查找到的有效問題數、返工次數和測試結果，再決定要不要擴大使用。

如果你看過我之前寫的 Matt Pocock Skills 拆解 ，可以把兩套放在一起比較。Matt Pocock 那套從需求釐清一路管到 TDD 和雙軸 Code Review，重心在「實作過程的回饋迴路」；EGM 則把力氣集中在「動工前的設計文件」，實作階段刻意不表態。兩者並不衝突：用 EGM 把規格審清楚，再用自己慣用的實作與測試 Skills 動工，是我覺得很合理的組合。

這個專案能信任到什麼程度？

導入前，我會先看這幾件事：

• 授權：Apache 2.0，可以商用、修改和散布，但要遵守授權條款。
• 身分：Google 開源，但官方明確表示不是正式支援的 Google 產品。
• 成熟度：目前是 v0.1.0。官方的版本規則說，1.0 之前功能或不相容的流程變動會升 minor 版本，要等 Skill 名稱、參數、輸出路徑和報告格式穩定，才會進入 1.0。
• 資料流向：官方的 Privacy 文件 說明，EGM 沒有自己的雲端服務、資料庫、分析工具或遙測，也不需要另外註冊帳號。你的程式碼和文件是由你使用的 Coding Agent 處理，適用那個工具自己的條款與隱私設定。
• 執行權限：egm-bootstrap 會執行本機指令，也可能呼叫專案設定好的 formatter。用在含有公司原始碼或機密資料的專案前，還是要檢查 Plugin 內容與權限設定。

還有一個細節值得一提：EGM 自己的 AI 貢獻規範 寫著，超過 100 行非測試程式碼，或動到 skills/、agents/ 裡 3 個以上核心檔案的功能與大型修改，應該先開 issue 跟維護者確認，再用 /egm-brainstorm、/egm-draft、/egm-review 寫出設計文件並合併，最後才送實作的 PR。它要求貢獻者走的流程，就是它推薦給大家的那一套。

回到開頭那支會員 API

回到開頭那句「幫我新增會員管理 API」。

如果走 EGM，在任何一行 code 出現之前，會先有一份寫著登入方式、資料欄位和驗收條件的規格。這份規格被一隻完全不知道你們聊過什麼的金魚從頭讀過，「會員一定有 Email」這種只存在對話裡的假設，比較有機會在這個階段被問出來。

這跟我在 《文件驅動 AI 開發》 想講的事情很接近：把原本只存在對話裡的想法寫成文件，人和 AI 才有共同的依據可以檢查。EGM 再往前推一步，讓「檢查文件的人」刻意不帶任何先入為主的記憶。

但它也把一個問題留給我們：金魚只能抓出文件沒寫清楚的地方，抓不出大家都沒想到、所以也沒寫進去的需求。規格被審得再漂亮，最後要不要蓋、蓋成什麼樣子，還是得由人來決定。

參考資料

• google/elephant-goldfish-model（GitHub）
• Getting Started：EGM Setup & Workflow Guide
• EGM Architecture & System Lifecycle
• Harnesses：安裝方式與支援狀態
• Codex integration
• Claude Code integration
• FAQ
• EGM data handling（Privacy）
• Apache 2.0 License
• Dave Rensin：Elephants, Goldfish, and the New Golden Age of Software Engineering