07—AI Skill 测评体系完整进阶指南：5 大能力缺口与填补路径AI Skill 测评体系完整进阶指南：5 大能力

AI Skill 测评体系完整进阶指南：已解决的能力缺口与下一步路径

系列：SkillSentry · AI Skill 测评体系从零到一（七）

难度：深入

适合读者：想把测评体系做得更完善的工程师

📌 一句话摘要：触发率盲区、纯文本 Skill 支持、执行可信度加固——本文梳理测评体系哪些缺口已解决、哪些尚需推进，以及下一步路径。

🏷️ 推荐标签：AI Skill 测评体系触发率测评纯文本Skill 通用测评

当前测评体系的能力边界

AI Skill 测评体系已经能解决自判卷偏差、随机性和负向增益三个核心问题，但在以下几个方向上存在明确的能力边界——这是进阶前必须诚实面对的现实。

已经很好地解决了：

单条规则的原子级验证（原子场景用例）
业务逻辑组合验证（业务逻辑用例）
自判卷偏差（执行者和 Grader 分离）
负向增益检测（with vs without 对比）
多轮 E2E 用户旅程验证

已填补的缺口：

触发率盲区：新增阶段一 AI 模拟预评估，产出置信度估算（非精确测量，但覆盖了 0 到有）
纯文本 Skill 无法测：新增 Skill 类型自动检测 + 纯文本执行模式，response.md 作为 evidence 来源
效率层指标未采集：新增 timing.json 自动读取，报告第十二章展示 P50/P95 响应时间和 Token 消耗

还没解决，需要进一步完善：

注意：以下缺口不是等权重的。前两条是「不解决则测评结论不可信」的 blocker，后三条是「影响完整性」的改进项。

优先级	缺口	原因	影响
🟡 前提条件	MCP 环境就绪	未配置时自动降级为规则推断模式	规则推断模式下结论不可信；MCP 配置就绪即可真实执行
🟡 重要	触发率精确测量	AI 模拟方案是估算，不是精确率	S/A 级正式发布前需 skill-creator run_eval.py 精确测量
🟡 重要	真实用户分布	用例全是工程师设计，过于整洁	线上真实用户的口语化输入可能表现不同
🟡 重要	模型版本兼容性	没有自动检测模型升级后的行为变化	模型升级可能悄悄破坏 Skill
🟢 一般	知识时效性	没有规则到期提醒	业务规则变了但 Skill 没更新

进阶方向一：触发率测评

触发率是 AI Skill 测评体系的第一道门——Skill 触发不了，后面所有质量保障都没有意义。

当前状态：AI 模拟方案（阶段一自动运行）

每次测评启动时，系统在阶段一自动运行 AI 模拟预评估，不再是完全的盲区：

从 description 提取触发语义
  ↓
自动生成 10 条测试 prompt（5 应触发 + 3 不应触发 + 2 边界）
  ↓
AI 逐条判断触发概率 + 置信度 + 判断依据
  ↓
输出 trigger_eval.json，报告第十一章可视化

AI 模拟方案的价值：

覆盖了「完全没有触发率数据」的问题，从 0 到有
置信度 low 时自动提示优化 description
TN 误触发预测时发出警告

AI 模拟方案的局限：

是估算值而非精确测量，不适合作为 S/A 级正式发布的唯一依据
置信度受 description 清晰度影响，description 模糊则估算偏差大

精确测量路径：集成 skill-creator run_eval.py

S/A 级正式发布前，建议补充精确触发率测量：

触发率优化循环的工作方式（来自 skill-creator 源码）：

生成 20 个 eval query（10 个应触发 + 10 个不应触发）
60/40 分成 train/test，防止过拟合
循环：评估 → 调 LLM 改进 description → 重新评估
按 test 分数（不是 train）选 best description

集成前提：run_eval.py 依赖 claude CLI（claude -p 命令），需要 Claude Code 执行环境。

triggering 问题的特殊性： Claude 有「undertrigger 倾向」——不用 Skill 比应该用的时候更多。description 必须明确说明「即使用户没有显式提到，遇到 X 场景也应该使用」。

进阶方向二：多 Skill 编排链路测试

多 Skill 编排测试要解决的核心问题是：多个 Skill 协同时，单个 Skill 通过率无法保证组合结果的正确性。 当前状态下，我们只测单个 Skill——如果多个 Skill 需要协作完成一个任务，整体链路是没有覆盖的。

多 Skill 编排测试的三个核心问题：

路由正确性：用户的一句话，激活了正确的 Skill 组合吗？
上下文传递完整性：Skill A 的输出作为 Skill B 的输入，信息有没有丢失或变形？
端到端结果正确性：即使每个 Skill 单独测都通过，组合后可能产生新的错误。

编排测试特有的失败模式：

上下文污染：Skill A 写入的状态，让 Skill B 做出错误决策
格式不兼容：Skill A 输出 Markdown 表格，Skill B 期望 JSON 结构
触发竞争：同一句话同时触发两个 Skill，各自调用同一接口，产生重复操作（对报销系统是灾难）

建议的分层方案（来自项目对话整理）：

Level 1：接口契约测试（现在就可以做）
  → 静态分析各 Skill 的输入/输出格式是否兼容
  → 成本低，不需要运行时测试

Level 2：链路集成测试（等 Skill 都稳定后做）
  → 一个 prompt 触发多个 Skill，验证端到端结果
  → 需要所有参与 Skill 的单元测试先通过

Level 3：混沌测试（只在关键链路上做）
  → 故意让链路中某个 Skill 返回异常，验证整体容错

进阶方向三：真实用户数据驱动

工程师设计的「标准化」用例与真实用户输入之间存在系统性偏差，这个偏差会导致测评通过率虚高。 我们的用例全是工程师设计的整洁输入，而真实场景完全不是这样。

真实用户的输入：

口语化：「帮我报个餐费」而不是「请帮我创建一个日常餐费报销申请」
有错别字：「报消」、「报消单」
信息不完整：「帮我报销一下」（没说类型，没说金额）
背景混杂：「我昨天去北京出差，哦对了，帮我把上周的餐费也报了」

解决方法（来源：eval-dimensions.md §8.3）：

「加入真实用户历史输入样本，避免 prompt 过于『工程化』」

具体做法：

收集线上真实用户的对话记录（脱敏处理）
从中提取「触发了报销流程」的 query，加入 eval set
特别关注导致线上投诉的 query，作为重点测试用例

进阶方向四：模型版本兼容性测试

模型版本升级（如 Claude Sonnet 4 → Sonnet 5）是 AI Skill 测评体系的隐性风险——底层模型行为的静默变化会让已通过测评的 Skill 在新版本上出现回归。

来源：eval-dimensions.md §1.3：

「在模型升级前后各跑一轮完整 benchmark 对比」

建议的机制：

在 eval_environment.json 中记录 model 字段
模型升级时，自动触发对所有 S/A 级 Skill 的重新测评
对比新旧版本的通过率变化，发现「模型升级破坏了哪些场景」

进阶方向五：知识时效性管理

业务规则有「保质期」，规则变了但 Skill 没更新，这是一种测评无法覆盖的质量衰减——必须用主动管理机制来对抗。

来源：eval-dimensions.md §9.1：

「在 SKILL.md 中标注规则有效期，每季度对 S/A 级 Skill 做规则有效性复核」

建议的格式：

# 超标校验规则（最后验证：2026-03，下次复核：2026-06）
checkExpenseItem 返回 exceededMoney 时，自动扣减，无需询问原因...

触发复核的场景：

定期：S/A 级每季度
事件驱动：公司报销制度更新 → 立即触发相关 Skill 复核

三条件对比范式（深度评测）

三条件对比范式是一种判断「继续优化是否值得」的决策工具，在大版本改动后或资源有限需要取舍时特别有用。

来源：admission-criteria.md:99-109

这是一个可选的深度测评方法，在以下情况特别有用：

大版本改动后，想知道「这次改动整体上有没有进步」
想决定「要不要继续投入优化这个 Skill」

条件A：without_skill（纯模型能力）
条件B：with curated_skill（人工设计的 Skill）
条件C：with self-generated_skill（让模型自己生成 Skill）

解读：
  B > C → 人工 Skill 有价值，继续优化
  B ≈ C → 继续优化边际收益低，可能该停了
  B < C → Skill 过度约束了模型（极少见但危险）

给测评体系建设者的建议

从这个项目中，我们得到了几条实践经验：

1. 先确认 MCP 配置就绪再跑测评

SkillSentry 支持真实调用 MCP，但需要 MCP 在执行环境中正确配置。启动时会自动探测，探测失败则降级为规则推断模式。规则推断模式下的通过率没有任何意义——测评的价值完全建立在「真实执行」的基础上。

2. 用例质量 > 用例数量

20 个有判别力的断言，比 100 个弱断言更有价值。每次测评结束后，都要看一眼 eval_feedback，改进断言设计。

3. 负向增益比失败更危险——发现后用二分法定位

用例通过率 60% 是明显有问题，你会去修。但 Δ < 0 容易被忽视——「至少还有 80% 通过率呀」。实际上，加了 Skill 反而更差，说明这个 Skill 在某些场景是有害的。

发现 Δ < 0 后，用二分法逐步定位根因：

Step 1：找出 Δ < 0 的具体用例（报告中标红的 Δ 值）
Step 2：展开该用例，对比 with_skill 和 without_skill 的 transcript
Step 3：看 Analyzer 的改进建议（如果有 Layer 3 盲测结果）
Step 4：临时注释掉 SKILL.md 中一半的规则模块，重跑该用例
Step 5：
  → Δ 变正：被注释的那半规则里有问题，继续二分
  → Δ 仍负：另一半规则里有问题，继续二分
Step 6：找到具体规则 → 修改或删除 → 重测确认

不要猜测，二分法通常 3-4 轮就能定位到具体规则。

4. 测评不是一次性的

Skill 会迭代，模型会升级，业务规则会变化。测评是一个持续的过程，不是发布前跑一次就完了。建立定期测评机制（尤其是 S/A 级 Skill），才能保证质量持续可控。

总结：这套体系解决了什么，还有什么空白

已解决：

AI Skill 测评的「自判卷」偏差（四层验证体系）
随机性导致的结论不稳定（多次运行取均值）
负向增益的发现（with vs without 对比）
规则覆盖率的量化（功能/路径/断言三层覆盖率）
发布决策的标准化（准入指标表）
触发率盲区（AI 模拟估算，阶段一自动运行）
纯文本 Skill 无法测（Skill 类型自动检测 + 纯文本执行模式）
效率层指标未采集（timing.json 自动读取 + P50/P95 报告展示）
without_skill 文件系统污染（双 workspace 沙箱隔离）
通过率被存在性断言虚高（断言强度三级分级，精确断言单独计算准入）
transcript 含 AI 主观注释影响 evidence 可信度（双分离格式 + Grader 引用优先级）
quick 单次运行结论不稳定（强制 2 次，差距 >15% 自动降级）
触发率 AI 估算无门槛（low 置信度 / TP<70% / TN 误触发强制降为 CONDITIONAL PASS）

仍有空白：

触发率精确测量（AI 模拟是估算，S/A 级正式发布前需 skill-creator run_eval.py）
真实用户分布对齐（需要线上数据）
多 Skill 编排链路测试（需要多个稳定 Skill）
模型版本兼容性自动化（模型升级时自动触发回归测评）
知识时效性管理机制（规则到期提醒）
description 自动优化循环（依赖触发率精确测量）

对「权威可信」的诚实定位：

经过这轮信任加固，SkillSentry 的测评结论在以下维度已具备较高可信度：

维度	改进前	改进后
MCP 调用参数验证	可信	可信（不变）
Δ 增益有效性	中等（文件污染）	高（双 workspace 沙箱隔离）
通过率的意义	中等偏低（存在性断言稀释）	高（精确通过率独立展示）
transcript evidence 可信度	中等（AI 注释混入）	高（双分离，agent_notes 降权）
结论稳定性	未知（单次运行）	有基准（两次运行，差距可见）
触发率风险识别	无门槛（只给警告）	有机制（低置信自动降级）

AI Skill 测评体系还在发展中，当前最合理的定位是：对「核心 MCP 调用流程是否按规则执行」这个问题给出有底气的、可追溯的答案；对「这个 Skill 是否可以在 S 级场景下安全发布」，需要 standard/full 模式 + 灾难场景 + 精确触发率，缺一不可。

FAQ

Q：当前 AI Skill 测评体系最大的能力缺口是什么？

触发率测评是目前最大的 blocker 级缺口。现有体系只测「Skill 触发后的行为质量」，完全没有覆盖「Skill 能不能被触发」这个前提问题。一个触发率 40% 的 Skill，哪怕触发后行为完美，实际用起来也是废的——60% 的场景直接跳过了 Skill。结论：触发率测评必须在行为质量测评之前解决，否则所有通过率数据都缺乏前提保障。

Q：如何测试多个 Skill 协同工作时的质量？

多 Skill 编排测试建议分三层来做：Level 1 是接口契约测试，静态分析各 Skill 的输入/输出格式是否兼容，成本最低，现在就可以做；Level 2 是链路集成测试，用一个 prompt 触发多个 Skill 验证端到端结果，前提是所有参与 Skill 的单元测试已通过；Level 3 是混沌测试，故意注入异常验证整体容错，只在核心链路上做。特别要警惕「触发竞争」问题——两个 Skill 同时触发并各自调用同一接口，在报销系统里会产生重复提单的灾难性后果。

Q：模型版本升级（如 Claude 3 → 4）为什么需要重新测评？

模型升级会带来底层推理行为的变化，这种变化是静默的——没有任何报错，Skill 的表面功能看起来正常，但某些边界场景的处理方式已经悄悄改变了。建议在 eval_environment.json 中记录 model 字段，模型升级时自动触发对所有 S/A 级 Skill 的重新测评，并对比新旧版本的通过率差异。不做版本兼容性测评，等于把每次模型升级变成一次盲目的线上赌博。

Q：什么是三条件对比范式，什么时候用它？

三条件对比范式通过同时跑三组实验来量化「人工 Skill 的边际价值」：条件 A 是纯模型能力（without_skill），条件 B 是人工设计的 Skill，条件 C 是让模型自动生成的 Skill。如果 B > C，说明人工 Skill 有价值，值得继续投入；如果 B ≈ C，说明继续优化的边际收益已经很低了；如果 B < C，说明人工 Skill 过度约束了模型，反而拖了后腿。这个范式适合在大版本改动后或需要决定「是否继续投入资源优化」时使用，不适合日常增量迭代。

Q：AI Skill 测评体系未来的发展方向是什么？

最近期的方向是补齐触发率测评（集成 skill-creator 的 run_eval.py），这是当前唯一的 blocker 级缺口。中期是建立多 Skill 编排链路测试和真实用户数据驱动的用例体系，让测评更贴近线上真实分布。长期是实现模型版本兼容性的自动化检测和知识时效性的主动管理机制——让测评从「发布前跑一次」变成一个持续运行的质量护栏。这套 AI Skill 测评体系的终态是：Skill 质量在整个生命周期内都处于可观测、可干预的状态。