ai-skill-evolution底层逻辑¶

Ch07.010 ai-skill-evolution底层逻辑¶

📊 Level ⭐⭐ | 19.7KB | entities/ai-skill-evolution底层逻辑.md

01—为什么你的 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 模型安全、标准化地调用外部工具和接口。 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 是本文作者自研的 AI Skill 测评工具（非商用产品，仅作技术探讨），本身也是一个运行在 OpenCode 中的 AI Skill。

阶段零：AI 读取被测 Skill，提炼规则清单 + 检测 Skill 类型 ← AI 自动
阶段一：触发率预评估（AI 模拟）+ 收集必填信息 ← AI 自动估算，人工提供账号/数据
阶段二：风险定级 + 选择测评模式 ← AI 定级，人工选模式
阶段三：AI 设计测试用例，展示清单 ← 人工确认后继续
阶段四：分批执行（有 Skill / 无 Skill 并行，自动选执行模式）← AI 自动执行
阶段五：AI 汇总评分，计算各项指标（含触发率估算、效率指标）← AI 自动
阶段六：生成 HTML 报告，给出发布决策 ← AI 产出，人工决策橙色节点 = 需要人工介入的环节。

深度分析¶

自判卷偏差的深层机制¶

自判卷偏差的本质是评审者与执行者共享同一套推理过程，导致评审时无法真正独立验证。模型在执行 Skill 时已经生成了「这样做是对的」的内部信念，评审时这套信念会自动影响判断结果，形成确认偏误（confirmation bias）。这在心理学和认知科学中被称为「自我服务偏差」——个体倾向于收集支持自己观点的证据，忽略否定证据。在工程层面，这表现为两种具体形态： 1. 证据空洞化：评审 Agent 被要求提供「引用原文的证据」，但因为执行和评审共享上下文，评审时原文已经在上下文中，模型会把「上下文中出现过」误认为「证据充分」。 2. 阈值漂移：模型对自己的容错度比对外部验证者更高。「差不多对了」在执行者眼中可能等于「完全正确」，但外部评审者会要求逐字逐句的精确匹配。解决方案（执行/评审分离）的有效性在于：隔离上下文强制切断共享信念传导路径。评审 Agent 从零开始，只能依赖传入的输出结果和 Skill 原文，无法调用执行过程中的中间推理。

随机性的统计本质¶

大模型的随机性不是「不稳定」，而是服从一定分布的采样过程。temperature > 0 时，每次推理实际上是从模型学习到的条件概率分布中采样。这意味着单次结果只是该分布的一次实现，单次通过不等于「能力到位」，单次失败也不等于「能力缺失」。统计学对这一问题的处理方式是用置信区间替代点估计：

传统报告：「通过」（点估计，非此即彼）
概率性报告：「通过率 87% ± 5%」（区间估计，包含不确定性信息）标准差的阈值设定（> 0.3 为高度不稳定）背后隐含的逻辑是：在 3 次运行的样本量下，标准差 > 0.3 对应的变异系数（CV = 标准差/均值）已经大到说明模型行为在不同采样间存在质的差异，而不是量的波动。这种情况下「均值」本身已经没有意义——你需要先解决稳定性问题。

负向增益的结构性根因¶

负向增益（Δ < 0）之所以比直接失败更难发现，根源在于它违反了一个隐含假设：「加了 Skill」这个动作本身应当至少是中性的，不应当使情况变差。传统测试的逻辑不包含「退化」这一分支，所以当退化发生时，系统没有触发任何预警机制。三个根因的深层分析： 规则过于死板：Skill 试图将一个本来有弹性的任务强制压缩到精确规则中。但大模型的优势恰恰在于灵活性和泛化能力。当 Skill 规则限制了模型的灵活操作空间，同时规则本身又不是完全覆盖所有场景时，模型被「夹在」规则约束和真实需求之间，选择了错误的行为。 指令冲突：LLM 的预训练过程中已经学会了某些任务的最优行为模式。当 Skill 的指令与模型内在偏好（intrinsic preference）冲突时，模型需要在「遵循 Skill 指令」和「遵循内在偏好」之间做出选择。如果 Skill 指令的约束力不够强（比如用词模糊、优先级不明确），模型倾向于选择自己更熟悉的路径。 文档过长：LLM 的注意力机制虽然强大，但存在「远处文档权重稀释」问题。当 Skill 文档超过一定长度，关键规则可能被稀释在大量次要信息中，模型在长程推理中丢失对关键约束的记忆。

Δ 阈值作为硬性红线的合理性¶

「Δ < 0 是硬性红线」这一设计背后的逻辑是：Skill 的价值主张是「提升」而非「维持」。如果一个 Skill 无法让模型在它本来就能处理的任务上表现得更好，那为什么要引入额外的复杂性、运维成本和故障面？一个 Skill 上线意味着：维护成本增加、规则冲突风险增加、模型在某些场景下的行为变得更难预测。如果增益不显著为正（Δ > 0），这些成本完全没有理由被接受。

实践启示¶

1. 设计 Skill 时的「最小规则」原则¶

Skill 规则只写「必须约束」的部分，不写「可以推断」的部分。规则越少，被模型选择性忽略的风险越低。每个规则都应附带「为什么」——不只是描述行为，还要描述原因，这能显著提升模型对约束的遵循率（参考 docStatus 案例）。

2. 测评前置，而不是测评后置¶

很多团队在 Skill 上线之后才做测评，这时已经晚了。正确的做法是：Skill 测评应该在 Skill 第一次被模型执行时就触发，而不是等 Skill 「完成」了再测。测评和开发应当交织进行：写一条规则 → 立即测评 → 验证有效后再写下一条。

3. 关注标准差，不只是均值¶

通过率数字会骗人。87% 通过率 + 0.3 标准差意味着同一个 Skill 在不同运行间的表现可能从 60% 到 100% 不等。在做发布决策时，标准差比均值更重要——一个平均但稳定的 Skill 比一个平均但不稳定的 Skill 更值得上线。

4. Δ 为负时的根因分析流程¶

当 Δ < 0 时，不要急于删除 Skill。按以下顺序排查： 1. 对比 with_skill 和 without_skill 的具体失败模式——是 Skill 让模型在某个子步骤上变得更差，还是整个任务都变差了？ 2. 检查 Skill 规则中是否存在指令冲突（与模型内在偏好冲突的规则） 3. 评估 Skill 规则是否过于死板，限制了模型本来能灵活处理的边界情况 4. 考虑是否为 Skill 增加「例外条款」，让模型在特定条件下绕过 Skill 规则只有在查明根因之后，才能判断是应该修改 Skill 规则、缩减 Skill 覆盖范围，还是直接废弃这个 Skill。

5. 评审 Prompt 必须「强制引用」¶

在设计评审 Agent 的 Prompt 时，必须包含强制引用（forced citation）要求：评审结论的每个判断点都必须引用 SKILL.md 的具体原文段落。没有引用原文的判断视为无效评审。这不是锦上添花，是防止自判卷偏差的最后一道防线。

小结¶

维度	传统软件测试	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（无法验证）状态，不代表失败，但必须补充资产后重跑，不能忽略。