如何让 AI Skill 质量有据可查？Benchmark 驱动的评测体系设计

写在前面

一个 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 上线前的初始测试集只包含典型正例和反模式数据。失败案例和回归案例初始为空，随评测迭代和生产运行逐步填充。