优先级框架最容易在「会议室里嗓门最大的那位」开口时被玩坏：RICE 数字被灌水、MoSCoW 全部塞进 Must、Kano 里的「惊喜」变成「老板的私心」的婉转说法。下面这套 Prompt 强制模型同时做两件事：诚实套框架、质疑里面的假设，输出能在 planning 会上扛得住的版本。需要完整流程，见用 AI 给功能排优先级。
一句话总结
- 把 backlog 粘进 Prompt 1–3，先拿到一版 RICE、MoSCoW 或 Kano 排序，每条都带理由。
- 框架数值是固定的：RICE 的 Impact 用 3 / 2 / 1 / 0.5 / 0.25，Confidence 用 100% / 80% / 50%，分值是
(Reach × Impact × Confidence) / Effort。 - Prompt 4–9 专做团队最爱跳过的那部分：砍特性、写 kill criterion、压力测试 Top 1。
- 一条硬规则：让模型「建议」Reach 和 Impact，但 Effort 必须来自工程。没有任何模型懂你的代码库、技术债和迁移风险。
- 当前主流模型都够用。Claude Opus 4.7 和 GPT-5.5（都是 2026 年 6 月版本）给出的理由最有纪律；两者都是 1M token 上下文（Plus 在网页端约容纳 320 页），整个季度的 backlog 一次粘进去没问题。
这套 Prompt 适合用在哪
- 季度 / 半年 Roadmap
- Backlog 超过 30 条的 Sprint scope
- Steering committee 前的 Stakeholder 对齐
- 独立开发者从 30 条里挑下一步 3 件
- PM 面试优先级框架准备
RICE、MoSCoW、Kano 背后的数值
进 Prompt 之前先把刻度钉死，模型才会用标准值，而不是自己瞎编。下面这张表可以直接粘进任何 RICE Prompt 当参照。
| 因子 | 衡量什么 | 标准值 |
|---|---|---|
| Reach（覆盖） | 单位时间内影响的用户 / 事件数 | 原始计数（如 500 用户/季度） |
| Impact（影响） | 对单个用户的影响大小 | 3（巨大）、2（高）、1（中）、0.5（低）、0.25（极小） |
| Confidence（置信） | 对估算有多确定 | 100%（有数据）、80%（部分数据）、50%（凭直觉） |
| Effort（工作量） | 人月数 | 工程给的整数 |
RICE 分值 = (Reach × Impact × Confidence) / Effort。这套框架由 Intercom 的 Sean McBride 提出，Intercom 的原文是权威出处。MoSCoW 把条目分成 Must / Should / Could / Won’t（本周期）。Kano 按满意度曲线分类：基础（缺了难受）、性能（越多越好）、惊喜（出人意料地讨喜）、无差异（没人在乎）。
1. RICE 评分 + 置信度标记
下面是特性列表（粘贴）。请按 RICE 评分，刻度固定如下：
Impact = 3/2/1/0.5/0.25，Confidence = 100%/80%/50%，公式 = (Reach x Impact x Confidence)/Effort。
- 基于描述建议 Reach 和 Impact；Effort 留空，交给工程填。
- 每条标置信度（100/80/50）并写出最大未知点。
- 输出 markdown 表格，按 RICE 分降序。
- 表格后列出 Top 3，再列出"看着不错但置信度低"的 3 条。
[粘贴特性列表]2. MoSCoW + 理由
目标：[goal]。约束：[时间、资源、团队规模]。下面是特性列表。
- 归类 Must / Should / Could / Won't（本周期）。
- 每条 1 行理由，必须挂到上面的目标上。
- 抑制「全部塞 Must」的冲动。Must 超过 30%，重排。
[粘贴特性列表]3. Kano 分类
对每条特性按 Kano 分类：基础（缺了不行）、性能（越多越好）、惊喜（让人爱上）、无差异（没人在乎）。
- 每条 1 行理由，挂到某个用户分群。
- 标出「打着惊喜旗号实则无差异」的条目。
[粘贴特性列表]4. 反优先级清单（先砍再抬）
下面 15 个想法。请砍到 Top 5。
- 被砍的 10 个，从这几个原因里选 1 个：「影响低」「与 [X] 重复」「应该是设置，不是特性」
「过早优化」「目标分群不对」「依赖未就位的基础设施」。
- 留下的 5 个，每个给一句"为什么它配占这个位置"。
[粘贴特性列表]5. 优先级 → Roadmap
给定优先级列表（带粗粒度 T 恤尺寸估算），出 3 个月 Roadmap。
- 按月分组，明确每月容量假设。
- 标依赖风险（特性 B 被 A 卡住）。
- 标过度承诺（占用超过 80% 容量算红线）。
- 末尾一段：本期明确「不做」的事，以及为什么。
[粘贴优先级列表]6. 压力测试 Top 1
我的 Top 1 是 [feature]。压力测试：
- 谁具体受益（哪个分群、什么 job-to-be-done）？
- 谁不在乎，甚至反感？
- 为做它牺牲的容量和注意力是什么？
- Kill criterion——什么指标或信号触发「停，不行」？
- 在全力投入前，测假设最便宜的方法是什么？7. 意外后重排
本季度目标：[goals]。意外事件：[发生什么——竞品发布、流失暴涨、事故、裁员]。
- 重排剩余：留什么、推到下季度、彻底死掉。
- 每条「推后」的，写出能把它拉回来的新触发条件。
- 「死掉」的，诚实写出已经投入的沉没成本。8. Stakeholder 视角重组
我的优先级列表（粘贴）。请为 [CEO / 销售 leader / 工程 leader / 客服 leader] 重组：
- 他们会喜欢什么。
- 会推回什么，原因是什么。
- 我开场要先说的 2-3 句话，用来化解推回。
- 如果对方不让步，我能给的诚实让步是什么。
[粘贴优先级列表]9. Job-to-be-done 交叉核对
对下面每条特性，写出底层 JTBD，格式：「当我 [情境]，我想要 [动机]，以便 [结果]」。
- 标出 JTBD 模糊或写成「用户想要更好的 X」却没情境的条目。
- 按相同 JTBD 分组——同一个 job 的特性其实在抢同一个槽位，应只选 1 个。
[粘贴特性列表]10. 工作量诚实化
工程给的估算（粘贴）。压力测试估算：
- 每条找出最可能把估算炸掉的那块工作（迁移、对接、边界情况、设计反复）。
- 标出「1 周」的估算里藏着 2 周设计或 1 周 QA 的条目。
- 给一个区间，而不是单点数字。
[粘贴工程估算]11. 依赖与排序图
下面 10 条特性（粘贴）。映射依赖：
- A 解锁 B 的关系。
- 共抢同一个共享组件、不能并行的条目。
- 如果只有 2 个工程师做 2 个月，最优顺序。
- 哪些特性切小片就能解锁并行工作。
[粘贴特性列表]12. 季度回顾：优先级本身
上季度我们 ship 了 [N] 个特性（粘贴，每条带它本该推动的指标）。
- 每条：指标动了吗？动了多少 vs 预期？没动的原因是——特性选错、实现错、衡量错？
- 3 段回顾：下季度排优先级时要改的方法。
- 1 段：我们反复在犯的框架误用（RICE 灌水、MoSCoW 膨胀、Kano 洗白）。
[粘贴已上线特性]容易踩的坑
- 把 RICE 数字当事实，其实只是带置信度的猜测。
- 让模型估 Effort。它看不到你的代码库、技术债和团队——Effort 来自工程，不是 LLM。
- 没反优先级清单。每次 backlog grooming 都该明确杀掉一些条目。
- 重排没写触发它的「意外」，于是退化成「谁嗓门大谁赢」。
- MoSCoW 里 70% 都在 Must——框架已经废了。
- 没 kill criterion——东西上线后从来没人决定「停」。
常见问题
这些 Prompt 该用哪个模型？ 当前任何前沿模型都能给出能用的 RICE 或 MoSCoW 排序。截至 2026 年 6 月，Claude Opus 4.7 和 GPT-5.5 给出的理由最有纪律、最扛得住质疑，很少把所有东西都塞进 Must。两者都是 1M token 上下文（ChatGPT Plus 在网页端约容纳 320 页，完整 1M 在 $200 的 Pro 档），整个季度的 backlog 一次粘进去都没问题。
能让 AI 估工作量吗？ 不能。Reach 和 Impact 可以交给模型，因为它们描述的是模型能推理的用户行为。但 Effort 取决于你的代码库、技术债、对接和团队——这些模型都看不到。Prompt 10 是用来「压力测试」工程的估算，绝不是用来生成估算。
模型该用哪套 RICE 数值？
在 Prompt 里把刻度钉死，免得它瞎编：Impact 是 3 / 2 / 1 / 0.5 / 0.25，Confidence 是 100% / 80% / 50%，分值是 (Reach × Impact × Confidence) / Effort。不钉死的话，模型往往会把 Impact 按 1–10 打分、把 Confidence 当成随便的小数，结果不同轮次之间没法横向比较。
怎么防止 MoSCoW 全塞进 Must？ Prompt 2 里那条 30% 上限已经解决大半。如果模型还是把 Must 填爆，追一句：「重排：只有挡住既定目标的条目留在 Must，其余各降一级。」
Kano 和 RICE 能合用吗？ 能，而且是最强组合。先跑 Kano（Prompt 3）给每条特性贴满意度类型标签，再用 RICE（Prompt 1）在各标签内部排序。RICE 分低的基础类特性照样要上——它们是入场门槛，不是可选项。