TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
Google 開源 Elephant-Goldfish，AI 寫程式前先讓另一個代理審設計
Google 在 2026 年 10 月 22 日開源 Elephant-Goldfish 外掛，把 AI 寫程式前的設計工作拆成兩種代理：大象繼承完整討論脈絡整理設計文件，金魚不帶記憶、從新讀者角度獨立審查規格缺口，支援 Antigravity、Claude Code 與 Codex 安裝，採 Apache 2.0 授權。
用 AI 摘要這篇文章：
Google 在 2026 年 10 月 22 日於官方開源部落格發文，把內部使用的 Elephant-Goldfish Model（EGM）外掛正式介紹給外部開發者。這個外掛把「先設計、後寫程式」的 AI 開發流程包成可安裝的命令組：在 AI 動手寫程式之前，先由一個完全不繼承討論脈絡的代理，扮演第一次讀到規格的讀者去獨立審查設計文件。公告給出的動機很不客氣：生成式工具拉高的是寫程式的速度，但沒有結構性護欄的純速度，等於連錯誤也跟著自動放大。GitHub 儲存庫 google/elephant-goldfish-model 的提交紀錄顯示，初版開源發布落在 10 月 21 日，公告後兩天內已經併入社群貢獻，截至 10 月 26 日累積超過 1,600 顆星。
這個外掛原本是 Google 內部工程師的工具。公告原文寫得直接：「原本為 Google 軟體工程師內部開發，現在開源」，並宣稱「數千 Googlers 每天用這個外掛交付 Google 的生產程式碼」。這句話是官方對內部採用現況的說明，公告並沒有附上可重現的成效對照，外部團隊裝了之後能不能得到同樣結果，目前沒有任何量化數字可以查。
直接受影響的是已經在用 AI coding agent 寫程式的人：Antigravity、Claude Code、OpenAI Codex 三個環境已通過官方的自動化測試；Claude Cowork 與 ChatGPT Work 有安裝路徑，但官方文件明留驗證缺口。還沒讓代理寫程式的開發者，這則新聞目前與你無關。
大象記住一切，金魚假裝第一次聽到
EGM 的核心是一個刻意製造的資訊不對稱。大象是長脈絡的設計會話：載入系統歷史、架構圖、元件邊界與使用者旅程，負責訪談需求、辯論取捨、把每個微小的決定寫進設計文件，全程遵守不寫程式的規則。金魚則是無狀態的零上下文子代理：只拿到規格草稿與現行程式碼，不共享大象與你討論時留下的任何默契。公告對金魚的定位寫得很清楚：正因為跟設計者不共享盲點，它們才有本錢當客觀的批評者，去戳文件沒寫出來的邊界情況。
流程用三個命令走完。/egm-brainstorm 在任何文件出現之前先把模糊想法壓力測試一輪，官方文件描述它會派出一組六個視角的金魚群攻擊概念，產出結構化的概念簡介；/egm-draft 由大象逐節編寫 Markdown 設計文件，放在 docs/designs/ 目錄，內容必須涵蓋問題定義、技術方案、考慮過的替代方案，以及逐檔案列舉的修改計畫；/egm-review 才輪到金魚上場驗證。
審查這一步，公告與儲存庫現況已經不一樣了。公告描述三個步驟：理解檢查讓一隻金魚把架構與意圖回述給大象聽，回述不準就代表文件有歧義；接著多隻金魚扮演懷疑的技術審查者，找邊界情況、隱藏依賴與邏輯缺口；最後一關是實作就緒檢查，逐項驗證檔案路徑、資料結構與函式簽章是否齊全，給出 go 或 no-go 的判定。但儲存庫現版的 review skill 已經擴成五個關卡：Initial Zoom Out、Comprehension、Design Critique、Intermediate Zoom Out、Implementation Readiness，關與關之間還加了互動檢查點，關卡結束時會停下來確認，依關卡可以選擇繼續、回頭修文件或就地套用修正。
現版 skill 也把審查拆成可挑選的預設組合：完整審查走完五關；只想驗規格本文，跑到倒數第二關就乾淨收手，不做實作就緒測試；文件已經穩定、只想檢查實作計畫的話，可以直接跳到最後一關。這個設計透露了這套流程的實際用法：全餐不必每次上，按文件所處的階段挑關卡跑就行。文件演進的速度比公告文案快，安裝之後應以儲存庫為準。
配套命令也值得記住。/egm-resolve 把審查評論分類回寫到文件；/egm-drift-report 用語法樹掃描已核規格與現行程式碼的漂移，官方網站建議每週跑一次；/egm-bootstrap 能為既有程式庫由下而上產生文件，產出的文件掛上哨兵區塊，之後重跑可以只更新標記過的段落，讓文件跟著程式碼一起長。審查者本身是 agents/ 目錄裡的九個角色檔案，README 列出的名稱包括 Design Critic、Naive Reader、Tech Lead、Codebase Auditor 等七種視角。規格通過後，官方建議把設計文件用 pull request 提交進版本庫，再按批准的規格實作。
公告主打 Antigravity，儲存庫當天就有 Claude Code 與 Codex
公告寫這個外掛「核心目標是把 EGM 帶進 Antigravity，其他開發環境即將跟上」。但提交紀錄顯示，Claude Code、Claude Cowork、Codex 與 ChatGPT 的支援就落在公告當天：10 月 22 日的 commit 訊息明寫「Claude Code, Claude Cowork, Codex, and ChatGPT harness support」。換句話說，公告文案落後於儲存庫現況，Claude Code 與 Codex 的使用者不用等「即將」，現在就有官方安裝路徑。
官方文件對支援度做了分層，這比行銷文案可靠：Antigravity、Claude Code、Codex 三個環境通過自動化安裝測試、審查者隔離測試與端到端工作流測試；Claude Cowork（issue #105）與 ChatGPT Work（issue #106）有可用的安裝路徑，但官方明說留有雲端追蹤的驗證缺口。安裝命令如下：
| 環境 | 安裝方式 | 官方測試狀態 |
|---|---|---|
| Antigravity | agy plugin install https://github.com/google/elephant-goldfish-model | 通過三項自動化測試 |
| Claude Code | claude plugin marketplace add google/elephant-goldfish-model && claude plugin install egm@egm | 通過三項自動化測試 |
| Codex | codex plugin marketplace add google/elephant-goldfish-model && codex plugin add egm@egm | 通過三項自動化測試 |
| Claude Cowork | 從 claude.ai/plugins 或市集安裝同一套件 | 安裝可用，驗證缺口待補 |
| ChatGPT Work | 個人測試上傳外掛壓縮檔，工作區由管理員匯入市集 | 安裝可用，驗證缺口待補 |
各環境的行為有細微差異。Claude Code 的指令要加上 /egm: 前綴，子代理走 Agent 工具派發，預設可巢狀三層；審查角色在 Claude 這邊靠轉接檔載入，轉接檔會把共用角色設定成唯讀工具與隔離上下文，避免審查者動手改程式碼。Codex 與 ChatGPT 不原生註冊這些角色，而是由 general-purpose 子代理當場讀角色檔案扮演。
可移植性是靠工程紀律撐起來的。官方文件明寫「沒有任何環境拿到 skill 文字檔的 fork」：五個環境共用同一包 skills/、agents/ 與 resources/ 內容，根目錄的 plugin.json 宣告可攜的 Agent Plugins 1.0.0 schema，各環境的資訊清單只是指向這包內容的探索目錄，連詮釋資料漂移都有單元測試擋下來。這也是為什麼一個 Google 出的專案，能把同一套流程同時架上三家代理產品而不分裂成三份維護。
也有兩個地雷：只複製 skills/ 目錄的偷懶安裝會弄壞 EGM，因為 skill 執行期還要讀 agents/ 與 resources/document_standards/；更根本的是，官方文件明寫金魚審查需要全新上下文，環境若沒有子代理工具，review skill 會直接停下來，不退回同一個對話裡硬跑。官方文件還特別提醒，判斷環境支不支援要看實際工具清單，不要從產品名稱反推，ChatGPT 某些不提供全新上下文派發的模式就會踩到這條線。零上下文是這套方法的前提，官方寧可停也不折衷。
開源後的維護節奏也算誠實。10 月 23 日併入 Claude 讀檔的 PreToolUse hook（PR #113），讓外掛檔案讀取要經過使用者核准，同日修正 bootstrap 提示截斷與 Claude 對話紀錄查找（#114）；10 月 23 到 24 日讓使用者可以用一行設定自訂 EGM 的產物目錄（#118），把概念簡介、草稿與報告導到自己指定的資料夾，設計文件與其他專案檔不會搬移。主分支到 10 月 24 日共 9 筆提交，其中 Claude 讀檔 hook 與產物目錄設定（#113、#118）來自外部貢獻者，對一個開源四天的專案來說是健康的訊號。
「數千工程師每天用」的證據界線
採用現況的證據只有官方說法一層：公告與專案官網 egm.dev 首頁都拿「數千」當量級標語，但兩者都沒有提供對照組或量測方法，「讓 AI 第一次就寫出你要的程式」在公告裡也被定位為方法的目標而非保證。公告由五名作者代表 EGM 團隊署名，方法論的源頭是共同作者 Dave Rensin 的長文，公告引用他的說法「設計就是新的程式碼」；Rensin 的個人網站自述他是 Google Distinguished Engineer，早年開創了 Customer Reliability Engineering 團隊。
授權與支援的邊界倒是寫得明白：Apache 2.0 授權，README 與官網頁尾都聲明「這不是 Google 正式支援的產品」。工程團隊可以自由研究、修改規則與整合進自己的流程，但不能把它當成有服務承諾的產品依賴。
整套方法的價值排序也值得看一眼。公告收在「人類判斷才是唯一真正重要的產物」：代理負責探索與自動稽核，架構取捨與最終結果由工程師承擔；入門文件則把目標定得很樸素，做出符合你意圖的程式碼，外加一份解釋它為何長成這樣的文件。換句話說，這套外掛拚命自動化的東西，到頭來是為了逼出更高品質的人類決定，不把決定權外包出去。
就我的判斷，這次開源真正值得帶走的東西是流程本身的可移植性：規則是 Markdown、審查角色是文字檔，五個環境共用同一包內容，任何一個環境沒有特殊待遇。對跨檔案、多元件、需要交接的變更來說，先讓一個沒參與討論的讀者回述規格，最能抓出那種「聊天裡講過、文件裡沒寫」的缺口；反過來說，改一行說明文字的小任務跑整套編排是浪費，官方的入門文件自己也提醒，能一次修好的小 bug 就別硬走設計先行。
現在要做什麼
按環境分流最實際。Antigravity、Claude Code、Codex 的使用者，照上表整包安裝就能開始，挑一個下一個要動的功能先跑一輪 /egm-brainstorm 到 /egm-review，看看金魚回述失準的位置是不是正好落在你以為講清楚了的地方。Claude Cowork 與 ChatGPT Work 的使用者，安裝路徑可用，但值得盯著 issue #105 與 #106 等驗證補齊。還沒在用代理寫程式的人，什麼都不用做，先把「規格要寫到陌生人能讀懂」這個紀律帶走就夠了。
跑完第一輪之後怎麼判斷值不值得留下來，標準其實很具體：金魚回述出來的資料流，跟你心裡想的是不是同一條；實作就緒檢查能不能逐檔指出要改哪裡、輸入輸出約定是什麼。如果回述一直失準、關卡反覆擋下來，問題多半出在文件本身，把缺口補回規格再重跑一輪，比換模型或加更多審查角色有用。審查角色提供的是檢查角度，角色的數量本身不會自動換來正確率。
官方入門文件有個不花錢的建議值得採納：先不要裝任何東西，照著方法論把設計與審查的對話手動走幾輪，確認這套節奏適合你的專案，再讓外掛把它自動化。
未確認的事項要列清楚：內部採用成效只有官方說法；外部團隊的實際效果沒有公開數字；安裝命令與支援狀態在快速演進，基準是 2026 年 10 月 26 日的儲存庫快照，兩週後要安裝的人應回儲存庫再核一次命令與測試狀態。
一句話收尾：這次開源賣的並非又一個代理工具，而是 Google 把「設計文件先過獨立讀者這一關」做成了誰都能裝的流程包；裝不裝它，先問自己的規格經不經得起一個陌生人第一次讀。
