为什么你的 AI Skill 上线即翻车？一文搞懂 AI Skill 测评的底层逻辑
系列：AI Skill 测评体系从零到一（一）
难度：入门
适合读者：AI 产品经理、Prompt 工程师、对 LLM 应用质量感兴趣的开发者
📌 一句话摘要：花两周写好的 AI Skill 上线就出 bug？本文拆解 AI Skill 测评的 3 个核心设计，帮你在发布前发现负向增益、随机失效、自判卷偏差这三类隐藏问题。
🏷️ 推荐标签：AI Skill 测评 LLM 应用质量 Prompt 工程师 AI Agent 测试
你有没有遇到过这种情况
你花了两周时间写了一个 AI 报销助手，规则写得很详细：
- 日常报销走这个流程
- 差旅报销走那个流程
- 发票识别失败要降级处理
- 金额超标要自动扣减
上线第一天，用户反馈：「我说帮我报销，它问我要发票；我发了发票，它说不支持这种格式；我换了格式，它直接帮我提交了——但我只是想保存草稿！」
更隐蔽的情况是：换一位同事用同样的发票重新触发，这次它又正常工作了。
问题出在哪？规则写了，但没有系统地验证规则是否真的被执行了，也没有验证执行结果是否稳定。这就是 AI Skill 测评要解决的问题。
什么是 AI Skill
AI Skill 是一种以 Markdown 编写的「给模型看的说明书」，是 LLM 应用质量的核心载体。 它告诉大模型在特定场景下该怎么做，模型读懂了才能按规则执行；模型没读懂，规则就形同虚设。
用户说「帮我报销」
↓
模型读取 SKILL.md（报销规则文档）
↓
按规则调用 MCP 接口（查询报销人信息、上传发票、保存草稿...）
↓
输出报销草稿给用户
MCP（Model Context Protocol）：Anthropic 主导推动、目前已有广泛开源生态支持的行业开放协议，用于让 AI 模型安全、标准化地调用外部工具和接口。在上面的例子中，报销系统的所有接口都通过 MCP 暴露给模型，模型只需按规则调用，不直接发 HTTP 请求。更多信息见 MCP 官方文档。
Skill 的核心是 SKILL.md，里面包含：
- 触发条件：什么情况下使用这个 Skill（如：用户说了「报销」「发票」等关键词）
- 业务规则：具体怎么做，有哪些约束（如：草稿状态固定为
docStatus=10，传其他值会导致接口报错） - 接口调用：调用哪些工具，参数怎么传
- 异常处理：出错了怎么办
Skill 不是代码，是「给模型看的说明书」。模型读懂了才能按规则执行；模型没读懂，规则就形同虚设。
为什么 Skill 需要专门的测评
AI Skill 需要专门测评，是因为它有三个传统软件测试根本覆盖不了的结构性问题：自判卷偏差、随机性、负向增益。 传统软件测试的逻辑是：给定输入 → 执行代码 → 验证输出。代码是确定性的，同样的输入永远产生同样的输出。但 AI Skill 不一样。
问题一：自判卷偏差
传统测试：代码执行 → 断言框架验证（执行者和验证者完全分离）
AI Skill 测试（如果不设计好）：模型执行 Skill → 同一个模型判断结果是否正确
这就像让学生自己批改自己的试卷。模型倾向于认为自己做对了，即使实际上规则没有被正确执行。在实际测评实践中这个问题很明显：同一个用例，模型执行完后自己评审，证据（evidence）字段经常是空的，或者只写「根据整体输出判断通过」——这不是评审，是走形式。
问题二：随机性
同一个 prompt，今天运行通过，明天运行失败。这不是 bug，是大模型的本质特性——采样温度（temperature）大于 0，导致每次生成略有差异。
单次测试的结论不可靠。需要多次运行，用统计方法描述 Skill 的真实表现。例如：「通过率 87% ± 5%」（正负号表示误差范围）比「通过了」提供的信息量大得多。具体的稳定性判断标准将在第二篇指标体系中详细说明。
问题三：负向增益
这是最隐蔽的问题。
【数据来源说明】 以下数据来自本文作者团队针对企业级 AI Skill 落地场景的自研测试研究（以下简称 SkillsBench），共选取 86 个 LLM 应用任务（覆盖报销、审批、文档处理等场景），有效计算增益对比 84 个，研究结果仅作技术探讨，不代表行业统一结论。
在该研究中：84 个有效任务里，16 个（约 19%）加了 Skill 反而比没加更差。
原因可能是：
- Skill 的规则过于死板，限制了模型本来能做好的灵活性
- Skill 的指令和模型的默认行为冲突，模型「不知道该听谁的」
- Skill 文档太长太复杂，模型「选择性忽略」了部分规则
如果你只测「加了 Skill 之后能不能跑通」，永远发现不了这个问题。你需要同时测「没有 Skill 时模型表现如何」，然后对比增益差值（Δ，读作 delta）= 有 Skill 时通过率 − 无 Skill 时通过率。Δ 为负就是发布红线，说明这个 Skill 在某些场景帮了倒忙。
AI Skill 测评的三个核心设计
针对以上三个问题，AI Skill 测评各有一个对应的工程设计：执行者与评审者分离、多次运行取均值、有 Skill vs 无 Skill 对比。 这三个设计是整个测评体系的骨架，缺一不可。
1. 执行者和评审者分离（解决自判卷偏差）
执行 Skill 的 Agent 和评审结果的 Agent 完全独立，运行在不同的上下文中。评审 Agent 必须引用原文证据，不能凭感觉判断。
2. 多次运行取均值（解决随机性）
标准模式（standard）下每个用例运行 3 次，计算通过率的均值和标准差（standard deviation，衡量多次结果之间的波动幅度）。标准差 > 0.3 说明结果高度不稳定，通常意味着 prompt 存在歧义或 Skill 规则有冲突。
3. 有 Skill vs 无 Skill 对比（解决负向增益）
每个用例同时跑两个版本：
with_skill：加载 Skill 指令，模型按规则执行without_skill：不加载任何 Skill，纯模型通用能力
计算增益 Δ = with_skill 通过率 − without_skill 通过率。Δ < 0 立即触发预警，必须查明根因再决定是否上线。
一个真实的踩坑案例
报销助手落地过程中最高频的坑，是模型跳过「保存草稿」步骤直接输出「报销完成」——而这个问题用传统测试根本发现不了。
原因：SKILL.md 里写的是「最终调用 saveExpenseDoc 保存草稿」，但没有明确约束「docStatus 参数必须固定为 "10"」。模型自行推断参数值，有时传了 "20"（提交审批），直接提交了用户根本没有核对过的单据。
修复方式：在规则里补一句「docStatus 固定为 "10"，对应草稿状态，传其他值会导致单据直接进入审批流，不可撤回」——加上「为什么」之后，模型正确执行概率显著提升。
这个坑用传统测试发现不了（因为接口本身没有报错），只有设计针对「docStatus 参数值校验」的专项断言才能检测到。
一个完整的测评流程长什么样
一套完整的 AI Skill 测评流程共分七个阶段，其中六个阶段由 AI 自动完成，人工只需在信息收集、用例确认、发布决策三个关键节点介入。 下面是 SkillSentry 驱动的完整流程。
【工具说明】 SkillSentry 是本文作者自研的 AI Skill 测评工具（非商用产品，仅作技术探讨），本身也是一个运行在 OpenCode 中的 AI Skill。OpenCode 是一款开源的 AI 编程工具（GitHub：OpenCode），与普通聊天 AI 的区别是它能调用工具、读写文件、执行多步骤任务，类似于 Cursor 或 Claude Code 的定位。
flowchart TD
A["阶段零：AI 读取被测 Skill，提炼规则清单 + 检测 Skill 类型 ← AI 自动"] --> B
B["阶段一：触发率预评估（AI 模拟）+ 收集必填信息 ← AI 自动估算，人工提供账号/数据"] --> C
C["阶段二：风险定级 + 选择测评模式 ← AI 定级，人工选模式"] --> D
D["阶段三：AI 设计测试用例，展示清单 ← 人工确认后继续"] --> E
E["阶段四：分批执行（有 Skill / 无 Skill 并行，自动选执行模式）← AI 自动执行"] --> F
F["阶段五：AI 汇总评分，计算各项指标（含触发率估算、效率指标）← AI 自动"] --> G
G["阶段六：生成 HTML 报告，给出发布决策 ← AI 产出，人工决策"]
style B fill:#e8f4ff,stroke:#4361ee
style D fill:#fff3cd,stroke:#f0a500
style G fill:#fff3cd,stroke:#f0a500
橙色节点 = 需要人工介入的环节。
小结
| 维度 | 传统软件测试 | AI Skill 测评 |
|---|---|---|
| 输出特性 | 确定性，同输入同输出 | 概率性，需多次运行取均值 |
| 执行方式 | 代码执行 | 模型推理，规则可能被忽略 |
| 结果验证 | 断言框架直接比较 | 需独立 Agent 评审，防自判卷 |
| 测评目标 | 能不能跑通 | 还要测「加了有没有帮助」（Δ） |
下一篇，我们来看 AI Skill 测评的指标体系——通过率、增益 Δ、指令遵循率这些数字到底代表什么，该怎么记忆。
FAQ：关于 AI Skill 测评的常见问题
Q：AI Skill 测评和传统软件测试有什么区别？
传统软件测试针对的是确定性代码，同一个输入永远产生同一个输出，断言框架可以直接比较结果。AI Skill 测评面对的是概率性推理——大模型每次运行结果都可能略有不同，而且执行者（模型）和验证者如果是同一个模型，就会出现「自己批改自己试卷」的偏差。核心区别在于：AI Skill 测评必须同时解决随机性、自判卷偏差和负向增益这三个传统测试框架完全没有设计应对的问题。
Q：什么是负向增益，为什么比失败更危险？
负向增益指的是增益 Δ < 0，即加了 Skill 之后模型的表现反而比不加时更差。它比直接失败更危险，原因是它极度隐蔽——你只测「有 Skill 时能不能跑通」，结果可能是通过的，但你不知道没有 Skill 时模型本来表现得更好。在实际研究数据中，约 19% 的任务存在负向增益，常见原因是规则过于死板、指令与模型默认行为冲突。负向增益是发布红线，必须查明根因才能上线。
Q：如何判断一个 AI Skill 是否可以上线？
判断 Skill 能否上线，需要同时满足三条标准：一是通过率达到该风险等级的准入阈值（S 级关键场景要求 ≥ 95%）；二是增益 Δ > 0，确认 Skill 有正向价值而非帮倒忙；三是 IFR（指令遵循率）达标，S 级要求 100%。任何一条不满足都不应发布，其中 Δ < 0 是硬性红线，不接受「先上线再观察」。
Q：AI Skill 测评需要哪些前提条件？
在正式开跑测评之前，需要准备三类资产：测试账号（拥有对应权限，能触发 Skill 的目标流程）、测试数据（对应场景的发票、单据等，类型必须和测试用例匹配），以及对被测 Skill 的规则清单（测评工具可以自动从 SKILL.md 提炼，但人工确认一遍更准确）。如果测试资产不匹配，用例会进入 INCONCLUSIVE（无法验证）状态，不代表失败，但必须补充资产后重跑，不能忽略。
