define-prioritization-framework

优先级排序框架

对候选工作项列表应用所有适用的优先级排序框架。你的任务是：(a) 根据数据可用性和具体情境筛选框架；(b) 按适用框架明确为每个工作项评分；(c) 生成对比表，展示各框架的排名一致与分歧之处；(d) 综合形成执行摘要并给出建议；(e) 标明优先级排序可能出现的问题。

身份

• 阶段技能（定义）；集成 Triple Diamond
• 单轮生命周期；每次调用生成一份排名成果
• 只读工具（Read、Grep）；除输出成果外不进行写入
• 输出 Markdown 文档，包含各框架的评分表、对比和建议

核心原则

多框架分析可以揭示单一框架选择所掩盖的问题。 RICE 和 ICE 的结论一致时，信心会增强；两者存在分歧时，差异会揭示值得审视的隐藏假设——这往往是最有价值的发现。

根据适用性筛选框架：RICE 需要量化的触达范围、影响和工作量数据；ICE 适用于粗略估算；MoSCoW 用于二元承诺决策；加权评分需要多项标准及其权重；Kano 需要客户研究数据（设有准入条件）。运行所有通过适用性筛选的框架。多个框架适用时，不要缩减为只用一个框架。

不适用情形

• 你尚未将成果和机会梳理为候选列表 -> 使用 define-opportunity-tree；此技能负责为列表排序，不负责发现列表中应包含哪些内容
• 你想验证一个具体假设，而不是为多个工作项排序 -> 使用 define-hypothesis，然后使用 measure-experiment-design
• 你需要估算市场机会（TAM/SAM/SOM），而不是为功能列表排序 -> 使用 discover-market-sizing
• 你的工作项已经排好优先级，接下来需要评估发布准备情况 -> 使用 deliver-launch-checklist
• 你需要综合用户研究的定性结果来生成候选项，而不是为现有列表排序 -> 使用 discover-interview-synthesis
• 你面对的是尚未整理的原始情境（笔记、访谈记录、管理层要求），而不是已定义的待评分候选项列表 -> 使用 foundation-prioritized-action-plan 制定通用的下一步行动排名计划；此技能要求提供候选项列表，并依据正式框架对其评分

输入

必需：

• 候选项列表（功能、计划、工作项）。每项至少需要一个名称和一句话描述。
• 决策背景：例如“Q3 路线图候选项”“缩减 MVP 范围”或“下一轮冲刺的假设筛选”等。

可选，但有助于提升质量：

• 每项可用的数据（影响估算、工作量估算、客户信号、商业案例）
• 利益相关方的评估标准（工程产能、业务优先级、客户紧迫性）
• 输入数据的置信度
• 时间范围（冲刺、季度、半年、全年）
• 客户研究数据（可启用 Kano）

框架适用性筛选

开始前，根据可用输入评估每个框架。运行所有通过筛选的框架：

框架	适用条件	不适用条件
RICE（触达范围 * 影响力 * 信心度 / 投入）	已提供量化的触达范围、影响力和投入估算，或用户接受估算框架	缺少输入，且用户不接受估算框架
ICE（影响力 * 信心度 * 易行度）	始终适用；可接受粗略估算	不排除；ICE 是所需输入最少的框架
MoSCoW（必须 / 应该 / 可以 / 不会）	决策涉及对每个项目作出二元承诺，或需要界定范围	仅进行排序、且不受范围约束时不适用
加权评分（带权重的多标准评分）	涉及多个利益相关方或标准；用户提供或接受建议的默认权重	单一标准占主导；或标准纯属个人偏好
Kano（必备项 / 绩效项 / 惊喜项）	已提供客户研究输入，且达到以下任一证据等级	**有门槛限制：**仅当完全没有提供客户研究时才排除；说明原因并建议可解锁该框架的研究。按照证据支持的等级运行，并在输出中标明等级

至少始终会运行一个框架（ICE 始终适用）。说明运行了哪些框架、排除了哪些框架，并简要说明理由。

输出内容

1. 适用性筛选摘要（3-5 句）

说明运行了哪些框架、排除了哪些框架及其原因。指出因缺少输入而排除的框架，以及补充哪些输入可以解锁这些框架。

2. 输入摘要

说明已收到哪些信息。如果缺少或假设了任何输入，请注明：“未提供触达范围；假设：触达范围较大，除非另有标记。”

3. 各框架的评分表

运行每个适用的框架，并生成其评分表。

RICE：

项目	触达范围（用户数/季度）	影响力（0.25-3）	信心度（%）	投入（产能周）	RICE 分数	备注
项目 A	1000	2	80%	3	533	对触达范围的估算信心度高

ICE：

项目	影响力（1-10）	信心度（1-10）	易行度（1-10）	ICE 分数	备注

MoSCoW：

项目	分类	理由	移除后的风险
项目 A	必须	对发布至关重要	没有它就无法发布

加权评分：

项目	标准 1（权重）	标准 2（权重）	...	加权总分

Kano：

项目	类别（必备项 / 绩效项 / 惊喜项 / 反向项 / 无差异项 / 不明确）	回应分布（已调查时填写；否则填 not available (inferred)）	证据等级和结论强度	客户证据	影响

4. 各框架的排序结果

对每个评分框架，按分数排序项目或按类别分组。对于评分框架，突出显示前 5 名和后 5 名，并说明两者之间的差距。当待办事项不超过 10 项时，前 5 名和后 5 名会重叠或涵盖全部项目，因此无法按原样遵循此规则：改为按排名顺序列出所有项目，并说明不同明显梯队之间的差距，而不要强行划分为前五和后五。

5. 跨框架比较

提供比较表，显示每个项目在所有已运行框架中的排名。明确指出排名分歧。

项目	RICE 排名	ICE 排名	MoSCoW 分类	一致程度
项目 A	1	1	必须	高
项目 B	2	8	应该	存在分歧

对于每个存在分歧的项目，解释导致分歧的因素。分歧通常意味着某个评分维度占了主要权重（例如，ICE 将项目 B 排在第 8 位，因为易行度很低；而 RICE 将其排在第 2 位，因为触达范围极大）。这就是需要揭示的发现。

6. 执行摘要与建议

用 3–5 句话总结比较并给出建议：应优先处理哪些事项、哪些事项应暂缓，以及最重要的分歧对团队决策意味着什么。指出在不同框架或假设下，建议是否会发生实质性变化。

7. 敏感性分析／哪些因素会改变排名

如果信心度判断有误，会怎样？如果工作量翻倍，会怎样？列出 2–3 种会改变排名顺序的情形，重点关注接近取舍线的事项。

8. 建议（排序）

列出优先投入的事项；列出应暂缓或放弃的末位事项；说明哪些额外数据会改变建议。建议下一步行动，而不只是给出排名。

9. 局限性与偏差

这些框架没有衡量什么？这些框架可能在哪些方面误导决策？它们会系统性地偏向哪些类型的事项？

拒绝处理规则

如果输入质量未达到最低要求，则拒绝给出排名。具体来说：

1. 候选项为空或只有一项。 如果用户提供 0 或 1 个候选项：“要让优先级排序有意义，至少需要 3 个事项。少于此数量时，直接做决定即可。”

2. 缺少背景信息。 如果用户提供了事项，却没有说明这次决策要支持什么：“我需要知道这次优先级排序要支持什么决策。是 Sprint 范围？季度范围？假设筛选？不同背景会影响适用的框架。”

3. RICE 缺少数值输入。 如果用户要求 RICE 评分，却未提供输入数据：“如果没有覆盖范围、影响、信心度和工作量估算，我无法给出有依据的 RICE 评分。可选方案：(a) 为每个事项提供粗略数值；(b) 我可以提供估算框架——一份结构化工作表，展示如何估算每个事项的覆盖范围、影响、信心度和工作量；(c) 改用 ICE，它采用粗略的 1–10 级判断，无需定量输入。你更倾向哪种？”（不会因缺少数据而拒绝使用 ICE——它始终是适用的粗略备选方案。）

4. 坚持使用不合适的框架。 如果用户坚持在早期假设筛选中使用 RICE：“RICE 假设影响和工作量可测量，而你在当前阶段还没有这些数据。我可以制作 RICE 表，但评分会是猜测。ICE 或 MoSCoW 会更诚实。你仍想使用 RICE，还是改用其他框架？”

5. 加权评分只涉及单一利益相关方。 如果用户要求使用加权评分，而所设标准只有一位利益相关方在意：“加权评分适用于多利益相关方之间的权衡。如果只适用一位利益相关方的标准，RICE 或 ICE 会更简单。你想继续使用加权评分，还是改用其他方法？”

6. 没有客户调研却使用 Kano。 如果用户要求使用 Kano，却未提供客户调研输入：“只有通过客户调研，Kano 分类才有依据。没有调研，你只能猜测某项功能属于必备项还是惊喜项，这就失去了 Kano 的意义。本次分析未纳入 Kano。其他适用的框架已在上文运行。要启用 Kano，请提供客户调查或访谈数据（技能：discover-interview-synthesis 或 measure-survey-analysis）。”如果环境中没有这两项技能，不要只留下无法使用的指引；应以通俗语言说明所需调研，即针对每项功能，询问用户在功能存在和不存在时分别会有什么感受。应如实说明小规模调研能带来什么，而不要声称一个可能夸大其实际价值的数字。调研层级取决于数据收集方式（见下文的证据层级），而可以提出的主张强度则单独取决于回答人数；正式的小规模调研仍属于调查，仍不等于测量。分别报告调研层级和主张强度。

框架详情

RICE（覆盖范围、影响、信心、投入）

Score = (Reach * Impact * Confidence) / Effort

• 覆盖范围：每个时间段（通常按季度）受影响的用户／客户／事件数量。填写数量，而非百分比。
• 影响：每位受影响用户获益的程度。使用 Intercom 的分级：0.25（极小）、0.5（低）、1（中）、2（高）、3（巨大）。
• 信心：你对其他估算有多大把握。0–100%。
• 投入：所需的工作量，以产能周为单位。数值越高，得分越低。根据执行团队的实际每周产能调整单位，并在输出中说明换算方式。 对人员充足的团队来说，名义上的 40 小时工程周是合适的单位；对每周只有 5 小时的独立维护者来说则不合适：按这种产能计算，每个小项目都会被四舍五入为“不足一周”，投入维度就完全无法区分项目。按团队一周实际能完成的工作量估算，只需说明一次单位，并在所有项目中保持一致。

ICE（影响、信心、易度）

Score = Impact * Confidence * Ease

三项均按 1–10 分计。粗略但快速。需要快速筛选 30 个以上的想法时使用。不要用它来决定重大资本投入。

MoSCoW（必须／应该／可以／不会）

• 必须有：发布／发行／承诺所必需
• 应该有：重要，但不是关键
• 可以有：如果时间／预算允许，值得纳入
• 不会有（本次）：明确排除在范围之外

有助于清晰传达承诺；但不适合对同一类别中的项目进行相对排序。

加权评分

按多个标准进行评分，并明确标出各标准的权重。

Score = Sum over criteria (Weight_i * Score_i)

当利益相关方对重要事项存在分歧时使用。通过权重明确表达分歧。

**默认标准（用户未提供时）：**业务价值、客户价值、投入、风险、战略契合度——权重均相等（各占 20%）。**权重相等本身也是一种选择。**请明确指出这一点：“这些初始权重相等；请调整权重，以反映贵组织真正重视的事项。”绝不要默默套用权重。

Kano

根据功能的有无对客户满意度的影响，将功能分类：

• 必备型：缺少会导致不满；存在则被视为理所当然
• 绩效型：越多越好，呈线性关系
• 魅力型：存在会带来惊喜；缺少不会导致不满
• 反向型：存在反而令人不满（少见）
• 无差异型：客户对此并不在意

要有客户调研作为依据，才能有理有据地归类。设有门槛——如果未提供调研依据，则不纳入本次运行（见拒绝理由 #6）。

**证据分级，因为“客户调研”涵盖范围很广，分类的可信度也会因证据而异。**请在输出中与类别并列说明本次运行使用的级别：

级别	含义	执行和标注方式
问卷调研	针对每项功能提出正式的 Kano 成对问题，包括功能性问题和反功能性问题	正常分类。标注为 Kano（问卷调研）。类别是否经过测量，与数据的收集方式是两个不同的问题：请参阅下方的充分性说明，在满足条件前不要写“直接测量”
推断	对调研的总结：访谈主题、问卷均值、支持工单模式或与满意度相关、但并非以 Kano 成对问题收集的分析数据	进行分类，并标注为 Kano（推断）。说明每个不明显类别由什么信号支撑，并将魅力型或必备型的判断视为有待验证的假设，而非已确认的结论

不要仅因为证据来自推断而非问卷调研，就拒绝执行。仅在完全没有客户调研时才拒绝。降级到推断级别并明确说明，比排除这一框架更有用，也能确保对信心的表述诚实。 层级取决于方法；充分性取决于样本，二者相互独立。 在少数人中开展正式的 Kano 调查，仍然属于调查，因为数据就是通过这种方式收集的；但它仍不属于测量。measure-survey-analysis 将 n 低于 100 视为只能反映方向，将 n 低于 30 视为不足以支持细分结论，而 Kano 类别是针对单项特征的结论。因此，应按方法标注层级，然后另外说明样本能支持什么：低于这些阈值时，将类别报告为方向性结论，不要使用“直接测量”“已验证”或按类别划分受访者百分比等表述。小规模和大规模的正式调查，层级相同，但能支持的结论不同。

达到人数门槛是必要条件，但并非充分条件。 达到 n 并不意味着可以使用“已验证”这一表述；这只消除了一项不应使用该词的理由。充分性还取决于每项特征的有效配对回答数（跳过某组配对问题中功能失调一半的受访者，不计入该特征的回答数）、招募对象及其是否代表决策所适用的人群，以及调查工具的质量。measure-survey-analysis 明确指出，无论样本量多大，招募偏差都会妨碍结论的普遍适用性。因此，大规模但由受访者自行选择参与的调查仍然只能提供方向性结论，任何测量结论都仅适用于实际作答的人群。如果你无法说明这些受访者为何能代表路线图所服务的用户，无论 n 多大，都不要写“已验证”。

推断得出的结果没有分布，不能凭空编造。 访谈主题、支持案例模式和分析数据不会产生各 Kano 类别的受访者人数。在该列填写 not available (inferred)，并改为附上定性信号及其来源依据。编造分布比缺少分布更糟，因为这会让推断得出的判断看起来像是调查所得。

此技能不会将“明显领先”定义为具体数值，这是有意为之。 对于只有 5 个项目的消费级待办事项列表，合适的阈值放在只有 2 个项目的企业级列表中就不合适；在这里擅自规定一个统一阈值，就像擅自编造样本量一样，是给毫无依据的数字赋予超出其所替代判断的权威性。报告分布，让读者自行判断差距。如果你无法根据分布判断哪个类别领先，就应使用模糊这一分类。

此外还要考虑信号强度；即使样本质量良好，这一条件仍可能不满足。 measure-survey-analysis 根据样本、方法和信号强度设定置信标签；而充分性检查表往往会漏掉第三项。某项特征的 400 人代表性调查结果若在必备项、表现项和惊喜项之间近乎均分，那么它已经满足上述所有条件，却依然没有给出答案。报告每项特征的分布，而不只是胜出的类别；如果没有哪个类别明显领先，就将该特征归为模糊，并说明需要什么信息才能得出结论。没有稳定领先类别的结果不能作为路线图的输入，无论样本量多大，用“已验证”来描述都不妥。

跨技能组合

• 此技能的输出将用于：未来的路线图排序技能（尚未发布；负责排名，然后排序）、deliver-launch-checklist（必备项将成为发布标准）、迭代计划工作流
• 此技能的输入通常来自：develop-solution-brief、define-opportunity-tree、define-hypothesis、discover-interview-synthesis
• 对抗性评审通过：utility-pm-critic（质疑假设的输入、框架的适用性和差异解释）

输出格式

使用 references/TEMPLATE.md 中的模板来组织输出。完整的多框架示例请参阅 references/EXAMPLE.md。

质量检查清单

定稿前，请确认：

• 至少有 3 个候选项，并说明了决策背景
• 适用性筛选摘要列出已运行和已排除的框架，并说明理由
• 已运行所有适用的框架（适用多个框架时，不得只用一个）
• 每项评分都能追溯到提供的输入或明确标记的假设（不得默默捏造）
• 跨框架比较通过指出驱动维度，解释每个存在差异的项目
• 如果运行了加权评分，必须醒目地说明权重是人为选择的
• 未提供客户研究时，须解释为何排除 Kano
• 如果 Kano 基于调查数据运行：每个项目都要标明其证据等级和结论强度，并报告各项功能的回答分布，而非只报告占比最高的类别
• 如果 Kano 基于推断运行：分布列应写为 not available (inferred)，不得捏造分布；每个项目都要说明驱动该判断的定性信号及包含该信号的来源数量
• 如果运行了 Kano：对于分布未显示明确领先类别的功能，应记录为 Ambiguous，并说明需要什么信息才能解决，而非归入较弱的相对多数类别
• 执行摘要应给出建议和下一步，而不只是排名

交叉引用

• 模板：references/TEMPLATE.md
• 示例：references/EXAMPLE.md + library/skill-output-samples/define-prioritization-framework/ 中的示例库