Linus说内核不反AI工具——但做嵌入式18年的我告诉你AI写的驱动你敢用吗一句话观点Linus说内核不反AI是对的但AI生成的驱动代码在嵌入式场景下风险比互联网后端高两个数量级——内核社区要管的不应该是能不能用AI而是AI写的代码谁来负责。先交代一条2026年7月16日刚出的新闻。Linus Torvalds在内核邮件列表上发话了Linux内核不是一个反AI的项目。如果有人想在内核推动反AI议题他们最好创建分支或者离开。AI是一种有用的工具内核不会阻止开发者使用AI工具。这段话的背景是什么过去几个月内核社区里关于AI生成补丁的争议已经白热化了。有维护者公开拒绝AI生成的代码提交有开发者因为补丁被标注为疑似AI生成而愤然离场。两边吵得不可开交。而Linus这次的表态等于一锤定音别吵了AI工具可以用。我坐在电脑前看完这条新闻第一反应是——Linus说得没错但他没说到点子上。先说为什么Linus是对的我不会为了制造冲突就瞎说。Linus在这件事上的态度其实一直是一致的。Linux内核是个务实的项目。20多年前他选择Git而不是BitKeeper因为他要的是一个能用的工具而不是一个政治正确的选择。同样的逻辑如果AI工具能帮维护者减少工作量为什么不呢而且他说了一个非常关键的点“AI和人类的自然智能一样都不完美。”这话什么意思人类写的代码也有bug。内核里因为人类粗心导致的漏洞还少吗所以把AI生成的代码质量不行作为拒绝理由是不成立的——人类写的同样不行。从数据上看内核社区确实已经被补丁淹没。2025年合并窗口期每个版本平均有1.5万到2万个补丁。维护者严重不足。如果AI工具能做一些机械性的工作——比如代码格式化、简单重构、文档生成——那对维护者来说是天大的好事。所以Linus说内核不反AI从项目管理角度100%正确。但问题出在嵌入式跟服务器不一样我做了18年嵌入式干过后端现在主要做嵌入式Linux驱动和系统开发。这些年我最有感触的一件事是同样的代码、同样的工具在服务器上出事和在嵌入式设备上出事后果完全不同。AI写代码的问题恰恰在这。第一层差异出错代价你跑在云服务器上的Go服务如果AI生成了一段有内存泄漏的代码——好OOM了k8s重启Pod优雅降级没人受伤。最多丢几个请求客户投诉一下。但在嵌入式设备上呢你写的驱动在医疗器械里一段AI生成的DMA处理代码在边界条件下没释放中断——心脏起搏器停了。你写的驱动在汽车ECU里一个AI生成的I2C读写时序错误——刹车系统延迟了50ms。没有k8s没有优雅重启。设备就是物理世界里的一个东西它出错人受伤。第二层差异可调试性后端代码出问题你有日志、有APM、有分布式追踪、能热修复、能灰度发布。一套组合拳下来90%的问题都能定位。嵌入式驱动出问题呢串口输出一条panic信息设备已经挂了。你连ssh都进不去。要调试JTAG焊线示波器量波形逻辑分析仪抓时序。我用AI写过一段简单的GPIO中断处理代码看起来完美无缺。烧进去设备启动正常跑了一个小时后死机。debug了三天才发现——AI生成的代码里中断服务函数访问了一个被优化掉的静态变量。编译器没报错代码能跑但跑一段时间就崩。你说这个锅谁来背AI肯定不会背。提交代码的人他可能根本不懂中断上下文能做什么不能做什么。第三层差异安全合规嵌入式行业有大量的认证要求——医疗IEC 62304、汽车ISO 26262、工业IEC 61508。这些认证要求你追溯每一行代码的来源证明它是安全的。AI生成的代码你怎么追溯“这部分是GPT-7生成的我在prompt里说’写一个安全的SPI驱动’”——你觉得认证机构认不认这不是玩笑。我一个做汽车电子的朋友跟我说他们公司内部已经明确规定任何AI生成的代码不能进入有ASIL等级要求的模块。你敢用出了事你个人要负法律责任。真正该吵的不是能不能用而是责任怎么分Linus说可以用AI工具这没问题。但内核社区真正需要讨论的是另一个问题比能不能用重要一百倍当AI生成的代码引入了一个安全漏洞谁来负责这不是理论问题。现实中已经有案例了。2025年底一个BSD维护者发现有人用AI生成了一批网络驱动的补丁看起来像是那么回事但实际上一堆隐性的问题——资源泄漏、竞态条件、边界检查缺失。这些补丁如果合入主线后果不堪设想。维护者花了大量时间review这些代码最后得出结论review AI生成的代码比review人类写的代码要累得多。因为AI不会犯人类的错误——它犯的错是那种看起来完全合理、但就是不对的错误。是否是是是否是否AI生成代码看起来合理吗需要更深层的review直接拒绝代码逻辑正确边界条件处理资源管理正确并发安全打回重写可以合入这个流程图说明什么AI生成的代码你不能用看起来合理这个标准来判断。你得从头到尾、逐行逐句地检查它的逻辑、边界、资源、并发——这比你自己写一遍还累。我的建议三个可以三个不可以我不是来当反AI的保守派的。相反我认为AI是嵌入式开发的强大助力。但使用AI得有条件。可以用AI做的✅ 代码注释、文档生成这是AI的强项错误容忍度高✅ 简单的驱动骨架生成你填关键逻辑AI生成标准结构✅ 测试用例生成但必须人工审核边界条件不要用AI做的❌ 中断处理、DMA、实时逻辑这些地方出错的代价太高❌ 安全关键模块认证要求追溯AI做不到❌ 你没有能力review的代码如果你看不懂AI生成的汇编就不要用它写驱动最后说句得罪人的话我看了最近内核邮件列表上的争论两边都有点极端。反AI的人说AI生成的代码都是垃圾——这不对。AI写的代码在很多场景下够用甚至有时比新手写的更好。如果你一味排斥就是在浪费工具。挺AI的人说AI写的代码跟人类写的没区别——这也不对。AI写代码的方式跟人类有本质区别它没有意图不理解上下文不关心长期维护。它只是在做最可能的下一行的预测。这对于系统编程来说是非常危险的。以我20年的从业经历来看最大的一条经验是工具不决定代码质量写代码的人对代码的理解深度才决定质量。AI是个写代码的好工具但它不会对你的代码负责。而嵌入式开发里你写的每一行代码都对应着物理世界里的一个后果。用AI可以但别忘了——当设备在现场出了事客户不会去找OpenAI或者xAI。他来找你。你可以用AI帮你写代码但别指望AI帮你背锅。