第2章·RICE框架核心概念:区分Reach、Impact、Confidence、Effort四个维度及其含义
适用场景
本章适用于以下场景中需要精准分解Agent原型评估指标的团队或个人:
- 初次引入RICE框架,团队成员对四个维度的边界模糊不清;
- 在评估会上对各维度评分出现争议时,作为概念校准依据;
- 需要将定性描述转化为可量化的维度定义时;
- 构建RICE评分模板前,统一团队语言。
前置条件
- 已完成第1章《RICE框架总体认知》的学习或讨论;
- 手头至少有1个待评估的Agent原型描述(可来自真实项目或模拟案例);
- 准备一份空白评分表(参见“记录材料”章节的模板)。
操作步骤
- 界定Reach(覆盖范围)——明确该Agent原型可能影响的用户/任务/场景数量。用人数、频次或事件量量化,例如“每日触达200个会话”。
- 界定Impact(影响程度)——衡量原型带来的效果增量,如效率提升百分比、错误率降低幅度、用户满意度提升值。避免与Reach混淆,关键区别:Impact关注效果深度,Reach关注扩散广度。
- 界定Confidence(置信度)——评估当前证据链的可靠程度(数据来源、测试规模、专家判断一致性)。常用高/中/低三分法或1~5刻度。
- 界定Effort(投入成本)——汇总研发、算力、时间、人力等资源消耗。需包含隐性成本(如后续维护、兼容性改造),以人天或金额为统一单位。
输入输出物
| 输入物 | 输出物 |
|---|---|
| Agent原型需求文档(含目标用户、功能描述) | RICE四维评分表(每个维度含定义、量化值、备注) |
| 历史性能基线数据(若有) | 维度校准记录(分歧点、最终结论、依据来源) |
责任边界
- 产品经理:主导Reach和Impact的定义,提供业务视角的量化依据;
- 技术负责人:负责Effort的准确估算,包含基础设施、监控、调试成本;
- QA/测试负责人:提供Confidence所需的测试覆盖度、错误率数据;
- 团队全体:参与维度边界讨论,对最终定义达成一致后签字确认。
记录材料
使用以下模板记录每个维度的定义与量化值(建议用共享表格或文档):
| 维度 | 定义(一句话) | 量化值/等级 | 依据来源 | 备注 |
|------------|----------------------------------|-----------------|------------------------|----------------|
| Reach | 受影响会话数/用户数 | 2000次/天 | 日志统计(2025-03) | |
| Impact | 任务完成时长缩短 | 35% | 原型A/B测试结果 | 置信度中等 |
| Confidence | 证据可靠度 | 高 (0.85) | 3轮独立测试+专家评审 | |
| Effort | 开发+测试+部署人天 | 45人天 | 技术评估会议 | 含后期文档 |
异常处理
常见异常及应对:
- 维度混淆:Reach与Impact误填为同一项 → 重新对照“广度vs深度”口诀校准;
- Confidence虚高:因缺乏数据而凭感觉给高分 → 强制要求附加数据来源列;
- Effort遗漏关键成本:未考虑算力或第三方依赖变更 → 使用Effort清单(见记录材料模板)逐项勾选;
- 团队分歧:两个维度之间争议 > 30分钟 → 升为“议题”,安排加时专题会议,并记录分歧点。
验收标准
- 团队中任意成员都能独立用一句话说明四个维度的核心差异;
- 评分表每个维度均有明确、不重叠的量化指标或定性等级;
- Confidence维度必须附带具体数据/证据类型,禁止仅写“感觉”;
- Effort维度已包含隐性成本(如监控、文档、回归测试),并有人天拆分明细。
教学提示:请结合上图,让团队成员轮流用“广度、深度、可信度、成本”四词解释RICE。如果解释卡壳,说明维度区分尚未内化,需要返回步骤1~4重新练习。