写在前面一个 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 和 L2L1 单 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 判断，提前纳入可能难的场景反模式数据