芯耀
与非AI
731
我是老温，一名热爱学习的嵌入式工程师，关注我，一起变得更加优秀！
各位嵌入式老铁，周末愉快啊！
最近几个月，我一直在折腾一件事：就是把 AI Agent 塞进日常的嵌入式开发流程里面。
不是问一句“延时怎么写”的程度，而是真的让它读项目目录，分析需求，改代码，跑交叉编译，写文档。
然而，让我感触比较深的，是前几天整理一份寄存器地址表，这个任务。
那个表格总共586 条寄存器，散在几个头文件和一个 Excel 里面，要整理成一份结构化对照表，并且输出到项目的 docs 目录。
这种活，我以前干过，一整天下来眼睛发花，而还容易漏条目出错，所以这次，我把它丢给了 Agent了。
把芯片平台、分组规则、输出格式讲了一遍，然后我就去干别的事了，等我回来，那个表格已经躺在那了，剩下的只有一件事情：核对。
那一刻的感觉，挺奇怪的，感觉自己就像一个“废人”，帮不上忙，也插不上话~
（以前这活我来干，至少一天，它几十分钟交卷，格式还比我整齐，嗐）
后来又拿它干了同样性质的几件事：把散在 Excel 和聊天记录里的需求收拢成一份 PRD，把需求拆成技术条目，然后再按人天评估工时，改构建脚本把打包产物挪到指定目录。
关键是，每一件事情，它都做成了！而且都有一个共同点：输入输出清楚，步骤明确，结果可以验证。
于是我开始想：嵌入式开发里面，到底还有多少活是这个性质的？
我的判断是：只要一项工作能被拆成稳定的输入输出，有明确的步骤，有可验证的结果，它就一定会向机器迁移！
这不是预测，是正在发生的事。
JetBrains 今年 5 到 7 月做了调查，样本超过一万五千名开发者，平均 47% 的代码已经由 Agent 全量生成，38% 是 AI 辅助，只有 27% 纯手写。
更有意思的是分语言那一栏：Go、JavaScript、TypeScript 的开发者，Agent 生成占比最高，达到了54% 到 55%。
而C 和 C++ 开发者，平均还有 38% 的代码是采用古法编程，是所有语言里最“不 Agent 化”的一群人！（没错，就是我们这群搞嵌入式的）
很多人把这个数字当护身符，觉得这说明 AI 啃不动底层。but, i don't think so~
我更认同嵌入式顾问 Jacob Beningo 的说法：真正碰硬件的代码，可能只占现代固件项目的 20%，剩下的是应用逻辑、状态机和通信层。
整体下来，感觉跟这个比例差不多。问题恰恰出在这里：那 80% 正在被接管，而剩下 20% 恰恰是最贵、最难、最没法验证的部分。
我把这半年试下来的结果整理成了下面这张表，各位老铁可以对照自己的项目看看。
看到最后三行，可能有人会说：核心的活它还是干不了。
这种想法还是需要注意一下的，真正的变化不是“它能不能干最难的活”，而是“最难的活之外，那些活都去哪了”！
这里不得不说清楚：这不是Agent变笨了干不了这活儿，而是它没有“眼睛”，它看不见。（不过，现在有MCP协议和即将出来的MHS协议，让Agent看见，指日可待！）
Analog Devices 的软件总监 David Perez 讲过一句话，我记到现在：几乎每个嵌入式工程师，都有过一个“看起来很合理的驱动，编译干干净净，然后在凌晨两点的台架上挂掉”的故事。
David Perez说这不是Agent能力不足的问题，而是Agent的上下文管理出现了问题。
通用模型是按“一颗通用 MCU”在写代码，但我们的板子有具体的外设资源、时钟配置、DMA 映射、内存布局，还有一坨没人会写进注释的 error data，这些内容，Agent全都不知道。
有一位开发者曾经在博客上记录过一次翻车，我看了直冒冷汗。
他让 Agent 在树莓派上验证一个 IMU 驱动，Agent 跑了三条命令：看模块在不在，读一下 sysfs 节点，再看最后三十行内核日志。十五秒之后，宣布驱动工作正常。
实际上数据全是错的，少了一次 cache sync，DMA 每三个采样就损坏一个。日志里面其实有 Unhandled fault，但它只看了最后三十行，刚好落在一段干净的地方。
这才是最危险的地方：Agent 会用非常专业的语气，给你一个错误的胜利宣告！
所以我的做法是：先管理一下Agent的上下文。
芯片型号，板级资源，工具链路径和交叉编译命令，寄存器地图，编码规范，哪些目录不许碰，全部写进项目的 AGENTS.md，再配几个自己做的 skill，WorkBuddy、Codex、Claude Code 三端共用同一份。
（讲一遍是一劳永逸，每次重讲一遍是自我折磨）
编译报错也直接把日志喂回去，让它自己修，有可验证结果的环节，闭环跑得起来；没有的，就别指望它。
在这儿还得说一句公道话：不是所有环节都变快了。METR 去年做过一个随机对照试验，允许用 AI 的那组任务，实际完成时间反而慢了 19%。
这个结论虽然还有所争议，但它提醒了我一件事：AI 提效并不是必然项，它是有条件的！
条件就是前面的那三条：输入输出，步骤，可验证结果。但凡缺少其中一条，AI Agent就会从“帮手”变成“麻烦”。
还有一笔我们这行特有的账要算一下的：固件的缺陷并不像 Web，几分钟就能回滚。一个工业控制器或者车上的 ECU 代码固件发出去，它要在现场待上十年。
（这也是我一直坚持先出方案、审完再动代码的原因，慢是慢了点，但至少可以让嵌入式工程师睡觉安稳一些）
说了这么多，结论其实就一句话：AI Agent 抢的不是嵌入式工程师的饭碗，而是我们的工时。
它抢走的是整理、搬运、格式化、重复移植这些低判断密度的活，腾出来的时间，本来就该用在架构权衡、时序分析、现场那些说不清道不明的偶发问题上。
真正会被落下的，不是不会用 AI 的人，是手里只有“写代码”这一项技能的人。
如果你到现在还没开始，建议现在马上开始做一件事：把项目上下文写成一份 AGENTS.md。
花一个下午，省下来的绝对不止一个下午！
好了，今天就先说这么多，继续去折腾 Agent 了~
