我见过不少大模型项目的死法。
有的死在立项阶段，老板问了一句"准确率能到多少"，PM答不上来，项目就凉了。有的死在开发中期，预研时用五个精心挑选的case跑出100%准确率，真实上线掉到60%，差距解释不清楚。还有的死在上线之后，用户反馈AI回答离谱，团队翻了三周代码找不到bug——因为根本不是代码的问题。
这些失败看起来原因各不同，但往深了追，都指向同一个地方：团队用传统软件的交付思维在做AI项目。
传统软件交付的底层假设
传统软件的交付逻辑可以简化成一句话：你定义规则，机器执行规则。
这个世界观里，系统是确定的。你写了什么，它就做什么。边界情况可以用if-else枚举，测试用例可以穷举，"功能完成"有一个清晰的终点。产品经理的核心工作是把需求翻译成规格，开发的工作是把规格翻译成代码。质量管理的本质是验证代码是否符合规格。
这套逻辑运转了几十年，行得通，而且行得非常好。整个行业的协作流程——需求文档、技术评审、测试验收、上线回归——都是基于这个预设建起来的。
大模型进来之后，这个预设悄悄失效了。
大模型项目的底层逻辑：概率，不是规则
大模型不执行规则，它根据统计规律生成最可能的输出。
这一个字的差别，影响是根本性的。
"确定性"消失了。 同样的输入，不同时刻可能给出不同输出。不是bug，是模型的工作方式。传统软件里，一个功能要么正确要么错误，是二元判断。AI的输出是一个分布——大多数时候对，偶尔错，极少数情况出现离谱的错误。
"完成"的定义变了。 传统软件做完了就是做完了。AI功能永远没有"做完"——Prompt可以继续调，知识库可以继续扩，模型可以继续迭代。上线不是终点，是另一段工作的起点。
"测试"失效了。 传统测试的逻辑是"覆盖所有情况"。AI的输入空间是无限的，你永远无法穷举。黄金测试集能告诉你核心场景通过了，但阻止不了用户输入你完全没想到的东西。
"估时间"变难了。 开发一个传统功能，有经验的工程师能给出较准的工期。调一个Prompt优化效果，没人知道要调多少轮。可能三天就搞定，可能三周还没进展。这不是工程师的能力问题，是不确定性问题。
把这四点放在一起，你会发现传统软件交付体系的核心假设——确定性、可测、有终点、可规划——在AI项目里一条都站不住。
为什么认知偏差是系统性的，而不是个人问题
我一开始以为这是个别PM的问题。后来发现不是。
认知偏差是系统性的，因为整个组织的协作结构都是按传统软件的范式设计的。
产品经理的培训告诉你：写清楚需求，工程师就能实现。但AI项目的Prompt调优需要PM自己下场，需求文档写得再清楚，工程师也无法保证效果。
技术评审的框架是确认"技术上能不能做到"。但AI项目的关键问题是"做到什么程度算可以"，评审会上几乎没人能回答，因为标准本身就是模糊的。
项目计划表按里程碑排。AI效果调优没有明确里程碑，只有一轮一轮的测试和迭代。当项目经理问"这个功能什么时候能完成"，没人能给出诚实的答案，于是大家编了一个听起来合理的日期，然后全员对齐到那个日期跑。
这不是个人的失职，是整个协作框架失配的必然结果。一个PM就算自己想清楚了AI项目的逻辑，也要在组织节点上一次次应付来自传统框架的要求：需求文档何时冻结？测试通过率是多少？上线时间是哪天？这些问题本身就预设了确定性，让人无法诚实回答。
产品经理会在哪些节点撞墙
说几个我见过的真实撞墙点。
第一堵墙：立项汇报
PM用传统方式准备了需求文档，列了功能点、用户路径、验收标准。老板问：准确率能到多少？
回答不了。不是PM没做功课，是在立项阶段，没有真实数据预研，这个问题本来就没答案。但组织期待一个数字，于是PM说了"预计85%"，老板点头，项目启动了。
这个85%从哪来的？没人说得清楚。
第二堵墙：中期回顾
预研时用了五个case，效果很好，大家信心满满。真实数据进来，60%的准确率，比预期低了25个百分点。
传统软件的中期回顾是确认进度——做完了多少。AI项目的中期回顾要面对一个难受的真相：效果不达标，说不清为什么，也说不清再给多少时间能解决。
会议室里所有人都不知道该怎么往下推。
第三堵墙：上线后的Bad Case
用传统软件的思维，Bug是本不该出现的，修完就消失了。AI的Bad Case不是Bug，是模型在当前能力边界内的正常表现。修一个可能带出另一个，改了Prompt一个地方效果变好，另一个地方效果变差。
PM每周开Bad Case Review，记录一条条问题，却越开越绝望——问题清单在增长，不在收缩。
这不是管理失控，是对AI迭代规律的理解还停留在传统打补丁的框架里。
AI项目交付失控的根因
如果只能说一句话：传统软件交付管理的是执行不确定性，AI项目交付管理的是结果不确定性。
传统项目的不确定性来自"能不能按时完成"，结果是确定的。AI项目的不确定性来自"完成了结果会是什么"，这个问题到上线那天都没有确定的答案。
两种不确定性需要完全不同的应对策略。前者的核心是计划和进度管理，后者的核心是快速验证和容错设计。用进度管理的工具去处理结果不确定性，必然失控。
这也是为什么做传统软件越久的PM，转AI项目时反而适应得更慢——过去的经验形成了直觉，但这套直觉在概率世界里会持续误导判断。
一个没有答案的问题
我没有整齐的结论。
传统交付思维和AI交付思维之间的差距是真实的，但弥合这个差距，靠培训够吗？
我倾向于认为，只有真正在AI项目里撞过墙的人，才会形成不同的认知。理解"AI输出是概率分布"不需要什么基础，但连续三周调Prompt没有进展、还要对老板解释为什么没完成——经历过那种场景之后，理解才会真正内化。
所以问题变成了：在还没有足够多的人经历过这种撞墙之前，组织怎么做出正确的决策？
我不知道答案。但我觉得这个问题，比"怎么做好AI项目交付"更值得想。