AI 硬件开发的两套操作系统:文档驱动 vs 演示驱动

今天来聊聊 AI 硬件开发的文档驱动与演示驱动。

它们的差别，不在于用不用 AI，也不在于流程画成什么样，在于：

这个团队认定「什么叫确认过了」。

而这件事，决定了团队每天在为什么争论、返工在哪里发生、一个想法从冒出来到被验证要走多久。

一、走过两条路线，现在有了第三条

硬件开发传统上偏瀑布式。

从概念、计划、开发、验证到发布，每个阶段有明确的评审和文档输出，过了关口才能进下一阶段。

而且它不是凭感觉推进的，背后有一套评审体系兜底：

IPD 流程里有 6 个 TR 技术评审点，从需求分析、架构设计，到详细设计、小批量验证，每一关都要评估成熟度、发现问题、给出对策。

• 这套做法好处是整体可控，最后的产出质量有保障；

• 不好的一点是缺少迭代，赶上需求变化就难受。

后来大家想引入敏捷。

敏捷的思路反过来：每个阶段先做一个能跑的原型，一轮一轮逼近真正的产品。

但硬件有个绕不过去的约束——你不可能像改代码一样去迭代模具、去改硬件。

所以过去硬件引入敏捷，只能有限度地用：

在两个里程碑之间做迭代，大关口还是以瀑布为主。

比如 ID 设计环节会反复打印样品给客户确认，甚至会到客户现场试装，这就是局部的敏捷。

AI 来了之后，第三条路线出现了。

以前你想在概念阶段验证一个想法，得画原型、写协议、搭环境，至少几周；

现在 AI 帮你跑，简单项目几个小时就能跑通。这就是 AI 驱动的第三路线。

不过笔者想说的是：三条路线的差别，其实不在流程，在内核。

怎么理解这个内核？看一件事就够了：

在这个团队里，什么才算可以拍板的事实？

二、两套系统，差在「事实从哪来」

文档驱动的答案是，写下来的就是事实；

演示驱动的答案是，跑起来的才算事实。

听起来差别不大，但它决定了一整串东西。

下面这张表是笔者自己的划分，不是行业标准，但用它来对照很管用。

文档驱动靠「各自读、再开会」来对齐。

开完会大家都点头，但每个人点的是自己脑子里的那个头。

等到集成的时候才会发现，小程序的理解和固件的理解不一样，固件的理解和硬件的实现不一致。

再看第四行。

文档驱动并没有消灭这些分歧，只是把它们推迟到项目后期才结算。

如果在开工前的一条演示链路上暴露，改的是字段长度和页面逻辑，改完再跑一遍就行。

本质是，错误暴露的位置变了，不是速度快了一点。

再看第六行。

想扩大研发能力的时候，文档驱动的做法是加文档、加流程、加人，靠堆资源；

演示驱动的做法是加环节——把一个复杂任务拆成更细的专业环节，每个环节交给 AI 做一部分，靠拆结构。

堆资源有天花板，拆结构没有。

同一件事，两套系统分别怎么做

拿一个具体功能说。

一个定时提醒，写成文档可能只有薄薄三行：到点响、可以重复、能改时间。

但这三行背后，要串起六七段链路——用户在小程序里设的规则得编码成协议，无线传到设备，固件解析出来，再驱动屏幕刷新和蜂鸣器响。

中间任何一段理解偏了，功能就是不通。

文档驱动的做法是，产品经理把这三行写完，硬件看硬件那部分，固件看协议那部分，前端看页面那部分。

每个人确认「我看懂了」，然后各自开工。

但「我看懂了」这四个字，三个人的含义并不一样——字段定义成几位、超时怎么处理，这些细节文档里没写。

演示驱动的做法是，产品经理先用 AI 把这条链路搭起来：

页面是真的，协议是真的，设备真的收到、真的刷新、真的响。

然后把硬件、固件、前端叫到一起跑一遍。

跑的过程里，那些说不清楚的细节会自己冒出来。

字段不够长、刷新有延迟、蜂鸣器和指示灯的时序打架——这些问题在会议室里讨论三天也讨论不出来，跑一遍十分钟就看见了。

两者的差别不在效率，在于讨论的对象是什么。

文档驱动讨论的是描述，演示驱动讨论的是东西本身。

为什么装了一堆 AI 工具，开发方式却没变

工具买了，课也听了，每个人都在用 AI，但项目该延期还是延期。

问题出在：AI 工具是装在旧的「操作系统」上的。

要理解这一点，得先看看 AI 的工程能力是怎么一步步长起来的。

笔者观察到，它大致经历了三次变化。

第一次是提示词工程，解决的是怎么跟 AI 说清楚你要什么。

提示词写好了，产出质量就高。但这一阶段的天花板很明显——你不说，它不会问。

第二次是上下文工程，解决的是 AI 不了解你的项目。

这一步要喂的东西很具体：工程规范、器件手册、历史项目的踩坑记录。喂进去多少，它就能替你分担多少。

第三次是马具工程，给 AI 配上马鞍和缰绳，

让它稳定、可控、可验证地产出。说白了，这一步解决的不是 AI 聪不聪明，是它听不听话——马跑得快不难，难的是方向对、停得住、每次都能跑到同一个地方。

没有第三次，前两次都只是偶发性的提效，撑不起一套开发方式。

这也解释了为什么，光把工具塞给每个部门，换不来整体产出。

工具是应用，应用跑不动一台没有操作系统的机器。

三、不是所有项目都要换系统

说到这儿，可能有人会想：那是不是所有项目都得上演示驱动？

不是。换操作系统是有代价的——团队要学新东西，前几个项目一定会慢下来，本来三天能干完的活可能拖到五天。

所以在换之前，先判断值不值得。

笔者自己的判断标准是这样。

这三种情况，文档驱动够用：

• 改款项目，主体架构不动只调整局部；

• 模块化程度高的项目，接口早就定死了，各做各的也不会打架；

• 做了多年的成熟产品线，大家脑子里本来就有一张一致的图。

这三种情况的共同点是，歧义本来就少，少到用文档压得住，不需要额外搭一套演示链路。

这几种情况，建议上演示驱动：

• 跨部门协作多的项目，硬件、固件、结构、云端、应用都要参与；

• 协议接口复杂的项目，字段长度和时序都容易对不齐；

• 新人多的团队，没有共同的历史记忆，每个人对产品的想象都不一样；

• 需求变更频繁的项目，每次变更都牵动多个模块。

这几种情况的共同点是，歧义多，而且压不住。

能不能两套混着用

有人会问：能不能一套系统里混着用？

能，但要分清哪些环节用哪套。

一个常见的分法是：

物理环节用文档驱动，数字环节用演示驱动。

硬件、结构、工艺这些必须打样才能验证的环节，文档和评审依然是趁手的工具；

而协议、接口、交互、页面这些能跑起来的环节，交给演示。

真正要小心的是在同一个问题上两套并行——文档说一套，演示跑一套，谁说了算不清楚。

混用的前提是先划清边界：

哪部分以文档为准，哪部分以演示为准。

四、怎么迁：别想着一步换完

确定要换，接下来是怎么换。

以下是笔者在自己项目里踩过坑之后总结的三步，顺序不能乱。

第一步，挑一个不那么关键的项目，先跑通一条闭环。

不要动主流程，不要开会宣布变革，就挑一个次要项目，让产品经理用 AI 把一条端到端的链路跑起来。

第二步，让这个演示成为这个项目的共同事实。

 评审不看文档，看演示；有分歧不辩论，跑一遍。

跑通了就是对，跑不通就是不对，没有解释空间。

第三步，把跑通的做法固化成规范。

 哪些环节可以交给 AI，哪些必须人来判断，每个环节的输入输出是什么，交接文档长什么样，工具怎么串起来——把这些沉淀下来。

这里有个判断标准：凡是只存在于老员工脑子里的东西，都值得固化。

 笔者做智能锁的时候，产品复位会检测硬件状态——指纹有问题滴一声，刷卡感应有问题滴两声，按键有问题滴三声，售后只要让客户按一下按钮、听几声就能定位问题。

这种知识 AI 里没有，因为它从没被写下来过。

第三步要做的，就是把这一类东西一条条挖出来、落成文字。

这一步的目的，是让能力留在组织。

反过来说更清楚：不这么做，人一走，能力就跟着走了。

三种常见的走偏

迁移过程中有三种典型的走偏。

第一种，把换系统当成买工具。工具买回来了，流程照旧，人会本能地用新工具干旧活——用 AI 生成一份更漂亮的 PRD，但依然是文档驱动。

第二种，想一次性全公司铺开。改流程、改考核、改组织一起动，结果每个环节都在磨合期，问题叠在一起，最后分不清是哪个环节出的错。

第三种，演示做完了就扔。

每个项目都从头搭一遍演示，不做沉淀。这样跑到第五个项目，团队还是那么累——因为能力一直留在个人身上，没有变成组织资产。

三种走偏的共同点，都是把换操作系统当成了一个要完成的动作，而不是一套要建立的默认。