TL;DR
让 AI 当排优先级的”结构化二审”，而不是当决策者。把 backlog 加上你自己的真实影响数据喂给它，要它按 RICE 套框架打分并写清理由，然后逐条拿你自己的分析数据去核对每个 reach 和 impact。AI 擅长一致地套框架、把理由写出来；它不擅长猜影响和工作量——这两项依赖数据，也依赖一份它看不见的代码库。回报是一份打好分、可排序的清单，你能在冲刺规划里一条一条地为它辩护。
任务场景
backlog 30+ 条，下一个冲刺要清晰，“团队想做啥就做啥”不是策略。你要一份带评分和理由的清单：前 5 做、后 5 砍 / 延，干系人基于”具体那一条”反驳，而不是基于”感觉”。一个通用大模型——Claude Opus 4.7、GPT-5.5、Gemini 3.1 Pro——很擅长这件事里”记账”的部分：把同一套公式套到 30 条异质条目上不跑偏，并把每个分背后的”为什么”写出来。它做不好的恰恰是你真正拿工资在做的那部分：判断真实世界里的影响。
RICE 公式，一行说清
RICE 由 Intercom 的 Sean McBride 提出，目的是把主观判断从路线图决策里剥掉。公式是：
RICE = (Reach × Impact × Confidence) / Effort| 分量 | 衡量什么 | 取值 |
|---|---|---|
| Reach（触达） | 在固定时间窗（如一个季度）内影响多少用户 | 来自你自己分析数据的真实计数 |
| Impact（影响） | 对每个用户的撬动程度 | 3 = 巨大，2 = 高，1 = 中，0.5 = 低，0.25 = 极小 |
| Confidence（置信） | 你对上述估计有多大把握 | 100% = 高，80% = 中，50% = 低 |
| Effort（工作量） | 总工作量，单位人月 | 工程给的数字，哪怕粗略 |
RICE 最有用的一点：同一套公式适用于产品、增长、平台各类工作，所以一个结账修复和一个内部工具任务能落在同一把尺子上。
AI 帮得上和帮不上的地方
AI 强在：把评分规则一致地套到全部 30 条上、找出功能间依赖、为平台团队重新定义 Impact、起草你将在评审会上念出来的理由。正如 IdeaPlan 在其 AI-RICE 指南里指出的，只要你给模型真实分析数据让它推理，它确实能改善 RICE 的输入——尤其是 Reach 和 Confidence。
AI 弱在两个分量上，而且它最弱的地方正是出错代价最高的地方：
- Impact 需要你的使用数据、win rate、NPS 和竞争语境。没看过这些数字的模型只会输出一个自信的占位值。把 AI 给的每个影响分当成待确认的假设，不是事实。
- Effort 取决于你的代码库、技术债、团队构成和架构——这些模型都看不见。用 AI 去拆解工作量、让你能向工程提更准的问题，绝不要让它直接给出人月数。
需要给 AI 的输入信息
- backlog + 一句话描述
- 季度目标（一句话说清成功长啥样）
- 约束：团队规模、时间、本季度不动的代码区域
- 每条功能的真实影响数据：用户提的次数、客服工单、销售请求、流失原因
- 工程的工作量估计，哪怕是粗略区间
- 战略必发：哪些功能不看分也必须发，每条写明原因
可直接复制的 Prompt
为以下 backlog 排优先级。
季度目标：[一句话]
约束：[列表]
战略必发（带原因）：[列表]
Backlog：
1. [功能] — [描述] — 使用数据：[N 次请求 / 工单 / 销售请求] — 工程估：[小 / 中 / 大]
2. ...
用 RICE 评分：
- Reach：每季度受影响用户数，附计算过程
- Impact：0.25 / 0.5 / 1 / 2 / 3——解释为什么选这个
- Confidence：50% / 80% / 100%——解释（低置信 = 需要先验证）
- Effort：人月，以我的工程估为锚
请输出：
1. 评分表：功能 / R / I / C / E / RICE 总分 / 理由 / 依赖
2. 本冲刺前 5，含排序
3. 后 5 砍 / 延，附理由
4. "观察列"：3 个现在分低、但数据变化后可能重排的
5. 你评分中最大的风险——哪里你自己也会 push back
6. 哪些功能要先验证，评分才可信
不要凭空编 reach 数。我没给数据就标 [需要数据] 并踢出前 5。平台团队补一句：“把 Impact 改成’解锁其它团队的程度’，不是终端用户影响。“早期团队没有分析数据，就降到 ICE（Impact × Confidence × Ease）——它跳过 Reach，在你没数据去诚实估 Reach 时更快。
一个完整算例
三条 backlog，用同一把尺子打分：
| 功能 | Reach（用户/季） | Impact | Confidence | Effort（人月） | RICE | 结论 |
|---|---|---|---|---|---|---|
| 企业版 SSO | 1,200 | 2 | 80% | 3 | 640 | 前 5——卡住 3 笔销售 |
| 行内 CSV 导出 | 8,000 | 0.5 | 100% | 1 | 4,000 | 前 5——便宜、高触达 |
| AI 摘要组件 | 500 | 3 | 50% | 4 | 188 | 观察列——需先验证 |
CSV 导出胜出，不是因为它令人兴奋，而是因为”高触达 / 低工作量”压过一个花哨、低置信的赌注。AI 组件 50% 的置信就是信号：在它配得上一个冲刺之前，先做一次假门（fake-door）测试。这种排序事后看显而易见，却能挡住”谁嗓门大谁赢”的会议。
RICE 和其它框架的取舍
| 框架 | 优化目标 | 适用场景 |
|---|---|---|
| RICE | 单位工作量下的用户影响广度 | 有客户数据的中型团队；默认首选 |
| ICE | 打分速度 | 早期、不到 10 人、数据少 |
| WSJF | 带时间敏感性的价值交付速度 | 大团队、50+ 人、规模化敏捷 |
| Kano | 区分”惊喜项”和”必备项” | 当你需要搞清用户为什么想要某功能 |
RICE 是最通用、用得最多的——按 ProductLift 对 94 个团队的调查，约 38% 把它选作默认框架。更老练的做法是组合用：Kano 分类需求的性质，RICE 给单个功能打分，story mapping 排发布。
AI 输出怎么接进你的工具链
模型产出一份打好分的清单，工具让它落地、可追溯。像 Productboard 这类做发现和优先级的平台，会把”多少客户提了这个功能、他们的 ARR、它在客服和销售对话里出现多频繁”汇到一起，再把胜出项推进 Jira 或 Linear 去执行。你不用这些工具也行，一张共享表格就够——不能省的是评分必须公开可见。隐藏评分会积怨，公开评分逼出具体反馈。
怎么判断 AI 给的结果能不能直接用
- 每个 reach 数字引用的是你的数据，不是模型编的估值
- 置信低于 100% 的都说明”做什么验证能拉高”
- 前 5 包含你列出的战略必发，即使 RICE 分低
- 后 5 的理由含”什么条件下重新进来”
- 前 5 排序考虑了依赖，不是只看分
容易踩的坑
- 没数据就信 AI 的影响分。 最常见的评分失败。
- 跳过 Confidence。 在没验证的功能上一押就是一整个冲刺。
- 没”观察列”。 世界变化时本该回来的功能被遗忘。
- 一次性评分。 前 5 每冲刺重评、整 backlog 每季度重评；RICE 不是一次性仪式。
- 让 AI 把战略必发压下去。 你写了原因——就守住它。
FAQ
- 哪个 AI 模型最适合做这件事？ 任何前沿模型都能搞定记账部分。Claude Opus 4.7 和 GPT-5.5 都能产出干净、有理有据的 RICE 表；你要它顶的时候，Claude 往往对薄弱数据顶得更狠，这正是这里想要的。
- AI 能替我估工作量吗？ 不能。工作量取决于你的代码库和团队。用 AI 把活拆成子任务，好让你向工程提更准的问题，然后采用他们的数字。
- Kano / MoSCoW / WSJF 呢？ Prompt 结构一样，框架不同。RICE 在产品 / 增长 / 平台间最复用；只有在缺 Reach 数据时才换成 ICE。
- 要不要让整个团队看到评分？ 要。公开评分把含糊的反对变成具体的反对，这正是全部意义所在。
- 多久重评一次？ 前 5 每冲刺一次；整 backlog 每季度一次。
相关
- 功能优先级 Prompt ——更多写法
- 功能优先级 AI ——流程变体
- 工作量优先级 Prompt ——非功能事项
- 技术债务优先级 Prompt ——技术债评分
- PRD 草稿 ——胜出的功能要写 PRD
- 项目计划草稿 ——排好之后排交付
- Roadmap 规划 AI ——多季度视图
标签: #工作流