产品经理岗位 AI 落地——如何从用户信号里找到值得做的需求

@金山办公

产品经理别急着让 AI 写 PRD：用 WPS Comate 从用户信号里找出真需求

用户吐槽、社媒讨论、竞品功能、内部想法每天都在涌进来。真正难的不是“让 AI 写一份 PRD”，而是判断：哪些信号值得做，哪些只是噪音，最后为什么是这个 MVP。

💡	产品经理最危险的 AI 用法之一，就是"看见几条反馈 → 让 AI 直接写 PRD"。

看起来省了时间，实际上可能只是把未经验证的判断写得更完整。用户吐槽不是需求，竞品功能不是答案，AI 生成的 PRD 也不是结论。

这次，我们不让 WPS Comate 直接替产品经理"拍脑袋写需求"，而是把它放在更适合的位置：搜索、整理、聚类、评分、生成草稿；产品经理负责判断证据是否可靠、需求是否值得做、MVP 是否足够小。

整个工作流的核心：不是从"反馈"直接跳到"PRD"，而是先经过清洗、证据化、评审，再进入需求池。

一、为什么"用户说了什么"不能直接等于"要做什么"

比如用户说：“AI PPT 生成出来不好改。”这句话听起来很明确，但它背后可能对应完全不同的问题：

生成前大纲不能调整，用户没机会确认方向。

生成后单页版式不方便重排。

企业场景品牌模板、品牌色不符合要求。

内容质量配图和正文语义不匹配。

交付结果导出 PPTX 后不可编辑或格式不稳定。

如果直接把它写成“优化 AI PPT 编辑体验”，范围就太大了。开发不知道改哪里，设计不知道先解决什么，产品自己也很难解释为什么先做这一项。

更好的做法：先把"反馈"拆成可复查的证据，再聚类成候选需求，最后选一个最小、最值得验证的切口。

二、第一步：让 WPS Comate 先建立"证据表"，不要急着给结论

每一条进入需求池的信号，都应该能被别人重新找到、重新理解、重新判断。因此至少保留：

字段	为什么要留
证据 ID	后续 Top3、PRD、验收标准都能回链。
来源类型	区分 BBS、社媒、竞品网页、评论等。
URL / 发布时间 / 采集时间	确保材料可以复查，并判断时效。
原文摘录	保留用户原话，不先改写成产品语言。
上下文	看清用户到底在什么任务里遇到问题。
用户场景 / 用户意图	区分“他说了什么”和“真正想完成什么”。
分类理由	说明为什么它指向某个候选需求。

WPS Comate 在这里更像"研究助理"：把散乱信号压缩成一张可复查的证据表。

三、三路信号一起看，但它们回答的是不同问题

1社区 / BBS：找真实问题

重点看用户正在做什么、卡在哪一步、有没有截图或复现路径、评论里是否有人补充同类问题。

2外部社媒：找用户原话和替代方案

小红书、B 站、知乎、Reddit 等更适合看用户怎么表达不满、怎么比较工具，但这些只能作为“发现入口”，不能直接当结论。

3竞品网页：看预期差

不是抄功能，而是看用户已经被什么体验教育过：入口、输入方式、生成前确认、生成后编辑、导出与分享等。

同一个需求候选，最好同时能看到"真实问题""用户原话"和"预期差"三个角度。

四、第二步：让 WPS Comate 做聚类和多角色评审，产品经理再做取舍

证据表有了之后，不要马上生成 PRD。先让 WPS Comate 把相似问题合并成候选需求，再从多个角色做一次评审。

产品经理问题是否真实？是否影响主流程？MVP 能不能足够小？

交互 / 设计能不能用低成本交互改动解决？会不会增加理解负担？

研发技术是否可行？改动范围多大？是否碰核心高风险链路？

商业化 / 运营影响面和业务价值如何？是否影响转化、留存或售后成本？

候选需求再按痛感强度、影响面、主流程阻断、技术可行性、改动范围、业务价值和证据可信度等维度评分，最终得到 Top3。

你是“产品需求发现与评审总控 Agent”。基于我提供的用户反馈证据表： 1. 清洗有效证据； 2. 合并相似问题，形成候选需求； 3. 分别从产品、设计、研发、商业化/运营视角评分； 4. 输出 Top3，并解释每个候选为什么进入 Top3； 5. 所有关键判断必须引用证据 ID； 6. 证据不足时列出下一轮还需要采集什么，不要硬凑结论。

五、真实 case：AI PPT 最后选中的，不是"大改编辑器"

在已经跑过的 AI PPT case 里，收集到的信号包括：

“希望直接修改大纲内容”

“品牌模板库”

“复杂指令与长文档处理”

“空白区域过多”

“配图与当前页核心内容关联性弱”

“AI 重新生成版式”

“内容校对”

经过聚类后，Top3 变成：

排名	候选需求	代表证据
1	生成前大纲确认与轻编辑	E01、E03、E06
2	企业模板与品牌规范生成	E02、E06
3	单页质量修复：版式重排、图文匹配、内容校对	E04、E05、E07、E08

最终选择 Top1，并不是因为另外两个不重要。

而是因为“生成前大纲确认与轻编辑”更适合先做 MVP：在现有生成链路中增加一个“大纲确认”状态，范围更小，也更容易验证。

六、第三步：让 WPS Comate 生成 PRD v0，但每个判断都要被证据"拉住"

到这里，WPS Comate 才开始生成 PRD v0。重点不是写得长，而是每个关键判断都能回到前面的证据 ID。

一份合格的 PRD v0 至少要包含：

问题定义到底是谁，在什么任务里，被什么问题阻断。

目标用户这一版优先服务谁，而不是"所有人"。

MVP 范围这一轮只解决什么。

不做什么主动收窄范围，防止需求膨胀。

关键状态用户流程里新增或变化了哪些节点。

验收标准必须能被产品、设计和开发实际验证。

真正重要的不是"AI 帮你写了多少字"，而是 PRD 里的问题定义、假设和验收标准，都能回到证据 ID。

七、最后再做一次 Rubric 自评：这份 PRD 到底能不能交

在提交前，让 WPS Comate 再做一轮自评。可以简单分成三档：

等级	判断标准
不合格	没有证据 ID 回链；缺 URL 或原文；PRD 明显编造场景；验收标准不可测试。
合格	有 3–5 条有效证据；Top3 能解释合并理由；PRD v0 控制在一个 MVP；关键判断可回链。
优秀	至少 5 条有效证据，覆盖 2 类以上信号源；有弱证据说明；角色评分有分歧；PRD 写清待验证假设。