GAN 啟發的生成器-評估器代理框架，用於自主建構高品質應用程式。基於 Anthropic 2026 年 3 月的框架設計論文。
GAN 風格框架技能
靈感來自 Anthropic 的長期應用開發框架設計（2026 年 3 月 24 日）
一個多代理框架，將生成與評估分離，形成對抗性回饋循環，驅動品質遠超過單一代理所能達到的水準。
核心洞察
當要求評估自己的作品時，代理是病態的樂觀主義者——它們稱讚平庸的輸出，並說服自己忽略真正的問題。但設計一個獨立的評估器，讓它極度嚴格，遠比教生成器自我批評要容易得多。
這與 GAN（生成對抗網路）的動態相同：生成器產生，評估器批評，而這個回饋驅動下一次迭代。
使用時機
- 從一行提示建構完整應用程式
- 需要高視覺品質的前端設計任務
- 需要可運作功能而不只是程式碼的全端專案
- 任何「AI 垃圾」美學不可接受的任務
- 願意投入 50-200 美元以獲得生產級品質輸出的專案
不適合使用時機
- 快速的單一檔案修復（使用標準
claude -p） - 預算緊縮的任務（低於 10 美元）
- 簡單的重構（改用 de-sloppify 模式）
- 已經有良好規格和測試的任務（使用 TDD 工作流程）
架構
┌─────────────┐
│ 規劃器 │
│ (Opus 4.6) │
└──────┬──────┘
│ 產品規格
│ (功能、衝刺、設計方向)
▼
┌────────────────────────┐
│ │
│ 生成器-評估器 │
│ 回饋循環 │
│ │
│ ┌──────────┐ │
│ │ 生成器 │--建置-->│──┐
│ │(Opus 4.6)│ │ │
│ └────▲─────┘ │ │
│ │ │ │ 即時應用
│ 回饋 │ │
│ │ │ │
│ ┌────┴─────┐ │ │
│ │ 評估器 │<-測試----│──┘
│ │(Opus 4.6)│ │
│ │+Playwright│ │
│ └──────────┘ │
│ │
│ 5-15 次迭代 │
└────────────────────────┘
三個代理
1. 規劃器代理
角色： 產品經理——將簡短提示擴展為完整的產品規格。
關鍵行為：
- 接收一行提示，產出包含 16 項功能、多個衝刺的規格
- 定義使用者故事、技術需求和視覺設計方向
- 刻意雄心勃勃——保守規劃會導致平庸結果
- 產出評估器後續使用的評估標準
模型： Opus 4.6（需要深度推理來擴展規格）
2. 生成器代理
角色： 開發者——根據規格實作功能。
關鍵行為：
- 以結構化衝刺方式工作（或使用較新模型的連續模式）
- 在撰寫程式碼前與評估器協商「衝刺合約」
- 使用全端工具：React、FastAPI/Express、資料庫、CSS
- 管理 git 以進行迭代間的版本控制
- 讀取評估器回饋並納入下一次迭代
模型： Opus 4.6（需要強大的編碼能力）
3. 評估器代理
角色： QA 工程師——測試即時運行的應用程式，而不只是程式碼。
關鍵行為：
- 使用 Playwright MCP 與即時應用互動
- 點擊功能、填寫表單、測試 API 端點
- 根據四個標準（可設定）評分：
- 設計品質——是否感覺像一個連貫的整體？
- 原創性——自訂決策 vs. 模板/AI 模式？
- 工藝——字體、間距、動畫、微互動？
- 功能性——所有功能是否真的能運作？
- 回傳結構化回饋，包含分數和具體問題
- 設計為極度嚴格——絕不稱讚平庸的作品
模型： Opus 4.6（需要強大的判斷力 + 工具使用）
評估標準
預設四個標準，每個評分 1-10：
## 評估評分表
### 設計品質（權重：0.3）
- 1-3：通用、模板化、「AI 垃圾」美學
- 4-6：合格但平庸，遵循慣例
- 7-8：獨特、連貫的視覺識別
- 9-10：可媲美專業設計師的作品
### 原創性（權重：0.2）
- 1-3：預設顏色、標準佈局、無個性
- 4-6：有些自訂選擇，大多為標準模式
- 7-8：清晰的創意視野，獨特的方法
- 9-10：令人驚喜、愉悅、真正新穎
### 工藝（權重：0.3）
- 1-3：佈局破損、缺少狀態、無動畫
- 4-6：可運作但感覺粗糙、間距不一致
- 7-8：精緻、流暢的轉場、響應式
- 9-10：像素完美、令人愉悅的微互動
### 功能性（權重：0.2）
- 1-3：核心功能故障或缺失
- 4-6：快樂路徑可運作，邊緣案例失敗
- 7-8：所有功能正常，良好的錯誤處理
- 9-10：無懈可擊，處理每個邊緣案例
評分
- 加權分數 = 總和（標準分數 * 權重）
- 通過門檻 = 7.0（可設定）
- 最大迭代次數 = 15（可設定，通常 5-15 次足夠）
使用方式
透過指令
# 完整三代理框架
/project:gan-build "建立一個包含看板、團隊協作和深色模式的專案管理應用"
# 自訂設定
/project:gan-build "建立一個食譜分享平台" --max-iterations 10 --pass-threshold 7.5
# 前端設計模式（僅生成器 + 評估器，無規劃器）
/project:gan-design "為加密貨幣投資組合追蹤器建立一個登陸頁面"
透過 Shell 腳本
# 基本用法
./scripts/gan-harness.sh "建立一個音樂串流儀表板"
# 帶選項
GAN_MAX_ITERATIONS=10 \
GAN_PASS_THRESHOLD=7.5 \
GAN_EVAL_CRITERIA="functionality,performance,security" \
./scripts/gan-harness.sh "建立一個任務管理的 REST API"
透過 Claude Code（手動）
# 步驟 1：規劃
claude -p --model opus "你是產品規劃器。閱讀 PLANNER_PROMPT.md。將這個簡短提示擴展為完整的產品規格：'建立一個看板應用程式'。將規格寫入 spec.md"
# 步驟 2：生成（第 1 次迭代）
claude -p --model opus "你是生成器。閱讀 spec.md。實作衝刺 1。在連接埠 3000 啟動開發伺服器。"
# 步驟 3：評估（第 1 次迭代）
claude -p --model opus --allowedTools "Read,Bash,mcp__playwright__*" "你是評估器。閱讀 EVALUATOR_PROMPT.md。測試 http://localhost:3000 的即時應用。根據評分表評分。將回饋寫入 feedback-001.md"
# 步驟 4：生成（第 2 次迭代——讀取回饋）
claude -p --model opus "你是生成器。閱讀 spec.md 和 feedback-001.md。解決所有問題。改善分數。"
# 重複步驟 3-4 直到達到通過門檻
模型能力演進
框架應隨著模型改進而簡化。遵循 Anthropic 的演進：
階段 1——較弱模型（Sonnet 等級）
- 需要完整的衝刺分解
- 衝刺之間重置上下文（避免上下文焦慮）
- 最少 2 個代理：初始化器 + 編碼代理
- 大量支架補償模型限制
階段 2——能力模型（Opus 4.5 等級）
- 完整 3 代理框架：規劃器 + 生成器 + 評估器
- 每個實作階段前的衝刺合約
- 複雜應用程式的 10 衝刺分解
- 上下文重置仍有幫助但較不關鍵
階段 3——前沿模型（Opus 4.6 等級）
- 簡化框架：單次規劃，連續生成
- 評估減少為單次最終評估（模型更聰明）
- 不需要衝刺結構
- 自動壓縮處理上下文增長
關鍵原則： 框架的每個元件都編碼了對模型無法獨自完成之事的假設。當模型改進時，重新測試這些假設。移除不再需要的部分。
設定
環境變數
| 變數 | 預設值 | 說明 |
|---|---|---|
GAN_MAX_ITERATIONS |
15 |
最大生成器-評估器循環次數 |
GAN_PASS_THRESHOLD |
7.0 |
通過的加權分數（1-10） |
GAN_PLANNER_MODEL |
opus |
規劃器代理的模型 |
GAN_GENERATOR_MODEL |
opus |
生成器代理的模型 |
GAN_EVALUATOR_MODEL |
opus |
評估器代理的模型 |
GAN_EVAL_CRITERIA |
design,originality,craft,functionality |
逗號分隔的標準 |
GAN_DEV_SERVER_PORT |
3000 |
即時應用程式的連接埠 |
GAN_DEV_SERVER_CMD |
npm run dev |
啟動開發伺服器的指令 |
GAN_PROJECT_DIR |
. |
專案工作目錄 |
GAN_SKIP_PLANNER |
false |
跳過規劃器，直接使用規格 |
GAN_EVAL_MODE |
playwright |
playwright、screenshot 或 code-only |
評估模式
| 模式 | 工具 | 最適合 |
|---|---|---|
playwright |
瀏覽器 MCP + 即時互動 | 有 UI 的全端應用 |
screenshot |
螢幕截圖 + 視覺分析 | 靜態網站、純設計 |
code-only |
測試 + linting + 建置 | API、函式庫、CLI 工具 |
反模式
-
評估器太寬容——如果評估器在第 1 次迭代就通過所有項目，你的評分表太寬鬆了。收緊評分標準，並為常見的 AI 模式加入明確的扣分。
-
生成器忽略回饋——確保回饋以檔案形式傳遞，而非內嵌。生成器應在每次迭代開始時讀取
feedback-NNN.md。 -
無限循環——務必設定
GAN_MAX_ITERATIONS。如果生成器在 3 次迭代後無法突破分數高原，停止並標記為需人工審查。 -
評估器測試表面化——評估器必須使用 Playwright 與即時應用互動，而不只是截圖。點擊按鈕、填寫表單、測試錯誤狀態。
-
評估器稱讚自己的修復——絕不讓評估器建議修復然後評估那些修復。評估器只批評；生成器負責修復。
-
上下文耗盡——對於長時間會話，使用 Claude Agent SDK 的自動壓縮或在主要階段之間重置上下文。
結果：預期成效
根據 Anthropic 發表的結果：
| 指標 | 單一代理 | GAN 框架 | 改善幅度 |
|---|---|---|---|
| 時間 | 20 分鐘 | 4-6 小時 | 12-18 倍更長 |
| 成本 | 9 美元 | 125-200 美元 | 14-22 倍更多 |
| 品質 | 勉強可用 | 生產就緒 | 質變 |
| 核心功能 | 故障 | 全部正常 | 不適用 |
| 設計 | 通用 AI 垃圾 | 獨特、精緻 | 不適用 |
取捨很明確： 約 20 倍的時間和成本，換取輸出品質的質的飛躍。這適用於品質至上的專案。
參考資料
- Anthropic：長期執行應用的框架設計 — Prithvi Rajasekaran 的原創論文
- Epsilla：GAN 風格的代理循環 — 架構解構
- Martin Fowler：框架工程 — 更廣泛的產業背景
- OpenAI：框架工程 — OpenAI 的平行研究
