第一次做 AI 产品的时候,我完全按传统软件的思路走。PRD 写得很细,每个功能节点的输入输出都定好了,流程图画得清清楚楚。开发完一上测试,懵了——同样的输入,AI 每次给出的结果都不一样。
我的第一反应是:这是 bug 吧?
后来才明白,这不是 bug。这是 AI 产品的本质特征。而这一个认知,把我之前习惯的那套产品思维整个撬开了。
确定性 vs 不确定性:AI产品的根本差异
传统软件是确定性系统。你写一个计算器,1+1 永远等于 2。你写一个表单提交,点击保存就是保存。用户的每一步操作,对应的结果是可预期的。产品经理在写 PRD 的时候,可以把每个分支都穷举出来——用户点这个,系统做那个,例外情况走这条路,无一遗漏。
AI 不是这样。同样的问题,AI 今天给一个答案,明天给另一个,都不算错,但就是不一样。比如智能客服场景,用户问「我的快递到哪了」,AI 直接告诉他在某个转运中心;两分钟后同一个人再问一遍,AI 却要求提供订单号。两次回答都有道理,但用户感受到的是混乱。
这种不一致性,在传统软件里是必须消灭的缺陷。但在 AI 产品里,它是系统的固有属性。你没有办法把它消灭,你只能学会跟它共存,甚至把它设计进产品里。
这就是我说的「思维断层」——不是 AI 多了什么功能,而是你对「产品该如何表现」的底层假设,从此不再成立了。
AI的逻辑不是人写的,是学出来的
传统软件的逻辑是人写的。产品经理定规则,开发写 if-else,不管嵌套多深,每一条分支都是人拍板的,可以打开看,可以对着规则调试。
AI 的逻辑是从数据里学出来的。你给它数据,它自己找规律,找到的规律是什么,有时候连写模型的人都说不清楚。
一个做内容审核的团队跟我聊过。最早用关键词库,三千多个敏感词,人工维护,准确率 72%。换 AI 模型之后准确率到了 94%,因为 AI 在理解语义,不是匹配字符串。但代价是,你再也没法打开一个 Excel 看到所有判断规则。某天 AI 突然把一条正常内容标为违规,你想知道为什么——答案是「模型就是这么判断的」。
这对产品设计的影响比大多数人意识到的深得多。你没有办法像调 bug 一样去调 AI 的行为,你能做的是调数据、调评估、调反馈机制。产品思维的作用点变了。
AI产品上线后还会「自己变」
还有一件事让我花了一段时间才真正接受:AI 产品上线之后,它还会继续变。
一个医疗写作项目,帮医生写论文初稿。上线时医生对 AI 生成内容的采纳率是 62%,三个月后没做任何改版,涨到了 78%。系统在收集医生的反馈数据,模型一直在自动优化。
听起来很完美。但又过了一个月,心内科医生开始投诉,说 AI 质量下降了。一查,心内科方向的采纳率从 75% 掉到了 60%。原因是那段时间混进去了一批低质量的训练数据,模型学偏了。
「学坏了」这个词,我第一次听他们说的时候觉得有点荒谬。但后来想想,这是 AI 产品的真实处境:你不改代码,它也在变;你不改代码,它还能变差。
这意味着上线不是终点。传统软件意义上的「上线后维护」,主要是修 bug、加功能。AI 产品的维护是另一回事——你需要持续监控模型的表现,像照看一个有自主行为的东西一样。
不确定性不是bug,是设计对象
所以当我说「不确定性不是 bug,是你要设计的对象」,这句话是什么意思?
意思是,你的设计要把不确定性本身考虑进去。
比如指标体系。传统产品通常定一个目标值——智能客服准确率达到 90%。但 AI 产品的表现会波动,定一个死数字会让团队不停地恐慌。更合理的做法是定三个层级:底线(低于这个值就是事故,比如低于 80%)、正常目标(90%)、理想值(95%)。这样正常波动就不会引发不必要的恐慌,真正触底才报警。
比如用户体验设计。当 AI 判断某张影像「疑似肺结节」,直接给结论和同时展示「疑似肺结节(置信度 61%,建议结合 CT 进一步确认)」,对用户的价值是不同的。把 AI 的"底气"告诉用户,是一种设计选择,不是技术细节。
比如降级方案。AI 一定有搞不定的情况,好的设计应该提前想清楚:AI 不确定的时候怎么给保守回答,AI 判断超出边界的时候怎么转人工,系统整体出问题的时候怎么切到规则兜底。这三件事不是上线后出了问题再临时想,是 PRD 里就该写清楚的。
这些设计动作,在传统软件里要么不需要存在,要么只是边缘性考量。在 AI 产品里,它们是架构层面的东西。
放弃「完全掌控」的预设
从传统软件切换到 AI 产品思维,最难的一步不是学技术,是放弃「系统应该可以被完全掌控」这个预设。
PRD 写不清每个输出,因为输出本身就是不确定的。测试没有唯一正确答案。迭代不能假设系统状态是稳定的,因为模型随时在变。
但这不是让产品经理束手无策——是工作性质变了。从「定义系统应该怎么运行」,变成「定义系统在各种情况下应该如何表现,包括它表现不好的时候」。
不确定性是你的工作对象,不是你的对手。