写在前面
一个 AI Skill 的质量好不好，怎么知道？
最常见的回答是："用着感觉还行"，或者"跑了几个测试 case 看起来不错"。
这两个答案的共同问题是：没有可比较的数字，没有固定基准，就没有退化检测能力。你不知道今天的版本比上个月好了还是差了，也不知道一次看起来"微小的 Prompt 改进"是否悄悄降低了某类边界场景的性能。
这篇文章是对 AI Skill 与 Workflow 评测体系的完整概念设计，从数据集构建到指标体系，从评分机制到发布门禁，试图建立一套让 Skill 质量有据可查、可追溯、可持续改进的方法论。
五个设计原则
原则一：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 分析。
测试集规模的统计学依据
样本量不足时结果偏差大、不同批次间波动明显。标准公式：
css
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 版本迭代流程
css
开发者修改 Skill → 提交到 staging 分支 → 触发评测（在测试集上跑）
↓
分数 > 当前 main 版本（棘轮原则，平局不接受）
↓ 是 ↓ 否
合入 main 拒绝发布，附评测报告Canary 发布机制
对于影响范围广的 Skill 改动，在通过测试集评测后，还应进行线上 Canary 发布：
- 新版本先以 20% 流量运行（staging 分支）
- 收集真实流量上的用户体验分
- 收集到双侧各 N 条有效样本后做均值比较
- 新版本均分 ≥ 旧版本 → 全量切换；否则回滚
Canary 的关键：用户体验分必须来自真实交互，而不是离线测试集。测试集衡量准确率，线上 Canary 衡量"对真实用户是否有帮助"------这两者衡量的是不同的东西。
发布门禁的量化标准（初期建议）
| 发布类型 | 最低要求 |
|---|---|
| 修复已知失败案例 | 本次修复的测试案例全部通过 + 回归案例不退化 |
| 扩展新能力 | 新场景覆盖率 ≥ 80% + 现有测试集不退化 |
| 路由逻辑变更 | 路由准确率 ≥ 当前版本 + Canary 通过 |
| 完整 Skill 重写 | 所有类别分数 ≥ 当前版本均值 |
架构：三层分离
参考 Benchmark-Evaluator 分离的设计思路：
markdown
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% 自动化起步，逐步向语义层推进
这套体系的建立不是一蹴而就的，但每一步都能带来实质改善。从"感觉还行"到"有据可查"的距离，比大多数人想象的要近。
欢迎访问 PrimeSkills ------ 一个精心策划的 AI Agent 与技能市场，所有内容均经过真实企业级工作流验证。没有噱头，只有真正有效的东西。
更多实用知识和有趣产品，欢迎访问我的个人主页