Google 開源 Elephant-Goldfish：AI 寫程式前，先讓另一個代理讀懂設計
Google 開源 Elephant-Goldfish Model 外掛，以大象保留設計脈絡、金魚獨立檢查規格。解析腦力激盪、文件草擬與三層審稿流程，以及 Antigravity、Claude Code、Codex 的安裝和支援邊界。
和 AI 聊了一下午，設計看似已經清楚，換個沒參與的人來看，卻不知道資料從哪裡進、失敗後怎麼恢復。Elephant-Goldfish 想讓這些缺口在寫程式前浮現。
Google 在 2026 年 10 月 22 日宣布開源 Elephant-Goldfish Model 外掛，把保留脈絡的設計工作與重新開始的審稿工作分開，讓規格先接受獨立閱讀，再進入程式實作。
其中的「大象」負責理解系統、討論取捨並整理設計。「金魚」只拿到需要審查的材料，從讀者、技術與實作準備等角度找出缺口。
這套流程要交付的是足以指導修改的設計文件，而不是多幾句看起來嚴格的提示詞。檔案、資料結構與函式介面是否說清楚，會直接影響後面能不能照規格動手。
我的判斷是，涉及多個元件與既有使用者的變更最值得採用這種分工。但新的對話環境不會自動帶來正確答案，工程師仍須決定證據是否充分、取捨是否可接受。
先分清楚大象該記住什麼、金魚刻意不繼承什麼，才知道三個階段為何不能只合併成一次自我檢查。
Elephant-Goldfish 為什麼拆開設計與審稿脈絡？
大象保留專案歷史與設計意圖，金魚則用沒有承接原對話的環境檢查規格，減少依賴討論中未寫下的共識。Elephant-Goldfish 的分工針對的是「參與討論的人懂，文件本身卻沒有講清楚」的問題。
開發者和代理來回解釋之後，可能已經知道某個欄位不能修改、某種失敗要交人工處理。但這些限制若只留在聊天裡，下一個負責實作的人便得自行猜測，程式也可能照著不完整的規格生成。
Google 的開源公告把長脈絡工作稱為大象，負責保存整體架構、專案記憶與細部決定。它適合在設計期間持續理解為何選這個方案。
金魚則重新開始，閱讀指定設計文件與需要的原始碼，檢查內容能否獨立成立。它不繼承先前討論的默契，因此較有機會指出文件漏寫的條件，讓設計者把意思補回正式材料。
這種獨立並不保證判斷完全客觀。代理仍可能誤解程式或提出不適用的建議，工程師要評估評論的依據，而不只是看到另一個模型說通過，就結束設計。
要讓這種分工有用，第一階段便得先把問題與取捨說清楚，而不是直接開始改程式。
egm-brainstorm 如何把模糊需求變成可討論的範圍？
腦力激盪階段採取不寫程式的規則，由代理追問背景、邊界與替代方案，讓人先選擇要解決的問題。這個暫停動手的安排，是為了避免實作太早固定尚未想清楚的選擇。
以一個假設的檔案匯入功能為例，「讓客戶上傳資料」還不足以動工。哪些檔案能收、讀到一半失敗怎麼辦、重送會不會產生重複資料，都會改變後面的介面與保存方式。
如果直接要求代理完成畫面，它可能先把上傳按鈕做出來，但重要的失敗流程仍沒有決定。腦力激盪把這些問題提前，使使用者可以在尚未寫程式時選擇取捨。
大象在這裡扮演訪談與共同設計的角色。它可以追問系統限制，並讓使用者比較方案，但設計的目標仍由人決定，不能把代理偏好的技術選項當成既定需求。
不同選擇也應帶著理由。例如先支援小檔案，可以縮小初期處理範圍。若必須接長時間匯入，就需要決定進度、恢復與錯誤回報。這些是示意情境，並非外掛自動替所有產品做出的標準答案。
選擇需要留下可閱讀的理由，接下來的設計文件才不會只是一串功能名稱。
egm-draft 要留下哪些能實作的決定？
草稿階段把問題、技術方案、替代方案與具體修改檔案寫進持續更新的 Markdown 設計文件。Markdown 是用純文字標記標題、段落與清單的格式，方便與程式碼一起保存版本。
這份文件的用途，是讓後續工作者知道要改哪裡，以及修改為何符合先前的選擇。只寫「新增匯入功能」無法達到這點，因為實作者還不知道資料從哪裡進來、要保存什麼狀態。
延續匯入的假設例子，設計可說明接收檔案的入口、處理結果的保存方式與錯誤回應。若需要修改數個檔案，也應把各檔案的責任寫清楚，讓變更範圍有明確邊界。
替代方案則保留沒有採用的路徑與原因。下一位實作者遇到困難時，便能看出某個看似方便的做法是否早已因資料限制而被排除，減少重新做一次相同討論。
這也方便區分需求改變與實作偷換方案。若後來真的放寬檔案範圍，文件可以記下新決定，而非讓不同代理各自沿用印象中的版本。
官方將這個階段設計為反覆編寫，而非一次吐出長文件後就凍結。因為新的問題可能改變原方案，修正要回到同一份規格，避免聊天與文件各自保留不同版本的決定。
文件完整與否，不能只由寫它的那段對話判定，必須交給沒有參與討論的讀者試著重建意思。
理解檢查、對抗審稿與就緒關卡如何接續？
金魚先回述架構與意圖，再從不同角度找邊界與依賴，最後確認檔案路徑、資料結構與函式簽章是否足以開始實作。函式簽章描述一個程式功能接收什麼、回傳什麼，是不同部分能接起來的約定。
理解檢查先問文件能不能被讀懂。如果新讀者回述的資料流與設計者想像不同，代表文件可能有歧義，這時急著增加更多技術評論，反而會讓討論建立在不同前提上。
例如，設計者以為匯入完成才更新清單，讀者卻以為每處理一筆就立即顯示。兩種理解會產生不同的中途狀態，回述能先讓差異浮現，再由人決定文件應明確寫成哪一種。
等基本意思能對齊，再由持懷疑態度的審稿者尋找缺口。它們可從隱藏依賴、邊界情況與邏輯問題檢查設計，讓評論針對具體條件，而不是籠統說「應該更安全」。
最後的實作就緒檢查，則確認指示是否已足夠讓人動手。方案可能有道理，卻還沒指出要修改的介面。若此時交給程式代理，未寫下的決定仍會由它臨場補完。
就緒關卡因此需要比「這個方案可行」更具體。負責接收資料的函式，是否知道錯誤時要回傳哪種結果。呼叫它的畫面，是否知道何時可以顯示完成，都應在開始實作前對齊。
這幾層審查各有用途，可以沿著同一項匯入設計理解差別。
| 審查位置 | 讀者要能回答的問題 |
|---|---|
| 理解檢查 | 檔案進來後，資料經過哪些地方？ |
| 對抗審稿 | 處理中斷或重送時，既有方案是否漏掉情況？ |
| 實作就緒 | 修改哪個檔案、輸入與回傳的約定是否已寫明？ |
表中的例子是對官方流程的示意，不表示外掛已替這個假設功能找出真實缺陷。找到問題後要回到設計者解決，若只累積評論而不修正文件，下一個代理仍會撞上同樣缺口。
如何讓評論真正回到規格與程式碼？
官方程式庫提供審查、處理評論與規格漂移報告等工作流程，並建議把已核設計提交成 PR，再按批准規格實作。PR 是把修改交給他人審查的合併請求，可讓團隊看清版本差異。
官方 README列出的評論處理流程，能協助把審稿發現分類並回寫修正。對團隊來說，關鍵是知道哪個問題成立、怎麼修改，以及哪些建議因不符需求而未採納。
若金魚要求改掉已明確決定的限制，也應回原始依據判斷。例如產品只能保留特定資料，審稿者不能因為多存一份比較方便，就把這項限制當成可隨意調整的偏好。
規格通過後，程式仍可能在實作過程偏離決定。專案提供的漂移報告，是針對已保存規格與現行程式之間的差異提出線索，讓文件不只在開工前被看一次。
這也使設計文件具有後續用途：當需求真的改變，可以一起更新規格與程式，說明取捨如何調整。若只是默默修改程式，下一輪審稿仍可能拿舊設計作為前提。
對已進入實作的變更，AI 程式驗收教學補上測試與人工審查的分工。規格可實作，與實際程式正確運作，仍是需要各自證據的事情。
延伸閱讀：AI 程式驗收教學：人工審查、測試與逐步上線，各自能抓到哪些錯誤
這些流程能追蹤決定，卻不能替工程師判定每項評論都正確，也不代表審過規格便不用測試程式。
Antigravity、Claude Code 與 Codex 的安裝資訊為何要分日期？
十月二十二日公告以 Antigravity 為主要整合入口，而本次查閱的官方 README 已另列 Claude Code 與 Codex 等安裝方式。公告與持續更新的程式庫描述不同時間點，讀者應依實際環境採用對應指令。
依二〇二六年十月二十六日查閱的內容，Antigravity 可透過外掛入口安裝，Claude Code 與 Codex 則各有自己的外掛市集命令。桌面與工作區環境另有設定說明，不能只把一條命令複製到所有工具。
命令名稱也有差異。Claude Code 使用帶有外掛名稱的前綴，因此官方通用示例與實際輸入可能不同。安裝後應沿該環境指南確認腦力激盪、草稿與審查入口。
程式庫還列出不同審稿角色，例如新手讀者、技術主管與程式庫稽核者。這些角色提供檢查角度，不代表增加數量就必然增加正確率，仍要讓它們取得適合該問題的材料。
程式碼授權與產品支援要分開
專案採 Apache 2.0 授權，README 同時明示這不是 Google 正式支援的產品。工程團隊可以研究與整合開源流程，但不能把它當成由 Google 代為運行且有產品服務承諾的功能。
Google 公告說數千名內部工程師每天使用，這是官方對採用情況的說明。它沒有提供本次可重現的成效對照，不能由使用人數推導每個外部專案都會第一次就寫對。
在這些邊界下，外掛是否值得增加一道設計流程，仍要回到修改的規模與交接需求。
哪些變更值得增加獨立設計審查？
當一項修改牽涉資料保存、元件邊界或多個修改檔案，讓新讀者重建方案更容易揭露實作前就能修正的誤解。這些變更若等到程式完成才發現前提不同，通常要同時回頭修改多處。
我會把這套流程用在需要交接的設計上：如果下一個人只讀文件，能否知道資料如何流動、失敗後怎麼做，以及哪些選擇不能自行更改。金魚回述失準的位置，正好是文件需要補上的內容。
只改一段說明文字的小任務，未必需要完整審稿編排。流程應服務變更本身的理解成本，否則大量文件與評論，也可能變成另一種需要維護卻無助於交付的工作。
若團隊還在選擇代理可使用的工具，Claude Code UI 工具查核能幫助理解工具各自的角色，再決定審查應要求哪些證據。
延伸閱讀：Claude Code UI 設計工具怎麼選？10 個 GitHub 專案逐項查核與分工指南
審查是否有效，應看規格補上了哪些可執行決定，而不是看派出了多少個代理。可以先拿下一個需要跨檔案修改的功能，用獨立讀者回述一次設計，再觀察文件是否真的減少了猜測。
常見問題 FAQ
Elephant-Goldfish 的金魚完全不看程式嗎？
它不繼承共同設計的聊天脈絡，但可閱讀指定規格與現行程式，才能檢查方案是否符合專案條件。
規格通過後還要人工審查嗎？
需要。專案把人類放在決定架構取捨與承擔結果的位置，獨立代理提供評論，不能代替人決定所有問題。
可以自行調整審稿角色嗎？
官方程式庫提供可調整的規則、代理角色與工作流程。調整時應保留每個角色要取得的證據與明確任務，避免只換角色名稱卻沒有改變檢查方式。
