ARTICLE · 1087880
这个AI助手最有用的地方,竟然是“答不上来”
让业务直接问PRD｜AI助手实践
“发货单的逻辑是什么？”“补单数据怎么算？”“门店数量那个数从哪来的？”
做产品经理，经常会反复回答这些问题。
答案有些写在PRD里，有些藏在流程图和不同版本的方案里。业务想确认一个口径，未必知道该翻哪份文档，直接问产品经理往往最快。
但对我来说，每一次“帮忙确认一下”，都会打断手头的工作。回复本身可能只要两分钟，重新接上刚才的思路，却没那么快。
于是我想：能不能让业务直接向产品文档提问？
我用扣子（Coze）搭了一个AI产品助理，第一版花了一个下午。后来又一边测试，一边调整，发布到了业务日常使用的飞书里。
原本只是想少回答几遍重复问题。用起来之后，我发现，它还能帮我找到文档里没写清楚的地方。
01
先把一件小事做好
我的需求很简单：
业务提出产品问题，AI去产品方案知识库里检索，再把查到的内容整理成容易理解的回答。查不到，就明确告诉对方。
不需要替我做决策，也不需要帮业务自由发挥。
尤其是数据口径、功能边界这类问题，回答听起来再顺，都不如答得有依据重要。AI如果编出一个结论，业务再拿去跟客户承诺，后面的解释成本会更高。
所以，搭建之前，我先写了三条规则：
第一，只回答有文档依据的内容。
不能因为“通常是这样”，就把通用经验当成我们产品的实际逻辑。
第二，把话说清楚，但别改掉原本的意思。
业务需要知道的是：这个数统计了什么、在什么条件下统计、有哪些不包含的情况。术语可以解释，关键条件不能省。
第三，查不到就明说。
比如：“这个问题我暂时没查到对应的产品方案，建议联系产品经理确认。”
这些是我希望它遵守的规则。到底有没有做到，还得拿真实问题去测。
02
第一个坑：文档里有，不代表AI读到了
把飞书里的产品方案导入知识库后，我问了一个问题：
“总体业务流程是什么？”
AI回答：没查到。
我明明画过流程图，怎么会没有？
打开知识库预览才发现：业务流程那一节只剩下标题，图里的内容没有被提取出来。
在这次使用的导入方式里，文档进去了，流程图里的信息却没进去。
这也让我意识到，上传成功和知识可用，是两回事。
我的处理方式很直接：在关键流程图下面，补一段文字，把参与角色、主要步骤和状态变化写清楚。
比如发货单流程：
直播结束后，总部选择商品和时间段生成发货单；供应商下载模板，填写物流单号后上传；门店收货后确认送达，流程结束。
文字不需要长，但关键环节不能漏。如果涉及分支或异常情况，也要交代清楚。
这段说明不仅方便AI检索，对不熟悉流程的同事也有帮助。
流程图补充文字说明前后｜概念示意图
03
第二个坑：多一道判断，反而少答了一些问题
最开始，我加了一个“意图识别”节点：先判断用户问的是不是产品问题，是的才去查知识库。
听起来挺合理，结果第一个测试就出了问题。
我问：“发货单的逻辑是什么？”
它回：“你好，我是产品知识助手，只负责产品相关问题哦。”
一个正常的产品问题，还没进入检索，就被拦住了。
意图识别误拦截案例｜示意图
我重新想了一下使用场景：这是给业务查产品方案的入口，有没有必要在检索前，再加一道分类？
至少在这个阶段，它带来的误判已经影响了正常使用。我把这个节点删掉了。
后来，我又遇到了类似的问题。
我加过一个“判断检索结果是否足够回答”的节点。知识库已经查到了发货单的关键数据逻辑，它却认为这些内容不足以解释“整体逻辑”，最后仍然选择了拒答。
这个节点也被我删掉了，交给生成回答的大模型结合检索内容处理。
最终保留下来的主流程很简单：
开始 → 知识库检索 → 大模型整理回答 → 结束。
最简产品答疑流程｜示意图
这次经历让我学到：增加一个节点之前，先确认它解决了什么实际问题，再看它有没有带来新的误判。流程看起来更完整，不代表回答就更可靠。
04
跑通之后，还有一些小事要调
核心流程搭好后，我又处理了几个配置问题：
输出格式选成了JSON，但模型返回的是自然语言，导致解析失败。改成文本输出后解决。 回答结束后，又出现了一段 {"output":"..."}。检查后发现是结束节点重复返回了内容，调整后恢复正常。 在当时使用的飞书消息展示方式里，Markdown符号原样显示。我改用了中文序号组织回答。 测试同事能搜到机器人，业务同事却搜不到。最后发现是应用可用范围没有覆盖业务部门。
这些问题都不复杂，但要从“我这里能跑”，走到“业务可以正常用”，还是得把整条链路实际走一遍。
上线前的四项检查｜示意图
05
用起来之后，我最关心两件事
发布到飞书后，业务可以直接找“小池同学”问问题。
比如发货单状态怎么流转、补单怎么算，它能根据知识库整理回答，末尾标注参考的PRD。
我最关心的，一是回答里的口径对不对，二是能不能找到对应依据。
回答流畅，只能说明它会组织语言。标注了来源，也还需要核对来源是否真的支持这个结论。
目前，我的直观感受是，飞书里重复答疑的消息少了一些。但比这个更有价值的，是后来补上的一个小功能。
06
把“答不上来”留下来
最初，助手查不到答案，就提示业务联系产品经理，对话到这里结束。
但我越想越觉得可惜。
每一次答不上来，都值得追问一句：为什么？
是文档没写？是内容没有导入完整？还是业务的问法和文档里的表达差得太远？
于是，我加了一个飞书多维表格插件：当AI判断没有查到答案时，把问题自动记录到表格里。
表格很简单，只有三列：
问题内容、提问时间、处理状态。
我每周花十分钟左右看一眼，再回到原文核对。
这里要注意，答不上来，并不一定意味着PRD缺内容。前面那个流程图的例子，就是文档有，但没有被读到。
所以，这张表更像是一份排查清单：
文档确实没写，就补充内容。 文档写了却没查到，就检查导入和检索。 文档表述含糊，就把条件、口径和例子写清楚。
通过这张表，我确实发现了几个PRD里没有交代清楚的问题，也趁这个机会补上了。
以前，业务问完，我解释完，这个问题可能就过去了。现在，它至少能留下来，推动一次文档修正。
回答问题有了一个出口，没回答好的问题也有了一个去处。
从未解问题到知识完善｜示意图
07
如果你也想搭一个，我建议从小处开始
这次实践下来，我最想分享的是四点：
1. 先选一类具体问题。
比如产品功能解释、业务流程或数据口径。范围清楚，才容易判断回答到底对不对。
2. 用业务真实问过的问题测试。
别只用文档里的标题提问。“发货单逻辑是什么”这种宽泛的问法，才是它真正会遇到的输入。
3. 检查知识有没有被完整读到。
尤其是流程图和嵌入内容。文档导入成功后，最好再核对一次关键内容是否可检索。
4. 给答不上来的问题留一个记录入口。
不需要一开始就做复杂的分析。一张简单的表，定期有人看、有人处理，就能发挥作用。
我最初搭这个助手，是想让自己少被打断几次。
后来发现，要让它答得更好，我得先把文档写得更清楚：哪些条件不能省，哪些口径容易歧义，哪些流程只画了图，却没有解释。
它替我接住了一部分重复问题，也让我重新看了一遍自己写的PRD。
那些我以为已经交代清楚的事，原来还有不少值得再写明白一点。