【CSDN 编者按】在 AI 赋能开发的当下，“用 AI 写代码”早已不是新鲜事，但能让AI从零搞定一个系统原生不支持的硬件驱动，仍是不少开发者眼中的“进阶操作”。本文作者将一台吃灰的 2016 款 MacBook Pro 变废为宝，以 FreeBSD 系统适配 BCM4350 无线芯片为目标，完整记录了从“直接让 AI 移植 Linux 驱动失败”，到“让 AI 写规范、定方案、迭代开发”的全过程，最终成功实现可用的FreeBSD内核模块。

我那台 2016 年的 MacBook Pro，已经在柜子里吃灰很久了。

这台机器有著名的“Flexgate”屏线问题，日常使用价值不大。于是我一直在想：不如把它当成实验机，折腾一下 FreeBSD —— 一个我关注了很多年，却始终没有真正上手的操作系统。

去年假期期间，正好赶上 FreeBSD 15 发布，我终于抽出时间把这台旧 MacBook 装了起来。

但我没想到，这件事最后会演变成一次完整的「AI 写驱动」实战。

背景：FreeBSD 不支持 BCM4350

2016 款 MacBook Pro 用的是博通 BCM4350 Wi‑Fi 芯片，FreeBSD 本身并不原生支持。

在 FreeBSD 论坛上，比较常见的解决方案是使用 wifibox：跑一个极小的 Linux 虚拟机，把 PCI Wi-Fi 设备直通进去，让 Linux 用 brcmfmac 驱动管理这块芯片。brcmfmac 是 Linux 下博通 FullMAC 系列芯片的驱动（ISC 协议）。它会把 802.11 帧传输、WPA 加解密这类工作卸载到芯片内部的固件里，驱动和操作系统只做上层管理。

从理论上讲，如果我们要给 BCM4350 写一个 FreeBSD 原生内核模块，思路听起来很完美：固件和驱动的职责是分离的，FreeBSD 对其他已支持无线设备的「管理逻辑」已经现成，我们只需要把一部分 Linux 上的「粘合代码」移植到 FreeBSD 就行。

从理论上讲，如果要为 BCM4350 写一个 FreeBSD 原生驱动：FreeBSD 已经具备 Wi-Fi 管理框架，固件负责大量底层逻辑，而剩下的主要是“胶水代码”移植——忽略一堆细节的话，这事听起来好像并不复杂，对吧？

第一幕：直接让 AI 移植 Linux 代码，结果崩麻了

到了 2026 年，一听到「把一堆代码从 A 系统移植到 B 系统」，最本能的零级思路当然是：上 AI。

于是，我从 Linux 源码里把 brcmfmac 目录克隆下来，然后让 Claude Code 把它改成 FreeBSD 可用版本。FreeBSD 本身已经有 LinuxKPI 兼容层，可以跑 Linux 内核驱动。我还特意让 Claude 参考 iwlwifi 驱动（Intel 无线网卡的 softmac 驱动），告诉它：“照这个方式做。”

一开始看起来真的能成 ——Claude 也是这么跟我说的。模块确实编译过了，但完全无效。毕竟，测试用的虚拟机里根本没有真实硬件。等我把 PCI 设备直通进虚拟机，尝试加载驱动去驱动芯片，问题立刻爆炸：

● 内核直接 panic

● Claude 修好 panic 后，又发现驱动「啥也不干」

● AI 拼命在代码里加 #ifdef __FreeBSD__

● 抱怨 LinuxKPI 功能缺失

● 不断构建 FreeBSD shim 和回调

● 还警告我：这项目会变得极其复杂、一团乱麻

最后，驱动还是反复 panic，所以这条路基本走死了。

第二幕：不直接改代码，先让 AI 写一份「芯片驱动说明书」

折腾好几轮后，AI 生成的 diff 已经大到我不想看了，但驱动离能用还差十万八千里。

刚好那段时间，Armin Ronacher 分享了他用 Claude Opus 和 PI Agent 从零做游戏的经验。视频里提到，用 PI 编码代理比直接用 Claude Code 效率高得多，这也让我意识到：我之前的思路太直球了。

brcmfmac 驱动代码量不小，支持好几代 Wi‑Fi 适配器、各种功能。但我的需求其实不多：

● 只针对 BCM4350 这一颗芯片

● 只走 PCI

● 只做 Wi‑Fi 客户端

于是我换了打法：不再直接让 AI 改代码，而是新开一个 PI 会话，让代理先给我写一份详细的 brcmfmac 工作规范，重点聚焦 BCM4350。

我明确要求：这份规范的目标读者是 clean-room 实现环境中的工程师，需要讲到“bit 级别”且结构清晰。我简单定了一下文档结构，就让 AI 疯狂输出。几轮下来，AI 直接给我整了一本11 章的驱动说明书：

当然，不能直接相信 AI 写的东西。

我又新开干净的 PI 会话，让 Codex 模型去校对这份规范：「源码是唯一事实，规范必须验证，补上缺漏、修正错误。」AI 真的找出好几处问题，还提了一堆优化。

但我还是不放心，又开了一轮会话，让 Opus 再复核一遍修正内容。后来我还顺手用几个模型轮流跑了这个校对流程：Opus 4.5、4.6、Codex 5.2、Gemini 3 Pro 预览版。以我的体验来看：Gemini 幻觉最严重——还挺可惜的，这模型写简单代码其实不错，还有免费额度能用。

最终，我得到了一份“相对可信”的驱动规范。

第三幕：拿着说明书，让 AI 从零写 FreeBSD 原生驱动

有了规范，我开了个全新项目，只丢给 AI 一份文档：「我们要给 BCM4350 从零写一个全新的 FreeBSD 驱动。」我让代理先别着急写代码，先把关键决策点列出来跟我确认，比如：

● 驱动放内核源码树里吗？

● 用 C 语言写吗？

● 依赖 LinuxKPI 吗？

我还要求：把所有决策都写到项目文档里，在 AGENTS.md 里显式引用。

有意思的是，和真实项目一样，不是所有决策都会坚持到最后。比如最开始我让 AI 基于 linuxkpi 和 linuxkpi_wlan 开发，觉得这样移植更简单。跑了几轮发现并不顺手，我直接让 AI 删掉 LinuxKPI，全部重构。AI 一次完成，还同步更新了决策文档。

有了规范、文档、计划，整个流程就变成了枯燥但稳定的流水线：

● 代理拥有编译机和测试虚拟机的 SSH 权限

● 虚拟机直通了 Wi‑Fi PCI 设备

● AI 按计划有条不紊地写代码、编译、测试

● 每完成一段，就把进度记到文档里

● 偶尔代码崩溃或卡死虚拟机，我会让 AI 先总结、排查、记录问题，再修复

经过很多轮低人力介入的迭代后，我得到了一个能正常工作的 FreeBSD BCM4350 无线内核模块，其功能包括：Wi‑Fi 扫描、2.4G / 5G 连接和WPA/WPA2 认证。

我把代码开源在：https://github.com/narqo/freebsd-brcmfmac，里面大部分代码都不是我手敲的。目前还有一些已知问题，我正在让 AI 代理慢慢修复。同时我也建议各位：这个项目除了学习、测试、实验，别拿来干别的。

网友在 Hacker News 上吵翻了，我统一回应一下

这篇分享发出去后，在Hacker News 上引发了一波存在主义讨论，焦点集中在这几点：

1. 驱动许可证合规吗？

说实话，我不想掺和这件事。只要有人告诉我这类 AI 生成的代码该怎么合规授权，我就照着做。AI 默认没给我加协议，我现在用的是 ISC 协议，因为原版 Linux brcmfmac 就是 ISC。

2. 驱动还没写完，有啥价值？

软件工程里，几乎没有什么东西是真正「完成」的。我们写代码，别人找 bug、找漏洞、处理边界情况，然后迭代。至少在 2026 年，AI 编码也没改变这个基本逻辑。AI 只是加快了代码产出的环节，就像之前各种工具提升协作、debug 效率一样。

3. 真正的价值在哪里？

这台老旧的 MacBook 没什么价值，这个驱动目前也没什么实际价值，但这段经历很有价值。

从「直接让 Claude 移植代码 = 不行」，到「AI 代理需要规划、记录、迭代才能推进复杂项目」，而且全程我自己并没有写一大堆冗长的 Markdown 文档，AI 帮我完成了工程管理层面的工作——这才是最有价值的部分。