Three questions product managers must answer before launching an AI feature

"我们也要上个AI功能"——老板一句话，产品经理就开始选模型、写Prompt、画交互。上线后点击率不错，留存没变化，用户反馈"答得不太准"。问题不在执行，在启动前三个问题没问清楚：用户到底在为哪一步付出代价？AI搞错了会发生什么？如何证明AI做得更好？问完这三句，再动手也不迟。

来源可能是老板在行业会上受了刺激，可能是竞品刚发布了智能助手，也可能是技术团队跑通了一个很酷的Demo。在提需求的时候，给到的就是一句话和一个截止日期。

然后，产品经理的路径依赖就开始了：选哪个模型，Prompt怎么写，入口放在哪，交互长什么样。

等功能做好上线，一看数据：点击率不错，留存没变化，用户反馈里全是"答得不太准"。复盘时才发现，不是执行不到位，而在启动之前，好多问题还没弄清楚。

所以在立项前，至少要把下面三个问题搞清楚：

第一问：用户到底在为哪一步付出代价？

——听起来没问题，但问法不对。

真正的问题是：用户在这个场景里，具体卡在哪一步？这一步现在要付出什么代价？

可以是时间，比如写一份周报要花四十分钟。

可以是门槛，比如不会写SQL就拿不到数据。

也可以是心理负担，比如面对空白文档不知道从哪里下笔。

一个很实用的检验办法是：把"AI"两个字拿掉，用一句话描述这个功能的价值。"帮用户把40分钟的周报压缩到5分钟"是成立的。"用AI提升写作体验"就不成立，因为它描述的是手段，不是价值。

还没完，继续问：这个代价，传统方案能不能解决？

传统功能的逻辑是确定的：输入相同，输出相同，有问题就是Bug，修掉即可。

所以要换一种提问方式：不是"它能不能做对"，而是"它做错了，后果有多重"。

可以从三个角度拆开看：

错误能不能被及时发现：如果输出是一段用户马上就能读、能判断的文字，错误的风险相对可控。如果输出是一个藏在流程深处、几天后才会暴露的结果，那就更危险。

错误之后有没有退路：用户能不能一键撤销，能不能手动修改，能不能回到原来的流程。好的AI产品都会给"错"留出体面的出口，比如明确标注"AI生成，请核对"，保留编辑入口，在置信度低的时候主动说"我不确定"。

把这些想清楚，你才知道这个功能应该做成"自动执行"，还是"给出建议由用户确认"。

这是最容易被跳过的一问。

传统功能有现成的验收方式：按钮能点，流程能走通，数据能入库。

如果启动前没有定义，上线后就会陷入两种尴尬：要么每个人凭感觉评价，开会时各说各话；要么只看点击量和使用次数，却不知道用户到底有没有得到价值。

所以，一开始我们就需要把这些定下来：

写出"好"的标准：不需要一开始就很精细，哪怕只是五条判断规则：事实不能错，语气要符合场景，长度要在某个范围，不能出现敏感内容，格式要能直接使用。有了这个，评估才有共同语言。

准备一批真实样本：找五十到一百个来自真实场景的输入，包括典型的、边缘的、刁钻的。每次调整模型或Prompt，都拿这批样本跑一遍，对比前后的差异。没有样本集的AI产品，优化基本靠运气。

设计上线后的反馈回路：用户有没有采纳输出，改动了多少，有没有点"不满意"，有没有重新生成。这些行为信号比单纯的使用次数更能说明问题。采纳率和修改率，往往比点击率诚实得多。

一个功能如果说不清楚"怎么算做好了"，那它在启动时就已经失去了迭代的方向。

三问之后，再谈怎么做

回头看这三个问题，其实对应的是产品的三个基本判断：该不该做、能不能放心做、做得好不好。

它们并不新鲜，只是在AI时代被放大了。因为AI的能力边界模糊、输出不确定、成本和效果都在快速变化，团队很容易被技术的可能性牵着走，忘了回到用户、风险和结果这三个原点。

有意思的是，把这三件事想清楚之后，很多"必须上AI"的需求会自己变小，有的被规则方案替代，有的被收缩成一个更窄、更稳的场景。而留下来的那些，目标明确、边界清晰、验收有据，做起来反而更快。

先问清楚：用户的代价是什么，错了会怎样，怎么证明好。

问完这三句，再动手也不迟。

本文来自微信公众号“人人都是产品经理”（ID：woshipm），作者：禾木，36氪经授权发布。