AI时代嵌入式工程师的生存法则
坚持高质量原创，拒绝内容堆砌，喜欢的话点击上方星标，更新第一时间收到提醒，谢谢关注！
大家好我是沙师兄，从今天开始，我会再开一个新的系列，就叫AI for Embedder。
AI 的发展和 agent的能力相信大家都是有目共睹的，但是相较于前端应用算法等这类纯软，嵌入式涉及软硬结合开发又是较为特殊的一个领域。
所以我想聊一聊作为 AI 时代的嵌入式/BSP 工程师，AI带给了我们什么变化？我们应该做哪些应对？以及我理解的 AI 时代人才所应该具备的能力。
我不想只是简单的讨论“AI 会不会替代 嵌入式”这类问题，如果你只是想从我这里得到一些安慰，让我说：“嵌入式是特殊的，不会被替代”。
对不起，这我做不到，我们身处这个时代以及这个行业，变化才是唯一不变的。
我只是想分享这将近一年来我深度使用 ai agnet 后我的一些思考，以及我在行业前沿看到了哪些变化，发现了哪些机会。
后面会持续分享 AI 在嵌入式、BSP、内核等领域里的应用，比如结合 AI 定位问题、skill 分享、用 AI 学习陌生模块、分析日志、阅读代码、整理问题链路等等。
感兴趣的朋友欢迎关注~
在我们的讨论群里，除了日常工作上的问题和一些行业交流，最近最容易引起大家讨论的就是 AI 相关话题。
能明显感觉到，大家对 AI 非常焦虑，有的同学说我还没毕业呢，是不是等毕业了这行业就没有了一类的话。。
大家可能也会见过类似的文章，比如《很难了，大家做好准备吧》 一类的，点进去跟你说 AI 来了，太强了，人类没有用了。
你不学 AI 就要失业了，所以来学我的 AI 课吧。。。
我这个人一直不喜欢制造焦虑，也觉得没有必要过度焦虑。
AI 很强，而且会越来越强，但不代表你一定会失业。
大家焦虑的根源，更多来自一个变化：过去很多被认为专业的能力，开始变得不再稀缺了。
我们都认为 AI 会先长出手，替代一些体力劳动。结果没想到，它先长出了脑子。
写代码、写文档、做分析、画图、总结材料，这些过去被认为是脑力工作的事情，反而先被冲击到了。
其实归根结底，写代码本质上也是一项技能，和外语、开车、画图没有本质区别。
在原本的开发模式中，一个系统任务通常由上层领导、架构师或者资深工程师先拆解，再分配到每个人手里。普通工程师负责其中一块编码。
这个模式在过去成立，因为把代码写出来本身就有门槛。AI 出现以后，单纯编码的门槛正在下降。
它需要脑力，但是本质上就像是导航订好了起点和终点，工程师只是扮演了司机的角色。
如果一直停留在这个阶段，那确实应该焦虑。
其实说的现实一点，即使没有 AI，这类人也会面临 35岁的门槛焦虑。因为个人能力长时间没有提升，只是把重复的工作做了很多年罢了。
这种工作过去看起来是脑力劳动，实际更像高级体力活，“码农” 的称呼可能并不只是自嘲。
我说过很多次，我认为开发工程师的发展方向一定是架构师。
如果结合 AI 你的能力、效率都可以大幅提升，那就不需要焦虑，而是应该感到兴奋，因为你会发现你能做的事情远比之前多得多。
因为编码能力只是你个人能力的一部分，如今让你可以从编码这种体力活中解放出来，你可以更大的发挥自己的能力。
那么你可能会说，现在都 vibe coding了，不会写代码的人都写代码了，那我们还有什么优势呢？
但事实真的是这样吗？我反而认为，AI 不仅没有抹平人与人之间的能力差距，反而会放大个人能力差距。
专家使用 AI 工具获得的杠杆，可能是普通人的数十倍。
前段时间我看到一个新闻，一个云南小伙通过 AI 制作了一个动画短片，在外网有上千万播放量，被称为国产版“爱死机”。
我看过之后，确实觉得画面、质感、剧情完成度都非常高。
然而看过幕后制作过程就会知道，作者并不是不是随便输入几句话，AI 就生成了一个作品。
而是作者给 AI 的剧情框架和画面描述非常完整，细节堪比一篇“洛神赋”。
也就是说，整体内容早就在他脑子里形成了。
他能描述出每一个镜头、每一种氛围、每一处细节，所以 AI 才能把它准确地落出来。
对于我们嵌入式领域也是一样的，你对问题理解越深，你能够提供准确的上下文，它就能更快进入正确方向。
但是它不仅会放大你的能力，也会放大你的盲区。
如果你对问题一知半解，提供的上下文不够充足准确，例如没有提供你们的工程场景、没有提供你们的硬件特性。
这种情况下agent 可能只是在尝试在它能理解的范围内进行逻辑闭环，在给你讲一个看似逻辑合理的故事。
所以如果你没有足够的判断力，这种情况下 AI 无法帮助你解决问题，还可能会误导你。
最后我想聊一下，在经过一年的使用和思考后，我认为 AI 时代工程师应该具备的核心能力。
第一，是从模块执行到系统负责的能力。
过去很多工程师可能只负责一个模块，需求、架构、边界都由架构师来制定，最后分到个人手里完成编码和调试。AI 出现以后，很多执行型工作会被压缩。
未来一个工程师负责的范围可能会变大，从一个模块扩展到一个小系统。你要能理解目标、拆分任务、判断方案，再把一部分具体工作交给 agent 去做。
前一段时间 OPC 的概念很火，现在一些大厂又开始提 OPT，one person team。
一个人借助多个 agent，形成一个小团队的工作能力。这个过程确实会减少一部分人力使用，但效率也会明显提升。
工作过的朋友都知道，很多项目慢在跨团队沟通、信息同步和责任边界确认上。如果一个人能带着 agent 推进一整块事情，沟通成本会低很多。
第二，是组织多个 agent 并发工作的能力。
以前一个人做事，更多是串行推进。先看日志，再读代码，再翻 datasheet，再写验证步骤。
AI 之后，可以让多个 agent 同时工作。一个分析日志，一个读代码，一个整理寄存器，一个生成实验步骤。工程师负责把任务拆好、方向控住、结果收回来判断。
这时候工程师更像一个小团队的负责人。agent 承担一部分执行工作，人负责目标、拆解、判断和闭环。
所以 AI 时代的工程师，不能只把自己定位成“写某个模块代码的人”。更重要的是能不能负责一块完整的事情，能不能把 AI 组织进自己的工作流里。
第三，是上下文组织能力。
AI 很强，但它并不了解你的真实系统。它能看到什么，取决于你给它什么。
尤其是 Claude Code 这类工具，上下文窗口有限，会把你提供的信息都当成重要信息。如果你把无关信息、错误假设、过期结论混在同一个会话里，它很容易越聊越偏。
所以用 AI 不是简单提问，而是要组织上下文。你要告诉它当前系统是什么，现象是什么，已经验证过什么，哪些假设被排除了，哪些信息是可靠的，哪些只是猜测。
上下文越干净，AI 的输出质量越高。
第四，是回到物理世界验证的能力。
这一点在嵌入式领域尤其重要。AI 主要工作在数字世界里，代码、日志、文档、协议、datasheet、调用链，这些东西它都很擅长。
但嵌入式工程师面对的很多问题发生在物理世界：电源、时钟、reset、波形、外设响应、硬件连接、板级差异。
所以嵌入式工程师在 AI 时代的角色，应该是成为物理世界和数字世界之间的接口。我们要把物理世界中的现象整理成 AI 能理解的上下文，再把 AI 给出的方案拿回物理世界验证。
会用 AI 的人，不是简单把问题丢给 AI 等答案，而是能把 AI 组织进自己的工作流中，让它成为自己的杠杆。
由人来发起问题、拆解任务、控制方向、验证结果。
所以真正需要焦虑的，不是 AI 会不会替代你，而是当 AI 成为基础工具之后，你有没有能力用它放大自己。
你要知道和你竞争的不是 AI ，而是那些更会用 AI 的 人。