优先级框架最容易在「会议室里嗓门最大的那位」开口时被玩坏：RICE 数字被灌水、MoSCoW 全部塞进 Must、Kano 里的「惊喜」变成「老板的私心」的婉转说法。下面这套 Prompt 强制模型同时做两件事：诚实套框架、质疑里面的假设，输出能在 planning 会上扛得住的版本。需要完整流程，见用 AI 给功能排优先级。
这套 Prompt 适合用在哪
- 季度 / 半年 Roadmap
- Backlog 超过 30 条的 Sprint scope
- Steering committee 前的 Stakeholder 对齐
- 独立开发者从 30 条里挑下一步 3 件
- PM 面试优先级框架准备
1. RICE 评分 + 置信度标记
下面特性列表（粘贴）。请按 RICE（覆盖 × 影响 × 置信 / 工作量）评分。
- 基于描述给可信数值。
- 每条标置信度（高 / 中 / 低）并写出最大未知点。
- 输出 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 数字当事实，其实只是带置信度的猜测
- 没反优先级清单——每次 backlog grooming 都该明确杀掉一些条目
- 重排没写触发它的「意外」，于是退化成「谁嗓门大谁赢」
- MoSCoW 里 70% 都在 Must——框架已经废了
- 没 kill criterion——东西上线后从来没人决定「停」