JosephCooperHC Harness Design：生成-评估迭代工作流
受 Anthropic 工程博客 "Harness design for long-running application development" 启发， 本 skill 将 GAN 风格的 Generator + Evaluator 对抗架构落地为可操作的工作流。
核心理念：生成与评估分离，通过迭代反馈循环持续提升输出质量。
运行原则
优先用第一性原理判断是否真的需要 Harness，而不是机械地起多 agent：
- 如果任务简单、成功标准单一、一次生成就能验证，直接完成任务，不进入本流程。
- 如果任务复杂但用户尚未明确要求 subagent，先完成 Phase 1 和 Phase 2，再征求一次确认是否切换到 Harness 模式。
- 只有当用户明确要求 harness / 多 agent / subagent / Generator+Evaluator / 并行评审，或已经同意切换到 Harness 模式时，才进入完整的 subagent 迭代。
- 如果上层指令、权限或环境限制不允许创建 subagent，则降级为"手动 Harness"：
- 先产出评估标准和 Evaluator 提示词。
- 再由主线程显式分角色串行执行 Generator / Evaluator。
- 不要把串行角色扮演描述成真实多 agent 运行。
工作流总览
Phase 1: 理解任务 → Phase 2: 定义评估标准 → Phase 3: 自动迭代
┌─────────────┐
│ Planner │ ← 你（用户）+ 本 skill
│ 定义标准 │
└──────┬──────┘
│ 评估标准 + 任务描述
┌──────▼──────┐
┌───►│ Generator │
│ │ 生成产出 │
│ └──────┬──────┘
│ │ 产出物
│ ┌──────▼──────┐
│ │ Evaluator │
│ │ 独立评分 │
│ └──────┬──────┘
│ │
│ 达标？─┤
│ 否 ↙ └─► 是 → 交付
└────┘
Phase 1：理解任务（2 分钟）
目标：搞清楚要生成什么、给谁用、什么算好。
需要收集的信息
通过对话快速确认以下 4 点：
- 任务类型：前端页面 / 文档 / 代码 / 方案 / 其他
- 产出物：具体要交付什么（一个页面？一份文档？一段代码？）
- 目标用户：谁会使用/阅读这个产出物
- 质量期望：用户心中"好"的标准是什么（哪怕模糊的也行）
如果用户说不清楚质量标准，没关系——Phase 2 会引导他们定义。
确定 Generator 的领域 skill
根据任务类型，先看当前会话里实际可用的 skill，再决定是否给 Generator 或 Evaluator 加载。不要引用不存在的 skill 名称。
| 任务类型 | 优先 skill | 使用规则 |
|---|---|---|
| 前端页面设计（Figma 落地） | figma-implement-design |
仅当用户提供 Figma URL/node 或要求 1:1 对齐设计稿 |
| 前端页面设计（一般实现） | 无专门 skill | 直接按项目技术栈和现有前端规范实现 |
| 技术文档 / 方案设计 | tech-doc-writer |
适合 design doc、技术方案、使用指南 |
| 浏览器交互评测 | playwright |
主要给 Evaluator 用于访问页面、截图、核对状态 |
| 文档 / PDF 交付 | doc / pdf |
仅在产出格式或视觉校验需要时加载 |
| 代码实现 | 选择当前确实存在的语言/框架 skill，否则无 skill | 不要臆造 skill 名 |
| 其他 | 与用户讨论确定 | 先追求可执行，再追求花哨编排 |
如果某个预想中的领域 skill 当前不存在，直接不用，不要为了"完整性"硬塞一个虚构依赖。
确认后进入 Phase 2。
Phase 2：定义评估标准（5 分钟）
这是本 skill 的核心价值——帮用户把模糊的"好不好"变成可打分的具体维度。
Step 2.1：选择评估维度
根据任务类型，向用户推荐 3-5 个评估维度。每个维度需要：
- 维度名称
- 权重（百分比，所有维度加起来 = 100%）
- 评分标准（1-10 分，至少定义 9-10、7-8、5-6、1-4 四档）
- 具体检查项（2-4 个可操作的检查点）
维度推荐模板
以下是按任务类型预设的维度模板，作为对话起点（不是死板模板，根据用户反馈调整）：
前端页面设计：
- D1 任务效率（30%）— 用户能否快速完成核心任务
- D2 信息层级（25%）— 信息优先级是否通过视觉正确传达
- D3 视觉一致性（20%）— 颜色/字体/间距是否协调统一
- D4 交互反馈（15%）— 操作是否有及时明确的反馈
- D5 边界状态（10%）— 空状态/加载态/错误态是否妥善处理
技术文档：
- D1 准确性（35%）— 技术细节是否正确、无歧义
- D2 完整性（25%）— 关键信息是否都覆盖到
- D3 可读性（20%）— 结构是否清晰、是否易于快速定位
- D4 可操作性（20%）— 读者能否按文档实际执行
代码生成：
- D1 功能正确性（35%）— 是否满足需求、通过测试
- D2 代码质量（25%）— 可读性、命名、结构
- D3 健壮性（20%）— 错误处理、边界情况
- D4 性能（20%）— 是否有明显性能问题
Step 2.2：与用户确认并调整
将推荐的维度以表格形式展示给用户，问：
- "这些维度覆盖了你关心的方面吗？"
- "权重分配合理吗？哪个维度对你更重要？"
- "有没有需要增加或去掉的维度？"
根据用户反馈调整，直到用户确认。
Step 2.3：设定通过阈值
与用户确认：
- 通过分数：加权总分 ≥ X 分为通过（建议默认 7.5）
- 单项最低分：任何单项 < Y 分则不通过（建议默认 5.0）
- 最大迭代轮数：防止无限循环（建议默认 3 轮）
确认后进入 Phase 3。
Phase 3：自动迭代
Step 3.1：生成 Evaluator 提示词
基于 Phase 2 确认的评估标准，自动生成一段完整的 Evaluator 提示词。 提示词结构必须包含以下部分：
# [任务类型] Evaluator
你是一个独立的[任务类型]评估器。你的职责是按标准打分并给出改进意见，不要修改产出物本身。
你与 Generator 是对抗关系：严格按标准评分，不要因为"已经不错了"就放水。
## 评估流程
1. [根据任务类型定义检查方式——如前端需要实际访问页面，文档需要通读全文]
2. 按以下 N 个维度逐项评分（1-10 分）
3. 给出总评和具体改进清单
4. 判定：通过 / 需迭代
## 评分维度
[Phase 2 确认的所有维度，每个包含：分档标准 + 检查项]
## 评估输出格式
[标准化的评估报告模板，包含：评分表、判定结果、具体问题清单]
## 规则
- 只负责评估，不要自己改产出物
- 每个问题必须给出具体的、可执行的改进建议
- 如果同一问题连续 2 轮未改进，升级为 P0
- 评分要稳定：相同质量在不同轮次应得到相近分数
将生成的 Evaluator 提示词展示给用户确认。
Step 3.2：启动 Generator
创建 Generator subagent，提供：
- 用户的原始任务描述
- 要使用的领域 skill（Phase 1 确定的）
- 输出路径
- 与主 agent 相同的模型和
reasoning_effort；除非子任务非常小、低风险、非关键路径，否则不要静默降级 - 明确要求它只负责生成，不要自评
Step 3.3：启动 Evaluator
Generator 完成后，创建 Evaluator subagent，提供：
- Step 3.1 生成的 Evaluator 提示词
- Generator 的产出物路径
- 评估标准和通过阈值
- 与主 agent 相同的模型和
reasoning_effort - 可实际访问的评测入口：页面 URL、启动命令、文件路径、仓库路径或截图产物
Step 3.4：迭代循环
WHILE 轮数 < 最大迭代轮数:
1. Evaluator 评分
2. IF 总分 ≥ 通过阈值 AND 所有单项 ≥ 最低分:
→ 通过，输出最终结果
→ BREAK
3. ELSE:
→ 提取 Evaluator 的改进建议
→ 创建新的 Generator subagent（上下文重置！）
→ 将改进建议 + 原始任务描述作为输入
→ 回到 Step 1
关键：每轮 Generator 都用新的 subagent（上下文重置），只传入：
- 原始任务描述
- Evaluator 的改进建议
- 上一轮产出物的路径（供参考，不是让它在上面改）
这样 Generator 在干净的上下文中工作，避免"上下文焦虑"导致的保守改动。
每轮都保存最少三类产物，保证有证据链可追溯：
- Generator 产物
- Evaluator 报告
- 提炼后的改进清单
Step 3.5：输出最终报告
迭代结束后，向用户汇报：
## Harness 迭代报告
**任务**：[任务描述]
**迭代轮数**：N
**最终评分**：X.X/10
### 评分明细
| 维度 | 权重 | 第1轮 | 第2轮 | ... | 最终 |
|------|------|-------|-------|-----|------|
### 关键改进记录
- 第1→2轮：[主要改了什么]
- 第2→3轮：[主要改了什么]
### 产出物位置
[最终产出物的路径]
注意事项
上下文重置的重要性
每轮 Generator 必须是全新的 subagent。不要在同一个 agent 里说"请根据反馈修改"—— 这会让模型在越来越长的上下文中变得保守。干净的上下文 + 明确的改进方向 = 更好的产出。
评估与生成必须分离
不要让 Generator 自己评估自己的产出。即使是同一个模型，作为 Evaluator 时 它只拿到评估标准和产出物，不知道生成过程中的"苦衷"，才能客观评分。
子 agent 模型选择
- Generator 和 Evaluator 默认跟随主 agent 的模型与
reasoning_effort - 只有在用户明确允许，且任务很小、风险低、不在关键路径上时，才降级到更轻模型
需要真实可评测的对象
前端、文档、代码这三类任务都需要真实产物才能评估。进入 Phase 3 前，先确认至少具备以下之一：
- 可打开的页面 URL 或启动命令
- 可读取的文件路径
- 可运行的代码仓库或测试命令
如果这些都没有，就先补齐评测对象，再启动 Evaluator。
何时不需要 Harness
- 任务简单明确，一次就能做好 → 直接做，不需要本流程
- 用户明确说"不用这么复杂" → 尊重用户，可以只生成 Evaluator 提示词供手动使用
- 评估标准完全主观且用户无法量化 → 简化为用户手动审查，不做自动评分