“2016款吃灰Mac被AI救活了！我?guī)缀鯖]寫代碼，卻‘造’出了一個(gè)能跑通的FreeBSD Wi-Fi驅(qū)動(dòng)”

【CSDN 編者按】在 AI 賦能開發(fā)的當(dāng)下，“用 AI 寫代碼”早已不是新鮮事，但能讓AI從零搞定一個(gè)系統(tǒng)原生不支持的硬件驅(qū)動(dòng)，仍是不少開發(fā)者眼中的“進(jìn)階操作”。本文作者將一臺(tái)吃灰的 2016 款 MacBook Pro 變廢為寶，以 FreeBSD 系統(tǒng)適配 BCM4350 無線芯片為目標(biāo)，完整記錄了從“直接讓 AI 移植 Linux 驅(qū)動(dòng)失敗”，到“讓 AI 寫規(guī)范、定方案、迭代開發(fā)”的全過程，最終成功實(shí)現(xiàn)可用的FreeBSD內(nèi)核模塊。

原文鏈接：https://vladimir.varank.in/notes/2026/02/freebsd-brcmfmac/

作者 | Vladimir Varankin 翻譯 | 鄭麗媛

出品 | CSDN（ID：CSDNnews）

我那臺(tái) 2016 年的 MacBook Pro，已經(jīng)在柜子里吃灰很久了。

這臺(tái)機(jī)器有著名的“Flexgate”屏線問題，日常使用價(jià)值不大。于是我一直在想：不如把它當(dāng)成實(shí)驗(yàn)機(jī)，折騰一下 FreeBSD —— 一個(gè)我關(guān)注了很多年，卻始終沒有真正上手的操作系統(tǒng)。

去年假期期間，正好趕上 FreeBSD 15 發(fā)布，我終于抽出時(shí)間把這臺(tái)舊 MacBook 裝了起來。

但我沒想到，這件事最后會(huì)演變成一次完整的「AI 寫驅(qū)動(dòng)」實(shí)戰(zhàn)。

背景：FreeBSD 不支持 BCM4350

2016 款 MacBook Pro 用的是博通 BCM4350 Wi?Fi 芯片，F(xiàn)reeBSD 本身并不原生支持。

在 FreeBSD 論壇上，比較常見的解決方案是使用 wifibox：跑一個(gè)極小的 Linux 虛擬機(jī)，把 PCI Wi-Fi 設(shè)備直通進(jìn)去，讓 Linux 用 brcmfmac 驅(qū)動(dòng)管理這塊芯片。brcmfmac 是 Linux 下博通 FullMAC 系列芯片的驅(qū)動(dòng)（ISC 協(xié)議）。它會(huì)把 802.11 幀傳輸、WPA 加解密這類工作卸載到芯片內(nèi)部的固件里，驅(qū)動(dòng)和操作系統(tǒng)只做上層管理。

從理論上講，如果我們要給 BCM4350 寫一個(gè) FreeBSD 原生內(nèi)核模塊，思路聽起來很完美：固件和驅(qū)動(dòng)的職責(zé)是分離的，F(xiàn)reeBSD 對(duì)其他已支持無線設(shè)備的「管理邏輯」已經(jīng)現(xiàn)成，我們只需要把一部分 Linux 上的「粘合代碼」移植到 FreeBSD 就行。

從理論上講，如果要為 BCM4350 寫一個(gè) FreeBSD 原生驅(qū)動(dòng)：FreeBSD 已經(jīng)具備 Wi-Fi 管理框架，固件負(fù)責(zé)大量底層邏輯，而剩下的主要是“膠水代碼”移植——忽略一堆細(xì)節(jié)的話，這事聽起來好像并不復(fù)雜，對(duì)吧？

第一幕：直接讓 AI 移植 Linux 代碼，結(jié)果崩麻了

到了 2026 年，一聽到「把一堆代碼從 A 系統(tǒng)移植到 B 系統(tǒng)」，最本能的零級(jí)思路當(dāng)然是：上 AI。

于是，我從 Linux 源碼里把 brcmfmac 目錄克隆下來，然后讓 Claude Code 把它改成 FreeBSD 可用版本。FreeBSD 本身已經(jīng)有 LinuxKPI 兼容層，可以跑 Linux 內(nèi)核驅(qū)動(dòng)。我還特意讓 Claude 參考 iwlwifi 驅(qū)動(dòng)（Intel 無線網(wǎng)卡的 softmac 驅(qū)動(dòng)），告訴它：“照這個(gè)方式做。”

一開始看起來真的能成 ——Claude 也是這么跟我說的。模塊確實(shí)編譯過了，但完全無效。畢竟，測(cè)試用的虛擬機(jī)里根本沒有真實(shí)硬件。等我把 PCI 設(shè)備直通進(jìn)虛擬機(jī)，嘗試加載驅(qū)動(dòng)去驅(qū)動(dòng)芯片，問題立刻爆炸：

● 內(nèi)核直接 panic

● Claude 修好 panic 后，又發(fā)現(xiàn)驅(qū)動(dòng)「啥也不干」

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

● 抱怨 LinuxKPI 功能缺失

● 不斷構(gòu)建 FreeBSD shim 和回調(diào)

● 還警告我：這項(xiàng)目會(huì)變得極其復(fù)雜、一團(tuán)亂麻

最后，驅(qū)動(dòng)還是反復(fù) panic，所以這條路基本走死了。

第二幕：不直接改代碼，先讓 AI 寫一份「芯片驅(qū)動(dòng)說明書」

折騰好幾輪后，AI 生成的 diff 已經(jīng)大到我不想看了，但驅(qū)動(dòng)離能用還差十萬八千里。

剛好那段時(shí)間，Armin Ronacher 分享了他用 Claude Opus 和 PI Agent 從零做游戲的經(jīng)驗(yàn)。視頻里提到，用 PI 編碼代理比直接用 Claude Code 效率高得多，這也讓我意識(shí)到：我之前的思路太直球了。

brcmfmac 驅(qū)動(dòng)代碼量不小，支持好幾代 Wi?Fi 適配器、各種功能。但我的需求其實(shí)不多：

● 只針對(duì) BCM4350 這一顆芯片

● 只走 PCI

● 只做 Wi?Fi 客戶端

于是我換了打法：不再直接讓 AI 改代碼，而是新開一個(gè) PI 會(huì)話，讓代理先給我寫一份詳細(xì)的 brcmfmac 工作規(guī)范，重點(diǎn)聚焦 BCM4350。

我明確要求：這份規(guī)范的目標(biāo)讀者是 clean-room 實(shí)現(xiàn)環(huán)境中的工程師，需要講到“bit 級(jí)別”且結(jié)構(gòu)清晰。我簡(jiǎn)單定了一下文檔結(jié)構(gòu)，就讓 AI 瘋狂輸出。幾輪下來，AI 直接給我整了一本11 章的驅(qū)動(dòng)說明書：

└── 10-structures-reference.md  

當(dāng)然，不能直接相信 AI 寫的東西。

我又新開干凈的 PI 會(huì)話，讓 Codex 模型去校對(duì)這份規(guī)范：「源碼是唯一事實(shí)，規(guī)范必須驗(yàn)證，補(bǔ)上缺漏、修正錯(cuò)誤。」AI 真的找出好幾處問題，還提了一堆優(yōu)化。

但我還是不放心，又開了一輪會(huì)話，讓 Opus 再?gòu)?fù)核一遍修正內(nèi)容。后來我還順手用幾個(gè)模型輪流跑了這個(gè)校對(duì)流程：Opus 4.5、4.6、Codex 5.2、Gemini 3 Pro 預(yù)覽版。以我的體驗(yàn)來看：Gemini 幻覺最嚴(yán)重——還挺可惜的，這模型寫簡(jiǎn)單代碼其實(shí)不錯(cuò)，還有免費(fèi)額度能用。

最終，我得到了一份“相對(duì)可信”的驅(qū)動(dòng)規(guī)范。

第三幕：拿著說明書，讓 AI 從零寫 FreeBSD 原生驅(qū)動(dòng)

有了規(guī)范，我開了個(gè)全新項(xiàng)目，只丟給 AI 一份文檔：「我們要給 BCM4350 從零寫一個(gè)全新的 FreeBSD 驅(qū)動(dòng)。」我讓代理先別著急寫代碼，先把關(guān)鍵決策點(diǎn)列出來跟我確認(rèn)，比如：

● 驅(qū)動(dòng)放內(nèi)核源碼樹里嗎？

● 用 C 語言寫嗎？

● 依賴 LinuxKPI 嗎？

我還要求：把所有決策都寫到項(xiàng)目文檔里，在 AGENTS.md 里顯式引用。

有意思的是，和真實(shí)項(xiàng)目一樣，不是所有決策都會(huì)堅(jiān)持到最后。比如最開始我讓 AI 基于 linuxkpi 和 linuxkpi_wlan 開發(fā)，覺得這樣移植更簡(jiǎn)單。跑了幾輪發(fā)現(xiàn)并不順手，我直接讓 AI 刪掉 LinuxKPI，全部重構(gòu)。AI 一次完成，還同步更新了決策文檔。

有了規(guī)范、文檔、計(jì)劃，整個(gè)流程就變成了枯燥但穩(wěn)定的流水線：

● 代理擁有編譯機(jī)和測(cè)試虛擬機(jī)的 SSH 權(quán)限

● 虛擬機(jī)直通了 Wi?Fi PCI 設(shè)備

● AI 按計(jì)劃有條不紊地寫代碼、編譯、測(cè)試

● 每完成一段，就把進(jìn)度記到文檔里

● 偶爾代碼崩潰或卡死虛擬機(jī)，我會(huì)讓 AI 先總結(jié)、排查、記錄問題，再修復(fù)

經(jīng)過很多輪低人力介入的迭代后，我得到了一個(gè)能正常工作的 FreeBSD BCM4350 無線內(nèi)核模塊，其功能包括：Wi?Fi 掃描、2.4G / 5G 連接和WPA/WPA2 認(rèn)證。

我把代碼開源在：https://github.com/narqo/freebsd-brcmfmac，里面大部分代碼都不是我手敲的。目前還有一些已知問題，我正在讓 AI 代理慢慢修復(fù)。同時(shí)我也建議各位：這個(gè)項(xiàng)目除了學(xué)習(xí)、測(cè)試、實(shí)驗(yàn)，別拿來干別的。

網(wǎng)友在 Hacker News 上吵翻了，我統(tǒng)一回應(yīng)一下

這篇分享發(fā)出去后，在Hacker News 上引發(fā)了一波存在主義討論，焦點(diǎn)集中在這幾點(diǎn)：

1. 驅(qū)動(dòng)許可證合規(guī)嗎？

說實(shí)話，我不想摻和這件事。只要有人告訴我這類 AI 生成的代碼該怎么合規(guī)授權(quán)，我就照著做。AI 默認(rèn)沒給我加協(xié)議，我現(xiàn)在用的是 ISC 協(xié)議，因?yàn)樵?Linux brcmfmac 就是 ISC。

2. 驅(qū)動(dòng)還沒寫完，有啥價(jià)值？

軟件工程里，幾乎沒有什么東西是真正「完成」的。我們寫代碼，別人找 bug、找漏洞、處理邊界情況，然后迭代。至少在 2026 年，AI 編碼也沒改變這個(gè)基本邏輯。AI 只是加快了代碼產(chǎn)出的環(huán)節(jié)，就像之前各種工具提升協(xié)作、debug 效率一樣。

3. 真正的價(jià)值在哪里？

這臺(tái)老舊的 MacBook 沒什么價(jià)值，這個(gè)驅(qū)動(dòng)目前也沒什么實(shí)際價(jià)值，但這段經(jīng)歷很有價(jià)值。

從「直接讓 Claude 移植代碼 = 不行」，到「AI 代理需要規(guī)劃、記錄、迭代才能推進(jìn)復(fù)雜項(xiàng)目」，而且全程我自己并沒有寫一大堆冗長(zhǎng)的 Markdown 文檔，AI 幫我完成了工程管理層面的工作——這才是最有價(jià)值的部分。

未來沒有前后端，只有 AI Agent 工程師。

這場(chǎng)十倍速的變革已至，你的下一步在哪？

4 月 17-18 日，由 CSDN 與奇點(diǎn)智能研究院聯(lián)合主辦「2026 奇點(diǎn)智能技術(shù)大會(huì)」將在上海隆重召開，大會(huì)聚焦 Agent 系統(tǒng)、世界模型、AI 原生研發(fā)等 12 大前沿專題，為你繪制通往未來的認(rèn)知地圖。

成為時(shí)代的見證者，更要成為時(shí)代的先行者。

奇點(diǎn)智能技術(shù)大會(huì)上海站，我們不見不散！