从埋点缺失到需求评审走过场，产品经理的每一步都可能埋下失败的种子。本文深度剖析AI产品开发中的四大关键陷阱，尤其针对AI产品的特殊性，提出核心逻辑预验证等实操解法，帮助产品人从'功能交付'转向'效果交付'。
需求评审顺利通过，开发按时交付，测试没有找到什么大问题，然后就上线了。
半个月后复盘，没有什么数据能说明这个功能有没有用，因为压根没有埋点。再过一个月，老板问效果怎么样，所有人沉默。
这件事我认识的好几个做产品的人都遇到过，不同公司、不同规模，但故事基本上长一个样。问题不在于流程走没走，而在于走的人有没有真的在想：这个东西做出来之后，我怎么知道它有没有用。
项目开始的时候，大多数团队都会说”我们做用户调研”和”我们分析竞品”。没有人说不做，但实际上怎么做，差距极大。
调研最常见的路子是做问卷。发给几十个用户，收上来一堆勾选数据，整理成图表，然后得出”用户对这个功能有较强需求”的结论。这个结论是真的吗？不一定，因为问卷问的是”你觉得有没有用”，用户回答”有用”和用户真的去用，是两件事。
问卷能告诉你频率和比例，但告诉不了你情绪。用户为什么烦，在哪个具体时刻烦，烦到愿意换工具还是烦完就忍了——这些问卷抓不住。真的去聊五六个人，收获远比收一百份问卷多。聊的时候也别问”你想要什么功能”，这个问题基本上没什么用，用户能想到的功能，往往就是他现在用的工具缺的那一个，不一定是真正的解法。更有用的问法是：上次你处理某件事的时候，怎么做的，哪里最让你头疼。
我认识一个朋友，他们团队做了个给销售用的内部工具，跳过调研直接开发了将近三个月。上线之后销售没什么人用，去聊才知道，销售白天基本上不坐电脑前，需要的是手机上快速填的东西，而那个工具是桌面端的表单。这个信息如果在开始就去问，随手一个问题就能问出来，但没有人问。
竞品那边，很多人做完就是一张功能对比表，谁有什么谁没什么列得整整齐齐。这张表做完用处其实不大，功能谁都有、谁都能做，真正的差距在用户实际怎么感受。更有价值的是去找竞品的负面评价——在应用商店、在社区、在各种吐槽帖里，用户在骂它什么。骂的地方通常就是空缺。
还有一件事，启动阶段很容易被跳过：把这个项目要实现的业务目标说清楚。
说清楚不是写”提升用户体验”或者”做一个AI文案生成功能”，是写成”用这个功能，运营写一篇内容的时间从半小时压到五分钟以内”。前一种说法让你有了功能就觉得完成了，后一种逼着你去想上线之后怎么量。
没有这个目标，上线之后你会发现自己说不清楚这个项目成没成。目标还有另一个用处：它是后来所有争论的裁判。开发说某个功能实现起来很复杂，你说这个功能对目标帮助有限、可以先简化——有了具体目标，这个对话才能进行下去，否则就是两个人各说各的道理。
规划阶段说白了要做两件事：把用户痛点翻译成功能清单、排优先级；再想清楚用户是在什么场景下用的，他是赶时间、是第一次用、还是来完成一个例行任务。这些网上讲烂了，我不多说。
我想单说一个做AI产品特有的动作，大多数人会跳过它：在真正写文档之前，自己先把核心逻辑跑一遍。
做传统产品，你写”点击按钮，系统保存数据，跳转成功页”，开发照着写代码，结果和你想的基本上是一样的。做AI产品，你写”AI根据用户输入生成文案”，开发调了个接口，生成出来的东西可能跟你想的完全不是一回事。模型在这个场景下表现怎么样、延迟有多长、什么输入会跑偏——这些不亲手跑一遍，你写在文档里的描述就是想象。
现在工具方便，用Cursor或者直接调各家API，自己写个最简单的demo，把核心流程跑通。不需要写得多精细，能跑就够。
拿这个东西去找开发的时候，对话质量完全不一样。不是”我想做一个AI生成的功能，大概是这个思路”，是”你看，这是我跑出来的效果，这个延迟有点高，这种输入它处理得不好，我们怎么解决”。对话直接从概念推进到具体问题，省掉很多来回。
（要主动跟开发说清楚：这个demo是用来验证方向的，不是让你照着工程实现的。快速写出来的代码结构通常很随意，有时候不说清楚，开发真的会把它当参考。）
PRD相关的文章实在太多了，我只说几个我观察到的高频问题。
第一个是背景和目标的部分，很多人用”提升用户体验”这类话来填充。这句话什么项目都能用，用了等于没写。要写的是具体的：现在这件事花多长时间，目标是压到多长，用什么来衡量。有了这个，后面的功能决策才有参照——某个功能加进来是否真的帮你实现这个目标，还是只是让PRD看起来更饱满。
第二个，也是我见过最多人漏的：只写正常情况，不写异常。
正常情况是：用户点击按钮，系统返回结果，用户满意。这段写完基本没什么用，因为开发脑子里已经有了。真正容易出问题的是：接口超时了显示什么？用户输入了一堆乱码怎么处理？AI生成的内容里出现了不合适的词怎么办？这些不写，开发会按最省力的方式处理，最省力的方式通常是白屏或者报一个用户看不懂的错。
如果一份PRD里正常流程写了五页、异常处理写了半页，基本上没写完。
做AI产品还有一块很多人没写：AI逻辑本身是怎么设计的。不是写”AI自动生成结果”，是写清楚：用户的输入怎么处理，用什么指令去调用模型，输出以后做什么校验，结果质量不合格的时候走哪个分支。这一块是AI产品PRD里最费脑子的地方，因为你得真的想清楚，而不是留一句”由AI决定”。
这里有个根本差别，想清楚了才知道哪些地方应该多花时间写。
做传统产品，程序逻辑是写死的。用户点了什么，后台做什么，结果是确定的。PRD的工作是把这些确定的事情描述出来。功能列全了、状态覆盖了，基本上开发就能还原你想的东西。
做AI产品，你描述了一个输入，但输出是概率性的——今天生成的和明天生成的不一定一样，用户觉得好的和AI生成的不一定匹配，偶尔还会冒出莫名其妙的东西。这个特性决定了你没办法靠枚举功能点来写完一份PRD。所以传统产品的PRD是在画图，把每条路画出来；AI产品的PRD更接近设规则，你说不了每条路的结果，但你得把边界定好——什么情况下应该生成、什么情况下应该拒绝、生成得太烂了怎么兜底、模型宕机了走哪个降级方案。
具体来说，AI逻辑这一块至少要写清楚几件事：用什么指令去调用模型（不同的指令结构，输出质量差距可以很大）；输出的内容做不做二次校验，校验什么；如果内容里出现敏感词或者格式不对，走什么流程；用户觉得结果不好，可以怎么重新生成，重新生成的逻辑和第一次一样还是有调整。
这些问题在你写PRD之前自己跑过demo会更容易回答，因为你已经亲手碰过那些边界情况了。没跑过的话，这一块写起来通常很虚，写完也不知道有没有写对。
这个差别想清楚了，你才会明白为什么”AI处理”这四个字在PRD里是完全不够的。
说到PRD，还有一个环节很多人走过场：需求评审。
评审会最常见的状态是PM念PPT，开发听着，最后问有没有问题，没人说话，散会。这种评审开了等于没开，很多问题都是开发在真正写代码的时候才发现的，那时候改起来代价已经很高了。
判断评审质量有个简单的方法：评审会上开发有没有提问题。”这个状态怎么处理？””这两个逻辑有没有优先级？””这个接口按你的描述实现起来很复杂，有没有别的方案？”——他们提问说明他们在认真理解需求，这才是评审的作用。如果开发全程没有问题，要么PRD写得极其清楚（大概率不是），要么他们根本没仔细看。评审结束之后，这些问题再补是费的力气翻倍的。
很多团队的习惯是上线之后才想”我们得看一下数据”，那时候再加埋点，前面那段时间用户的行为全没了。
在写PRD的时候就把数据需求定好。产品不说，开发不会主动想，数据团队也不知道你想看什么，这件事必须产品主动推。
做AI产品，有一类数据是传统产品不太会去想的：用户有没有真正采用AI给的结果。不是”看了”，是”用了”。用户点了复制、还是改了很多才用、还是直接关掉页面重写——这三种行为说的是完全不同的问题。第一种说明质量够，第二种说明凑合，第三种说明基本没用。
我认识的一个团队做了个AI摘要功能，自测觉得挺好，上线之后也没什么投诉。加了埋点之后发现，有六七成的用户看完摘要还是会去翻原文——用户不信任摘要，看完还是要自己确认。这个发现改变了他们后来整个迭代方向，而在有埋点之前，他们完全不知道这件事。
顺便说一下，有人会把收集用户行为数据和后续做模型微调混在一起想，觉得埋点了就能训练模型。这是两件差别很大的事，后者需要的资源和工程能力远不是大多数小团队能负担的。大多数情况下，收上来的数据能帮你改Prompt、优化交互，就已经很有价值了，不必想太远。
关于市场分析和行业分析，很多人把这两件事列为启动阶段的必做项，但说实话，小团队做一个垂直工具，通常不需要单独出大报告。老板已经有他的判断，你写几十页他也不一定看。真正需要认真做的场景只有几种：去融资的时候，或者要进医疗、法律这类监管很重的行业。其他情况，在PRD背景部分用几段话说清楚就够了。
以上是我现在觉得比较顺的思路，不一定对，尤其是具体做什么类型产品的团队，可能跟我接触的项目差别挺大的。
你们现在项目启动，是从调研开始往下推，还是功能已经定了再补调研？如果是后者，补出来的调研一般长什么样？
本文由 @Talen 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。