一台2016年的MacBook Pro，在柜子里吃灰很久了。
这机器有个通病叫“Flexgate”，屏幕排线容易坏，基本就是个电子垃圾。主人Vladimir突发奇想，想给它装个FreeBSD系统当个实验机。
结果卡住了。卡在Wi-Fi上。
FreeBSD不支持这台电脑里的Broadcom BCM4350网卡。
这要是放在以前，故事可能就结束了——要么忍，要么买张外置网卡。
但现在是2026年，Vladimir决定让AI试试。
结局是：驱动写出来了，能用，而他自己一行代码都没写。
更有意思的是，他最后还特意补了一刀：“强烈不建议在生产环境使用。”
AI第一次碰壁，场面一度很尴尬
说实话，现在的AI写代码，很多时候就像是给新手司机一辆法拉利——看着猛，起步容易熄火。
Vladimir一开始也是这么想的。既然Linux有现成的驱动，FreeBSD又有兼容Linux驱动的LinuxKPI层，那让AI把代码“搬”过来不就行了？
他把Linux驱动的源码扔给Claude Code，指着Intel无线网卡的例子说：“照着这个改。”
刚开始，AI信誓旦旦说没问题。代码确实编译通过了，看起来像那么回事。
但一上真机，瞬间打脸。
内核直接崩溃。
AI倒是挺勤快，开始疯狂打补丁，到处加 #ifdef FreeBSD 的宏定义，一边改一边抱怨FreeBSD的兼容层这不行那不行。
改到最后，补丁比原码还厚，驱动还是跑不起来。
这时候Vladimir意识到，让AI直接“翻译”代码，这条路走不通。
先让AI写本书
这是个很有意思的转折点。
一般人遇到这种情况，要么硬着头皮继续修，要么直接放弃。Vladimir换了个思路。
他受了一位开发者的启发，停掉了手里的活，重新开了一个AI会话。这次他没让AI写代码，而是下了一道指令：
“给我写一份详细的规格说明书，解释这个驱动是怎么工作的，细致到每一个比特。”
他还特意强调，这份说明书是给“在初始环境里重新实现的开发者”看的。
AI这次没让他失望。几轮交互后，吐出了一本“11章的书”：
spec
├── 00-overview.md
├── 01-data-structures.md
├── 02-bus-layer.md
├── 03-protocol-layer.md
...
└── 10-structures-reference.md
当然，AI的话不能全信。
Vladimir又开了一个新会话，专门用来“查作业”。让Codex模型去核对说明书和源码是否一致，再用Opus模型去复核Codex的修改。
用他的话说，这是一场“拖延症练习”。他试了Opus 4.5、Opus 4.6、Codex 5.2，还有Gemini 3 Pro。
吐槽一句：Gemini幻觉最多，虽然免费，但在这事儿上不太靠谱。
“莫得感情的写码机器”
有了说明书，事情就变得“枯燥”了。
Vladimir又开了一个全新的项目。这次他没给源码，只给了那本说明书。
他对AI说：“我们要基于这个规格，给BCM4350写个全新的FreeBSD驱动。”
AI反问了一堆问题：代码放内核源码树里吗？用C写吗？要不要依赖LinuxKPI？里程碑怎么定？
Vladimir让AI把这些决策全记下来，写在项目文档里。
这里有个小插曲。起初他想偷懒，让AI继续用Linux的兼容层。结果写了几个版本发现不对劲，果断让AI把LinuxKPI删了，用FreeBSD原生接口重写。
AI二话不说，一次性重构完毕，顺便更新了决策文档。
之后的流程，就像流水线一样：
AI通过SSH连上测试机，按里程碑一步步写代码、编译、测试。崩了就记录问题，修好再继续。
经过无数次“无聊”的迭代，驱动跑通了。
支持扫描，支持2.4GHz/5GHz，支持WPA/WPA2认证。
代码已经扔到了GitHub上。Vladimir在仓库说明里写得很清楚：
I didn’t write any piece of code there.
我一行代码都没写。
看起来很美，评论区却吵翻了
这事儿传出去后，有人惊呼：AI这是要解决所有操作系统的硬件兼容难题啊！
确实，以后什么显卡驱动、声卡驱动，只要有一个系统跑通了，AI理论上就能给你“搬”到另一个系统上。硬件厂商想通过不提供驱动来锁死生态，这招以后可能不太好使了。
但评论区里，也有不少人泼冷水。
一位网友直言：
花了几个月，试了三次，搞出来一个充满Bug、没人敢在生产环境用的东西。可惜很多人只看标题，就开始喊“AI已战胜人类程序员”。
这话有点扎心。
确实，如果是一个资深内核开发者，花几个月时间移植驱动，结果可能更稳定。AI虽然完成了从0到1，但这个“1”，目前还只是个半成品。
还有人提到了法律风险：GPL协议怎么算？
Linux驱动是开源的，AI“学习”了代码然后重写，这算不算衍生作品？如果新代码闭源发布，会不会吃官司？这个问题，目前还没人能给出标准答案。
代码能跑，但别急着用
老实讲，这个故事最打动我的，不是AI有多强，而是Vladimir的方法论。
他其实是在用AI做一次“人类式的项目管理”。
他没有让AI直接干苦力，而是先让AI理清逻辑、制定规范，最后才是写代码。这恰恰是很多人类程序员容易忽略的步骤——拿到需求就开干，写到一半才发现架构有问题。
AI在这里，扮演了一个不知疲倦、但需要时刻盯着的老实员工。
至于那个驱动？
Vladimir的态度很诚恳：仅供学习研究，千万别拿来当主力网卡的驱动。
毕竟，这玩意儿要是崩了，你连报错都看不了。
未来，我们可能会看到越来越多这种“缝合怪”软件。AI写的代码，人类看不懂，但能跑。
你敢把自己的数据交给没人能完全看懂的代码吗？
参考链接：
https://vladimir.varank.in/notes/2026/02/freebsd-brcmfmac/