腾讯元宝：产品经理怎么用？需求梳理

产品经理的一天常被三件事切碎：看反馈、开评审会、写文档。腾讯元宝（底层是混元大模型）能接住的是中间一段——把散落在聊天记录、客服工单、访谈笔记里的说法，压成一张能进评审会的需求表。它不替你排优先级，但能让你在开会前十分钟拿到一份有分类、有出处、有空白标记的清单。

先按来源分层，再决定传什么

需求来源至少有四种，信息质量差得很远。用户访谈是一手原话，量小但能还原场景；客服工单量大、重复率高，适合做频次统计；销售和客户成功的转述经过二次加工，常把"客户想要"说成"客户需要"；数据异常则要看埋点和漏斗，不属于文本整理的范畴。

可带走的判断是：原话优先于转述，频次优先于个案。把这两条贴在需求池的入口，能挡掉相当一部分伪需求。整理时要求每条后面标来源，评审时被问"这是谁说的"，你能立刻答上来。

四列拆解：角色、场景、问题、期望

这四列不是随便定的。角色决定权重，场景决定真伪，问题决定痛点强度，期望决定验收标准。一条需求如果写不出场景，多半是想象出来的；如果期望只有"体验更好"，它在开发那里无法验收。

把形容词追问成动作，是这一步的核心。"希望结算页更快"可以落成"从点击结算到看到支付方式，不超过两步"；"搜索不准"可以落成"输入品牌名，结果前三条里有官方店"。改完的句子能测，能测的才能排期。

同时要求它标出信息不足的条目。不要让它补全——模型很擅长把空白填成合理的样子，那些填出来的内容一旦进入需求文档，会在评审会上变成争论的起点。宁可留一个"待确认"，也不要一个假答案。用户表达模糊时，与其让模型猜，不如按置信度不足就转人工的思路先挂起。

评审会：抽三类，留一类空白

90 分钟的评审会，讨论往往是散的。让工具抽三类内容：已达成的结论、待办事项、未决问题。待办必须带责任人和时限，缺失的单独列出来，会前五分钟补齐，比会后在群里追问三天有效。

讨论里的矛盾点要并排摘出来，不要让它裁决。两个方案冲突，往往不是谁对谁错，而是各自服务的目标不同。工具能做的是把冲突摆到桌面上，取舍仍然是产品经理的活。

如果会议本身是线上开的，转写质量决定整理质量。开着实时记录边开边看，比会后凭记忆补纪要稳，具体做法可参考会议实时记录的用法。

一段可复用的提问

需求整理提问模板

这是本次需求评审的讨论记录与用户反馈：{粘贴内容}。请按以下要求处理：1）按"角色 + 场景 + 问题 + 期望"整理成条目，每条标注来源；2）抽出已达成的结论、待办事项（含责任人与时限）、未决问题；3）列出相互矛盾的说法，并排呈现，不要裁决；4）标出信息不足、需要补充调研的条目。只使用材料中出现过的信息，不要推测用户没有表达的需求。

• 材料超过一万字时按议题分段，一次只处理一个议题
• 把"信息不足"单独成节，避免混进结论
• 输出后自己过一遍优先级，这一步不要外包给工具

四类场景的做法与判断标准

表格的用法是：先看"怎么问"，再用"判断标准"验收。不达标时调整输入，而不是反复重问同一句。

它在需求梳理上做不到什么

它不知道你的业务目标、留存曲线和研发成本。优先级本质是取舍，取舍需要依据，而这些依据不在对话里。它能告诉你哪类问题出现得多，告诉不了你哪类问题值得做。

它也不会替你访谈。工具只能整理已经存在的文本，用户没说出口的顾虑、没说完整的场景，仍然要靠人问出来。把访谈省掉，整理出来的只是二手的二手。

长会议记录接近上下文上限时会漏掉中段，具体额度以官方最新版本为准。超过一定长度就按议题切段，每段单独整理再合并，比一次性塞进去可靠。

保密是硬边界。未公开的经营数据、客户名单、合同条款、尚未发布的功能规划，不要放进对话；需要处理时先脱敏。

它还会生成"看起来合理"的条目，比如把你没问过的用户心理写进需求。压制的办法只有一个：要求每条结论都能指回一句原话，指不回去的删掉。

三个执行层面的问题

• 条目太多，怎么收敛到能评审的数量？：先按"影响人数 × 发生频率"粗排，再看实现成本。让它按来源分组，工单类通常能合并掉一半，访谈类则要保留细节。不要一上来画四象限，维度没定清楚时四象限只会制造假精确。
• 能不能直接让它写 PRD？：可以起骨架，背景、目标、范围、主流程、异常分支这几节它写得比人快。但字段定义、权限边界、并发和失败重试必须自己补，这几处它经常写成一句话带过，开发看到会来回问。
• 录音转写有错别字，影响抽取吗？：影响专有名词。先把产品名、模块名、人名做一次统一替换，再交给它归类，否则同一个模块会出现三四种写法，归类会散。数字和日期也要抽查，转写对"十"和"是"这类同音字很容易错。

把需求整理交给工具之后，省下的时间应该花在两件事上：判断哪条不做，以及把要做的那条讲清楚。把通用提示词改成自己的讲的是模板怎么调；需求条目要长期沉淀、支持多人查询，用数据库记住这些信息是另一条路。