用途
eval-design 是一个评估数据集设计技能，旨在帮助用户构建能够真正衡量应用关键表现的测试集。它适用于以下场景：
- 用户已有智能体轨迹或生产日志，希望基于这些数据构建评估集；
- 用户已有评估原则，但需要合理分层的测试数据；
- 用户希望生成对抗样本来对系统进行压力测试；
- 用户需要进行覆盖率分析，确认是否测试了所有重要方面；
- 用户需要为人工标注者提供标注指南。
主要能力
1. 提取评估维度
- 从轨迹中提取：读取智能体轨迹，聚类失败类型（工具调用失败、幻觉模式、离题响应、格式违规、超时/性能问题），将每个失败聚类映射为评估维度，并按频率排序确定优先级。
- 从规格中提取：阅读产品文档/设计文档，提取硬约束（系统绝不能做的事）、质量期望（每个场景下“好”的标准）以及边界情况。
- 从访谈中提取：当用户既无轨迹也无规格时，通过一次性提问获取信息，包括：谁使用系统、他们要求系统做什么、3个完美响应示例、3个不可接受响应示例、最担心的失败、硬性红线。
输出为测试计划，写入项目的 eval-design.md 文件，包含场景、风险等级、维度列表（含ID、标准、优先级、来源）。
2. 设计分层采样
- 难度分层：将样本按难度分为三层——简单（50-60%）、边界（25-35%）、对抗（10-15%），并说明每层的作用。
- 样本量建议：每个分层至少10个样本（二项置信区间约±15%），生产环境建议30+（约±9%）。每个维度最低30个样本（10×3层），生产目标90个（30×3层）。
- 数据设计四象限：每个评估维度覆盖四种案例类型——正常路径、边界、对抗、负例（超出系统领域）。
3. 生成测试数据
- 合成数据生成：使用3-5种不同的提示模板生成多样化的合成输入，模板多样性比输出数量更重要（例如5个提示×10个输出优于1个提示×50个输出）。
- 关键规则：只生成输入，绝不生成标签。标签必须来自真实系统输出加人工判断（或确定性规则），避免LLM同时生成输入和标签导致自洽循环和虚高准确率。
- 对抗样本：为每个维度生成三类对抗输入——近失（刚好在通过/失败边界错误一侧）、混淆因素（两个维度冲突）、分布偏移（训练中罕见的领域或格式）。
- 标注指南：如需人工标注，提供模板，包含标准、通过/失败条件、示例和边界情况处理规则。
4. 输出 OpenJudge 数据集
- 将数据集格式化为可直接用于 OpenJudge GradingRunner 的标准格式，字段包括：
query（必需）、response（必需）、reference_response（可选）、context（可选）、metadata（可选，用于分层、过滤和分析）。
5. 覆盖率检查
- 运行捆绑的脚本
scripts/coverage_check.py（仅标准库，不依赖 OpenJudge）验证覆盖率：python scripts/coverage_check.py --dataset eval-data/dataset.jsonl - 报告每个维度和每个（维度×分层）的计数，标记薄弱单元（每维度<5，每单元<10），检查对抗样本占比（≥10%），并返回结论（adequate / thin_coverage；adequate时退出码0）。可使用
--self-test验证脚本。
使用方式
该技能按照清单顺序执行任务：
- 提取评估维度；
- 设计分层采样（60/30/10分割，含难度分层）；
- 生成测试数据（合成输入+对抗样本）；
- 输出 OpenJudge 数据集；
- 运行覆盖率检查脚本。
执行后输出以下文件：
eval-design.md：包含维度、分层设计和数据集摘要；eval-data/dataset.jsonl：完整的评估数据集（OpenJudge格式）；eval-data/adversarial-inputs.jsonl：对抗输入（无标签，供人工/系统标注）；eval-data/labeling-guide.md：人工标注指南（如需要）。
适用场景
- 为聊天机器人、客服系统、智能体应用等设计评估数据集；
- 需要从生产数据中识别失败模式并转化为评估维度；
- 需要构建分层测试集以检测边界退化；
- 需要生成对抗样本来测试系统鲁棒性；
- 需要为人工标注提供标准化指南。
限制
- 该技能本身不生成标签，标签需依赖真实系统输出和人工判断；
- 覆盖率检查脚本仅检查数据集结构，不评估模型性能；
- 样本量建议基于统计规则，实际需求可能因场景而异；
- 对抗样本比例最低为10%，但具体比例需根据风险调整。
常见错误
- 跳过分层：平坦随机样本会被简单案例主导，边界退化无法检测；
- 用同一个LLM生成输入和标签：导致自洽循环，评判者和测试数据生成器必须独立；
- 对抗样本太少：10%是最低要求，这些案例才能区分鲁棒系统和脆弱系统；
- 不做覆盖率分析：维度少于5个测试案例时只是在猜测；
- 所有合成数据使用同一提示模板：模板多样性直接决定测试多样性，至少使用3种不同生成提示。