AI赋能硬件IPD开发的四个等级,你的团队在第几级?

About this offer

硬件出身的作者用一套 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:三个判断——多数团队的位置、真正的分水岭、跳级的代价 跳级最典型的失败场景是这样的:产品经理很能干,一个人把演示做得漂漂亮亮,老板看了很满意,于是决定全公司推广。 半年后回头看,除了那个产品经理更累了,什么都没变: 因为其他人从头到尾没有参与过那条链路,也没有形成任何共同的约定。 能力的迁移只能一级一级走,没有捷径。 归根结底,你在哪一级,不由你用了多少工具决定,而由上一个项目的成果有没有被下一个项目接住决定。 本文由人人都是产品经理作者【产品人卫朋】,微信公众号:【产品人卫朋】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载 题图来自Unsplash,基于 CC0 协议