AI功能立项前，产品经理该先问清哪三件事？

“我们也要上个AI功能”——老板一句话，产品经理就忙着选模型、写Prompt、画交互。结果上线后点击率还行，留存没起色，用户反馈全是“答得不太准”。毛病不在执行，在启动前三个问题没问明白：用户到底在为哪一步付出代价？AI搞错了会发生什么？怎么证明AI做得更好？这三句问完，再动手也不晚。

这两年，差不多每个产品团队都接到过同一类需求：“我们也要上个AI功能。”

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

接下来，产品经理的路径依赖就来了：挑哪个模型，Prompt怎么写，入口放哪里，交互做成什么样。

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

所以立项前，至少得把下面三个问题搞明白：

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

不少AI功能的立项理由是“这个环节可以用AI优化”。

——听着没毛病，但问法不对。

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

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

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

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

只有把代价讲清楚，你才能判断AI是不是对症的药。

有个挺实在的检验方式：先把“AI”这个词删掉，再用一句话讲清楚这个功能到底值在哪。“帮用户把40分钟的周报压缩到5分钟”，这话站得住；“用AI提升写作体验”就站不住，它讲的是手段，不是价值。

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

如果一个模板、一个筛选器、一条规则就能搞定，那都没必要上AI。

AI的强项是处理模糊、开放、难以穷举的任务，比如理解一段自然语言，生成一段初稿，从大量文本里提炼要点。任务本身足够确定时，用规则往往更快、更便宜、更可控。

第一问的目的，是防止把AI当作目的，而不是手段。

第二问：AI 搞错了，会发生什么？

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

可AI功能的底层逻辑不同，它是概率性的，永远存在一定比例的错误，而且这个比例不会降到零。

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

可以从三个角度拆开看：

出错要付多大代价，得先掂量清楚。推荐一首不合口味的歌，用户划走就完了；生成一条有误的法律条款，用户照着用了，后果完全是另一回事。代价越高，AI越该退到辅助位置，最终决定交给人来做。

错误能不能被及时看出来，同样关键。输出是一段用户马上能读、能判断的文字，风险相对可控；输出藏在流程深处、几天后才暴露，那就更危险。

还得先想清楚：一旦出错，退路在哪里。用户能不能一键撤回？能不能自己动手改？能不能退回到原来的流程？成熟的 AI 产品都会给“错”留一个体面的出口——明确写上“AI生成，请核对”，保留编辑入口，置信度低时主动承认“我不确定”。

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

不少AI功能口碑翻车，问题不在模型错得多，而在产品把一个本该是建议的东西，设计成了结论。

第三问：如何证明AI做更好？

这一问最容易被跳过。

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

AI功能的输出质量是一条连续的灰度，"好不好"没有天然的标准。

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

所以，一开始就得把这些定下来：

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

再准备一批真实样本：从真实场景里挑五十到一百个输入，典型的、边缘的、刁钻的都要覆盖。模型或 Prompt 每调整一次，就用这批样本跑一轮，比较改动前后的差别。手里没有样本集的 AI 产品，优化只能碰运气。

上线之后要设计反馈回路：用户到底有没有采用输出，动手改了多少，点没点“不满意”，有没有重新生成。比起单纯统计使用次数，这些行为信号更能反映真实情况。采纳率和修改率，通常也比点击率更诚实。

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

三问之后，再谈怎么做

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

这些做法本身不新，只是到了 AI 时代被放大了。AI 的能力边界说不清，输出不稳定，成本和效果又都在快速变化，团队很容易被技术的各种可能带着跑，反倒忘了回到用户、风险和结果这三个原点。

有意思的是，这三件事一旦想明白，不少“必须上 AI”的需求会自己缩水：有的改用规则方案就能解决，有的被收窄成一个更小、更稳的场景。而真正留下来的那些，目标清楚、边界明确、验收有依据，推进起来反倒更快。

所以，下次再有人对你说"我们也做个AI功能"，不妨先别急着打开模型文档。

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

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