4.1 置信度的定义
在 RICE 指标中，Confidence（置信度）衡量的是评估者对一项 Agent 能力或功能预期效果有多大把握。它并非精确的概率值，而是在现有信息不完备的情况下，对“该功能上线后能达到预期收益”这一判断的可靠程度。置信度越高，说明评估者越肯定；置信度越低，意味着不确定性较大，需要更多验证。
4.2 置信度评估维度
置信度不是凭空产生的，它由多个维度共同支撑。下表列出主要评估维度及其常见数据来源：
| 维度 | 说明 | 常用数据来源 | 参考权重 |
|---|---|---|---|
| 数据支撑度 | 是否有定量数据（用户测试、A/B 实验、日志分析）支持假设 | 用户行为日志、实验平台、问卷调查 | 40% |
| 经验相关性 | 团队成员是否拥有类似功能的设计或研发经验 | 历史项目复盘、专家访谈、领域知识 | 25% |
| 推理完整性 | 从问题到方案的逻辑链条是否严密、无明显漏洞 | 设计文档、评审记录、因果图 | 20% |
| 外部佐证 | 行业报告、竞品分析、学术论文等第三方参考 | 市场研究、竞品对标、文献综述 | 15% |
4.3 主观与客观结合
置信度天然包含主观成分——即使是数据驱动，解读数据本身也依赖人的判断。正确做法是：用客观数据校准主观判断，而不是完全替代。例如：
- 客观数据高（如 A/B 测试显著 +10%）→ 置信度可设为 0.8 以上
- 无实验数据但有强专家经验 → 置信度宜在 0.5~0.7 之间
- 仅有推测或直觉 → 置信度应低于 0.3
团队应记录主观置信度的依据，便于后续复盘校准。常见的“拍脑袋”做法是将直觉与事实混淆，导致评估偏差。
4.4 Agent 能力置信度
在 Agent 场景中，置信度评估需要额外关注 Agent 自身能力的稳定性。例如：
- 意图识别准确率
- 工具调用成功率
- 多轮对话一致性
- 异常处理鲁棒性
这些指标往往需要线上灰度数据和离线评测相结合。Agent 能力置信度越低，RICE 中的 Confidence 分数就越需要打折。
4.5 置信度评估流程结构图
4.6 类比说明
置信度类似于天气预报中的“降水概率”。当气象台预报“明天有 70% 概率下雨”，并不表示 70% 的城市会下雨，而是基于历史数据和模型，判断明天下雨的可能性是 70%。类似地，RICE 中的 Confidence = 0.7 意味着：我们有 70% 的把握该 Agent 功能上线后能产生预期效果。
4.7 常见误区
- 误区 1：把置信度等同于准确率。准确率是事后统计，置信度是事前判断；二者可能偏差很大。
- 误区 2：忽略样本量。基于 10 条用户反馈得到的置信度与 10000 条反馈得到的置信度，即使数值相同，实际可靠程度完全不同。建议同时标注“数据量级”。
- 误区 3：主观与客观对立。不应将专家经验视为不可靠，也不应完全迷信数据。两者结合才能减少偏差。
4.8 练习题
题目：某 Agent 团队计划上线“自动发票识别”功能。目前仅有 5 条用户内测反馈（4 条好评），无正式日志数据。三位工程师一致认为该功能很有价值。请估计 Confidence 分数，并说明主要依据。
参考答案：建议 Confidence ≈ 0.3 ~ 0.4。数据支撑度极低（样本太少）、经验相关性中等、推理完整性一般，外部佐证无。综合权重后不宜超过 0.4。团队应先做小范围灰度实验获取更多数据。
4.9 应用边界
置信度在 RICE 中的核心作用是 调节优先级。例如：
- 功能 A：Reach=500，Impact=High（3），Effort=Medium（2）→ 原始 ICE=500×3/2=750
- 若 Confidence=0.9 → 加权分数=675，适合优先启动
- 若 Confidence=0.3 → 加权分数=225，可能排在其他更确定的功能之后
实际使用中，可结合团队风险偏好设置置信度阈值（如低于 0.5 不进入 sprint），或作为 backlog 排序的二次因子。注意：置信度不应完全替代数据验证，而是帮助团队在对不确定性的认知基础上做出更理性的决策。