深夜十二点，后厨的灯还亮着。你是一家餐厅的主厨，桌上堆着厚厚一沓点菜单——有人要麻辣香锅，有人要轻食沙拉，还有人备注“能不能来个惠灵顿牛排”。后厨只有四口锅、六个厨师，明晚就要确定菜单。你不可能把所有菜都端上桌，只能挑出最该做的几道。 需求优先级排序，就是AI产品经理在“后厨”里干的活。用户反馈、老板想法、数据洞察、竞品动态，全是一张张点菜单；开发资源是那四口锅，迭代版本是每晚定稿的菜单。你需要一套方法回答三个问题：哪些菜必须先上？哪些菜可以稍等？哪些菜根本不该出现？ 本文的主角是两个工具：RICE模型——像给每道菜算“做菜性价比”；Kano模型——像按食客口味把菜分为“必点招牌、越做越香、可有可无、黑暗料理”。两者合起来，再加上变更管理和竞品对标，就构成了 AI 产品经理完整的需求优先级排序框架。

岗位关联

掌握这套方法，你能把需求评审从“比谁嗓门大”变成“用分数说话”，让团队心服口服地知道先做什么、后做什么、不做什么。

目录
  1. 可视化演示
  2. RICE评分模型
  3. Kano模型五类
  4. 需求收集分类
  5. better-worse系数
  6. 组合决策矩阵
  7. 需求变更管理
  8. 竞品对标定位
  9. 实战落地流程
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

动态演示需求优先级排序详解与实战指南的核心机制，通过架构/数据/状态/性能四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

需求优先级排序详解与实战指南：RICE RICE模型评分框架 Kano模型需求分类 核心机制可视化 需求优先级排序详解与实战指南整体架构与关键组件

RICE评分模型

主厨的小本子上记着每道菜的四组数字：今晚能接待几桌客人、客人吃到这道菜会多开心、你有几成把握、后厨要忙活几小时。四组数字一乘一除，就得到这道菜「值得现在做」的性价比分数——这就是 RICE 的工作方式。

RICE 是四个英文单词的首字母：Reach 触达度、Impact 影响力、Confidence 信心度、Effort 成本。触达度回答「多少用户会被这个功能影响」，影响力回答「每个受影响用户的变化有多大」，信心度回答「你的估算有多靠谱」，成本回答「团队要投入多少人周」。AI 产品经理常遇到这类选择：先做智能客服的「情绪识别」，还是先做「多轮对话优化」？用 RICE 把直觉变成可比较的数字，争议立刻消解大半。

回到后厨：麻辣香锅能喂饱 200 桌、客人很满意、做法熟练、一刻钟出锅，性价比爆表，今晚就做它；惠灵顿牛排只有 5 桌点、做法生疏、还要两小时，分数低，下周再说。RICE 不会替你拍板，但它让所有人的直觉站在同一把尺子上。

RICE=R×I×CE\displaystyle RICE = \frac{R \times I \times C}{E}
一句话理解：触达用户越多、单个影响越大、把握越足、成本越低，分数就越高，越该先做。
  1. 触达度 R（周期内受影响用户数）估算该功能上线后，一个版本周期能服务多少用户。用户基数大的功能天然占优势。
    R=周期内受影响用户数R = \text{周期内受影响用户数}
  2. 影响力 I（对单个用户的改变强度）用 0.25（轻微）到 3（巨大）打分。比如「夜间模式」对视觉疲劳是 2 分，「语音纠错」可能只有 0.5 分。
    I=3(巨大) 到 0.25(轻微)I = 3(\text{巨大})\ \text{到}\ 0.25(\text{轻微})
  3. 信心度 C（数据支撑程度）0 到 100% 的百分比。有埋点数据支撑给 90%，纯拍脑袋给 40%。信心度越低，算出来的分数越不可信。
    C=可用数据支撑度100%C = \frac{\text{可用数据支撑度}}{100\%}
  4. 除以成本 E（投入人周）包括设计、开发、测试、上线全部工时。除数越大，分数被稀释得越厉害，提醒你「贵菜要慎重」。
    RICE=R×I×CE\text{RICE} = \frac{R \times I \times C}{E}

Kano模型五类

点菜单里有一道「白米饭」。客人不会因为白米饭好吃而夸你，但如果你家没有白米饭，差评能刷满整面墙。这就是食客口味的底层差异——主厨必须把菜分成五类来理解客人的真实情绪。

日本质量管理大师狩野纪昭提出的 Kano 模型，把需求按「有/无」两种状态下用户的反应分成五类：基本型需求（M）是白米饭，没有会不满，有了理所当然；期望型需求（O）是红烧肉，做得越好越满意；兴奋型需求（A）是隐藏惊喜菜，没有无所谓，上了能让人发朋友圈；无差异需求（I）是免费小咸菜，有和没有都没感觉；反向需求（R）是香菜，有人爱有人骂，做了反而得罪人。

Kano 的调研方法很特别：对每个功能要问两个问题——「有这个功能时，你感觉如何？」和「没有这个功能时，你感觉如何？」每个问题五档答案：喜欢、理应如此、无所谓、能忍受、不喜欢。把正反两题的答案组合后查一张映射表，就能把该功能归类。比如「有它很惊喜，没它也能忍」→ 兴奋型；「有它理所当然，没它非常不满」→ 基本型。

回到后厨：你终于明白，为什么客人从不为白米饭点赞，但你要是敢把米饭换成杂粮饭，第二天就有人投诉「怎么没有白米饭」。AI 产品里，「聊天记录不丢失」是基本型——做好了没人夸，丢了全是骂；「AI 帮你写周报」是兴奋型——没有也正常，有了用户到处安利。分清五类，你才知道资源该往哪儿砸。

属性=Kano评价表(正向回答,反向回答)\text{属性} = \text{Kano评价表}(\text{正向回答}, \text{反向回答})
一句话理解：Kano 不是问「你喜不喜欢这个功能」，而是把「有」和「没有」两种情绪对比着问，才能分清这需求是底线、卖点还是雷区。
  1. 设计正反问题同一功能写两个问句，一个问「有」，一个问「没有」，各配五档感受选项。
    Q+:有这个功能感觉如何？Q−:没有它感觉如何？Q_{+}: \text{有这个功能感觉如何？} \qquad Q_{-}: \text{没有它感觉如何？}
  2. 收集回答组合每个用户给出一对答案（正题 + 反题），例如「喜欢」+「不喜欢」。
    (a正, a反)∈{1,…,5}2(a_{正}, \ a_{反}) \in \{1,\dots,5\}^{2}
  3. 查表映射属性把这对答案代入 Kano 评价表，得到 M / O / A / I / R / Q 六类之一（Q 代表回答矛盾，需剔除）。
    属性=表(a正,a反)\text{属性} = \text{表} (a_{正}, a_{反})
  4. 统计占比定类把所有用户的映射结果统计，占比最高的类别即该需求的 Kano 属性。
    P(属性)=被归类为该属性的人数有效回答人数P(\text{属性}) = \frac{\text{被归类为该属性的人数}}{\text{有效回答人数}}

需求收集分类

点菜单不会整整齐齐地送进后厨。它们有的写在前台便签上，有的来自外卖平台评论区，还有的是老板半夜发来的语音——主厨要做的第一件事不是做菜，而是把所有「想做菜的念头」集中到一个草稿本上，这就是需求池。

需求收集渠道五花八门：用户访谈和论坛反馈是「食客现场点单」，客服工单和投诉是「吃完后的吐槽」，数据埋点是「后厨的剩菜统计」，竞品动态是「隔壁餐厅的偷师笔记」，老板和销售的要求是「VIP 客户的指定菜」。AI 产品经理要做的，是把这些零散信息统一格式记进需求池：每条需求写明来源、提出时间、原始描述、预估用户价值。

有了需求池，下一步是分类和统计。分类维度至少有三种：按需求类型分为功能类、体验类、性能类、Bug 修复；按价值维度分为用户价值、商业价值、战略价值；按紧急度分为紧急、重要、一般。分类之后做频次统计——同一个问题被 20 个用户提到，和只有 1 个用户提，权重自然不同。

草稿本满页都是菜名，但主厨知道，写下来不等于要做。需求池的价值在于「先收后筛」——先完整记录，再定量排序。没有这个池子，所有需求都挤在脑子里，每一道菜都像急单，后厨迟早崩溃。

需求权重=提及频次×来源可信度×影响用户规模\text{需求权重} = \text{提及频次} \times \text{来源可信度} \times \text{影响用户规模}
一句话理解：需求权重不是需求优先级，它只是告诉你「这条需求的分量有多重」，为后续 RICE 和 Kano 打分提供原材料。
  1. 提及频次记录同一需求被多少独立用户或渠道提出，频次越高说明群体诉求越强。
    F=独立提及次数F = \text{独立提及次数}
  2. 来源可信度数据埋点和付费客户提的需求比论坛匿名帖更可靠，给 0.5~1.0 的系数。
    S=渠道可信系数S = \text{渠道可信系数}
  3. 影响用户规模估算该需求若被满足，能覆盖当前用户池的百分比。
    U=受影响用户数总用户数U = \frac{\text{受影响用户数}}{\text{总用户数}}
  4. 相乘得权重三项相乘得到需求权重，权重大的需求优先进入 RICE 打分环节。
    W=F×S×UW = F \times S \times U

better-worse系数

光把菜分成五类还不够。两道菜同属期望型，一个能让客人满意 80%，一个只能提升 20%，该先做哪个？于是主厨拿出两个「情绪喇叭」：一个测量「做了能赢多少夸」，一个测量「不做会挨多少骂」——这就是 better-worse 双系数。

better 系数反映做成后的满意度提升潜力，worse 系数反映缺失时的愤怒程度。计算方式是：把 Kano 调研得到的每类人数代入公式。注意 A 和 O 是「加分项」，M 和 O 是「减分项」——期望型 O 同时在两边出现，因为它做得好是亮点，做不好就是槽点。worse 通常是个负数，取绝对值越大，越说明这是保命需求。

四象限怎么用？better 高、worse 低的是兴奋型，优先当营销亮点；better 高、worse 也高的是期望型，是核心竞争区，重点投入；better 低、worse 高的是基本型，底线保障，用最低成本满足即可；better 低、worse 也低的是无差异，直接砍。AI 产品里，「大模型回答无幻觉」是 worse 拉满的基本型，「AI 生成个性化头像」是 better 拉满的兴奋型——两件事不能互相抢资源，但要分得清谁保命、谁出彩。

better=SA+SOSA+SO+SM+SIworse=−SM+SOSA+SO+SM+SI\displaystyle better = \frac{S_A + S_O}{S_A + S_O + S_M + S_I}\qquad\displaystyle worse = -\frac{S_M + S_O}{S_A + S_O + S_M + S_I}
一句话理解：better 越大越该做（做了赢口碑），worse 的绝对值越大越必须先保（不做被骂死）。
  1. 统计属性人数把 Kano 问卷结果按属性归类，数出兴奋型（A）、期望型（O）、基本型（M）、无差异（I）各有多少人。
    SA, SO, SM, SIS_A,\ S_O,\ S_M,\ S_I
  2. 算 better 分子能带来「满意」的是兴奋型 + 期望型，它们占所有非反向属性的比例，就是满意度提升潜力。
    better=SA+SOSA+SO+SM+SIbetter = \frac{S_A + S_O}{S_A + S_O + S_M + S_I}
  3. 算 worse 分子造成「不满」的是基本型 + 期望型，负号代表这是「防止坏情绪」的分数。
    worse=−SM+SOSA+SO+SM+SIworse = -\frac{S_M + S_O}{S_A + S_O + S_M + S_I}
  4. 取绝对值读数worse 绝对值越接近 1，说明缺了它骂声越猛。两类分一组合，需求就能落进四象限。
    ∣worse∣=SM+SOSA+SO+SM+SI|worse| = \frac{S_M + S_O}{S_A + S_O + S_M + S_I}

组合决策矩阵

主厨手里有两份清单：一份是「性价比排行榜」（RICE），一份是「食客情绪分类表」（Kano）。单看任何一份都会做错菜——性价比第一的菜可能是客人根本不 care 的咸菜，情绪拉满的惊喜菜可能贵到做完就破产。所以要做一个「组合决策矩阵」，把两份清单叠在一张纸上。

组合的方式是给两类分数分配权重再相加。先对 RICE 做归一化处理，把它压缩到 0~1 之间，消除量纲差异；再给 Kano 属性一个价值系数，兴奋型给最高分，反向型给负分；最后按产品阶段设定权重——增长期多看重 RICE（性价比），成熟期多看重 Kano（体验差异）。

菜单定稿那晚，主厨把综合分高的菜排进前几页：高 RICE + 高 Kano 的「招牌菜」首批上线；高 RICE + 低 Kano 的「走量菜」排进日常；低 RICE + 高 Kano 的「惊喜菜」放进节假日彩蛋；双低直接划掉。这样排出来的菜单，既照顾营业额，又照顾口碑。

综合分=wR×RICE−RICEmin⁡RICEmax⁡−RICEmin⁡+wK×f(Kano属性)\displaystyle \text{综合分} = w_R \times \frac{RICE - RICE_{\min}}{RICE_{\max} - RICE_{\min}} + w_K \times f(\text{Kano属性})
一句话理解：RICE 管「值不值得投入」，Kano 管「做了对情绪有多大价值」，两者加权相加，得到一张终极菜单排序。
  1. RICE 归一化把所有需求的 RICE 分数压到 0~1，避免某条需求分数过大直接绑架决策。
    RICEnorm=RICE−RICEmin⁡RICEmax⁡−RICEmin⁡RICE_{norm} = \frac{RICE - RICE_{\min}}{RICE_{\max} - RICE_{\min}}
  2. 赋予 RICE 权重默认 0.6，意味着大多数时候性价比还是第一位的；资源宽裕时可下调。
    wR×RICEnormw_R \times RICE_{norm}
  3. 映射 Kano 价值分兴奋型 = 1.0，期望型 = 0.8，基本型 = 0.5，无差异 = 0.2，反向型 = -0.5。
    f(属性)={A:1.0, O:0.8, M:0.5, I:0.2, R:−0.5}f(\text{属性}) = \{A:1.0,\ O:0.8,\ M:0.5,\ I:0.2,\ R:-0.5\}
  4. 加权相加得综合分两类得分相加，所有需求有了同一个总分，按总分排序即可进入排期。
    综合分=wR×RICEnorm+wK×f(属性)\text{综合分} = w_R \times RICE_{norm} + w_K \times f(\text{属性})

需求变更管理

菜单已经印好发给食客了，一位 VIP 客户突然说：「不加这道菜，这桌我就退订。」加还是不加？加，后厨要重新备料，其他菜全部delay；不加，大客户流失。主厨需要的不是纠结，而是一套「加菜申请流程」——这就是需求变更管理。

变更来源很多：老板的突发灵感、大客户的定制要求、数据异常暴露的紧急 Bug、合规政策的新规定。AI 产品经理面对变更，第一步不是拒绝，而是量化「变更影响度」——评估波及多少模块、影响多少用户、拖累多少进度，然后用一个公式把影响变数字。

「加菜申请单」填好后，主厨按规则决策：影响超大且紧急 → 立即开评审会，考虑砍掉其他菜腾出后厨；影响大但不紧急 → 排进下一版菜单；影响小 → 顺手加上。每一次变更决策都要同步给全团队——前厅要知道怎么跟客人解释，后厨要知道备料计划变了。菜单不是不能改，而是改了要有记录、有交代。

影响度=波及模块数模块总数×受影响用户占比100%×预计返工人周版本总人周\displaystyle \text{影响度} = \frac{\text{波及模块数}}{\text{模块总数}} \times \frac{\text{受影响用户占比}}{100\%} \times \frac{\text{预计返工人周}}{\text{版本总人周}}
一句话理解：影响度是三维乘积——改的面积越大、伤的用户越多、返工的活越重，这个变更越要慎重。
  1. 波及模块占比列出需要改动的模块数除以系统总模块数。AI 产品尤其要小心，改一个 Prompt 可能牵动整个对话链路，波及面常常被低估。
    M=波及模块数模块总数M = \frac{\text{波及模块数}}{\text{模块总数}}
  2. 受影响用户占比评估变更会改变多少用户的使用体验。只影响 5% 边缘用户的变更，和影响 80% 主流程的变更，分量完全不同。
    U=受影响用户数总用户数U = \frac{\text{受影响用户数}}{\text{总用户数}}
  3. 进度损失系数估算返工人周占当前版本总人周的比例。已开发完的功能被推翻重做，代价要计入变更成本。
    P=预计返工人周版本总人周P = \frac{\text{预计返工人周}}{\text{版本总人周}}
  4. 乘出影响度三项相乘，得到 0~1 之间的影响度。超过 0.5 的变更必须走正式评审，低于 0.2 的可以搭车处理。
    影响度=M×U×P\text{影响度} = M \times U \times P

竞品对标定位

隔壁餐厅新出了一道「分子料理冰淇淋」，门口排起了长队。你的店员着急：老板，我们也上吧！主厨却先夹起一块尝了尝：这道菜成本高、翻台慢、目标客群是追求新鲜的年轻人，而你家主打家庭聚餐——抄它？大概率亏本。竞品对标不是为了跟风，而是为了找「差异化机会」。

竞品对标分四步走。第一步是需求拆解：把竞品功能拆成需求要素。比如竞品 AI 助手有「实时语音对话」，拆开看，它其实是「低延迟语音识别 + 大模型对话 + 打断控制」三个子需求的组合。第二步是功能矩阵对比：画一张表，左侧列需求要素，顶行列自家和竞品，逐项标记「有/无/弱」；第三步是找差异化机会：优先关注「竞品没有 + 我方 Kano 价值高」的格子，那里是突破口；第四步是判断时机：竞品刚上且口碑好，你跟进叫「补短板」；竞品已经做烂了，你再做只能「帮人擦屁股」。

机会分=(1−竞品覆盖度)×Kano价值系数\displaystyle \text{机会分} = (1 - \text{竞品覆盖度}) \times \text{Kano价值系数}

1. 竞品覆盖度：计算竞品在某个需求要素上的完成度，1 表示做得很好，0 表示完全没做。

2. 取缺失部分：1 - 覆盖度 越大，说明该要素的市场空白越大。

3. 乘以 Kano 价值：空白需求还得有价值才值得做，乘以 Kano 价值系数（兴奋型 1.0，期望型 0.8，基本型 0.5）。

4. 按分数排序：机会分最高的几个要素，就是差异化投入的候选方向；分低的要素即使竞品有，也不用着急跟。

隔壁的冰淇淋再火，也不该让家庭餐馆改卖甜品。AI 产品同理：竞品做出了「AI 写小红书文案」，但你的目标用户是程序员，他们更需要「AI 写代码注释」——机会分很快算出来，后者远高于前者。对标的意义不是「你有我也要有」，而是「你没做的、我用户又想要的，才是我的机会」。

P竞品∈[0,1]P_{\text{竞品}} \in [0, 1]
1−P竞品1 - P_{\text{竞品}}
机会分=(1−P竞品)×f(属性)\text{机会分} = (1 - P_{\text{竞品}}) \times f(\text{属性})
排序后选择Top要素\text{排序后选择Top要素}

实战落地流程

从一大摞点菜单到最终端上桌的菜，中间是一条完整的出菜流水线：验菜、排单、上桌、复盘。需求优先级排序也一样，不是开会两小时就能定死的事，而是一个滚动循环——验证价值、安排排期、复盘指标、动态调整。

第一步，需求价值验证。在正式投入开发前，用最低成本验证需求真伪：小范围内测、原型点击测试、问卷调研。AI 产品还要特别验证「技术可行性」——比如「实时语音转写」的延迟能否达到预期，模型效果是否撑得起功能。验证通过才进入 RICE 和 Kano 打分流程，避免把高分给了一个伪需求。第二步，版本规划排期。按综合分把需求分进 P0（本迭代必做）、P1（下个迭代做）、P2（观察池），和研发对齐工作量。第三步，复盘指标设计。上线前就定好衡量标准：功能使用率、任务完成率、NPS 变化、用户留存提升，用数据验证当初的 RICE 估算准不准。第四步，动态调整。把复盘结果带回需求池，重新打分——表现超预期的需求提权重，低于预期的降权重，市场变化触发新的需求入池。

一家好餐厅的菜单每个月都在变：上个月的爆款「芝士焗红薯」这月乏人问津，就被换成了新研发的「芋泥啵啵」。AI 产品的需求优先级同样如此——你排的 P0 不是圣旨，而是「基于当前信息的最佳猜测」。保持循环，让数据说话，你的菜单才会越排越精准。

滚动优先级=复盘信号→重新打分→重排P0/P1/P2\text{滚动优先级} = \text{复盘信号} \rightarrow \text{重新打分} \rightarrow \text{重排P0/P1/P2}
一句话理解：需求优先级是活的，每次上线后的数据都会回流到需求池，让下一轮的排序更准。
  1. 复盘信号触发上线后把实际数据与预估对比，偏差大的需求成为「待重评」信号。
    Δ=实际指标−预估指标预估指标\Delta = \frac{\text{实际指标} - \text{预估指标}}{\text{预估指标}}
  2. 重新打分把复盘信号带入 RICE 的信心度（C），数据越真实，信心度越高，分数越可信。
    C新=min⁡(1.0, C旧+∣Δ∣)C_{\text{新}} = \min(1.0,\ C_{\text{旧}} + |\Delta|)
  3. 重排优先级所有需求按新分数重新计算综合分，P0/P1/P2 顺位随之变化。
    排序=sort(综合分新)\text{排序} = \text{sort}(\text{综合分}_{\text{新}})
  4. 周而复始每个迭代重复验证-打分-排期-复盘循环，需求池永远保持最新鲜的排序。
    循环:V→R→P→E→V\text{循环}: V \rightarrow R \rightarrow P \rightarrow E \rightarrow V

AI 应用场景

智能客服功能排期：先做情绪识别还是多轮优化？

阶段：需求分析与版本规划

解决的问题：AI 产品团队常为「先做哪个 AI 能力」争论不休。情绪分析派说要做共情，多轮优化派说要做上下文。没有量化方法时，只能比嗓门大，做完才发现用户根本不 care。

具体案例：某智能客服产品经理用 RICE 分析：「多轮上下文优化」触达 60 万月活用户、影响力 3、信心度 80%、成本 8 人周，得分 18 万；「情绪识别」触达 60 万、影响力 1、信心度 50%、成本 10 人周，得分 3 万。再叠加 Kano 问卷发现，多轮优化是期望型（better 高），情绪识别是兴奋型——最终决定多轮优化进 P0，情绪识别作为 P1 彩蛋功能。

大模型功能裁剪：Kano 调研识别伪需求

阶段：需求验证与范围控制

解决的问题：大模型能力越来越强，产品团队容易陷入「什么都能做，结果什么都做不好」的陷阱。需要一套方法识别「伪需求」——看起来酷炫但没有用户买单的功能。

具体案例：一款 AI 写作助手计划加入「AI 生成藏头诗」功能。产品经理用 Kano 双向问卷调研 200 名目标用户，结果显示 60% 的回答落进「无差异需求」，better 系数仅 0.2，worse 系数仅 0.1。RICE 得分再高，进入组合矩阵后 Kano 权重一拉，总分依然垫底——该功能被砍掉，资源转投「AI 查重改写」。

模型升级引发的需求变更管理

阶段：迭代发布与变更控制

解决的问题：底层大模型版本升级后，原本「成本高、效果差」的需求可能突然变得「便宜又好用」，触发需求池重新洗牌。传统需求变更流程不识别这类技术驱动变更，容易错失机会或造成返工。

具体案例：某 AI 翻译产品原计划用 20 人周自研「古文翻译引擎」，因成本过高排在 P2。新模型 API 上线后，产品经理用影响度公式重新评估：波及模块 2/12、影响用户 82%、返工人周仅 2/30，影响度仅 0.27——低于阈值，直接搭车实现，原 P2 需求一跃成为下版本主打功能，为公司省下 18 人周成本。

Python 演示

python75 行
# -*- coding: utf-8 -*-"""RICE + Kano 需求优先级排序演示""" RICE_WEIGHT = 0.6    # RICE 权重KANO_WEIGHT = 0.4    # Kano 权重KANO_VALUE = {'M': 0.5, 'O': 0.8, 'A': 1.0, 'I': 0.2, 'R': -0.5, 'Q': 0.0} # Kano 评价表: (正问题答案, 反问题答案) -> 属性# 答案: 1=喜欢 2=理应如此 3=无所谓 4=能忍受 5=不喜欢KANO_TABLE = {    (1, 1): 'Q', (1, 2): 'A', (1, 3): 'A', (1, 4): 'A', (1, 5): 'O',    (2, 1): 'R', (2, 2): 'I', (2, 3): 'I', (2, 4): 'I', (2, 5): 'M',    (3, 1): 'R', (3, 2): 'I', (3, 3): 'I', (3, 4): 'I', (3, 5): 'M',    (4, 1): 'R', (4, 2): 'I', (4, 3): 'I', (4, 4): 'I', (4, 5): 'M',    (5, 1): 'R', (5, 2): 'R', (5, 3): 'R', (5, 4): 'R', (5, 5): 'Q',}  def rice_score(reach, impact, confidence, effort):    """RICE 得分 = 触达度 x 影响力 x 信心度 / 成本"""    return reach * impact * confidence / effort  def kano_mapping(positive, negative):    """单个用户的正反回答 -> Kano 属性"""    return KANO_TABLE.get((positive, negative), 'Q')  def better_worse(counter):    """输入属性计数 dict, 返回 (better, worse)"""    total = sum(v for k, v in counter.items() if k in 'MOAI')    if total == 0:        return 0.0, 0.0    better = (counter.get('A', 0) + counter.get('O', 0)) / total    worse = -(counter.get('M', 0) + counter.get('O', 0)) / total    return better, worse  def main():    demands = [        {'name': '夜间模式', 'reach': 8, 'impact': 2,         'confidence': 0.8, 'effort': 2,         'answers': [(1, 3), (1, 2), (2, 3), (1, 4), (1, 2)]},        {'name': '数据报表', 'reach': 6, 'impact': 2,         'confidence': 0.9, 'effort': 3,         'answers': [(2, 5), (2, 4), (3, 5), (2, 5), (1, 5)]},        {'name': '语音输入', 'reach': 5, 'impact': 3,         'confidence': 0.6, 'effort': 6,         'answers': [(1, 5), (1, 4), (1, 3), (2, 4), (1, 2)]},        {'name': '节日皮肤', 'reach': 3, 'impact': 1,         'confidence': 0.4, 'effort': 2,         'answers': [(3, 3), (3, 4), (4, 3), (3, 3), (4, 4)]},    ]    max_rice = max(rice_score(d['reach'], d['impact'], d['confidence'], d['effort'])                   for d in demands)    results = []    for d in demands:        r = rice_score(d['reach'], d['impact'], d['confidence'], d['effort'])        counter = {}        for pos, neg in d['answers']:            attr = kano_mapping(pos, neg)            counter[attr] = counter.get(attr, 0) + 1        b, w = better_worse(counter)        kano_attr = max(counter, key=counter.get)        norm_rice = r / max_rice        score = RICE_WEIGHT * norm_rice + KANO_WEIGHT * KANO_VALUE[kano_attr]        results.append((score, d['name'], round(r, 2), round(b, 2),                        round(w, 2), kano_attr))    for score, name, r, b, w, attr in sorted(results, key=lambda x: -x[0]):        print('%-6s 综合分%.3f | RICE=%-5s | better=%-4s | worse=%-4s | %s'              % (name, score, r, b, w, attr))  if __name__ == '__main__':    main()
目的：演示完整的需求优先级排序流水线——先算每个需求的 RICE 分数，再把 Kano 问卷回答映射为属性，计算 better/worse 双系数，最后用加权综合分输出最终排行榜。
  1. demands = [...]定义 4 条需求，每条含 RICE 四要素和一组正反问卷答案，相当于后厨草稿本上的四张点菜单。
  2. rice_score(...)实现 RICE 公式 R×I×C÷E，投入产出比一目了然。
  3. KANO_TABLE = {...}Kano 评价映射表，把「有/无」两种感受组合翻译成属性，是口味的翻译机。
  4. kano_mapping(pos, neg)查表得到单个用户对某功能的属性判断，如 (1,3) 是兴奋型（A）。
  5. better_worse(counter)计算 better 和 worse 双系数，分子的 A/O/M 组合对应「加分」与「保命」。
  6. norm_rice = r / max_riceRICE 归一化到 0~1，消除不同需求之间的量纲差距，否则分数悬殊会绑架排序。
  7. score = RICE_WEIGHT * norm_rice + KANO_WEIGHT * KANO_VALUE[kano_attr]组合决策矩阵的核心公式，把性价比和情绪价值捏成一个总分。
  8. sorted(results, key=lambda x: -x[0])按综合分降序输出终榜，就是那张定稿菜单。

常见误区

误区我算出来这个需求 RICE 分最高，那它就是铁打的 P0，不管什么时候都得先做它，分数摆在那里还能有错？

正解RICE 是「当时当下」的快照，不是永久承诺。信心度 C 会随数据积累变化，市场环境变了触达度 R 也会变；更关键的是，如果 C 只有 40%，算出来的高分可能只是错觉——就像一道菜你觉得客人会喜欢，是没尝过的瞎猜。每次迭代前都要重新校准 C，把新数据带回公式重算。

为何常见：人天生喜欢「确定性」——一个数字让人觉得排期有了依据，便不再回头质疑数字本身的假设。

误区Kano 说基本型需求「没有会被骂」，那不是天大的事吗？当然要把它排在最前面，投入最多资源把它做到极致。

正解基本型是「入场券」不是「加分项」：做好了用户无感，做不好用户暴怒。正确策略是用最低成本满足底线，把精兵强将投到期望型和兴奋型上。就像白米饭——你要保证它稳定供应、品质不翻车，但没必要花大价钱研究「分子米饭」，红烧肉才是客人复购的理由。

为何常见：把「缺失后果严重」误读成「做好了收益巨大」，混淆了「防御性需求」和「进攻性需求」的本质区别。

误区worse 算出来是负数，那越接近 0 越好？所以 worse = -0.2 比 worse = -0.8 更值得做？

正解worse 前面的负号只是方向标记，代表「缺失导致的负面情绪」。比较两个需求时，要比的是绝对值：|−0.8| > |−0.2|，说明前者缺失时骂声更猛，更应该优先保障。可以把它理解为「失分风险值」——分越大，风险越不能碰。

为何常见：直觉上「正数比负数好」，看到负号就本能地想避开，忽略了负号在这里只是符号约定而不是优劣排序。

误区Kano 不就是问用户喜不喜欢这个功能吗？直接问「你要不要 AI 写周报」，大多数人都会说想要，做就是了。

正解Kano 的灵魂是「双向提问」：必须同时问「有这个功能时你的感受」和「没有它时你的感受」，再对照映射表归类。单问「喜不喜欢」，只能得到一堆「想要」，分不清是底线、卖点还是伪需求——就像只问客人「爱不爱吃辣」，却不知道他能不能接受菜里没盐。

为何常见：习惯了常规问卷的「满意度打分」思路，没理解 Kano 的那个「没有它」的对照组，才是区分需求属性的关键镜头。

面试题

Q1. RICE 中的 R 指什么？

单选题 · easy

  • A.触达度← 正确答案
  • B.回报率
  • C.需求数量
  • D.研发成本

答案：A。R 是 Reach 触达度，代表一个版本周期内受该功能影响的用户数。它衡量的是「这个功能能覆盖多少人」，而不是投资回报或需求数量。就像主厨先看一道菜能端给几桌客人，桌数越多，菜的潜在影响力越大。

Q2. RICE 综合得分的正确公式是？

单选题 · easy

  • A.(R×I×C)÷E← 正确答案
  • B.(R+I+C)÷E
  • C.R×I÷(C×E)
  • D.(R+C)÷I×E

答案：A。RICE = （触达度 × 影响力 × 信心度） ÷ 成本。三个要素在分子上相乘体现「扩大收益」，成本在分母上体现「控制投入」。选 C 的同学把信心度放到了分母，相当于越没把握分数越高，逻辑就反了。

Q3. 某功能触达 50000 用户、影响力 3、信心度 80%、成本 4 人周，该需求的 RICE 分数是多少？

单选题 · mid

  • A.30000← 正确答案
  • B.60000
  • C.15000
  • D.75000

答案：A。套公式 50000 × 3 × 0.8 ÷ 4 = 30000。关键是信心度 80% 要化成 0.8 再乘，成本放在分母。这就像一道菜：喂饱的桌数 × 满意度 × 把握程度，再除以备料工时，才是性价比。

Q4. 在 Kano 模型中，「没有它用户会不满，有了它用户觉得理所当然」属于哪类需求？

单选题 · mid

  • A.基本型需求← 正确答案
  • B.期望型需求
  • C.兴奋型需求
  • D.无差异需求

答案：A。这是基本型需求（M）的典型特征——好比餐厅的白米饭，吃到了不觉得惊喜，缺了马上投诉。期望型是「有了越做越满意」，兴奋型是「没有无所谓，有了很惊喜」，无差异是「有和没有都没感觉」。

Q5. 下列哪些属于 Kano 模型的五类属性？（多选）

多选题 · mid

  • A.基本型需求← 正确答案
  • B.期望型需求← 正确答案
  • C.反向需求← 正确答案
  • D.滞后需求

答案：ABC。Kano 五类是基本型（M）、期望型（O）、兴奋型（A）、无差异（I）、反向（R）。「滞后需求」不是 Kano 术语，属于技术采用周期里的概念。反向需求也要记住：香菜对某些人是加分，对另一些人就是劝退，这类需求做了反而得罪用户。

Q6. better-worse 双系数中，worse 的绝对值越大说明什么？

单选题 · mid

  • A.缺失时不满越严重，越要保证← 正确答案
  • B.做出来后满意度提升越大
  • C.用户对该功能完全无感
  • D.该功能是明确的伪需求

答案：A。worse 本身是负值，绝对值越大代表「没有它时的负面情绪越强烈」——这是基本型和期望型需求的信号，必须优先保障。better 才对应「做出来后满意度提升」。把 worse 绝对值当失分风险值，越大越要防。

Q7. 组合决策矩阵中，RICE 归一化的主要目的是什么？

单选题 · mid

  • A.消除量纲差异，避免分数悬殊绑架排序← 正确答案
  • B.把所有需求分数变为负数
  • C.让 RICE 分数等于 Kano 分数
  • D.提高计算速度

答案：A。RICE 原始分数可能从几到几十万，直接和 Kano 价值系数（0~1）加权相加，RICE 会彻底掩盖 Kano 的贡献。归一化到 0~1 后，两个维度才有公平对话的资格——就像把「桌数」和「好评率」都换算成百分制再比。

Q8. 需求变更管理中，对「紧急且影响大」的变更应如何处理？

单选题 · easy

  • A.插入当前迭代并走变更评审← 正确答案
  • B.一律延后到下个版本
  • C.悄悄做不告知团队
  • D.只更新文档不改计划

答案：A。紧急且影响大的变更（如数据合规要求、核心链路故障）需要立即走变更评审，必要时砍掉当前迭代的低优需求腾出资源。延后可能酿成更大事故，悄悄做会破坏团队信任，只改文档不落实更是自欺欺人。

Q9. 竞品对标时，哪些情况下「竞品有、我也要有」的判断是错的？（多选）

多选题 · hard

  • A.该功能只是竞品的兴奋型亮点，与你的产品定位无关← 正确答案
  • B.你的目标用户对该功能毫无感知← 正确答案
  • C.竞品功能实现成本极低
  • D.你的 Kano 调研显示该需求是无差异或反向← 正确答案

答案：ABD。跟风前要算「机会分」。竞品做得好不代表你的用户需要——如果这功能在竞品是兴奋型亮点、你的用户是务实型人群、Kano 调研又显示无差异，抄过来只是浪费资源。选项 C 成本低反而是「可以做」的理由，不是「不能抄」的理由。

Q10. 需求 X：触达 10 万、影响 2、信心 60%、成本 5 人周；需求 Y：触达 4 万、影响 3、信心 80%、成本 3 人周。按 RICE 应优先做哪个？

单选题 · extreme

  • A.优先做需求X
  • B.优先做需求Y← 正确答案
  • C.两者分数相同
  • D.信息不足无法计算

答案：B。X = 100000 × 2 × 0.6 ÷ 5 = 24000；Y = 40000 × 3 × 0.8 ÷ 3 = 32000。Y 虽然触达用户少，但影响大、信心足、成本低，综合性价比反而更高。这提醒我们：别被「用户基数大」迷惑，RICE 是四项指标的合力，不是单看触达量。