硬件项目里每个部门都很努力，问题却总要拖到样机联调才暴露。作者认为根因不在执行而在顺序——PRD、硬件、嵌入式、结构各自拿走文档一角，天然留下解释空间，AI 驱动的 IPD 正在把顺序倒过来。

跟很多中小企业，以及集团性的企业合作过产品项目，包括最近跟国内家电厂合作。

对接合作过程有一个非常明确的感受：

每个部门其实都很努力在做好自己的事情，但是由于每个部门信息的局限性，导致整个协调效率就很低。

很多本应在项目初期就暴露并处理的问题，硬生生拖到了投入重资源研发的阶段。

比如成本问题，这个是要在启动项目前就要初步评估的，如果投入很多资源后再评估，就会浪费大量资源，甚至项目都要推倒重来。

再比如等到样机出来，硬件、固件、小程序才第一次凑到一起联调。

最后发现很多细节对不上：

• 小程序定义的字段长度，固件那边理解得不一致；
• 硬件预留的空间，装不下结构想要的位置；
• ……

各方的负责人坐在同一个会议室里，谁都没有做错，因为从一开始，他们手里拿的就是几份不同的东西。

这件事之后笔者一直在琢磨：

明明每个人都在认真干活，为什么最后还是要撞一次墙？

问题不在执行，在顺序。

图1：三份文档，三个「产品」

三个部门各自开工，直到样机联调才第一次看到同一个东西。

一、文档对齐，为什么必然失效

传统的硬件开发是先写文档，再各自开工。

产品经理写 PRD，硬件工程师看硬件那部分，嵌入式看协议那部分，结构工程师看外观尺寸那部分。

每个人从同一份文档里拿走自己的一角。

看上去是同一个源头，但实际拿到手的东西并不一样。

文档这个东西，写的人以为说清楚了，读的人以为自己理解了。

三个工程师脑子里的产品，很可能是三个完全不同的产品。

怎么理解呢？

你可以试着用一段文字给四个人描述一个房间：进门左手边是一个两米宽的柜子，柜子旁边有一扇窗户。

描述完你问他们：柜子在左边还是右边？窗户在柜子的前面还是后面？

四个人能给你四种答案。

图2：文字天然留出解释空间

协议字段、装配公差、交互逻辑，比描述一个房间复杂得多。

不是因为他们不认真，而是文字本身就留了解释空间。

而硬件开发里的协议字段、装配公差、交互逻辑，比描述一个房间要复杂得多。

文档天然会产生歧义，这是它的属性，跟写文档的人的水平无关。

以前没有更好的办法，只能靠评审、靠会议、靠反复确认，把歧义一点点压下去。压不掉的，就留到样机阶段，用一次返工来结算。

对硬件来说，返工才是开发里最贵、最费时的部分。

二、AI 来了，但提效提错了地方

AI 来了以后，笔者接触到的硬件团队，第一反应基本一致：让每个部门各自用 AI 提效。

• 产品经理用 AI 写 PRD、做原型；
• 硬件工程师用 AI 画原理图、做 PCB；
• 嵌入式工程师用 AI 写固件驱动；
• 结构工程师用 AI 做 3D 结构图。

半年过去，每个部门的效率都上去了，汇报里也都能拿出提效的数字。

但项目该延期还是延期，该返工还是返工。

问题不在 AI 有没有用，在于提效提得不均匀。

假设一个产品开发要经过几个环节。

AI 让其中一个环节快了 10 倍，另一些环节只快了 2 倍，还有一些环节几乎没动。

这个时候你会发现，公司在 AI 上投入的时间不算少，但最终的有效产出并没有明显增加。

因为决定整体产出的，是最慢的那个环节，不是最快的那个——这就像一支乐队，每个乐手单独练得再好，不合到一个节拍上，也合不成一首曲子。

局部提效是加法，整体提效是乘法。

当一个环节快了 10 倍，而上下游只能快 2 倍的时候，多出来的那 8 倍产能会堵在中间。对硬件来说，堵住的代价更直接——不是库存，是返工。

三、什么叫演示驱动?

先说一个常见的误解。

一听「演示」，第一反应通常是让 AI 做一个可以点击的原型交互界面，页面做得漂亮，能模拟数据操作。

这个不叫演示驱动，本质上还是文档驱动。

因为它跑不起来——接口没通，硬件没参与，数据是假的。

它依然是一份文档，只不过长得比 Word 好看。

笔者说的演示，是一个真正能跑起来的最小硬件产品闭环。

比如这样一条链路：

小程序生成一条数据包，通过无线通道发出去，设备收到后解析字段，把内容显示在硬件屏幕上。

链路不长，但整条跑通之后，一批问题会提前暴露出来：

• 页面设计得合不合理
• 协议字段定义的长度够不够，要不要优化
• 硬件对数据的解析有没有问题，能不能正常工作
• 交互方式符不符合用户预期

这些问题在过去通常要等到样机阶段才被发现，而现在，它们在开工之前就已经暴露了。

图3：演示驱动的最小闭环——小程序、无线通道、固件解析、屏幕显示，全部真实跑通。

四、一个产品做过两遍

笔者用同一个产品验证过这件事：智能空气助手，一个空调孔新风设备。

这个产品笔者做过两遍，一遍是完全古法开发，一遍是借助 AI。

两次的差别，具体到每个环节是这样：

图5：同一个产品做过两遍的环节耗时对比。AI 的提效是有条件的，条件就是私有数据。

需求整理那一项，过去要 3 小时起步。

因为需求散落在电商评论、聊天记录、旧说明书里，先要整理，再要结构化成功能清单。

现在把这些东西直接扔给 AI，10 分钟出结果。

结构设计那一项，过去 1 天。

因为要先选结构软件，安装、验证，还要学怎么用。

现在把需求描述清楚，AI 10 分钟把结构做出来。

嵌入式开发更是典型。写固件要查手册、做时序分析，以前对着 500 页的 datasheet 翻半天，现在把 PDF 丢给 AI，10 分钟出寄存器表和引脚定义。

不过这里要补一句：BOM 这一项能压到 7 天，有个前提——企业自身要有积累，把以往的选型数据、方案数据喂给 AI。

没有这个积累，产出会不准。

AI 的提效是有条件的，条件就是私有数据。

五、IPD 的每一关，会发生什么变化

对于做硬件的企业，无论用什么流程，大体都符合这样一条阶段线：

概念 → POC → 立项 → EVT → DVT → PVT → MP

变化发生在这条线的每一关上。

图6：协议冻结从 EVT 前移到 POC，是整条阶段线上最值钱的一处变化

概念阶段。

过去以市场分析、概念方案、可行性评估为主，这部分是 AI 比较擅长的，变化相对温和。

真正的变化是：现在概念阶段要多做一件事——先跑一条可演示的链路出来。

POC 阶段。

这是变化最大的一关。

过去做 POC，是搭一个局部验证。

用 Arduino、树莓派、面包板，把某个技术点验一下。

比如做一个电子标签产品，因为首次用电纸屏，就先做个技术预研。

有些成熟项目甚至会直接跳过这一关。

现在不一样了。

演示 demo 可以跑完整功能操作，从应用到后台，核心链路能跑通，关键数据有测试结果。

过去要拖到 EVT 才能定下的协议，现在在 POC 阶段就冻结了。

六、有几句话必须说清楚

AI 不会把硬件开发的周期变成两周。

物理世界有硬约束，开模具要一个月，硬件验证要一周，这些当下解决不了。

对于正式的产品项目，周期普遍在 6 到 8 个月。

全新业务从 0 到量产，2 到 3 年也很正常。笔者之前从 0 到量产做的几个产品，真正跑顺都花了两年左右——产品做出来只是一方面，后面还要跑供应链、跑渠道。

那演示驱动省下来的是什么？

省下来的是前期准备和反复沟通的时间。

这部分时间不产生物理约束，全部是认知对齐的成本。

更重要的是，省下来的是市场窗口。

对一家企业来说，机会窗口往往只有一两年。

在这个窗口里，你要把品牌、渠道、销售额做起来。

省下来的这几个月，价值不在人力成本，在于你能不能赶在窗口关上之前站住位置。

还有一句忠告：别急着在公司里推大 IPD。

中观和宏观层面的 IPD 变革，会涉及组织架构和权力结构的变更。

具体来说，跨职能团队会削弱职能部门的权力，因为要做横向拉通。

如果变革带来的收益低于或者只跟以前持平，都会影响企业的正常运转。

结合自己企业的情况，在搞清楚逻辑之前，不要盲目尝试。

本文讲的这套演示驱动，属于微观 IPD 开发流程，是开发层面的提效，不涉及组织权力的重新分配。这也是它能落地的原因。

回到最开始那个问题：

为什么每个部门都在认真做事，最后还是要靠联调来发现问题？

因为大家手里拿的不是同一个东西。

演示驱动的价值，不在于让某一个环节变快，而在于让所有人在开工之前，就看到了同一个东西。

文档驱动让团队先签合同再做产品，演示驱动让团队先看见产品再签合同。

这才是 IPD 在 AI 时代真正能发挥作用的地方。

归根结底，人负责判断和现实验证，AI 负责生成、检查和归档。