做过7年硬件PM，我发现AI产品立项最容易死在需求定义这一步——一旦出错，几十万模具费打水漂，几乎没有回头路。
核心内容：
1. 需求定义错误是硬件项目致命伤，成本远高于软件
2. AI硬件立项三大常见死法：技术驱动、功能堆叠、忽视供应链
3. 避免立项失败的三大原则：聚焦核心场景、成本倒推、供应链先行

摘要上篇聊了AI硬件行业的半场复盘，后台收到不少私信，有同行说“终于有人敢说真话了”，也有创业的朋友问“能不能写写具体的”。
好，这次不聊行业，聊点更落地的——产品立项。为什么说需求定义最致命
图注做了好多年硬件PM，我见过太多项目死在立项阶段。不是死在技术不行，不是死在供应链跟不上，也不是死在市场没钱。是死在一个大多数人根本不重视的环节：需求定义。软件和硬件最大的区别就在这里。软件需求写错了，改个代码，下周重新发版，成本可控。硬件需求定义错了，等你发现的时候——模具已经开了，钢模费几十万没了；物料已经备了，几十万颗芯片压在仓库里；认证已经送了，几万块测试费打水漂了。没有回头路。我见过一个团队，立项时想做一个“AI智能台灯”，能调光、能播放白噪音、能语音控制、还能监测坐姿提醒。听起来很美好对吧？结果开模之后发现：语音模组的功耗太大，台灯待机电流超标，过不了3C认证。最后整个项目推翻重来，损失上百万。问题出在哪？不是技术不行，是立项时根本没想清楚：这盏灯到底要解决什么问题。三个最常见的死法
图注死法一：技术驱动，不是场景驱动立项会上的第一句话往往是“我们用了XX芯片，算力能达到XX TOPS”。但从来没人问：“用户到底拿这个东西干嘛？”我做过一个对比：同样是AI墨水屏产品，先定技术方案再做出来的，用户测试时反馈“不知道这东西能干嘛”；先定场景再做出来的，用户说“这个功能正好是我需要的”。顺序反了，全盘皆输。死法二：MVP变成“最大可行产品”立项会上每个人都要加功能。老板说要加语音助手，市场部说要加社交分享，技术总监说我们芯片支持NPU可以加个本地大模型。PM扛不住压力，全加了。结果每个功能都只做到60分，没有一个能打的。用户拿到手觉得“好像什么都行，又好像什么都不行”。硬件的MVP跟软件不一样——硬件每多一个功能，BOM多一份成本，结构多一层复杂度，认证多一个项目。加功能不是加一行代码，是加一整套供应链。死法三：忽略供应链的现实约束PRD写得天花乱坠，但有几个现实问题没人考虑：

• 你选的那颗AI芯片，交期18周，你排得上量产吗？
• 你选的那块墨水屏，全球只有两家供应商，你议价权在哪？
• 你设计的那个异形外壳，开模费是标准件的3倍，成本扛得住吗？

这些问题不在立项阶段解决，等到设计定稿了再发现，要么推倒重来，要么硬着头皮上——然后亏钱。怎么避免：我的三条原则
图注说完问题，说解法。不是什么高深的方法论，就是我这几年用血泪换来的几条原则。原则一：一个杀手场景，做到90分立项时不要列功能清单，只回答一个问题：用户买这个产品，最核心的那个使用场景是什么？找到它，然后把所有资源砸在把这一个场景做到90分。其他功能可以没有，但核心场景不能差。消费者记住你的产品，永远是因为那一个特别好的体验，而不是十个都还行的功能。原则二：成本倒推，不是功能堆叠先定目标售价，再倒推BOM上限，然后反推方案选型。比如你定了一个AI墨水屏卖599，那BOM不能超过250（按4倍定价倍率算）。250里头屏体吃掉100-120，SoC控制在30以内，电池15，结构件20，剩下的留给其他料和组装费。在这个框架里做选择题，而不是先做加法再被成本打脸。原则三：供应链前置，不是后置需求定义阶段就把供应链工程师拉进来。你不需要他做方案，你需要他告诉你三个信息：

• 这颗芯片交期多久？有没有国产替代？
• 这个物料几家供应商？独家还是多家？
• 这个结构件开模复杂度多少？有没有公模可用？

这三个答案会直接决定你的需求定义是否可落地。很多PM觉得供应链是后期的事，等设计完了再找他们。到那时候，设计已经定了，供应链说“这个选型有问题”，你改还是不改？改，前面白做；不改，后面吃亏。最后说几句
AI硬件立项的本质，不是技术问题，是商业判断。你判断的这个场景到底成不成立，这个价位用户买不买单，这个成本结构能不能赚钱——这些判断对了，技术方案可以迭代优化。这些判断错了，芯片再先进也白搭。做了这么多年硬件PM，我最大的感悟就一句话：做对的事情，比把事情做对重要得多。立项阶段就是在决定“做对的事情”。这个阶段多花两周想清楚，比后面花两个月改方案划算太多了。

登录查看剩余 70% 内容