如何让AI Skill质量有据可查：Benchmark驱动的评测体系设计
如何客观衡量AI技能质量？本文设计了一套由基准测试驱动的评测体系，涵盖数据集构建、指标体系、评分机制和发布门禁，让质量评估有据可查、可追溯且可持续改进。
人们通常用“感觉还行”或“测试几个案例看起来不错”来回应。
这些回答的共同缺陷在于缺乏可比数字和固定基准，导致无法检测性能退化。你无法知晓当前版本相较于上月是进步还是退步，也无法确认一次看似微小的Prompt调整是否暗中削弱了某些边界场景的表现。
本文旨在系统化设计AI技能与工作流的评测体系，覆盖数据集构建、指标体系、评分机制及发布门禁，目标是构建一套让技能质量有据可查、可追溯、且可持续优化的方法论。
五个设计原则
原则一：Benchmark 驱动
每次评估必须产出可比数值。评估并非简单运行查看结果，而是基于固定数据集执行，产生与历史版本可对比的分数。若无固定基准，退化检测能力无从谈起。
原则二：评测对象与评测执行严格分离
执行Skill或Workflow的Agent实例，与对执行结果评分的Agent实例，必须是完全独立的两个session。来自SkillLens研究的核心发现：LLM自评准确率仅46.4%，等同于随机猜测。同一实例既执行又评分，分数无效。
原则三：棘轮原则
新版本Skill或Workflow上线的前提是测试集分数严格优于当前版本，平局不接受。历史最优分数作为保护线，任何导致回退的改动均不允许发布。
原则四：分层评测
Skill评测与Workflow评测分层独立进行，不互相混淆。单个Skill的质量问题不能通过工作流层面表现不错来掩盖；工作流的端到端质量也不等于各个Skill分数之和。
原则五：自动化替代人工是设计目标，不是未来规划
人工评分是起点，不是终态。框架设计从一开始就要为自动化留出接口，即使当前某个评估维度仍需人工，其评分结果也要成为训练未来自动评分器的标注数据。
评测对象分层：L1 和 L2
L1 单 Skill 评测单个 Skill（含路由类 Skill）在标准输入上的输出质量
L2 工作流 评测多个 Skill 串联的执行链路
路由类Skill，即决定调用哪个下游Skill的Skill，作为L1的一种类型参与评测。路由本质上也是一个Skill，只是其输出是调用哪个下游Skill而非文本产出物。
工作流按链路长度分为两个子级，共用同一套指标框架：
- L2a 子工作流：完成单一业务目标的Skill串联，例如Bug分析工作流：路由到专家Skill分析再到生成报告。
- L2b 端到端工作流：从任务输入到最终交付物的完整链路，例如Bug修复：Bug分析到代码修改再到PR提交。
各层独立评测，但有数据传递关系：L1路由Skill的错误会导致L2分析准确率计为0，L2a的产出质量影响L2b的最终评分。
测试数据集设计
初始测试集：只有两类，其余随时间填充
Skill上线前的初始测试集只包含典型正例和反模式数据。失败案例和回归案例初始为空，随评测迭代和生产运行逐步填充。
| 类型 | 初始状态 | 说明 |
|---|---|---|
| 典型正例 | 主体，按维度覆盖采样 | 代表Skill预期处理的主流输入 |
| 预判边界案例 | 少量，人工设计 | 根据Skill Owner判断，提前纳入可能难的场景 |
| 反模式数据 | 少量，人工设计 | 不该由此Skill处理的输入，验证不被误触发 |
| 失败案例 | 初始为空 | 评测中发现的失败模式，提炼后加入 |
| 回归案例 | 初始为空 | 已修复Bug对应的输入，防止后续版本重现 |
如何选测试数据
核心原则是覆盖输入空间的多样性，而非追求数量。步骤：
- 梳理该Skill输入的主要变化维度，包括领域、复杂度、完整性、边界条件等。
- 按维度矩阵从历史真实数据中采样，确保每个维度的主要取值都有覆盖。
- 主动设计预判边界案例，将Skill Owner认为可能难的场景提前纳入，不等失败后再补。
- 加入反模式，即不该由此Skill处理的典型输入。
靠随机抽取的风险在于容易集中在好抽的典型case，边界场景和少数域长期缺失，导致评测只能检出浅层问题。
以Bug分析Skill为例，输入变化维度可能是：
| 变化维度 | 主要取值 |
|---|---|
| 技术领域 | Android / QNX / MCU |
| Bug 严重程度 | Crash / 功能异常 / 性能问题 |
| 日志完整性 | 完整日志 / 缺失关键段 / 无日志 |
| 根因深度 | 表层现象 / 跨模块 / 硬件边界 |
按此矩阵采样，每格至少有1条，优先域如Android Crash可多取。反模式包括功能需求单、操作咨询、重复提交的单，这些不应触发Bug分析。
测试集规模的统计学依据
样本量不足时结果偏差大，不同批次间波动明显。标准公式：
n = Z² × p × (1−p) / E²
- n：所需最小样本量
- Z：置信水平对应的Z值，95%置信水平取1.96
- p：预期通过率，未知时取0.5，所需样本量最大
- E：可接受的误差范围，±10%则E = 0.10
实用速查表（95%置信水平）：
| 允许误差 | 所需样本量 | 适用场景参考 |
|---|---|---|
| ±15% | 43 条 | 快速验证、初期探索 |
| ±10% | 97 条 | P0/P1 Skill 常规评测 |
| ±7% | 196 条 | 需精确对比的 A/B 测试 |
| ±5% | 385 条 | 高置信度发布决策 |
分层规模建议（初期）：
| 优先级 | 最小规模建议 | 误差范围 |
|---|---|---|
| P0（关键 Skill 及核心工作流） | ≥100 条 | ±10% |
| P1（重要 Skill） | ≥45 条 | ±15% |
| P2（其他） | 通过 L2 覆盖，无独立测试集 | — |
L1 隔离原则
L1评测的核心要求：测试输入必须直接提供给被测Skill，不得通过上游Skill的实际执行来触发。
举例：评测从日志中提取关键时间点这个Skill，L1测试集应直接提供日志内容作为输入，而不是让系统先从工单系统获取日志再触发该Skill。前置Skill一旦变化就会污染当前Skill的评测结果，L1的责任边界必须清晰。
指标体系
L1 单 Skill 指标
分类轴是输出性质而非业务领域，评测方法由输出是什么决定：
| Skill 类型 | 典型例子 | 主要质量指标 | 评分方式 |
|---|---|---|---|
| 路由决策类 | Bug 分类路由 | 路由准确率、误路由分布 | 完全自动 |
| 数据获取类 | 获取工单信息、获取代码文件 | 字段完整率、检索成功率 | 完全自动 |
| 信息提取/转换类 | 提取日志关键时间点 | 提取召回率、字段准确率 | 自动为主 |
| 分析推理类 | Bug 根因分析、代码 review 评估 | 结论准确率（0-5 分制）、推理链质量 | 半自动 |
| 内容生成类 | 代码生成、文档生成 | 编译通过率 / 逻辑正确性 | 分级自动 |
L2 工作流指标
| 指标 | 说明 | 评分方式 |
|---|---|---|
| 步骤完成率 | 各 Phase 成功完成的比例，用于定位链路瓶颈 | 自动 |
| 端到端准确率 | 最终产出的综合质量 | 分析类半自动；代码类分级自动 |
| 自主完成率 | 无需人工干预、全程自主完成任务的比例 | 自动 |
| 辅助完成率（HITL） | 经人工介入辅助后最终完成任务的比例 | 人工记录 |
| Token 消耗 | 全链路累计 Token（输入 + 输出） | 自动 |
| 执行时长 | 从任务触发到产出交付的端到端时间 | 自动 |
自主完成率与辅助完成率的关系：前者衡量AI能独立做到什么程度，后者衡量配合人工后能达到什么程度。两者差距反映HITL介入带来的增量价值，也是判断该工作流是否适合进一步自动化的重要依据。
0-5 分制
0-5分共6个等级，以Bug分析场景为例：
| 分值 | 通用定义 | Bug 分析场景 |
|---|---|---|
| 5 | 完全正确，过程和证据链无误 | 根因完全正确，分析过程清晰，所有证据链正确 |
| 4 | 结论正确，细节有误 | 根因正确，部分证据链细节错误 |
| 3 | 方向基本正确，但结论不完整 | 根因不完全正确，但分析思路基本正确 |
| 2 | 结论有偏差，但有一定启示价值 | 分析思路偏差，但对进一步分析有启示 |
| 1 | 有输出，但帮助极为有限 | 有分析输出，但价值极低，接近无用 |
| 0 | 完全没有帮助 | 分析毫无方向，无任何参考价值 |
0分代表完全没有帮助，不区分有害与无用，因为评分时难以准确界定，且两者对评测结论的影响是一样的。
评分机制：从人工到自动化
结构化人工评分（当前阶段）
人工评分不可避免，但可以被约束和标准化：
- 评分前公示标准答案：评分者对照预先确定的标准答案打分，减少主观性。
- 独立双评：同一结果由两个独立评分者打分，不一致时取低分并标记为争议案例。
- 评分者不参与执行：Skill Owner负责改进Skill，评分者不知道正在测试的是哪个版本。
自动化路径
阶段一：路由层完全自动化
路由决策是确定性的，调用了哪个Skill是可观测事实，路由准确率是第一个实现100%自动化的指标。
阶段二：独立 LLM 评分器
对于需要语义理解的评分维度，使用独立LLM实例作为评分器：
- 评分器使用与执行器不同的模型，具有不同的偏见模式。
- 评分器接收标准答案、Agent输出和评分Rubric，不接收任何版本信息。
- 评分器结果需定期与人工标注进行校准，初期至少对20%的样本做人工复核。
阶段三：评分器专化训练
积累足够人工标注数据后，训练针对特定业务场景的评分器。这个阶段的评分器能识别业务特定的正确性标准，而非泛化的语义相似度。
版本管理与发布门禁
Skill 版本迭代流程
开发者修改 Skill → 提交到 staging 分支 → 触发评测（在测试集上跑）
↓
分数 > 当前 main 版本（棘轮原则，平局不接受）
↓ 是 ↓ 否
合入 main 拒绝发布，附评测报告
Canary 发布机制
对于影响范围广的Skill改动，在通过测试集评测后，还应进行线上Canary发布：
- 新版本先以20%流量运行，部署在staging分支。
- 收集真实流量上的用户体验分。
- 收集到双侧各N条有效样本后做均值比较。
- 新版本均分≥旧版本则全量切换，否则回滚。
Canary的关键在于用户体验分必须来自真实交互，而非离线测试集。测试集衡量准确率，线上Canary衡量对真实用户是否有帮助，两者衡量不同的东西。
发布门禁的量化标准（初期建议）
| 发布类型 | 最低要求 |
|---|---|
| 修复已知失败案例 | 本次修复的测试案例全部通过 + 回归案例不退化 |
| 扩展新能力 | 新场景覆盖率 ≥ 80% + 现有测试集不退化 |
| 路由逻辑变更 | 路由准确率 ≥ 当前版本 + Canary 通过 |
| 完整 Skill 重写 | 所有类别分数 ≥ 当前版本均值 |
架构：三层分离
参考Benchmark-Evaluator分离的设计思路：
Benchmark（数据层） 测试数据集 + 标准答案 + 评估函数定义
↓
Evaluator（执行层） 触发工作流执行，收集轨迹和产出物
↓
Scorer（评分层） 独立评分器对产出物评分（与 Evaluator 隔离）
↓
ResultStore（存储层） 原始数据、分数、轨迹全量保留
↓
Dashboard（展示层） 分数趋势、退化告警、对比视图三层之间职责清晰：Benchmark不知道怎么执行，Evaluator不知道怎么评分，Scorer不知道执行细节，这种隔离保证每一层都可以独立迭代。
实施路线图
Phase 1（0-3个月）：结构化
目标：人工评分变得可靠、一致、可追溯
- 固化测试数据集v1.0，完成数据集版本化管理。
- 路由准确率实现100%自动化计算。
- 建立标准化评分Rubric，双评机制上线，计算评分者间一致率。
- 建设ResultStore，所有评测结果结构化存储。
- 评测结果与Skill版本绑定，支持历史对比。
Phase 2（3-6个月）：半自动化
目标：人工评分减少60%，自动化覆盖高确定性维度
- 独立LLM评分器上线，覆盖分析准确率的初步自动评分。
- 评分器校准机制：每批次20%人工复核。
- Canary发布机制上线，针对高频更新的Skill。
- Dashboard上线：分数趋势、Skill间对比、退化告警。
Phase 3（6-12个月）：自动为主
目标：人工评分仅保留校准和异常处理，日常评测完全自动化
- 评分器校准一致率达到80%以上。
- 测试集从历史失败案例中持续自动扩充，非静态。
- 跨Skill级联失败分析：自动检测Skill A退化是否导致下游Skill B失败率上升。
总结
让AI Skill质量有据可查，需要：
- 固定 Benchmark：每次评测都在同一数据集上跑，产出可比较的数字。
- 执行与评分分离：避免LLM自评的46.4%随机猜测问题。
- 棘轮原则：分数只能上升，平局不接受，历史最优分数是保护线。
- 分层评测：L1 Skill和L2 Workflow各自独立，不相互掩盖。
- 渐进自动化：从路由层100%自动化起步，逐步向语义层推进。
这套体系的核心在于固定基准、执行评分分离、棘轮原则、分层评测和渐进自动化，从主观判断转向数据驱动，让AI技能质量持续可察可控。