GAN-Style Harness 技能
靈感來自 Anthropic 的長期應用程式開發框架設計（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 提升至 Opus 以進行更深入的規格擴展
2. 生成器代理
角色： 開發者——根據規格實現功能。
主要行為：
- 在結構化的衝刺中工作（或使用較新模型的連續模式）
- 在編寫程式碼前與評估器協商「衝刺合約」
- 使用全端工具：React、FastAPI/Express、資料庫、CSS
- 管理 git 以進行迭代間的版本控制
- 讀取評估器反饋並將其納入下一次迭代
模型： 預設為 Sonnet；可透過 GAN_GENERATOR_MODEL=opus 提升至 Opus 以獲得最大編碼能力
3. 評估器代理
角色： QA 工程師——測試實際運行的應用程式，而不僅僅是程式碼。
主要行為：
- 使用 Playwright MCP 與實際運行的應用程式互動
- 點擊功能、填寫表單、測試 API 端點
- 根據四個標準進行評分（可配置）：
- 設計品質——它是否感覺像一個連貫的整體？
- 原創性——自訂決策 vs. 模板/AI 模式？
- 工藝——字體排印、間距、動畫、微互動？
- 功能性——所有功能是否真的有效？
- 返回帶有分數和具體問題的結構化反饋
- 被設計為無情地嚴格——從不讚揚平庸的工作
模型： 預設為 Sonnet；可透過 GAN_EVALUATOR_MODEL=opus 提升至 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 "Build a project management app with Kanban boards, team collaboration, and dark mode"
# 使用自訂配置
/project:gan-build "Build a recipe sharing platform" --max-iterations 10 --pass-threshold 7.5
# 前端設計模式（僅生成器 + 評估器，無規劃器）
/project:gan-design "Create a landing page for a crypto portfolio tracker"
透過 Shell 腳本
# 基本用法
./scripts/gan-harness.sh "Build a music streaming dashboard"
# 帶選項
GAN_MAX_ITERATIONS=10 \
GAN_PASS_THRESHOLD=7.5 \
GAN_EVAL_CRITERIA="functionality,performance,security" \
./scripts/gan-harness.sh "Build a REST API for task management"
透過 Claude Code（手動）
# 步驟 1：規劃
claude -p --model sonnet "You are a Product Planner. Read PLANNER_PROMPT.md. Expand this brief into a full product spec: 'Build a Kanban board app'. Write spec to spec.md"
# 步驟 2：生成（迭代 1）
claude -p --model sonnet "You are a Generator. Read spec.md. Implement Sprint 1. Start the dev server on port 3000."
# 步驟 3：評估（迭代 1）
claude -p --model sonnet --allowedTools "Read,Bash,mcp__playwright__*" "You are an Evaluator. Read EVALUATOR_PROMPT.md. Test the live app at http://localhost:3000. Score against the rubric. Write feedback to feedback-001.md"
# 步驟 4：生成（迭代 2 — 讀取反饋）
claude -p --model sonnet "You are a Generator. Read spec.md and feedback-001.md. Address all issues. Improve the scores."
# 重複步驟 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 | 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 | 測試 + linting + 建構 | 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：長期運行應用的框架設計 — Prithvi Rajasekaran 的原創論文
- Epsilla：GAN 風格的代理循環 — 架構解構
- Martin Fowler：框架工程 — 更廣泛的行業背景
- OpenAI：框架工程 — OpenAI 的並行工作