看懂 AI Skill 测评报告：PASS / FAIL / INCONCLUSIVE 背后的发布决策逻辑
系列：AI Skill 测评体系从零到一（六）
难度：实操
适合读者：需要根据报告做发布决策的产品/研发负责人
📌 一句话摘要：测评报告顶部的绿/橙/红色横幅决定能不能发布，本文手把手教你读懂每个数字和每种状态的含义，以及发现问题后的修复路径。
🏷️ 推荐标签：人工智能 LLM Agent 质量评估
报告是写给谁看的
AI Skill 测评报告服务两类读者，关注点完全不同——产品/研发负责人只需要看三个区块，测评工程师需要深入用例详情。
产品/研发负责人（做发布决策）：
- 只需要看：决策横幅 + 汇总卡片 + 发布决策矩阵
- 核心问题：这个 Skill 能不能上线？
测评工程师（定位问题）：
- 需要看：用例详情展开 + evidence + MCP 调用链 + 幻觉检测
- 核心问题：哪里出了问题？如何修复？
报告顶部有「📖 名词速查」区块，列出了报告中所有专业术语的解释（如 INCONCLUSIVE、Δ、IFR、transcript 等），不熟悉的读者先看这里。
📌 建议阅读顺序（三步快速读懂报告）：
- 先看顶部「📖 名词速查」：花 1 分钟通读速查表，能解决 90% 的术语困惑，不用中途去查资料
- 再看「决策横幅」：绿/橙/红色横幅直接告诉你结论，是否能上线一目了然
- 最后看「改进建议」：P0/P1 条目是下一步必须做的事，P2 是优化方向
如果你是测评工程师需要定位问题，再进入「各用例执行情况」展开每条断言的 evidence 细节。
第一眼看决策横幅
报告最顶部的决策横幅是发布决策的最终结论，分为 PASS（绿）、CONDITIONAL PASS（橙）、FAIL（红）三种。
✅ PASS（绿色） 所有核心指标达标，无负向增益，灾难场景全部通过。 → 可以发布
⚠️ CONDITIONAL PASS（橙色） 通过率接近阈值但差距在 3% 以内，或部分灾难场景未执行。 → 需要与产品/研发负责人当面对齐：说明差距是什么、影响范围有多大、修复时间线是什么，经负责人明确知情后才可有条件发布。
CONDITIONAL PASS 的操作步骤：
- 在报告用例详情中找出所有失败用例，说明根因
- 评估每个根因对线上用户的实际影响（是否为已知边缘情况）
- 约定具体修复时间（如「3 个工作日内修复并重测」）
- 由产品/研发负责人签字确认，文档保存
- 修复完成后必须重跑对应用例，确认通过后升级为 PASS
❌ FAIL（红色） 核心指标未达标，或有未解决的负向增益。 → 不允许发布，修复后重测
🔘 INCONCLUSIVE（灰色） 用例无法得出结论——不是 AI 出错，而是测试环境缺少触发条件。
常见环境限制原因：
- 发票类型不符：测试「住宿发票检测」规则，但手头只有汽油发票，住宿关键词不会出现在 OCR 结果中，规则无法触发
- 账号数据不符：测试「无差旅申请单时中断」，但测试账号恰好有 12 条有效申请单，中断条件不满足
- 测试方法层级错误：直接调用 MCP 接口，绕过了 Skill 行为层，Skill 的逻辑约束无法被验证（这是测试设计问题，不是 Skill 问题）
- 历史数据缺失：测试「查询旧单据」时，单据已被系统清理或数据库中不存在
- 权限未开放：测试账号没有触发某规则所需的权限
→ 不影响整体结论，报告中单独列出，需补充对应测试资产后重验
橙色警告「规则推断模式」： 如果 MCP 不可用，横幅下方会出现橙色警告。 → 结论不能作为发布依据，需配置 MCP 后重测
汇总卡片：6 个数字的含义
报告的汇总卡片展示 6 个核心数字，其中增益 Δ < 0 和幻觉次数 > 0 是两个硬红线，触发任何一个都不能发布。
以下阈值（S≥95% 等）为参考值，不是行业统一标准，可根据实际业务风险调整。
| 卡片 | 怎么看 | 红线是什么 |
|---|---|---|
| 有效通过率 | 对照风险等级阈值（S≥95%，A≥90%，B≥80%） | 低于阈值 → FAIL |
| vs baseline 增益 Δ | 正数好，负数危险 | Δ < 0 → 必须查根因，不能上线 |
| 幻觉/编造数据 | S 级要求 0 次 | > 0 → 不能上线 |
| INCONCLUSIVE | 不是 AI 出错，是测试环境缺少触发条件 | 参考意义（需补充测试资产后重验） |
| 待修复问题 | P1/P2 分级 | P1 建议正式发布前修复 |
| 路径覆盖率 | 对照模式目标（quick ≥40%，standard ≥70%） | 参考意义 |
用例执行结果：哪些场景有问题
报告的「四、各用例执行情况」章节按用例逐条展示通过率和增益 Δ，颜色直接标注风险等级——绿色安全、橙色需关注、红色需修复。
| 字段 | 说明 |
|---|---|
| 通过率数字（如 100% / 83%） | 该用例所有断言的通过比例，绿色≥95% / 橙色50-95% / 红色<50% |
| Δ 值（如 +87% / ≈0 / -10%） | with_skill 比 without_skill 高多少，正数越大越好 |
| PASS / INCONCLUSIVE 标签 | PASS=全部通过；INCONCLUSIVE=测试环境限制无法触发，非 AI 错误 |
Δ 值三种情况：
+87%→ Skill 有显著增益，这个场景 Skill 明确有价值≈0「持平」→ Skill 对这个场景没有额外帮助（但也没有负向影响）；有些场景通用模型本身就能处理，持平不是问题-10%→ ⚠️ 负向增益，Skill 在这个场景比没有 Skill 还差，必须查根因
用例详情展开：找根因
点击任意用例行展开，里面有 8 个区块，最可信的是 Layer2a 字段精确校验——直接从执行记录提取，不经过任何 LLM 推断。
① 执行统计
MCP调用 6 次 · 耗时 1.2s · tokens 12,453
快速了解执行情况，耗时异常（>15s）需要关注。
② Layer2b Grader 断言结果
每条断言的 [ground_truth] 或 [grader] 标签，代表评审来源：
✅ [ground_truth] saveExpenseDoc 调用参数 docStatus=10
evidence: transcript Step5 入参：{"docStatus":"10","expenseType":"1",...}
❌ [grader] 输出包含详情链接，不含字面占位符 {fdId}
evidence: response.md 第12行：'https://...params={"fdId":"{fdId}",...}' 含占位符
evidence 为空（红色警告）：该断言不可信，需人工核查或改进断言设计。
③ Layer2a 字段精确校验
直接从 transcript 提取字段做精确比对：
✓ saveExpenseDoc 参数 docStatus=10 证据：transcript Step5 入参
✗ 详情链接不含占位符 {fdId} 证据：response.md 第12行链接含占位符
这里的结果是最可信的，因为直接从执行记录提取，不经过 LLM 推断。
④ MCP 调用链
1. queryExpenseApplier ✓ 210ms → fdCompanyId=xxx, fdBankName=招商银行
2. checkInvoice ✗ 180ms → HTTP 500（测试环境限制）
↳ 降级：使用本地识别结果继续
3. saveExpenseDoc ✓ 390ms → code=200, fdId=a1b2c3d4
接口报错、降级处理、耗时异常都在这里可见。
⑤ 隐含声明验证（幻觉检测）
✓ saveExpenseDoc 调用了一次 transcript 中出现 1 次（Step5）
✗ fdMonthOfOccurrence 取当前月份 实际值 120251100（发票月），非 120260200（提单月）
未通过的 claim 标红，这是发现幻觉的核心地方。 金融场景下 S 级要求 0 次幻觉——任何编造信息都可能导致错误的报销金额。
⑥ 断言质量建议（橙色区块）
💡 「输出包含报销金额」只检查了存在性，未验证金额与发票一致，幻觉金额也会通过。
建议改为：报销金额等于发票识别金额
这是 Grader Agent 对断言本身的批评。不影响本次结论，用于下次迭代改进断言。
⑦ 无 Skill 基线结果（折叠区）
展开看 without_skill 版本的断言通过情况：
- 通过率高（>80%）→ 这个场景 Skill 增益不大，通用模型本身能处理
- 通过率低（<30%）→ 这个场景 Skill 有显著价值
⑧ 人工反馈
可以在报告页面留存文字反馈，由测评工程师记录到 feedback.json，用于下次迭代参考。
（当前版本暂未实现交互式反馈录入）：本版本报告为静态 HTML，反馈需手动写入 feedback.json 文件。后续版本计划在报告页面内直接支持留言和导出。
发布决策参考
发布决策矩阵：只有「PASS + full 模式 + MCP 真实执行」才是最可靠的发布依据，其余情况均需补充条件。
注：以下决策框架中的通过率阈值（S≥95% 等）为参考值，来源于本项目基于业务容错度、用户预期、历史数据三因素制定的准入基线，不是行业统一标准，可根据实际场景调整。
| 情况 | 建议 |
|---|---|
| PASS + full 模式 + MCP 真实执行 | ✅ 可以发布 |
| PASS + standard 模式 + S/A 级 | ⚠️ 建议补跑 full 后再做正式决策 |
| CONDITIONAL PASS，差距 ≤3% | 与团队对齐，有条件发布，约定修复时间 |
| CONDITIONAL PASS，灾难场景未执行 | 补跑 full 模式 |
| 规则推断模式 | ❌ 不作发布依据，修复 MCP 后重测 |
| 任何 FAIL | ❌ 修复后重测 |
发现了问题，怎么修复
问题：某个用例 Δ < 0（负向增益）
- 展开该用例，看
[grader]断言和 evidence - 对比 without_skill 版本的表现（展开折叠区）
- 看 Analyzer 的改进建议（如果有 Layer 3 盲测结果）
- 通常原因：Skill 的某条规则过于死板，限制了模型灵活性
负向增益根因二分法： 逐条禁用 Skill 规则模块，定位导致负向的具体模块，而不是猜测。
问题：幻觉检测未通过
- 看具体哪条 claim 未通过，evidence 中有详细描述
- 找到 SKILL.md 中对应的规则，确认规则描述是否清晰
- 如果规则清晰但模型仍幻觉 → 需要在规则中增加「断言」式约束，如「链接中不得包含
{fdId}字面占位符」
问题：覆盖率不足
运行 full 模式，或手动在 evals.json 中添加未覆盖规则的用例。 覆盖率低意味着有规则没有被测到，通过率再高也不可信。
修复后怎么重测：迭代流程
修复 Skill 后无需重新开始整个测评，在同一 session 下创建新的 iteration，只重跑受影响的用例，大幅节省时间。
iteration-1 结果（初始测评）
→ 发现问题，修复 Skill
→ 在 OpenCode 中说「在上次测评基础上迭代」
→ AI 在同一 workspace_dir 下创建 iteration-2
→ 只重跑失败用例或受影响的批次（节省时间）
→ 多次 iteration 后，Benchmark 数据章节可横向对比通过率变化
什么情况需要全量重跑（而非只跑失败用例）：
- Skill 做了大范围重构（影响多条规则）
- 修复了一条规则但担心引入回归问题
- 底层模型版本升级
什么情况只跑受影响的用例：
- 只修复了 1-2 条具体规则
- 修复的是边界情况，不影响主流程
下一篇，我们来看测评体系目前能做什么，以及下一步可以怎么发展。
常见问题
Q：测评报告的 PASS / CONDITIONAL PASS / FAIL 分别意味着什么？ PASS（绿色）= 所有核心指标达标，无负向增益，可以直接发布。CONDITIONAL PASS（橙色）= 通过率接近阈值但差距 ≤3%，或部分灾难场景未执行，需与负责人当面对齐后有条件发布，并约定具体修复时间。FAIL（红色）= 核心指标未达标或存在未解决的负向增益，不允许发布，必须修复后重测。
Q：看到 INCONCLUSIVE 结论应该怎么处理？ INCONCLUSIVE 不是 AI 出错，是测试环境缺少触发条件——比如想测住宿发票检测规则，但手头只有汽油发票，该规则根本不会触发。正确处理是补充对应的测试资产（正确类型的发票、专用测试账号、特定数据）后重新跑该用例。INCONCLUSIVE 用例不计入通过率，不影响整体发布决策。
Q：哪些情况下绝对不允许发布（硬红线）？ 有三个硬红线，触发任何一个都不能发布：① 增益 Δ < 0（加了 Skill 反而更差）；② S/A 级灾难场景有任何失败；③ 测评在「规则推断模式」下运行（MCP 未真实调用，结论不可信）。此外，幻觉次数 > 0 在 S 级场景也是硬红线。
Q：发现负向增益（Δ < 0）应该怎么排查根因？ 使用「规则模块二分法」：逐条禁用 SKILL.md 中的规则模块，每次禁用后重新跑受影响的用例，观察 Δ 变化。当禁用某个模块后 Δ 转正，说明该模块是根因。通常原因是某条规则限制太死板，把「必须」改为「优先」后，给模型保留兜底能力，Δ 一般会回正。
Q：测评报告里最重要的章节是哪个？
决策层面：顶部的「发布决策横幅」最重要，5 秒内告诉你能不能发布。技术层面：「三、真实 MCP 接口调用记录」和「四、各用例执行情况（展开后的断言 evidence）」最重要——前者证明测评是真实执行的，后者是定位具体问题的核心依据。特别是带 [ground_truth] 标签的断言，可信度最高，应优先关注。
