需求优先级最烦人的地方，不是没有方法论，而是每个人都能拿方法论替自己说话。
业务说用户等不了，技术说这块顺手，老板说先做能卖钱的，产品经理夹在中间，最后会议开了两小时，只得到一张谁都不太服的列表。
用 AI 做 MoSCoW 评分，真正有用的地方不在“让模型决定做什么”，而是把一团情绪和口头判断，先压成一张能讨论、能复查、能改的结构化草稿。
AI 不该当产品经理，但可以当第一轮记录员
MoSCoW 本来就不复杂：Must have 是这个版本没有就不成立；Should have 是重要但不阻塞；Could have 是锦上添花；Won't have 是这轮先不做。
难点在于，现实需求很少自带这些标签。一个“导出报表”可能是大客户合同条款，也可能只是内部运营想省点复制时间。只给一句需求描述，AI 再聪明也会猜。
所以第一步不是写神奇 Prompt，而是把输入补齐。至少要有四类信息：需求来源、影响用户、业务后果、时间约束。没有这些字段，AI 给出的优先级只是看起来整齐，实际没啥用。
一个可直接用的 Prompt 框架
可以从这个版本开始，不用搞太复杂：
你是产品经理助手，请用 MoSCoW 方法对下面需求做初评。
对每条需求输出：
1. MoSCoW 分类：Must / Should / Could / Won't
2. 置信度：高 / 中 / 低
3. 判断依据：只引用我给出的信息，不要脑补
4. 需要产品经理补问的问题
5. 如果要降级，最小可交付版本是什么
判断原则：
- Must：不做则核心流程不可用、合规/合同阻塞、发布无法成立
- Should：明显影响体验或转化，但有替代路径
- Could：有价值但不影响主流程
- Won't：本版本收益不清、依赖未就绪、验证成本过高这里最重要的不是分类，而是“置信度”和“补问问题”。AI 很容易给答案，但产品团队真正需要的是知道哪些答案不可靠。
会省时间，也会暴露脏数据
第一次跑这种流程，往往会发现一个尴尬事实：很多需求根本没写清楚。
“优化登录体验”到底是验证码太烦，还是首屏慢，还是错误提示看不懂？“增加数据看板”是给销售看，还是给老板看，还是给客户看？这些东西不拆清楚，任何优先级会议都会变成玄学。
AI 的价值，是把这些含糊地方提前揪出来。它不能替你判断业务取舍，但能帮你发现：这条需求没有影响范围，那条需求没有 deadline，还有一条看似 Must，其实只是某个人声音大。
最终拍板仍然要人来
别把 AI 初评直接当排期。更稳的做法是三步：AI 出第一版，产品经理改第二版，关键干系人只讨论被修改过的条目。
这样会议会短很多，因为大家不再从空白页开始争。每个分歧都有原始字段、AI 理由、人工修改记录。谁想把 Could 提成 Must，就得补充证据，而不是单靠一句“这个很重要”。
如果团队已经有 Jira、Linear、飞书多维表格，也可以把这个流程做成批处理：导出需求字段，交给模型初评，再把结果写回表格。重点不是自动化得多漂亮，而是让优先级从“凭感觉排”变成“有证据改”。
MoSCoW 加 AI，最好的状态不是快 10 倍拍板，而是快 10 倍进入真正有价值的争论。产品经理少当裁判，多当证据管理员，这事才算用对了。