大部分嵌入式工程师用AI只停留在对话

上周和一个硬件工程师聊。

他跟我说了一句话。

他说身边工程师对AI的认知，还停留在对话形式。

我听完愣了一下。不是觉得意外，是觉得这句话太准了。

他说的「对话形式」是什么？打开AI对话框，问芯片参数，问电路设计建议，问报错原因，问一段代码怎么写。问完复制粘贴，下一条再问。

这不是提效。这是搜索。

用完就没了。下一条。

他接着说，并没有把真正手头上重复的工作想办法用工作流之类的沉淀下来。

这句话点中了大部分嵌入式团队用AI的现状。

个人在用，但都是一次性对话，用完就没了。下次遇到同样的问题，再问一遍。换个同事来做，又从头问一遍。每个人的AI对话记录里躺着一堆碎片化的问答，但没有一条能被下个项目复用。

你可能觉得，问一问也挺好啊，确实比以前快了。

对，比以前快。对个人来说没毛病。

但对团队来说，这个快的上限很低。因为每次快的效率都锁在个人脑子里，离职了，这个效率就没了。

真正能提效的，是把重复的工作流沉淀下来，团对报团，用一套标准流程一起冲。

比如我现在做了几个工作流。硬件接口分析，丢进去一份原理图，直接输出结构化的接口定义。

项目文件架构和程序架构搭建，新项目启动的时候一键生成标准化的目录和模板。

提取指定单片机数据手册比较器寄存器内容，不用再翻几十页PDF找哪一个参数，自动截图或者输出md文档给我。

我提出帮我生成项目某些功能，AI自动根据我项目的硬件接口，功能需求，再根据我多年积累的程序架构，编程规范，生成高质量代码，这个对后期维护价值巨大，嵌入式团队技术负责人应该懂：

说出来你可能不信，光这几个工作流，我起码打磨了几个月，你看到的是几句话，但没人跟你讲，光想这个思路，可能都要一个月。

这背后是对研发流程的理解，是对市面上AI模型和工具的理解。

这个工作流具体可以看我下面这篇文章：

每个小工作流等同于写一个程序。写完测，测出问题改，改完又测。我最夸张的一个迭代了20多个版本，就一个工作流搞了半个月，最后没达到我的要求。

直接扔了，就是做整理项目成知识库和问答那个两个skill，踩了巨坑。

20多个版本，半个月，扔了。

刚开始气得想打自己一拳，浪费了这么起码10亿的token，想顺着网线把claude，gpt，glm拉出来打一顿，卧槽，出的什么馊主意！

后面想通了，该有这年纪该有的稳重，起码赚了经验。

因为这个过程让我知道了AI在嵌入式这个具体环节里能做到什么程度，哪些地方是它的瓶颈，哪些地方是它能稳定输出的。这个认知本身就是价值。

当你深入进去，会发现很多细节问题。

比如项目知识库整理，最恶心的就是那种一个工程代码兼容几十个硬件的，AI碰到这种，不做 skill引导，很多答案都是瞎编，我在这里调的时间最长。

还有，不仅仅是要求设计者懂AI对话这么简单。还要熟悉各种AI工具、模型的组合，Claude适合做什么，GPT适合做什么，国产模型适合做什么，什么时候该用哪个。这都是真金白银砸进去测出来的。

还有你得在嵌入式行业有很深的积累。否则你怎么去界定标准？什么架构是好的架构？什么样的接口分析输出是工程师真正需要的，而不是一堆正确的废话？

这三个条件叠加在一起，能做这件事的人就很少了。这也是为什么我一天工作10个小时，时间和脑子都不够用的原因。

但好处也很明显。一旦工作流成熟，下次换一个项目，直接可以无限复用，或者只要微调。因为我设计的skill，不绑定任何硬件，芯片不同，硬件不同，但是流程，代码架构都是通用的。

对话是劳动，干一次拿一次的钱。工作流是资产，建一次，反复用。

我以前一直觉得这种话有点鸡汤，但现在真的越来越认可了。谁能把AI工作流结合到自己的行业，谁就掌握了生产力。

不是说你用AI提了20%的效率叫掌握生产力。而是你把重复的工作变成标准化流程，让自己和团队每次都能稳定地提效，这才叫掌握。

大部分嵌入式团队卡在这里。因为这个设计过程本身需要同时懂嵌入式业务和AI工作流，工程师压根没时间研究。

所以我前几天在朋友圈发了条推文，预测未来1-2年，这个人才需求还会持续增大。不是那种「会用AI写代码」的需求，而是「能把AI嵌入到开发流程里形成标准化工作流」的需求。这两个完全不是一回事。