docs/zh-CN/skills/gan-style-harness
GAN 风格编排技能
灵感来源于 Anthropic 的长时间运行应用开发编排设计(2026年3月24日)
一种多智能体编排,将生成与评估分离,形成对抗性反馈循环,推动质量远超单个智能体所能达到的水平。
核心洞察
当要求评估自身工作时,智能体是病态的乐观主义者——它们会赞美平庸的输出,并说服自己忽略真正的问题。但设计一个独立的评估器并使其极度严格,远比教会生成器自我批评要容易得多。
这与 GAN(生成对抗网络)的机制相同:生成器负责产出,评估器负责批评,这种反馈驱动下一轮迭代。
适用场景
- 根据一行提示构建完整应用
- 需要高视觉质量的前端设计任务
- 需要工作功能而不仅仅是代码的全栈项目
- 任何"AI 垃圾"美学不可接受的任务
- 愿意投入 50-200 美元以获得生产级质量输出的项目
不适用场景
- 快速单文件修复(使用标准
claude -p) - 预算紧张的任务(<10 美元)
- 简单重构(改用去垃圾化模式)
- 已有完善测试规范的任务(使用 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 次足够)
使用方法
通过命令行
# Full three-agent harness
/project:gan-build "Build a project management app with Kanban boards, team collaboration, and dark mode"
# With custom config
/project:gan-build "Build a recipe sharing platform" --max-iterations 10 --pass-threshold 7.5
# Frontend design mode (generator + evaluator only, no planner)
/project:gan-design "Create a landing page for a crypto portfolio tracker"
通过 Shell 脚本
# Basic usage
./scripts/gan-harness.sh "Build a music streaming dashboard"
# With options
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(手动)
# Step 1: Plan
claude -p --model opus "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"
# Step 2: Generate (iteration 1)
claude -p --model opus "You are a Generator. Read spec.md. Implement Sprint 1. Start the dev server on port 3000."
# Step 3: Evaluate (iteration 1)
claude -p --model opus --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"
# Step 4: Generate (iteration 2 — reads feedback)
claude -p --model opus "You are a Generator. Read spec.md and feedback-001.md. Address all issues. Improve the scores."
# Repeat steps 3-4 until pass threshold met
随模型能力的演进
编排应随模型改进而简化。遵循 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 | 测试 + 代码检查 + 构建 | 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 的并行工作
