当一个AI助手被提上议程,产品经理第一张图该画什么?

前段时间，业务方找到我，提了一个听起来很清楚的需求：

“我们想做一个AI智能问答助手，把产品资料、市场观点和一线话术都放进去。以后产品经理、渠道经理和理财经理遇到问题，直接问它就行，最好能覆盖90%以上的常见咨询。”

谁来用、做成什么样、希望达到什么效果，似乎都说清楚了。

很多产品经理听到这里，可能已经开始想：用哪个大模型？要不要做RAG？知识库怎么建？

但我没有马上打开PRD模板。

因为这个需求还有点“虚”。它更像大家对未来产品的期待，还不是一个可以直接交给研发去做的需求。

所以，我先问了一个很简单的问题：

“你们说的常见问题，具体都有哪些？”

“覆盖90%的问题”，到底是哪90%

业务方说：“产品信息、产品卖点、市场观点，还有客户平时经常问的那些，基本都要覆盖。”

这个回答不能说不对，但还是太大了。

后来，我们把一线人员平时遇到的问题一个个拿出来看。

“这款产品的风险等级是什么？”产品资料里一般能找到。

“这只产品今天的净值是多少？”需要从业务系统获取最新数据。

“现在能不能赎回？”要看产品类型、开放期、持有期和交易日历。

“为什么最近收益出现波动？”可能要结合市场表现和研报观点，再用一段用户能听懂的话解释出来。

这些问题都出现在同一个聊天框里，但背后的处理方式完全不同。

有的问题查资料就够了，有的问题必须调接口，有的问题需要按规则判断，还有一些问题信息不完整，系统应该先问一句，而不是急着给答案。

比如用户只问：“这款产品最近怎么样？”

他想问的是收益、风险，还是能不能赎回？如果系统不问清楚，就只能猜。

如果一开始不把问题拆开，“覆盖90%”很容易变成一句好看的口号：系统能回答很多简单问题，但用户真正着急的时候，它却帮不上忙。

后来，我们开始看历史咨询记录：哪些问题出现得最多，哪些最耗时间，哪些答错以后风险最高。整理完这些，“常见问题”才真正有了边界。

一句简单提问，背后可能是一整条流程

业务方还给了我们一个典型问题：

“财富牛S款达到业绩比较基准了吗？”

站在用户角度，这就是一个简单的是非题。但系统不能直接回答。

它要先弄清楚，用户问的是成立以来、最近一个月，还是当前投资周期；比较的是累计收益、年化收益，还是某个区间表现；产品本身又属于哪种类型。

即使这些信息都有了，系统还要知道数据从哪里取、更新到哪一天。接口出了问题，是告诉用户暂时查不到，还是使用上一日数据？答案里是否需要增加风险提示，也要提前定好。

用户只说了一句话，但产品经理需要设计的是一整条流程：

确认产品和问题，补充时间和指标，获取数据，匹配规则，最后组织成一段能直接使用的回答。

如果只是把几份产品说明书放进知识库里，这个问题很难真正答好。

我先画的，不是聊天框

这时候我越来越确定，这个项目最先要画的，不是页面原型，也不是漂亮的聊天框。

而是一张很朴素的“问题—任务—能力分流图”：

用户会问什么，他真正想做什么，这个问题需要查资料、取数据、按规则判断，还是需要大模型帮忙组织语言。

产品期限和风险等级这类固定信息，交给知识库；净值和收益率这类实时信息，去业务系统里查；能不能赎回、什么时候到账，按明确规则判断；产品卖点和收益波动原因，再让大模型结合已有信息进行表达。

如果用户的问题说得不完整，就先追问。

聊天框只是用户看到的入口。真正决定系统能不能用的，是后面这些能力有没有准备好。

我们还去看了一线人员现在怎么回答问题：去哪里找资料，哪些问题需要找产品经理确认，哪些数据要打开多个系统才能查到。

有时候，真正困难的地方不是AI不会回答，而是资料不完整、数据拿不到，或者规则一直没有统一。

AI不会自动把这些问题变没。

第一期不要什么都做

把问题拆开以后，大家很容易想：既然都分析出来了，那第一期全部做掉。

但这往往是AI项目最容易踩的坑。

最后，我们决定先做资料完整、数据稳定、规则清楚、咨询频率高的问题，比如产品基础信息、风险等级、产品期限、产品对比和常见理财知识。

至于个性化投资建议、复杂收益分析，以及需要多个系统共同执行的操作，先不急着上。有些保留人工确认，有些等数据和规则准备好以后再做。

这不是把产品做小了，而是先让它真正能用起来。

很多企业AI项目不是死在模型不够强，而是一开始想做得太多。知识库没准备好，接口没接完，规则也没人确认，演示做了一遍又一遍，却一直不能上线。

有时候，明确“这一期不做什么”，反而能让项目走得更快。

准确率高，不代表真的能用

业务方最开始希望把“回答准确率”作为主要验收指标。

但只看平均准确率，问题很大。

AI把一段产品介绍写得不够好，和AI错误地告诉用户“这个产品可以随时赎回”，肯定不是同一种错误。

前一种可以慢慢优化，后一种可能直接让一线人员向客户传递错误信息。

所以，我们后来不只看准确率，还会看哪些问题答错了，错误严重不严重。有些错误可以接受，有些必须避免，还有一些一旦发生，就不能上线。

除此之外，还要看用户的问题是不是真的被解决了，多少问题最后转给了人工，以及一线人员愿不愿意继续使用。

一个AI助手好不好用，不是看它能说多少话，而是看它知不知道什么时候可以回答，什么时候应该再问一句，什么时候应该老老实实地说“这个问题我暂时无法确认”。

后来，这个项目的PRD当然还是写了。

但在动笔之前，我们先把用户、场景、问题、数据、规则和一期范围理了一遍。

这个过程没有漂亮的页面，也没有炫酷的模型演示。

但正是这些看起来不够“AI”的工作，决定了知识库怎么建、接口接哪些、规则由谁确认，以及系统到底能不能真正进入业务。

所以下次，当有人跟你说“我们也做一个AI助手吧”，先不要急着讨论模型，也不要马上画聊天框。

先把一件事弄明白：

用户遇到了什么问题，他真正想完成的任务是什么，我们到底能帮他做到哪一步？

这张图画清楚了，后面的路才不容易走偏。