AI项目的死亡率高得惊人，而大多数失败并非技术问题，而是产品经理深陷认知陷阱。本文通过三个亲手埋掉的AI项目案例，揭示立项会上那些无人追问的真相：用户角色分裂、物理场景错位、情感边界失控。从宠物换装到家谱生成，每个案例都暴露出AI产品特有的死亡逻辑，作者最终提炼出立项前必须通过的三道关卡框架。
每天都有一个AI项目死掉，其中三个是我亲手埋的！
2025年上半年，平均每天有一个AI项目永久关闭。AI Graveyard的死亡名单已经逼近1300个，那些项目的名字你大概都没听说过——它们消失得悄无声息，连讣告都没有。
那些数字对我来说太远了。
直到我在半年之内，连续亲手毙掉三个自己推动的立项。
我记得最后一次是在周五下午三点的评审会上。PPT翻到最后一页，我停顿了一下，合上了电脑，说了句：”先搁置吧。”会议室沉默了三秒钟。没有人追问原因，因为大家心里都清楚——这个项目从一开始就不对，只是没有人在立项的时候说出来。
那三秒钟的沉默，值一篇文章。
先说一个让很多PM不愿意承认的事实：大多数AI伪需求的诞生，不是因为PM判断力不够，而是因为PM根本没有机会判断。
在我经历过的立项现场，大概有三种经典剧本：
1、老板驱动型 老板从某个闭门论坛回来，在周会上说了一句话：”我们必须有自己的AI产品。”于是全组开始头脑风暴，方向从AI客服到AI选题助手，七嘴八舌讨论了两个小时，最后拍板定了一个方向——谁都说不清楚目标用户是谁，但PPT做得很漂亮。
2、竞品刺激型 某个竞品悄悄上线了一个AI功能，截图在工作群里疯传。三天后，你收到一条消息：”他们都有了，我们为什么没有？”立项就这么开始了。不是因为用户需要，而是因为”不能落后”。
3、OKR交差型 年底了，KPI里重点标红写着”探索AI方向落地”。立项是最快的交差方式，哪怕这个项目在Q2就会被悄悄叫停，先把这一条打勾再说。
这三种“剧本”，我都亲历过。它们有一个共同特征：立项会上，没有人真正问过”用户是谁，他们现在怎么解决这个问题”。
我印象最深的一次对话是这样的：
产品总监问：”用户有没有这个需求？”
我说：”应该有吧，这个功能很“酷”。”
然后……没有人再追问了。
就这样，一个项目启动了。
除了组织压力，还有一个更隐蔽的陷阱，几乎所有PM都踩过，但很少有人意识到：
立项时你脑子里的“目标用户”，和真正使用产品的用户、真正付费的用户，经常不是同一个人。
场景一旦确定，用户角色就会随之漂移——但很多PM的立项文档里，这三个角色一直是同一个人。
我用后面要复盘的「家谱故事生成器」项目来举例：
结果就是：我为子女设计了一个送给老人的礼物，但老人看完之后说”这不是真的”。整个链路，在我写第一行需求文档之前就已经断了。
ToC产品里，使用用户和付费用户可以不是同一个人，但产品体验必须让使用用户”爽”到，才能带动付费用户买单。ToB产品里，使用用户（员工）的爽点和决策用户（管理层）的买点，更是需要同时设计，缺一不可。
这就是大多数AI立项在最开始就埋下的雷：我们以为用户是一个人，实际上是三个。
每个案例我都会按同一个结构来讲：我以为→现实是→真正的死因→如果当时用了某个方法。
三个案例，死法各不相同，但病根是一个。
❌ 我以为： 用户在给宠物买衣服之前，一定想知道穿上去好不好看。AI虚拟换装能解决这个视觉焦虑，转化率应该能提升。逻辑听起来无懈可击。
✅ 现实是： 我们访谈了12个铲屎官，问的是同一个问题：”你上次给宠物买衣服，是怎么决定要买的？”
12个人的回答：
9个人：“看到买家秀觉得可爱就下单了”
2个人：“跟博主买的同款”
1个人：“想确认一下合不合身”
我们的产品，是为那1个人设计的。
再去看数据：目前淘宝/天猫宠物服装类目的平均退货率通常在 15%～25%之间。但不全是因为衣服合身，而是用户根本不在乎合不合身。他们买宠物衣服，本质上是在买“给宠物拍照发朋友圈”这件事本身。 衣服只是道具，不是商品。
真正的死因：操作成本 > 决策收益。
为了买件30块的衣服，用户需要给宠物拍照、上传、等AI生图、对比效果——而在这个流程结束之前，他已经直接在另一个tab下单了。AI换装解决的问题，99%的用户从来就没有。
如果当时做过四象限定位：
把宠物换装的需求扔进四象限——需求频率（中高，宠物主确实经常买衣服）× 决策复杂度（极低，感性冲动消费）——它落在”高频低复杂”象限。
这个象限的特征是：用户早已形成了顺手的解决路径，习惯极难被打破。AI换装不是技术不行，是进错了象限。
这个案例的本质是：这是一个完美的产品，只是它解决的，是我想象中用户的问题。
❌ 我以为： 鸟类环志站长每天要手工记录大量数据，字迹潦草、容易出错。用手机OCR识别环志编号，能把他们从手写记录中解放出来，效率至少提升50%。
✅ 现实是： 我们去做了田野访谈，跟着两位站长还原了真实的作业场景。
鸟网收网之后，站长需要在极短时间内完成整个流程：取鸟、称重、量翅长、上环、记录、放飞。全程高度紧张，容不得任何耽搁。
当时我拿出手机，在现场模拟了一遍”解锁手机→打开APP→对焦→拍清楚”的操作链路。单是这个动作，就超过了30秒。
而现实条件是：手是湿的（露水加上鸟的应激反应），光线不足（作业时间是清晨4-6点），鸟在持续挣扎，山顶信号一格。
我站在那里，手机屏幕在晨光里几乎看不清，突然意识到一件事：我们在空调房里设计的产品，在这里是一个新的负担，不是一个解决方案。
真正的死因：技术选对了，节点选错了。
如果当时做过用户里程图：
把环志作业的全流程按行为阶段拆开，在每个阶段标注时间、情绪状态和物理环境，真正的痛点节点会一目了然：
正确的产品应该是：帮站长做日终汇总和月度上报的结构化工具，而不是现场OCR识别。
我们把AI塞进了最不该放的那个节点。不是技术不行，是我们从来没有真正站在用户的现场里想过这件事。
❌ 我以为： 用AI把家谱信息生成有温度的家族故事，既有仪式感又有传播性，是一个情感刚需。中国人重视血脉传承，这个方向感觉很对。
✅ 现实是： 我们做了小范围的用户情感测试，找了5个家庭，让他们看AI根据家谱信息生成的祖先故事。
前两个家庭反应还不错，觉得”有意思””很感动”。
第三个家庭是一位七十多岁的老人。他看完之后沉默了很久。然后抬起头，说了一句话：
“这不是我爸的故事，这是你们编的。”
后来我们才知道，AI为了让叙事更完整，给他父亲”补充”了一段1962年参加某次集体劳动的经历。但那一年，他父亲正在狱中服刑。
那一刻我意识到，这个产品有一个根本性的矛盾：家族记忆的核心价值是不可篡改的真实性，而AI最擅长的，恰恰是在真实和虚构之间找到最流畅的叙事。 这两件事，天然冲突。
真正的死因：AI的“合理补全”伤害了需求的严肃性。
但这个项目还有第二个死因，就是我在第一章里提到的用户角色分裂：
我为子女设计了一个送给老人的礼物，但老人是唯一真正在乎这件事的人——而他们在这个产品的链路里，完全缺席。
当AI的幻觉伤害了需求的严肃性，这个产品就没有救了。
三个项目，死在不同的地方。但起点是一样的：我们爱上了解决方案，然后反过来去找问题 …
举个：
医生每天要手写或口述大量重复性病历。格式高度标准化（主诉、现病史、体格检查、诊断……），容错率相对高（有护士和系统做二次核查），使用频次极高（一个科室医生每天产出几十份）。AI介入之后，不是替代医生的临床判断，而是把医生从机械的文字录入中解放出来。
把这个需求扔进四象限：需求频率极高 × 执行复杂度高但高度标准化。 这是AI最适合切入的象限。
真需求的三个共同特征：
频次极高： 用户每天都在经历这个痛苦，不是偶尔为之
过程极痛苦，结果高度标准化： 人做起来烦，但对错标准清晰，AI不容易犯灾难性错误
用户不需要参与感： 这个任务，用户巴不得不用自己做，AI替代不会带来失落感
对比三个失败案例：宠物换装（用户享受参与感）、鸟类环志（节点选错导致高摩擦）、家谱故事（用户必须亲历，AI的”补全”是污染）。每一个都反着来。
那三个项目，我复盘了很多次。我不认为自己是粗心大意。问题出在更深的地方：有三个认知陷阱，让我在立项时没有能力看清楚真相。
1、陷阱一：技术可行性 ≠ 需求存在
大模型太强了，强到让PM产生了一种幻觉：技术已经就绪，需求一定存在。
但这两件事从来都是独立的。GPT能写诗，不代表用户需要AI替他们写诗。OCR能识别文字，不代表用户愿意在作业现场多掏出手机一次。AI能生成家族叙事，不代表老人愿意接受一个”被编出来”的父亲。
技术可行性只回答了”能不能做”，但”用户需不需要”是另一个完全独立的问题。混淆这两个问题，是AI时代PM最普遍的认知错误。
2、陷阱二：用户说“这功能不错” ≠ 用户会用
访谈里用户说的”不错”是礼貌，不是需求。
我们做宠物换装的访谈时，几乎所有用户都说”这个功能挺有意思的”。但”有意思”和”我会为了这个改变我的购物习惯”，中间隔着一道很宽的沟。
真正的需求验证只有一个标准：用户愿不愿意改变现有的行为习惯来使用这个产品。 如果他现在的解决方案已经”够用”，再好的AI功能在他眼里都是多余的摩擦。
3、陷阱三：我们太爱解决方案了
这是最根本的病因。
PM在AI时代最大的问题，不是发现不了需求，而是太容易爱上解决方案。当你看到一个很酷的技术演示，大脑会自动开始构建使用场景——AI换装好酷，宠物市场又大，用户应该会喜欢。但那个”用户应该会喜欢”，是你的想象，不是用户的真实。
我们把这种逻辑叫做“拿着锤子找钉子”。但在AI时代更危险的是：这把锤子太好看了，让你觉得到处都是钉子。
做AI产品，PM最难的不是发现需求，而是有勇气承认：这个需求根本就不存在。
在任何访谈和调研之前，先做这个。
把需求放进两个维度来判断：需求频率（用户多久遇到这个问题）× 执行复杂度（解决这个问题有多难）。
操作方法： 用一句话描述需求场景，和3-5个核心用户确认频率和复杂度的感知。如果大家都觉得”不是什么大问题”，这个需求在四象限里大概率落在危险区。
追问红线： 如果需求落在”高频低复杂”——继续追问：用户现在用什么替代方案？那个替代方案有多顺手？如果答案是”很顺手”，立项大概率是多余的。
四象限通过之后，不要急着做功能设计。先做这一步：把用户完成这件事的全部行为阶段拆开，在每个阶段标注时间、情绪和物理环境。
操作步骤：
判断红线：
物理环境不允许（户外、手湿、光线差、无网络），不论节点多痛，都不适合AI介入
AI节省的时间少于30秒，而学习成本超过5分钟，冷启动期必死
这个节点是用户”享受”的过程（如宠物选衣服），AI介入等于抢走参与感
节点找对了，做最后一道关卡：
必须回答三个问题：
谁在用这个产品？（使用用户）
谁来为这个产品付费？（付费用户）
谁的痛苦是真正需要被解决的？（需求用户）
如果三个答案不一致，在立项前必须想清楚：
红线标准： 如果三类用户分裂，且你还没想清楚服务每个角色的路径，先暂停立项，不要靠”以后再说”蒙混过关。
我现在做新项目，立项前会固定做三件事：四象限定位、用户里程图拆节点、确认用户角色没有分裂。
这三件事加起来不超过两天。但它们能帮我在写第一行需求文档之前，就看清楚这个项目会死在哪里。这不是什么高深的方法论。它们本质上只是在强迫你回答一个在立项会上没有人真正追问过的问题：
用户真的需要这个吗？
在AI时代，PM最稀缺的能力，不是找到下一个好需求。而是在会议室里，当所有人都在说”这个方向很有潜力”、当老板刚从论坛回来眼睛放光、当竞品的截图刚在群里疯传
你能说出那句最难开口的话：
“我们先别急～～～”
本文作者为AI产品经理，文中案例均为亲身经历，部分细节做模糊处理。
本文由 @没没同学 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。