北京
【CSDN 編者按】在 AI 賦能開發的當下，“用 AI 寫代碼”早已不是新鮮事，但能讓AI從零搞定一個系統原生不支持的硬件驅動，仍是不少開發者眼中的“進階操作”。本文作者將一臺吃灰的 2016 款 MacBook Pro 變廢為寶，以 FreeBSD 系統適配 BCM4350 無線芯片為目標，完整記錄了從“直接讓 AI 移植 Linux 驅動失敗”，到“讓 AI 寫規范、定方案、迭代開發”的全過程，最終成功實現可用的FreeBSD內核模塊。
原文鏈接：https://vladimir.varank.in/notes/2026/02/freebsd-brcmfmac/
作者 | Vladimir Varankin 翻譯 | 鄭麗媛
出品 | CSDN（ID：CSDNnews）
我那臺 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 章的驅動說明書：
└── 10-structures-reference.md 當然，不能直接相信 AI 寫的東西。
我又新開干凈的 PI 會話，讓 Codex 模型去校對這份規范：「源碼是唯一事實，規范必須驗證，補上缺漏、修正錯誤?！笰I 真的找出好幾處問題，還提了一堆優化。
但我還是不放心，又開了一輪會話，讓 Opus 再復核一遍修正內容。后來我還順手用幾個模型輪流跑了這個校對流程：Opus 4.5、4.6、Codex 5.2、Gemini 3 Pro 預覽版。以我的體驗來看：Gemini 幻覺最嚴重——還挺可惜的，這模型寫簡單代碼其實不錯，還有免費額度能用。
最終，我得到了一份“相對可信”的驅動規范。
第三幕：拿著說明書，讓 AI 從零寫 FreeBSD 原生驅動
有了規范，我開了個全新項目，只丟給 AI 一份文檔：「我們要給 BCM4350 從零寫一個全新的 FreeBSD 驅動?！刮易尨硐葎e著急寫代碼，先把關鍵決策點列出來跟我確認，比如：
● 驅動放內核源碼樹里嗎？
● 用 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 幫我完成了工程管理層面的工作——這才是最有價值的部分。
未來沒有前后端，只有 AI Agent 工程師。
這場十倍速的變革已至，你的下一步在哪？
4 月 17-18 日，由 CSDN 與奇點智能研究院聯合主辦「2026 奇點智能技術大會」將在上海隆重召開，大會聚焦 Agent 系統、世界模型、AI 原生研發等 12 大前沿專題，為你繪制通往未來的認知地圖。
成為時代的見證者，更要成為時代的先行者。
奇點智能技術大會上海站，我們不見不散！
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
