---
source_url: https://juejin.cn/post/7620226704209068072
tags: [juejin]
ingested: 2026-05-14
sha256: 557c1aa0434f37c23f92df8592da8d19a32af6a6fd9205ea0814732abad2e7a0
---
# 07—AI Skill 测评体系完整进阶指南：5 大能力缺口与填补路径
系列：SkillSentry · AI Skill 测评体系从零到一（七）
难度：深入
适合读者：想把测评体系做得更完善的工程师
📌 一句话摘要：触发率盲区、纯文本 Skill 支持、执行可信度加固——本文梳理测评体系哪些缺口已解决、哪些尚需推进，以及下一步路径。
## 当前测评体系的能力边界
### 已很好地解决
- 单条规则的原子级验证（原子场景用例）
- 业务逻辑组合验证（业务逻辑用例）
- 自判卷偏差（执行者和 Grader 分离）
- 负向增益检测（with vs without 对比）
- 多轮 E2E 用户旅程验证
### 已填补的缺口
- **触发率盲区**：新增阶段一 AI 模拟预评估，产出置信度估算
- **纯文本 Skill 无法测**：新增 Skill 类型自动检测 + 纯文本执行模式
- **效率层指标未采集**：新增 timing.json 自动读取，P50/P95 响应时间和 Token 消耗
### 还没解决（需要进一步完善）
| 优先级 | 缺口 | 原因 | 影响 |
|--------|------|------|------|
| 🟡 前提条件 | MCP 环境就绪 | 未配置时自动降级为规则推断模式 | 规则推断模式下结论不可信 |
| 🟡 重要 | 触发率精确测量 | AI 模拟方案是估算，不是精确率 | S/A 级正式发布前需 skill-creator run_eval.py |
| 🟡 重要 | 真实用户分布 | 用例全是工程师设计，过于整洁 | 线上真实用户的口语化输入可能表现不同 |
| 🟡 重要 | 模型版本兼容性 | 没有自动检测模型升级后的行为变化 | 模型升级可能悄悄破坏 Skill |
| 🟢 一般 | 知识时效性 | 没有规则到期提醒 | 业务规则变了但 Skill 没更新 |
## 进阶方向一：触发率测评
**触发率是测评体系的第一道门**——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，各自调用同一接口，产生重复操作（对报销系统是灾难）
### 建议的分层方案
| Level | 方案 | 前提 |
|-------|------|------|
| Level 1 | 接口契约测试：静态分析各 Skill 的输入/输出格式是否兼容 | 现在就可以做 |
| Level 2 | 链路集成测试：一个 prompt 触发多个 Skill，验证端到端结果 | 所有参与 Skill 的单元测试先通过 |
| Level 3 | 混沌测试：故意让链路中某个 Skill 返回异常，验证整体容错 | 只在关键链路上做 |
## 进阶方向三：真实用户数据驱动
**核心问题**：工程师设计的「标准化」用例与真实用户输入之间存在系统性偏差，导致测评通过率虚高。
### 真实用户输入的特点
- **口语化**：「帮我报个餐费」而不是「请帮我创建一个日常餐费报销申请」
- **有错别字**：「报消」、「报消单」
- **信息不完整**：「帮我报销一下」（没说类型，没说金额）
- **背景混杂**：「我昨天去北京出差，哦对了，帮我把上周的餐费也报了」
### 解决方法
1. 收集线上真实用户的对话记录（脱敏处理）
2. 从中提取「触发了报销流程」的 query，加入 eval set
3. 特别关注导致线上投诉的 query，作为重点测试用例
## 进阶方向四：模型版本兼容性测试
**核心问题**：模型版本升级（如 Claude Sonnet 4 → 5）是隐性风险——底层模型行为的静默变化会让已通过测评的 Skill 在新版本上出现回归。
### 建议的机制
1. 在 eval_environment.json 中记录 model 字段
2. 模型升级时，自动触发对所有 S/A 级 Skill 的重新测评
3. 对比新旧版本的通过率变化，发现「模型升级破坏了哪些场景」
## 进阶方向五：知识时效性管理
**核心问题**：业务规则有「保质期」，规则变了但 Skill 没更新，必须用主动管理机制来对抗。
### 建议的格式
```markdown
# 超标校验规则（最后验证：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 仍有空白
### 已解决
| 问题 | 解决方案 |
|------|---------|
| 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 |
### 仍有空白
| 缺口 | 状态 |
|------|------|
| 触发率精确测量 | 需集成 skill-creator run_eval.py |
| 真实用户分布对齐 | 需要线上数据 |
| 多 Skill 编排链路测试 | 需要多个稳定 Skill |
| 模型版本兼容性自动化 | 模型升级时自动触发回归测评 |
| 知识时效性管理机制 | 规则到期提醒 |
| description 自动优化循环 | 依赖触发率精确测量 |
### 对「权威可信」的诚实定位
经过信任加固，SkillSentry 的测评结论在以下维度已具备较高可信度：
| 维度 | 改进前 | 改进后 |
|------|--------|--------|
| MCP 调用参数验证 | 可信 | 可信（不变） |
| Δ 增益有效性 | 中等（文件污染） | 高（双 workspace 沙箱隔离） |
| 通过率的意义 | 中等偏低（存在性断言稀释） | 高（精确通过率独立展示） |
| transcript evidence 可信度 | 中等（AI 注释混入） | 高（双分离，agent_notes 降权） |
| 结论稳定性 | 未知（单次运行） | 有基准（两次运行，差距可见） |
| 触发率风险识别 | 无门槛（只给警告） | 有机制（低置信自动降级） |
**终态定位**：对「核心 MCP 调用流程是否按规则执行」给出可信的、可追溯的答案；对 S 级场景下安全发布，需要 standard/full 模式 + 灾难场景 + 精确触发率，缺一不可。