Google just open sourced their spec. driven AI coding agent methodology: Elephant Goldfish Model - https://github.com/google/elephant-goldfish-model (Idea from Google’s Distinguished Engineer: Dave Rensin). This is the method to facilitate software development in the AI era. Deep-context sessions agents draft specifications, and isolated zero-context Goldfish subagents stress-test them before coding.
Google 前不久開源了他們基於規格驅動(Spec-driven)的 AI 開發代理人方法論:大象金魚模型 - https://github.com/google/elephant-goldfish-model(Elephant Goldfish Model, EGM;概念源自 Google 傑出工程師 Dave Rensin)。
這是 AI 時代下促進軟體開發的方法。深層上下文(Deep-context)會話代理人負責草擬規格,而隔離的零上下文(Zero-context)子代理人則會在開始寫程式碼前對規格進行壓力測試。
這是 AI 時代下促進軟體開發的方法。深層上下文(Deep-context)會話代理人負責草擬規格,而隔離的零上下文(Zero-context)子代理人則會在開始寫程式碼前對規格進行壓力測試。
- The Elephant (Remembers everything): These deep context agents are used to load relevant context, including system history, architecture diagrams, component boundaries and user journeys. The “Elephant” runs structured brainstorming, probes operational limits and drafts specs.
- The Goldfish (Zero-context memory): These are stateless, isolated subagents that read only the drafted spec and source code. The Goldfish swarm stress-tests from different perspectives. Their personas in agents/ including Design Critic, Reader, Tech Lead, Codebase Auditor, Structural Validator, Style Editor and Architect.
EGM 的核心哲學是用兩種動物隱喻來建構整個軟體開發生命週期中的 AI 代理人:
- 大象(記住一切):這些深層上下文代理人用來載入所有相關背景資訊,包含系統歷史、架構圖、元件邊界與使用者旅程。「大象」負責執行結構化的腦力激盪、探索營運極限並草擬規格。
- 金魚(零上下文記憶):這些是無狀態(Stateless)、彼此隔離的子代理人,它們只閱讀草擬好的規格書與原始碼。「蜂群」會從不同角度進行壓力測試。 它們在 agents/ 目錄中的角色包含:設計評論家(Design Critic)、讀者(Reader)、技術主管(Tech Lead)、程式碼庫審計員(Codebase Auditor)、結構驗證員(Structural Validator)、風格編輯器(Style Editor)與架構師(Architect)。
The human owns the outcomes and uses the above AI agents as exploration partner and automated auditor. However, humans own the architectural decisions, trade-offs, and final results.
- 大象(記住一切):這些深層上下文代理人用來載入所有相關背景資訊,包含系統歷史、架構圖、元件邊界與使用者旅程。「大象」負責執行結構化的腦力激盪、探索營運極限並草擬規格。
- 金魚(零上下文記憶):這些是無狀態(Stateless)、彼此隔離的子代理人,它們只閱讀草擬好的規格書與原始碼。「蜂群」會從不同角度進行壓力測試。 它們在 agents/ 目錄中的角色包含:設計評論家(Design Critic)、讀者(Reader)、技術主管(Tech Lead)、程式碼庫審計員(Codebase Auditor)、結構驗證員(Structural Validator)、風格編輯器(Style Editor)與架構師(Architect)。
The human owns the outcomes and uses the above AI agents as exploration partner and automated auditor. However, humans own the architectural decisions, trade-offs, and final results.
人類負責掌控最終成果,並將上述 AI 代理人視為探索夥伴與自動化審計員。然而,架構決策、權衡取捨(Trade-offs)以及結果由人類完全承擔。
Based on the AI coding methodology, the Google and corresponding stakeholders (including Claude) contribute all the agent skills (Brainstorm, Draft, Review, Review Loop, Review Resolve, Drift Report, Bootstrap) to conduct this method to the software development work in several Harness environments (Google’s Antigravity, Anthropic’s Claude Code & Claude Cowork, OpenAI’s Codex & ChatGPT).
基於這套 AI 開發方法論,Google 與相關利益關係人(包含 Claude)貢獻了所有代理人技能(Brainstorm 腦力激盪、Draft 草擬、Review 審查、Review Loop 審查迴圈、Review Resolve 審查解決、Drift Report 偏離報告、Bootstrap 引導建置),以在多種 Harness 環境(Google 的 Antigravity、Anthropic 的 Claude Code 與 Claude Cowork、OpenAI 的 Codex 與 ChatGPT)中落實這套軟體開發工作流程。
This methodology and toolset helps to resolve unstructured, conversational AI code generation problems:
1. Hallucination Cascades & Context Pollution: When a single LLM thread interviews the developer, creates the design, and writes the code, the session context accumulates speculative hypotheses and conversational bias
2. Premature Implementation ("Weeds Syndrome"): Coding agents default to writing code immediately in nearby files, bypassing high-level architectural placement, simplicity checks, and existing infrastructure reuse.
3. Chat Dump Fatigue: Presenting multi-page design specs or lengthy review feedback directly in chat windows clutters conversation history, degrades LLM context performance, and creates poor user ergonomics.
4. Documentation Drift: Design documents written during project kickoff routinely rot as code evolves, breaking future AI agent onboarding
這套方法論與工具集有助於解決非結構化、對話式 AI 程式碼生成的常見問題:
1. 幻覺連鎖反應與上下文污染(Hallucination Cascades & Context Pollution):當單一 LLM 對話串同時負責面談開發者、建立設計與撰寫程式碼時,會話上下文不斷累積推測性的假設與對話偏見。
2. 過早實作 / 戒斷症狀(Premature Implementation / "Weeds Syndrome"):程式碼代理人預設會立即在鄰近檔案中撰寫程式碼,繞過高階架構配置、簡潔度檢查以及對現有基礎設施的重用。
3. 聊天訊息疲勞(Chat Dump Fatigue):在對話視窗中直接呈現長達數頁的設計規格或冗長的審查回饋,會使對話歷史變得雜亂,降低 LLM 上下文效能,並帶來極差的使用者體驗。
4. 文件偏離(Documentation Drift):在專案啟動時撰寫的設計文件通常會隨著程式碼演進而過期腐朽,進而破壞未來 AI 代理人的導入與熟悉(Onboarding)。
I’ve done it with one of mid-size projects with success. If you haven’t tried it, strongly suggest that you give it a try. May the force be with you.
我已經在一個中型專案成功應用了這套方法。如果你還沒試過,強烈建議你親自體驗看看。願原力與你同在。
This methodology and toolset helps to resolve unstructured, conversational AI code generation problems:
1. Hallucination Cascades & Context Pollution: When a single LLM thread interviews the developer, creates the design, and writes the code, the session context accumulates speculative hypotheses and conversational bias
2. Premature Implementation ("Weeds Syndrome"): Coding agents default to writing code immediately in nearby files, bypassing high-level architectural placement, simplicity checks, and existing infrastructure reuse.
3. Chat Dump Fatigue: Presenting multi-page design specs or lengthy review feedback directly in chat windows clutters conversation history, degrades LLM context performance, and creates poor user ergonomics.
4. Documentation Drift: Design documents written during project kickoff routinely rot as code evolves, breaking future AI agent onboarding
這套方法論與工具集有助於解決非結構化、對話式 AI 程式碼生成的常見問題:
1. 幻覺連鎖反應與上下文污染(Hallucination Cascades & Context Pollution):當單一 LLM 對話串同時負責面談開發者、建立設計與撰寫程式碼時,會話上下文不斷累積推測性的假設與對話偏見。
2. 過早實作 / 戒斷症狀(Premature Implementation / "Weeds Syndrome"):程式碼代理人預設會立即在鄰近檔案中撰寫程式碼,繞過高階架構配置、簡潔度檢查以及對現有基礎設施的重用。
3. 聊天訊息疲勞(Chat Dump Fatigue):在對話視窗中直接呈現長達數頁的設計規格或冗長的審查回饋,會使對話歷史變得雜亂,降低 LLM 上下文效能,並帶來極差的使用者體驗。
4. 文件偏離(Documentation Drift):在專案啟動時撰寫的設計文件通常會隨著程式碼演進而過期腐朽,進而破壞未來 AI 代理人的導入與熟悉(Onboarding)。
I’ve done it with one of mid-size projects with success. If you haven’t tried it, strongly suggest that you give it a try. May the force be with you.
我已經在一個中型專案成功應用了這套方法。如果你還沒試過,強烈建議你親自體驗看看。願原力與你同在。
沒有留言:
張貼留言