不确定性传播：AI 测试系统最容易忽视的设计

AI 最危险的不是"不知道"，而是"不知道自己不知道"——并且以自信的口吻输出。

一个价值三天工时的教训

某次需求分析中，AI 把"单笔限额"理解成了"单日限额"。它没有标记"待确认"，而是以完全确定的语气写下了 40 个测试用例。

三天后开发指出"测试场景根本不对"。三天工作全部返工。

问题不在于 AI 犯了错——问题在于 AI 犯错时没有留下任何"这里我不确定"的痕迹。

"不确定"的三种伪装

1. 格式伪装

整齐的表格、编号的列表——这些格式暗示"这是经过严格分析的结果"。但格式的工整度和内容的准确度之间没有任何关系。

2. 措辞伪装

LLM 不会说"我猜大概可能也许"。它倾向于使用确定性的措辞，包装成一个确定的事实。

3. 推理伪装

LLM 很擅长构建逻辑严密的推理链。但推理链的起点如果是一个错误的前提，越长的推理链会把错误包装得越隐蔽。

全链路不确定性标记

在 Skill 层面：不确定性处理规定

Guardrails:
  - 缺信息不得"脑补"，统一用【待确认】标注
  - 两个数据源冲突时，记录两种说法，不做选择
  - 风险等级无法确定时，就高不就低并标注

在 Command 层面：待确认项聚合可见

每个分析命令的产出中，"评审摘要"必须包含待确认项汇总：

## 待确认项（3 项）

| ID | 位置 | 问题 | 需要谁确认 |
|----|------|------|-----------|
| PD-1 | 需求 3.2 节 | "高频用户"定义不明确 | 产品经理 |
| PD-2 | 技术设计 | 缓存失效策略未说明 | 后端开发 |

在数据链路层面：标记必须传播

如果上游有一个待确认项未解决，所有依赖它的下游产出都必须带上同样的标记。

需求分析
  └── 【待确认】"单笔限额"还是"单日限额"？

      ↓ 传播到

风险矩阵
  └── RISK-007:【待确认 → PD-1】限额相关风险评级可能需要调整

      ↓ 传播到

测试用例
  └── TC-031:【待确认 → PD-1】限额边界值测试

人类审判者的"反确认偏差"训练

1. 评审摘要开头不是"分析结果"，而是"风险和不确定性"

把最需要人类判断的东西放在最前面。

2. 反馈模板中预设"不同意"选项

给每一条风险评级都提供四个选项：□ 同意 □ 升级 □ 降级 □ 移除

3. 定期做"AI 错误率校准"

统计过去 N 次分析中，AI 的哪些判断被人类修正了。用数字校准信任程度。

缺陷调查中的不确定性

三元判断 + 置信度：

判定	置信度	含义	后续动作
CONFIRMED_BUG	>= 90%	有充分证据	直接提交
EXCLUDED	<= 30%	证据显示不是	降级为 RISK
REMAINS_SUSPECT	30%-90%	证据不够	标记待人工确认

渐进信任：用数据建立信心

阶段	审查比例	重点
第 1 个月	80%	待确认项 + 高风险标注
第 3 个月	40%	高风险项 + 历史易错维度
第 6 个月	15%	仅高风险项 + 跨系统影响

设计建议

1. 在系统级别设计不确定性——在每个能力的定义中明确什么情况下标记不确定
2. 让不确定性可见——把待确认项聚合到显眼位置
3. 让反馈成本最低——用预填模板、勾选选项
4. 用传播代替静默——上游不确定下游必须知道
5. 用数据代替感觉——收集修正率数据，用数字校准信任

写在最后

AI Agent 系统的可靠性，不在于 AI 永远正确，而在于系统知道 AI 什么时候可能不正确——并且让人类在正确的时机介入。

---