[C/C++] 借助AI代理为FreeBSD系统实现BCM4350 Wi-Fi驱动适配实战

在AI深度参与软件开发的当下，让AI生成代码片段已不稀奇。然而，指挥AI从无到有地为一个操作系统“凭空”实现其原生不支持的硬件驱动，仍是许多开发者眼中颇具挑战的进阶操作。本文将分享我如何让一台闲置的2016款MacBook Pro重获新生，目标是在FreeBSD系统上驱动其内置的博通BCM4350无线芯片。整个过程并非一蹴而就，完整记录了从“直接让AI移植Linux驱动惨遭失败”，到“指挥AI先写规范、再做规划、最后迭代开发”的策略转变，并最终成功获得了一个可工作的FreeBSD内核模块。

我的那台2016年MacBook Pro，因为著名的“Flexgate”屏幕排线问题，已经在家里的柜子里吃灰很久了。它本身的日常使用价值有限，所以我一直琢磨着把它变成一台实验机，折腾一下我关注多年却从未深入使用的FreeBSD。

去年假期，恰逢FreeBSD 15发布，我终于抽时间把这台旧Mac装上了新系统。但我没想到，这个简单的决定，最终演变成了一次完整的「AI驱动开发」实战。

背景：FreeBSD不支持BCM4350

2016款MacBook Pro使用的是博通BCM4350 Wi-Fi芯片，而FreeBSD本身并不提供对它的原生支持。

在FreeBSD社区论坛上，一个比较常见的解决方案是使用wifibox：运行一个极简的Linux虚拟机，将PCIe Wi-Fi设备直通进去，然后利用Linux下的brcmfmac驱动来管理这块芯片。brcmfmac是Linux下博通FullMAC系列芯片的驱动（采用ISC协议）。它的特点是将802.11帧传输、WPA加解密这类繁重工作卸载到芯片内部的固件中完成，驱动和操作系统主要负责上层管理。

从理论上讲，如果我们要为BCM4350编写一个FreeBSD原生内核模块，思路听起来很美好：固件和驱动的职责是分离的，FreeBSD对其他已支持的无线设备的管理框架是现成的，我们似乎只需要把Linux上那部分“胶水代码”移植到FreeBSD的框架下即可。

忽略掉海量的细节后，这件事听起来好像并不太难，对吧？

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

到了2026年，一听到“把一堆代码从A系统移植到B系统”，最本能、最直接的想法当然是：让AI来干。

于是，我从Linux内核源码树里把brcmfmac目录克隆了下来，然后直接扔给Claude Code，要求它将其改造成一个能在FreeBSD上使用的版本。考虑到FreeBSD本身提供了LinuxKPI兼容层，可以用于运行部分Linux内核驱动，我还特意让Claude参考了iwlwifi驱动（Intel无线网卡的softmac驱动）的实现方式，告诉它：“就照着这个路子来。”

一开始，一切看起来都很有希望——Claude自己也这么认为。模块确实成功编译了，但这毫无意义，因为我的测试虚拟机里根本没有真实的硬件。当我把PCIe设备直通进虚拟机，尝试加载这个驱动去驱动真实芯片时，问题立刻像烟花一样炸开了：

• 内核直接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这一颗特定芯片。
• 只走PCIe总线。
• 只需要实现Wi-Fi客户端（Station）功能，而不是AP模式。

于是我彻底改变了策略：不再直接让AI去修改庞大的现有代码，而是开启了一个全新的PI会话，给代理下达了全新的任务：为我撰写一份详尽的brcmfmac驱动工作规范，并且必须聚焦于BCM4350。

我明确要求：这份规范的目标读者是身处“净室”（clean-room）实现环境中的工程师，文档需要讲解到“比特级别”的细节，并且结构必须清晰。我简单划定了一个文档大纲，然后就放手让AI开始“疯狂输出”。经过几轮迭代，AI直接给我整出了一本多达11章的驱动“说明书”：

% ls --tree spec/
spec
├── 00-overview.md
├── 01-data-structures.md
├── 02-bus-layer.md
├── 03-protocol-layer.md
├── 04-firmware-interface.md
├── 05-event-handling.md
├── 06-cfg80211-operations.md
├── 07-initialization.md
├── 08-data-path.md
├── 09-firmware-commands.md
└── 10-structures-reference.md

当然，我们不能直接相信AI生成的一切。

我又开启了一个干净的PI会话，让Codex模型去严格校对这份规范：“源码是唯一的事实来源，规范必须经过验证，请补全遗漏，修正错误。” AI确实找出了好几处问题，并提出了一系列优化建议。

但我还是不放心，于是又开启了一轮会话，让Opus模型对修正后的内容进行复核。后来，我甚至顺手用多个不同的模型轮流跑了一遍这个校对流程：Opus 4.5、Opus 4.6、Codex 5.2，以及Gemini 3 Pro预览版。以我的个人体验来看，Gemini产生的“幻觉”（胡编乱造）最为严重——这有点可惜，因为它在生成简单代码方面其实不错，而且还有免费额度可用。

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

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

有了这份相对可靠的规范，我开启了一个全新的项目，只向AI代理扔去一份简单的任务说明：“我们要为BCM4350从零开始编写一个全新的FreeBSD驱动。” 我要求代理先不要急于动手写代码，而是必须先把所有关键的技术决策点列出来与我确认，例如：

• 驱动是放在FreeBSD内核源码树内还是树外？
• 使用C语言编写吗？
• 是否依赖LinuxKPI兼容层？

我还特别强调：必须将所有决策明确记录在项目文档中，并在AGENTS.md文件里显式引用这些决策。

有意思的是，和真实的软件项目一样，并非所有初期决策都能贯彻始终。例如，最初我让AI基于linuxkpi和linuxkpi_wlan进行开发，认为这样移植会更简单。但在实际推进几轮后，我发现这个路径并不顺手，于是果断下令让AI彻底删除所有LinuxKPI相关代码，全部重构为纯FreeBSD原生实现。AI一次就完成了这个重大变更，并且同步更新了决策文档，记录下了这次架构调整。

拥有了规范、文档和明确的计划后，整个开发流程就变成了一条枯燥但稳定的流水线：

• AI代理拥有编译机和测试虚拟机的SSH权限。
• 测试虚拟机中已经直通了Wi-Fi PCIe设备。
• AI按照计划，有条不紊地编写代码、远程编译、加载测试。
• 每完成一个阶段性模块，就将进度记录到文档中。
• 偶尔代码会导致内核崩溃或虚拟机卡死，我会要求AI先总结现象、排查问题、记录日志，然后再进行修复。

经过多轮这种低人力介入的迭代后，我得到了一个能够正常工作的FreeBSD BCM4350无线网卡内核模块，其功能包括：Wi-Fi网络扫描、连接2.4GHz/5GHz网络，以及通过WPA/WPA2认证。

我把这个开源实战项目的代码托管在GitHub上：https://github.com/narqo/freebsd-brcmfmac，里面绝大部分代码都不是我亲手敲出来的。目前它仍然存在一些已知问题（例如电源管理），我正在指挥AI代理慢慢地修复它们。同时我也必须声明：这个项目仅供学习、测试和实验目的，请勿用于任何生产环境或关键任务。

网友的热议与我的回应

这篇经历分享发出后，在Hacker News上引发了一波关于“存在主义”的讨论，焦点主要集中在以下几个方面：

1. 驱动许可证合规吗？
   说实话，我本人不想深入掺和许可证的复杂讨论。只要有人明确告诉我这类AI生成的代码应如何合规地授权，我愿意遵循。AI在生成代码时默认没有添加任何许可证，我目前为其选择了ISC许可证，主要是因为原版Linux的brcmfmac驱动使用的就是ISC协议。

2. 驱动还没写完，有啥价值？
   在软件工程领域，几乎没有什么东西是真正“完成”的。我们编写代码，然后其他人发现bug、找出安全漏洞、处理边界情况，如此循环迭代。至少在2026年的当下，AI编码也并未改变这一基本逻辑。AI只是显著加快了“代码产出”这个特定环节的速度，就像历史上版本控制、集成开发环境（IDE）和调试器提升了协作与调试效率一样。

3. 真正的价值在哪里？
   这台老旧的MacBook本身价值有限，这个尚不完善的驱动目前也缺乏广泛的实用价值。但这段经历本身极具价值。
   从“直接让Claude移植代码 = 彻底失败”，到“AI代理需要先规划、记录、再迭代才能推进复杂项目”，而且全程我本人并没有耗费精力去撰写冗长的Markdown规范或设计文档——AI代理承担了大量的工程管理与文档化工作。这种与AI协作，将其作为“具有工程管理思维的初级工程师”来指挥和迭代的范式，才是本次探索中最具启发性的部分。

你是否也有类似的、利用AI解决棘手技术问题的“神操作”经历？欢迎在云栈社区的开发者广场分享你的故事和见解，与更多技术同好一起探讨AI时代下的开发新范式。