技能提升网客服每天转来几十条工单，销售强调某个大客户不做功能就不签，研发又说当前版本只能接两项。会议里谁的案例最紧急、谁的声音最大，需求就被贴上 P0，最后版本塞满承诺，真正高频的问题反而没有进入计划。
AI可以把不同渠道的说法去重、补齐证据字段并计算相对分数，但不能把工单数量直接当价值，也不能替团队做战略承诺。优先级应说明问题影响谁、不做损失是什么、证据有多可靠、实现要付出什么，以及为什么现在做、以后做或不做。
先把不同说法归并成同一个问题
客服写“报表导出失败”，销售写“需要高级分析”，客户可能真正遇到的是大数据量导出超时。同一根因会被不同角色包装成不同功能。先记录原话、用户任务、发生场景、当前替代方案和失败后果，再判断是否属于同一问题簇。
去重不能只看关键词。两个都叫“批量导出”的请求，可能分别面向财务审计和运营日报，频率、格式、权限与时效完全不同。保留原始记录到问题簇的映射，避免归并后丢失少数高风险场景。
工单数和合同金额都只是证据之一
统计受影响客户数、用户数、发生频率、流程中断时长、收入风险、留存、合规与人工成本。销售口中的“大单”需要注明签约概率、合同阶段和该功能是否真为唯一阻塞；客服高频问题也要排除重复报修和同一事故。
没有数据时可先给置信度，而不是填一个精确影响值。小客户提出的权限漏洞可能比大客户的便利功能更紧急，低频但阻断核心流程的问题也不能被简单平均。
先设硬门槛再做相对评分
严重故障、安全、合规、数据丢失和明确的合同义务通常属于硬门槛，先进入专门升级流程。其他候选再比较触达范围、单次影响、置信度和成本。这样可以避免一个高分便利功能挤掉必须修复的风险项。
产品经理 提供需求诊断、需求池、RICE、价值复杂度、Kano 和版本规划模板。它要求先确认用户、场景、痛点、价值、成功指标和约束，再输出可测试的优先级文档。
RICE 分数用来暴露假设
Reach 要使用相同周期，Impact 要说明评分定义，Confidence 要反映证据质量，Effort 要由研发评估并包含测试、迁移和运维。任何输入变化都应能看到分数变化。不要为了符合预期结论倒推数值。
分数相近时再看战略一致性、依赖顺序、学习价值和机会窗口。分数高但依赖未完成的需求可能进入 Next；分数一般但能验证关键假设的小实验可能更适合 Now。结果要写理由，不只排序号。
把解决方案与问题分开评审
客户提出的是一种方案，不一定是唯一解。先确认目标，再比较配置、流程优化、培训、数据修复、现有功能组合和新开发。能用低成本方式解决同一问题时，不应为了满足原始措辞直接做大功能。
对高价值但成本大的需求，先拆出最小验证项和不可拆依赖。拆分不是把完整体验切碎，而是优先验证风险最高的假设，并确保每个阶段有可衡量结果。
版本决定要同步给提出者
Now、Next、Later 和不做都要有条件。说明当前证据、选择原因、未满足的依赖、复查日期和什么变化会触发重排。对销售不得把“进入需求池”表达成已承诺日期，对客服要给可执行的临时方案。
研发确认实现成本与技术风险，设计确认流程完整性，运营客服确认上线准备，管理层确认战略与资源。AI可以生成评审摘要，但承诺范围和发布日期必须由有权限的人批准。
最终交付是一份可追溯需求池
每项包含问题簇、原始来源、目标用户、频率、影响、收入或风险、置信度、成本、依赖、硬门槛、决定、负责人和复查日期。已搁置条目也保留理由，避免同一争论每月从头开始。
真正的优先级不是让所有人满意，而是让有限资源投向最清楚、最重要且最可验证的问题。AI减少整理和计算时间，产品团队仍要为取舍、承诺和结果负责。
