GAN 風格協作框架技能
靈感來自 Anthropic 的長期應用開發 Harness 設計 (2026 年 3 月 24 日)
一個多代理協作框架,將生成與評估分離,形成對抗性的反饋循環,驅動品質遠超單一代理所能達到的水準。
核心洞見
當要求代理評估自己的工作時,它們是病態的樂觀主義者——它們會讚揚平庸的輸出,並說服自己忽視真正的問題。但設計一個獨立的評估器,使其變得殘酷嚴謹,遠比教導生成器自我批評要可行得多。
這與 GAN(生成對抗網路)的動態相同:生成器負責產出,評估器負責批評,而反饋驅動下一次迭代。
使用時機
- 從一行提示詞建構完整的應用程式
- 需要高視覺品質的前端設計任務
- 需要可運作功能而非僅是程式碼的全端專案
- 任何無法忍受「AI 劣質美學」的任務
- 願意投入 50-200 美元以獲得生產級品質的專案
不應使用時機
- 快速的單檔案修復(使用標準的
claude -p) - 預算緊張(低於 10 美元)的任務
- 簡單的程式碼重構(改用 de-sloppify 模式)
- 已經有明確定義與測試的任務(使用 TDD 工作流程)
架構
┌─────────────┐
│ 規劃器 │
│ (Sonnet) │
└──────┬──────┘
│ 產品規格
│ (功能、衝刺、設計方向)
▼
┌────────────────────────┐
│ │
│ 生成器-評估器 │
│ 反饋循環 │
│ │
│ ┌──────────┐ │
│ │ 生成器 │--建構-->│──┐
│ │ (Sonnet) │ │ │
│ └────▲─────┘ │ │
│ │ │ │ 即時應用
│ 反饋 │ │
│ │ │ │
│ ┌────┴─────┐ │ │
│ │ 評估器 │<--測試---│──┘
│ │ (Sonnet) │ │
│ │+Playwright│ │
│ └──────────┘ │
│ │
│ 5-15 次迭代 │
└────────────────────────┘
三個代理
1. 規劃器代理
角色: 產品經理 — 將簡短的提示詞擴展為完整的產品規格。
關鍵行為:
- 接收一行提示詞,產出包含 16 個功能、多個衝刺的規格
- 定義使用者故事、技術需求與視覺設計方向
- 刻意雄心勃勃 — 保守的規劃會導致平庸的結果
- 產出評估器後續將使用的評估標準
模型: 預設為 Sonnet;可透過 GAN_PLANNER_MODEL=opus 提升以進行更深入的規格擴展
2. 生成器代理
角色: 開發者 — 根據規格實作功能。
關鍵行為:
- 以結構化衝刺(或與較新模型搭配的連續模式)進行開發
- 在編寫程式碼前,先與評估器協商「衝刺合約」
- 使用全端工具:React、FastAPI/Express、資料庫、CSS
- 管理 git 以進行迭代間的版本控制
- 閱讀評估器的反饋,並在下一次迭代中納入
模型: 預設為 Sonnet;可透過 GAN_GENERATOR_MODEL=opus 提升以獲得最大編碼能力
3. 評估器代理
角色: 品質保證工程師 — 測試即時運行的應用程式,而非僅是程式碼。
關鍵行為:
- 使用 Playwright MCP 與即時應用程式互動
- 點擊功能、填寫表單、測試 API 端點
- 根據四個可設定的標準進行評分:
- 設計品質 — 整體感覺是否一致?
- 原創性 — 自訂決策 vs. 模板/AI 模式?
- 工藝 — 排版、間距、動畫、微互動?
- 功能性 — 所有功能是否真的有效?
- 回傳結構化的反饋,包含分數與具體問題
- 被設計為殘酷嚴謹 — 絕不讚揚平庸的作品
模型: 預設為 Sonnet;可透過 GAN_EVALUATOR_MODEL=opus 提升以獲得更強的判斷力與工具使用能力
評估標準
預設的四個標準,每個評分 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 sonnet "你是一個產品規劃器。閱讀 PLANNER_PROMPT.md。將這個簡短提示擴展成完整的產品規格:'建立一個看板應用程式'。將規格寫入 spec.md"
# 步驟 2: 生成 (第一次迭代)
claude -p --model sonnet "你是一個生成器。閱讀 spec.md。實作衝刺 1。在連接埠 3000 啟動開發伺服器。"
# 步驟 3: 評估 (第一次迭代)
claude -p --model sonnet --allowedTools "Read,Bash,mcp__playwright__*" "你是一個評估器。閱讀 EVALUATOR_PROMPT.md。測試 http://localhost:3000 的即時應用程式。根據評分表評分。將反饋寫入 feedback-001.md"
# 步驟 4: 生成 (第二次迭代 — 閱讀反饋)
claude -p --model sonnet "你是一個生成器。閱讀 spec.md 和 feedback-001.md。解決所有問題。提高分數。"
# 重複步驟 3-4 直到達到通過門檻
隨模型能力演進
隨著模型改進,協作框架應隨之簡化。遵循 Anthropic 的演進路線:
第一階段 — 較弱模型 (Sonnet 等級)
- 需要完整的衝刺拆分
- 衝刺之間的上下文重置(避免上下文焦慮)
- 最少 2 個代理:初始化器 + 編碼代理
- 大量框架補償模型限制
第二階段 — 能力強模型 (Opus 4.5 等級)
- 完整的 3 代理協作框架:規劃器 + 生成器 + 評估器
- 每個實作階段前都有衝刺合約
- 複雜應用程式採用 10 個衝刺拆分
- 上下文重置仍有幫助,但不那麼關鍵
第三階段 — 前沿模型 (Opus 4.6 等級)
- 簡化協作框架:單次規劃階段、連續生成
- 評估縮減為單次最終評估(模型更聰明)
- 不需要衝刺結構
- 自動壓縮處理上下文增長
關鍵原則: 框架的每個元件都編碼了關於模型獨自無法勝任的假設。當模型改進時,重新測試這些假設。移除不再需要的部分。
設定
環境變數
| 變數 | 預設值 | 說明 |
|---|---|---|
GAN_MAX_ITERATIONS | 15 | 生成器-評估器的最大循環次數 |
GAN_PASS_THRESHOLD | 7.0 | 通過的加權分數 (1-10) |
GAN_PLANNER_MODEL | sonnet | 規劃代理的模型 |
GAN_GENERATOR_MODEL | sonnet | 生成代理的模型 |
GAN_EVALUATOR_MODEL | sonnet | 評估代理的模型 |
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 | 測試 + 程式碼檢查 + 建構 | API、函式庫、CLI 工具 |
反模式
-
評估器過於寬容 — 如果評估器在第一次迭代就通過所有項目,則表示評分標準過於寬鬆。應緊縮評分標準,並為常見的 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: Harness Design for Long-Running Apps — Prithvi Rajasekaran 的原創論文
- Epsilla: The GAN-Style Agent Loop — 架構解構
- Martin Fowler: Harness Engineering — 更廣泛的行業背景
- OpenAI: Harness Engineering — OpenAI 的平行工作