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

📊 Level ⭐⭐⭐⭐⭐ | 16.7KB

测评体系的当前能力边界¶

SkillSentry 测评体系经过多个阶段迭代，已解决大量基础问题，但随着业务复杂度提升，仍存在需要持续投入的能力缺口。

已很好地解决的能力¶

• 单条规则的原子级验证：通过原子场景用例对每条规则进行独立验证
• 业务逻辑组合验证：通过业务逻辑用例验证多条规则组合后的行为
• 自判卷偏差：执行者和 Grader 角色分离，消除主观偏差
• 负向增益检测：with vs without 对比，确保 Skill 真正带来正向增益而非负向损害
• 多轮 E2E 用户旅程验证：完整模拟用户与系统的多轮交互场景

已填补的历史缺口¶

尚未解决的能力缺口¶

进阶方向一：触发率测评¶

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

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

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

AI 模拟方案的价值：覆盖了「完全没有触发率数据」的问题，从 0 到有；置信度 low 时自动提示优化 description。

AI 模拟方案的局限：是估算值而非精确测量，不适合作为 S/A 级正式发布的唯一依据。

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

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

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

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

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

核心问题：多个 Skill 协同时，单个 Skill 通过率无法保证组合结果的正确性。

三个核心问题¶

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

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

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

建议的分层方案¶

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

核心问题：工程师设计的「标准化」用例与真实用户输入之间存在系统性偏差，导致测评通过率虚高。

真实用户输入的特点¶

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

解决方法¶

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

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

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

建议的机制¶

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

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

核心问题：业务规则有「保质期」，规则变了但 Skill 没更新，必须用主动管理机制来对抗。

建议的格式¶

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

触发复核的场景¶

• 定期：S/A 级每季度
• 事件驱动：公司报销制度更新 → 立即触发相关 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 在某些场景是有害的。

二分法定位步骤：

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

4. 测评不是一次性的¶

Skill 会迭代，模型会升级，业务规则会变化。建立定期测评机制（尤其是 S/A 级 Skill），才能保证质量持续可控。

总结：已解决 vs 仍有空白¶

已解决¶

仍有空白¶

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

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

终态定位：对「核心 MCP 调用流程是否按规则执行」给出可信的、可追溯的答案；对 S 级场景下安全发布，需要 standard/full 模式 + 灾难场景 + 精确触发率，缺一不可。

深度分析¶

SkillSentry 测评体系的演进折射出一个根本性的工程挑战：如何对 AI 原生系统进行可信的质量评估。传统软件测试依赖确定性的输入-输出映射，而 Skill 的行为本质上受限于底层模型的概率特性。测评体系的核心创新在于引入了「with vs without」的对照范式——这不仅是技术手段，更是一种认识论上的转变，承认了 AI 系统的质量不能仅看绝对通过率，而必须衡量 Skill 带来的增量价值。

触发率问题揭示了测评体系中一个深刻的元认知困境：AI 模拟方案本质上是「用 AI 评估 AI」，这种自我引用结构天然存在可信度上限。Claude 的 undertrigger 倾向暗示，当前大模型在遵循指令方面存在系统性的保守偏差——不用 Skill 比应该用的时候更多。这不是某个模型的缺陷，而是当前 RLHF 训练范式对「拒绝执行」给予过度奖励的副产品。理解这一点，对于设计任何依赖模型遵循能力的产品都至关重要。

多 Skill 编排的挑战暴露了模块化 AI 系统的根本性难题：当多个 Skill 协同工作时，整体行为无法通过单独验证每个 Skill 来保证。上下文污染、格式不兼容、触发竞争这三种失败模式，实际上反映了分布式系统设计中经典的接口契约问题。只是在 AI 系统中，接口是自然语言描述的「description」，契约是隐式的业务规则，这使得问题更加隐蔽和难以形式化。

真实用户数据驱动的方法论揭示了评测领域长期被忽视的系统性偏差：工程师设计的用例代表了一种「理性用户」假设，而真实用户的输入充满了口语化表达、错别字、信息残缺和背景噪音。这种偏差导致测评通过率虚高，形成一种虚假的安全感。三条件对比范式（without_skill vs curated_skill vs self-generated_skill）提供了一种诊断工具，可以判断人工设计的 Skill 是否真正超越了模型的原生能力，还是只是在弥补一个根本不存在的缺陷。

模型版本兼容性问题和知识时效性问题本质上是同一挑战的两个面向：AI 系统的行为会随时间和环境变化，而传统测试的「一次通过，永远有效」假设在这种情况下失效。建立持续监控和定期重评机制，不是可选项，而是 AI 时代质量保障的必选项。这要求在架构设计阶段就考虑到测评的可重复性和环境敏感性。

实践启示¶

• 在设计 Skill 评测体系时，优先建立 with vs without 的对照基准：没有基准线就没有增量衡量，任何通过率数字都是空中楼阁。建议从第一个 Skill 开始就强制运行双测，即使初期结果看起来「没必要」。

• 触发率测量不要过早追求精确，宁可先有方向正确的估算：AI 模拟方案的价值在于建立触发率意识，而非提供精确数字。等业务成熟到需要 S/A 级发布时，再投入 skill-creator run_eval.py 的集成成本。过早优化是万恶之源。

• 多 Skill 编排必须从 Level 1 接口契约测试开始：很多编排问题在静态分析阶段就能发现，无需等到动态运行。投入小、收益大，应该成为任何多 Skill 系统的基线要求。

• 建立真实用户 query 的持续回流机制：每季度从线上数据中抽取脱敏样本加入评测集，是对抗「工程师设计偏差」的唯一有效手段。初期量不需要大，20-30 条有代表性的真实 query 比 100 条标准 query 更有价值。

• 将模型版本升级视为高风险事件，强制触发 S/A 级 Skill 的回归测试：模型升级前后的通过率对比应该成为发布门禁的一部分。如果通过率下降超过阈值，自动触发告警并暂停相关 Skill 的线上暴露。

→ 原文存档

→ 测评指标体系

→ 测评报告解读

相关实体¶

• MOC