硬件出身的作者用一套 skills 体系跑通了一个全新智能硬件的全链路，也承认半自动化才是当下能落地的形态。他把 AI 赋能硬件开发分成四个成熟度层级，从局部提效到深度赋能，逐级说明每一级卡在哪里、又该怎么往上走。

上一篇内容提出了演示驱动的AI赋能逻辑：硬件IPD开发的顺序，正在被AI倒过来。

有读者反驳，AI做不好原理图、做不好PCB、做不好结构…

这篇进一步解释一下，我本身是嵌入式硬件出身，结合对AI的深度使用：

• 用量产产品从定义到量产的全套完整资源，训练了一套skills体系；
• 用这套skills跑通了一个全新智能硬件：硬件、结构、固件、后台、小程序，实现联动控制；
• 其实也可以跑全自动化的Agent，但经过实践发现，当下阶段，半自动化才是能落地的东西。

其实硬件/结构绘图也好、代码也好，都属于极度结构化的内容，而结构化是一定可以被AI替代的。

也许未来2-3年，AI画硬件、做结构就可以超过90%的初中级工程师。

相比软件，只不过硬件有更多物理世界的约束，比如最近我们在做的产品，涉及钣金机构、塑胶外壳、硬件这些环节：

• ID设计完，但是机构实现难度过大或者成本过高，导致推倒重来；
• 钣金限制，导致塑胶外壳空间有限，PCB难以布局；
• 等等问题…，全是物理层面的限制。

当前阶段的演示驱动不是为了实现所有环节，而是让产品借助AI在短时间内，做好各种快速验证仿真，尽可能减少物理世界的返工。

比如前段时间特别火的AI硬件Mircoduck，仿真训练就做得很到位。

我将AI赋能的层次划分成了四个层级：

图1：AI 赋能硬件开发的四级成熟度，从局部提效到深度赋能

这也可以回答很多人的一个疑问：

我们用 AI 也有一阵子了，到底算用得好还是不好呢？

这个问题不好回答，是因为没有一个唯一的尺度：

• 说好吧，可是项目该延期还是延期；
• 说不好呢，每个人确实都在用，也都省了时间。

而AI成熟度四层级，每个等级之间的差别不在于快慢，在于组织的 AI 能力长在哪一层。

项目顺利的时候，两种团队都能交付。

只有等到人员流动、需求突变、或者要同时开两条产品线的时候，差距才会暴露——一种能力跟着人走，另一种能力留在原地。

下面逐级说，每一级给出四样东西：

长什么样、怎么自测、卡在哪里、往哪走。

第一级：局部提效

硬件工程师用 AI 提取数据手册，结构工程师用 AI 设计结构，嵌入式工程师用 AI 写驱动，前端用 AI 写页面。

再往前走一点的团队，还会给 AI 建专属资料库：

把常用器件的选型数据、成本数据整理进去，让它直接出方案、核算成本。

每个人都在用，每个人都在自己那一段里提效。

硬件产品的环节多，每个环节都有自己的专业门槛，也都有自己的优化空间。

AI 一来，每个环节都能找到提效点，这是好事。

但环节之间的缝隙，AI 填不了，有的环节提升了10倍，有些环节可能只提升了1倍，最终发现整体提效很优先，投入产出很低。

图2：一级的典型状态——每段都在提速，段与段之间的缝隙没人管

自测的问题：你们团队的 AI 提效，有没有跨出部门边界？

如果答案是「还没有」，那你在一级。

这一层级的问题出不是大家不想跨，是没有人负责跨。

每个人的考核只对着自己那一段，把手伸到相邻环节，做成了功劳不好算，做砸了责任是自己的。

在这种默认规则下，把手缩回来才是划算的。

建议的升级动作很具体：找一个人，试着把两段接起来。

不用做什么大动作，也不用改流程，就让他在 AI 的帮助下，把相邻的两段连起来跑一遍。

跑通一次，就能拿到一条完整链路的全局视角。

第二级：初步协同

二级的团队，已经有人跨出那一步了。

产品经理跑通了一部分，甚至跑通了完整的 Demo。

需求对齐的效率明显比开会高，以前要来回确认好几轮的东西，跑一遍就都看见了。

但二级有个特征：Demo 是一次性的。

图3：二级的两种结局——Demo 散场，还是留下一个能复用的资产

它只起到了拉通需求的作用。

项目进入正式开发，各部门又各做各的，Demo 里跑通的那些接口、那些约定，没有传下去。

到了下个项目，同样的坑，重新踩一遍。

还有一种更隐蔽的问题：这个 Demo 是产品经理一个人的成果，别人看懂了，但没有义务接着用。

建议的升级动作是：让 Demo 产生第一个可复用的资产。

• 通常是一份接口文档，固件工程师拿过去就能直接开工，不用再问一遍字段是什么意思；
• 或者一组测试向量，下一个项目直接拿来验证，不用重新设计方案。

当然了，资产不一定是文档。

有的团队沉淀的是一套评审清单——哪些接口必须验、验到什么程度；

有的团队沉淀的是一份踩坑记录——上一个项目在哪儿栽过跟头、怎么绕开的。

第三级：迭代联动

前两级是量的积累，到这一级，性质变了。

第三层级的团队，各部门直接在 Demo 的基础上做深度开发。

接口直接复用，测试用例直接继承，上一版调通的链路，下一版接着用。

Demo 不再是临时的，它变成了活的基线。

这时候会看到一些新现象：

• 新项目的起步速度快了，因为地基是现成的；
• 评审的时候大家看的是同一个东西，争论的对象从「你理解得对不对」变成「这么改行不行」；
• 新人上手也快了，打开演示跑一遍，产品的样子就清楚了。

这一级卡的东西跟前两级不一样——前两级卡在能力，这一级卡在规则。

规则决定了「复用」这件事有没有人会去做。

要做到接口复用、用例继承，原来那套默认规则必须改：

谁在什么时候交付什么、评审到底看什么、出了问题算谁的责任。

这些不改，Demo 就永远只是产品经理一个人的产物。

三级要做的事，本质上就是把这些东西变成组织能继承的规则。

图4：三级的关键动作——把接口文档和测试向量写进交付物清单，跟其他交付物同等对待

从三级往上，考的不是技术，是组织认不认这套新规则。

第四级：深度赋能

四级是方向，不是现状。

四级的形态是这样的：

描述好需求，AI 自动调研、生成方案，甚至能联动工厂打样。

从需求到样机，全链路 AI 驱动。

听起来很远，但它的拼图已经能看到了。

比如我验证的这套skills系统，就包含 18 个专业环节，一步一步执行。

每一步执行完都会生成一份交接文档，下一个环节根据交接文档继续往下做。

即便中间断档，后续也能围绕交接文档接着做，不会因为某个人离开就卡住。

举个环节层面的例子。

• 芯片手册提取这一步，输入是几百页的英文手册，输出是规范化的时序表和引脚定义；
• 原理图分析这一步，输入是原理图文件，输出是固件工程师能直接用的接口速查文档。

上一个环节的输出，就正好是下一个环节的输入，中间不需要人再翻译一遍。

图5：四级的运转方式——18 个环节靠交接文档一环扣一环串起来

人的角色也跟着变了：不再是一步步亲手执行，而是在每一步做确认和决策。

人从操作者变成了把关者。

自测的问题是：你们有没有足够的历史项目数据，可以拿来训练？

如果答案是「没有」，那你还没到四级。

四级真正的卡点在数据。

18 个环节要跑得准，前提是喂进去的东西足够多、足够对。

工程规范、器件手册、历史项目的踩坑记录，这些东西攒得越久，每一步的产出就越准。

所以往四级走的第一步，不是去买更强的模型，而是把现有项目的资料整理成能训练的格式。

没有这些积累，自动化就是一句空话。

AI 会给你一个看起来很专业、但完全不适用的方案：

• 它不知道你们厂那台老设备有特殊的时序要求；
• 也不知道某类器件在低温下会飘，因为这些从来没人写下来过。

而数据恰恰是最难速成的。

它只能靠一个个真实项目攒出来，过程中还会遇到一个尴尬：早期项目的数据不规范，得花时间清洗和补录。

所以四级通常出现在产品成熟、批量稳定、有多年积累的团队里。这不是聪明不聪明的问题，是时间够不够的问题。

三级到四级，考的是时间。

四级看下来，有三个判断

第一个判断：多数团队在一级和二级之间。

二级已经是主动跨部门协作的结果，能走到这里，说明团队里有愿意多做事的人。真正的问题在于，二级经常被当成终点。

第二个判断：真正的分水岭在二级和三级之间。

一级到二级，靠一个人愿意多走一步就能实现。

二级到三级，必须动规则——评审看什么、责任怎么划、交付物是什么。

前一步是个人选择，后一步是组织选择，两者需要的支持完全不是一个量级。

第三个判断：升级这件事，跳级是要还的。

从一级直接跳到三级，通常的结果是 Demo 做得漂亮，但没人接。

因为没有二级那段时间建立的协作习惯，接口复用根本落不了地。你会得到一个精美的演示，和一群不知道该拿它怎么办的人。

图6：三个判断——多数团队的位置、真正的分水岭、跳级的代价

跳级最典型的失败场景是这样的：产品经理很能干，一个人把演示做得漂漂亮亮，老板看了很满意，于是决定全公司推广。

半年后回头看，除了那个产品经理更累了，什么都没变：

因为其他人从头到尾没有参与过那条链路，也没有形成任何共同的约定。

能力的迁移只能一级一级走，没有捷径。

归根结底，你在哪一级，不由你用了多少工具决定，而由上一个项目的成果有没有被下一个项目接住决定。