INCONCLUSIVE 背后的发布决策逻辑¶

📊 Level ⭐⭐⭐⭐⭐ | 14.7KB

报告是写给谁看的¶

读者	关注点	核心问题
产品/研发负责人	决策横幅 + 汇总卡片 + 发布决策矩阵	这个 Skill 能不能上线？
测评工程师	用例详情展开 + evidence + MCP 调用链 + 幻觉检测	哪里出了问题？如何修复？

建议阅读顺序（三步）：先看「📖 名词速查」（1分钟）→ 再看「决策横幅」→ 最后看「改进建议」

决策横幅三种结论¶

横幅	含义	操作
✅ PASS（绿色）	所有核心指标达标，无负向增益，灾难场景全部通过	可以发布
⚠️ CONDITIONAL PASS（橙色）	通过率接近阈值但差距≤3%，或部分灾难场景未执行	需与负责人当面对齐，约定修复时间
❌ FAIL（红色）	核心指标未达标，或有未解决的负向增益	不允许发布，修复后重测
🔘 INCONCLUSIVE（灰色）	用例无法得出结论——测试环境缺少触发条件，非 AI 出错	不影响整体结论，需补充测试资产后重验

橙色警告「规则推断模式」：如果 MCP 不可用，横幅下方出现橙色警告。结论不能作为发布依据，需配置 MCP 后重测。

CONDITIONAL PASS 操作步骤¶

在报告用例详情中找出所有失败用例，说明根因
评估每个根因对线上用户的实际影响
约定具体修复时间（如「3个工作日内修复并重测」）
由产品/研发负责人签字确认，文档保存
修复完成后必须重跑对应用例，确认通过后升级为 PASS

INCONCLUSIVE 常见原因¶

发票类型不符：测试「住宿发票检测」但手头只有汽油发票
账号数据不符：测试「无差旅申请单时中断」但测试账号恰好有有效申请单
测试方法层级错误：直接调用 MCP 接口，绕过了 Skill 行为层
历史数据缺失：测试「查询旧单据」但单据已被系统清理
权限未开放：测试账号没有触发某规则所需的权限

汇总卡片：读懂核心指标¶

卡片	怎么看	红线
精确断言通过率 ★	对照风险等级阈值（S≥95%，A≥90%，B≥80%）	精确通过率低于阈值 → FAIL
综合通过率（括号内）	包含存在性断言，精确远低于综合说明断言集质量偏低	参考
vs baseline 增益 Δ	正数好，负数危险	Δ < 0 → 必须查根因，不能上线
幻觉/编造数据	S级要求 0 次	> 0 → 不能上线
INCONCLUSIVE	测试环境限制，非 AI 错误	参考（需补充测试资产后重验）
路径覆盖率	对照模式目标（quick ≥40%，standard ≥70%）	参考

断言三级分解：

精确断言 ★   80%  (4/5)  ← 准入判断依据
语义断言 ◆   100% (2/2)  ← 辅助参考
存在性断言 ○  1/1         ← 不计入准入

结果不稳定横幅¶

quick 模式强制运行 2 次，两次差距 > 15% 时：

⚠️ 结果不稳定（两次差距 XX%）
   run1: 75%，run2: 91%
   建议升级到 standard 模式（3次运行）以获得可信结论。

→ 发布决策自动从 PASS 降为 CONDITIONAL PASS

用例执行情况：Δ 值三种情况¶

Δ 值	含义
+87%	Skill 有显著增益，这个场景 Skill 明确有价值
≈0「持平」	Skill 对这个场景没有额外帮助（通用模型本身就能处理），不是问题
-10%	⚠️ 负向增益，Skill 比没有 Skill 还差，必须查根因

用例详情展开：8 个区块¶

点击任意用例行展开，最可信的是 Layer 2a 字段精确校验——直接从执行记录提取，不经过任何 LLM 推断。

① 执行统计¶

MCP调用 6 次  ·  耗时 1.2s  ·  tokens 12,453

耗时异常（>15s）需要关注。

② Layer2b Grader 断言结果（三类标签）¶

✅ ★精确  [tool_calls] [ground_truth]  saveExpenseDoc 调用参数 docStatus=10
   evidence: transcript [tool_calls] Step5 入参：{"docStatus":"10",...}
❌ ★精确  [response]  [grader]  输出包含详情链接，不含字面占位符 {fdId}
   evidence: response.md 第12行含占位符
✅ ◆语义  [response]  [grader]  报销主题包含出行目的和时间
   evidence: response.md 第3行
⚠️ ○存在性  [不计入准入]  没有编造发票信息

三类标签含义：

★精确 / ◆语义 / ○存在性：断言强度，○存在性不计入准入
[tool_calls] / [response] / [agent_notes]：evidence 来源，tool_calls 可信度最高
[ground_truth] / [grader]：评审来源，ground_truth 不经过任何 LLM

③ Layer2a 字段精确校验¶

✓ saveExpenseDoc 参数 docStatus=10    证据：transcript Step5 入参
✗ 详情链接不含占位符 {fdId}          证据：response.md 第12行含占位符

最可信（直接从执行记录提取，不经过 LLM）。

④ MCP 调用链¶

1. queryExpenseApplier   ✓  210ms  → fdCompanyId=xxx
2. checkInvoice          ✗  180ms  → HTTP 500（测试环境限制）
   ↳ 降级：使用本地识别结果继续
3. saveExpenseDoc        ✓  390ms  → code=200, fdId=a1b2c3d4

⑤ 隐含声明验证（幻觉检测）¶

✓ saveExpenseDoc 调用了一次        transcript 中出现 1 次（Step5）
✗ fdMonthOfOccurrence 取当前月份   实际值 120251100（发票月），非提单月

金融场景 S 级要求 0 次幻觉。

⑥ 断言质量建议（橙色区块）¶

💡 「输出包含报销金额」只检查了存在性，未验证金额与发票一致。
   建议改为：报销金额等于发票识别金额

不影响本次结论，用于下次迭代改进断言。

发布决策矩阵¶

情况	发布建议
精确通过率达标 + full 模式 + MCP 真实执行	✅ 可以发布
精确通过率达标 + standard 模式 + S/A 级	⚠️ 建议补跑 full 后再做正式决策
CONDITIONAL PASS，差距 ≤3%	与团队对齐，有条件发布，约定修复时间
CONDITIONAL PASS，灾难场景未执行	补跑 full 模式
quick 模式两次差距 > 15%	⚠️ 自动降为 CONDITIONAL PASS，升级 standard 模式
规则推断模式	❌ 不作发布依据，修复 MCP 后重测
任何 FAIL	❌ 修复后重测

硬红线（直接 FAIL）¶

Δ < 0：加了 Skill 反而更差
S/A 级灾难场景有任何失败
规则推断模式下运行（MCP 未真实调用）

S 级硬红线：幻觉次数 > 0

触发率 AI 估算自动降级规则（S/A 级）¶

情况	影响
TP 估算 ≥ 80%，置信度 high/medium	正常，标注参考值
TP 估算 ≥ 80%，置信度 low	自动降为 CONDITIONAL PASS
TP 估算 < 70%	自动降为 CONDITIONAL PASS
TN 有误触发预测	自动降为 CONDITIONAL PASS + 标红

发现了问题怎么修复¶

Δ < 0（负向增益）¶

使用「规则模块二分法」：逐条禁用 SKILL.md 中的规则模块，每次禁用后重跑，观察 Δ 变化。当禁用某个模块后 Δ 转正，说明该模块是根因。

通常原因：某条规则限制太死板 → 把「必须」改为「优先」，给模型保留兜底能力。

幻觉检测未通过¶

找到 SKILL.md 中对应的规则，确认规则描述是否清晰。规则清晰但模型仍幻觉 → 在规则中增加「断言」式约束，如「链接中不得包含 {fdId} 字面占位符」。

覆盖率不足¶

运行 full 模式，或手动在 evals.json 中添加未覆盖规则的用例。

修复后怎么重测：迭代流程¶

iteration-1（初始测评）
  → 发现问题，修复 Skill
  → 在 OpenCode 中说「在上次测评基础上迭代」
  → AI 在同一 workspace_dir 下创建 iteration-2
  → 只重跑失败用例或受影响的批次（节省时间）

需全量重跑的情况：Skill 大范围重构 / 修复一条规则但担心引入回归 / 底层模型版本升级

只跑受影响的用例：只修复了 1-2 条具体规则 / 修复的是边界情况不影响主流程

深度分析¶

测评报告的决策逻辑本质¶

AI Skill 测评报告是一套分层置信机制：用颜色横幅给出确定性结论，用精确通过率给出量化门槛，用 Δ 值识别 Skill 的真实价值。三个维度缺一不可——只看横幅会漏掉负向增益陷阱，只看通过率会忽略 Skill 相对基线的退化，只看 Δ 值会失去与业务风险等级的联动。

精确断言 vs 综合通过率的分离价值¶

精确断言 ★ 是唯一准入判断依据，综合通过率（含语义和存在性断言）提供辅助参考。当精确远低于综合时，说明断言集本身设计偏松——存在性断言没验证真实性，语义断言没绑定具体值。这个分离设计让「报告看着好看但实际有问题」的情况无所遁形。

Δ < 0 的破坏性含义¶

Δ < 0（负向增益）是报告体系中最危险的信号。它意味着在特定用例上，加了 Skill 的 AI 表现反而比不加更差。这通常说明 SKILL.md 中的某条规则限制太死板，强制 AI 走错误路径，而不是保留通用模型的兜底能力。「规则模块二分法」定位根因后，将「必须」改为「优先」往往能解决问题——这是 Skill 设计的核心教训。

INCONCLUSIVE 的设计哲学¶

灰色 INCONCLUSIVE 横幅是体系成熟度的体现：它承认测试环境的局限性，并将「AI 出错」和「测试条件不足」区分开来。这避免了对 Skill 的冤枉追责，同时也防止了用环境缺陷掩盖 AI 能力不足的问题。补充测试资产后重验的机制，确保了每张报告都有可信的结论。

Layer 2a vs Layer 2b 的证据可信度层级¶

用例详情的 8 个区块构成了一套证据层级：Layer 2a 字段精确校验可信度最高（直接从 transcript 提取，不经过 LLM），Layer 2b Grader 断言次之（经过 LLM 评分但有结构化 evidence），触发率 AI 估算再次。理解这个层级，才能正确解读报告中的 failure case——是 AI 真的错了，还是 evidence 来源本身不可靠。

实践启示¶

发布决策检查清单¶

当拿到一张测评报告时，按以下顺序检查： 1. 先确认不是规则推断模式（MCP 真实调用是前提条件） 2. 再看决策横幅颜色，PASS/FAIL/INCONCLUSIVE 各有明确含义 3. 对照风险等级阈值（S≥95%，A≥90%，B≥80%）检查精确通过率 4. 检查 Δ 值，负数必须查根因 5. S/A 级额外检查：灾难场景是否全部通过、幻觉次数是否为 0

收到 CONDITIONAL PASS 后的标准操作¶

当报告是橙色 CONDITIONAL PASS 时，不要直接进入修复流程。首先评估差距是否 ≤3%——这个范围内可以与团队协商有条件发布，但必须有书面记录和明确修复时间。如果差距 >3% 或有灾难场景未执行，必须完成修复才能继续。修复完成后，用同一个 Skill 在同一 workspace_dir 下创建 iteration-N，只重跑失败用例以节省时间。

改进断言质量的时机¶

报告中的「断言质量建议」橙色区块不影响本次结论，但指出了下次迭代的优化方向。当发现精确通过率远低于综合通过率时，应该将存在性断言升级为精确断言（如「输出包含报销金额」→「报销金额等于发票识别金额」），将语义断言绑定具体字段。好的断言集是报告可信度的基础。

负向增益的快速定位法¶

遇到 Δ < 0 时，用「规则模块二分法」定位根因：逐条禁用 SKILL.md 中的规则模块，每次禁用后重跑，观察 Δ 变化。禁用某模块后 Δ 转正，说明该模块是根因。常见修复方式是将「必须」改为「优先」，给模型保留兜底能力。修复后必须重跑确认 Δ 转正才能上线。

关联阅读¶

→ AI Skill 测评体系进阶指南 — 同系列其他章节

→ 原文存档