夜雨聆风拥抱AI这件事，嵌入式Linux内核线和应用线，该学的完全不同
三年后，我可能不会再"写"代码了——一个嵌入式老兵的 AI 畅想
前两篇聊了AI对行业的整体冲击，又聊了应用和内核这两条主线该怎么往上走。这周后台被问得最多的一个问题是——具体到"拥抱AI"这件事，这两条线到底该学点啥，又该在哪些地方别瞎折腾。
我们组一个干内核的同事，上个月自费报了个"AI提示词工程"培训班，学了一堆复杂的提示词模板，什么角色设定、思维链引导、few-shot示例，整整齐齐写了二十多页笔记。结果他拿这套模板去问一个驱动里的偶发死锁问题，AI给他一本正经地编了一套听起来很专业的解释，跟实际情况完全对不上。
他来找我吐槽，说感觉钱白花了。
我说，你这钱花得不算白，只是花错了方向。
一、先说清楚AI能帮上什么忙
这层不展开细讲了，前两篇聊过：样板代码、跨文件理解、文档生成、log初筛、测试用例枚举——这些AI干得不错。真实硬件时序、芯片errata、量产现场的疑难bug——这些AI还摸不着边。
这篇要往更具体的地方走——同样是用AI，应用线和内核线，该往哪使劲，该避开哪些坑。
二、两种容易踩的弯路
内核线的坑：把AI对硬件细节的描述当成权威。
AI在没有公开资料支撑的具体寄存器定义、芯片时序细节上，特别容易"自信地编造"——给出格式工整、逻辑自洽，但跟实际手册对不上的答案。我那位同事的遭遇就是典型。
应用线的坑：把AI生成的代码直接当成"测试过的代码"。
AI写出来的OTA回滚逻辑、IPC处理代码，看起来严丝合缝，但"看起来对"和"真实硬件场景下跑通"是两件事。尤其是断电、低内存这类极端场景，AI写代码时未必真的考虑到了。
三、关键洞察："验证"这件事，对两条线的权重不一样
有一条元技能，这两条线都得学，但权重不同——verify, don't trust（核实，而不是信任）。
内核线的核实对象，主要是"硬件事实"：寄存器定义、时序约束、errata条款，这些必须对照芯片手册和示波器实测。AI在这块的幻觉率，比在通用编程问题上的幻觉率高得多——因为这些细节往往压根没在它的训练数据里出现过，它会"创造性地"给你编一个。
应用线的核实对象，主要是"运行时行为"：内存长稳、断电场景、并发竞态，这些必须靠真实测试覆盖，不能靠代码审查"看起来没问题"就放行。
一句话总结：内核线警惕AI"编造事实"，应用线警惕AI"省略验证"。
四、应用线：该学什么，不该执着什么
五、内核线：该学什么，不该执着什么
六、从业者坑位——这些AI使用上的坑，我和身边人都踩过
七、诚实地说
国产大模型（DeepSeek、Qwen、GLM、Kimi这些）在中文语境和中文技术资料的理解上，确实有自己的优势；但在海外芯片厂商的英文手册、社区资料覆盖深度上，目前海外模型整体还是更扎实一些。两边各有取舍，不是非此即彼的选择，团队可以按场景搭配着用。
企业合规这件事得说清楚：芯片NDA文档、客户代码，不能直接丢给公网AI工具，这是底线，不是建议。这条红线，比"AI好不好用"重要得多。
AI工具的订阅成本，对中小团队也是真实负担，不是所有团队都能无脑给全员配最贵的agent工具，这也是要考虑的现实。
还有一件事我没有答案：AI agent什么时候能真正接入示波器、JTAG这类硬件调试工具，形成闭环自主调试？目前看不到明确的时间表，只能持续盯着看。
写在最后
AI能加速的，是"写出代码"这个动作；分辨这些代码对不对、靠不靠谱的，永远是工程师自己的判断力。内核线警惕的是AI编造硬件事实，应用线警惕的是AI替你省掉了该做的验证——方向不同，但本质都是同一句话：核实，而不是信任。
致敬，那些把AI说错的话，亲手用示波器打脸的工程师们。
也致敬所有把AI当镜子照、却没把自己照丢的嵌入式同行——AI能让你跑得更快，但分辨真假的那双眼睛，还是你自己的。
我那位报了培训班的同事，后来把那二十多页提示词笔记收进了抽屉，换了个更朴素的用法——遇到问题，直接把log和现象原样丢给AI，问一句"这可能是什么方向"，当成排查思路的起点，自己再去手册和示波器上核实。他说这么用，反而比那套花哨模板顺手多了。
关注「奔跑的码仔」，后台回复「入社」加入嵌入式大家庭，我们继续聊嵌入式这条人和AI都在往前跑的路。