任务场景
backlog 30+ 条，下一个冲刺要清晰。“团队想做啥就做啥”不是策略。你要一份带评分和理由的清单：前 5 做、后 5 砍 / 延，干系人可以基于”具体那一条”反驳，而不是基于”感觉”。AI 用来当一个结构化的二审，不是当决策者。
哪些情况适合让 AI 来做，哪些情况不要
AI 善于一致地套评分框架（RICE / ICE / Kano）、找出功能间依赖、给每个评分写理由。但它不擅长估”影响”——那需要你的使用数据、win rate、NPS、竞争语境。AI 的置信数字只是占位符，直到你用真实信号替换。
需要给 AI 的输入信息
- backlog + 一句话描述
- 季度目标
- 约束：团队规模、时间、本季度不动的代码区域
- 每条功能的真实影响数据：用户提的次数、客服工单、销售请求、流失原因
- 工程粗估
- 战略必发：哪些功能不看分也必须发，写明原因
可直接复制的 Prompt
为以下 backlog 排优先级。
季度目标：<line>
约束：<列表>
战略必发（带原因）：<列表>
Backlog：
1. <功能> — <描述> — 使用数据：<N 次请求 / 工单 / 销售请求> — 工程估：<小 / 中 / 大>
2. ...
用 RICE 评分：
- Reach：每季度受影响用户数，附计算
- Impact：0.25 / 0.5 / 1 / 2 / 3——解释
- Confidence：50% / 80% / 100%——解释（低置信 = 需要先验证）
- Effort：人月，以我的工程估为锚
请输出：
1. 评分表：功能 / R / I / C / E / 总分 / 理由 / 依赖
2. 本冲刺前 5，含排序
3. 后 5 砍 / 延，附理由
4. "观察列"——3 个分低但数据变化后可能重排的
5. 你评分中最大的风险——哪里你自己也会 push back
6. 哪些功能要先验证再说
不要凭空编 reach 数。我没给数据就标 [需要数据] 并踢出 top 5。平台团队的变体：“同样评分，但 Impact 改成’解锁其它团队的程度’，不是终端用户影响。“
建议让 AI 输出成什么样
可排序表（含 RICE 分量），前 5 排好序，后 5 写明理由，“观察列” 单独标。最后那条”评分最大风险”在 stakeholder review 时是你的护盾。
怎么判断 AI 给的结果能不能直接用
- 每个 reach 数字引用的是你的数据，不是 AI 编的
- 置信低于 100% 的都说明”做什么验证能拉高”
- 前 5 包含你列出的战略必发，即使 RICE 分低
- 后 5 的理由含”什么条件下重新进来”
- 前 5 排序考虑了依赖，不是只看分
容易踩的坑
- 没数据就信 AI 的影响分——最常见的评分失败
- 跳过 confidence——在没验证的功能上花一个冲刺
- 没”观察列”——世界变化时该回来的功能被遗忘
- 一次性评分——RICE 应该每季度重评
- 让 AI 把战略必发压下去——你写了就守住
实操加深
做「用 AI 给功能排优先级：RICE 评分 + 用真实数据 push back」这类任务时，AI 输出质量主要取决于输入包是否完整。至少给它受众、原始材料、目标格式、你要做的决策，以及一好一坏两个参考。第一轮先要求保留事实，第二轮再优化结构、语气或表达，不要让模型一边猜事实一边润色。
拿到结果后单独做一次复核：有没有遗漏限制、编造细节、行动项不清、语气和真实场景不符。最终稿最好能马上使用，包含明确对象、下一步和判断标准，而不是还需要别人重新解释一遍。
FAQ
- Kano / MoSCoW / WSJF 呢？ 结构一样，框架不同。RICE 在产品 / 增长 / 平台间最复用。
- 要不要让团队看到评分？ 要。隐藏评分会积怨；公开评分逼出具体反馈。
- 多久重评？ 前 5 每冲刺一次；整 backlog 每季度一次。
相关
- 功能优先级 Prompt ——更多写法
- 功能优先级 AI ——流程变体
- 工作量优先级 Prompt ——非功能事项
- 技术债务优先级 Prompt ——技术债评分
- PRD 草稿 ——胜出的功能要写 PRD
- 项目计划草稿 ——排好之后排交付
- Roadmap 规划 AI ——多季度视图
标签: #工作流