AI 做 driver 開發這種苦工,成了,但有個前提
最近看到兩個案例,讓我對「AI 能不能做 systems programming」這個問題改觀了不少。
第一個是有工程師讓 AI Agent 幫他寫 FreeBSD 的 Wi-Fi driver 規格書(clean-room spec)。整個工法是先產出 11 章的規格文件,把 BCM4350 晶片的行為、firmware 跟 driver 的互動方式全部整理清楚,再用另一個 model 對照原始碼抓錯、iterate。spec → review → iterate,沒有要 AI 直接產 code。
第二個是 Ladybird 瀏覽器把 LibJS 從 C++ 移植到 Rust,用 Claude Code 加 Codex 做大量翻譯,但要求兩個版本 byte-for-byte 輸出一致,跑完 test262 加 regression tests,零回歸。整個過程還用 lockstep 模式逐段比對每段 JS 的行為。
我在博士班研究 multi-agent systems,看了這兩個案例覺得有點驚訝。這已經不是「AI 幫你補全幾行 code」的層次了。
Systems programming 的難點,是「看起來跑了就好」永遠不夠。Driver 如果在 edge case 吃封包,你可能半個月才發現。所以這兩個案例都有一個共同點:把可驗證性推到最高。spec 讓你可以 review;byte-for-byte output + test suite 讓你可以 diff;lockstep 模式讓你可以逐段比對。
有點像我論文裡的 formal verification 思維。不是希望 AI 不出錯,是把出錯的邊界清楚定義出來,讓錯誤在你能管控的地方發生。
反過來說,那些「感覺差不多就好」的任務,才是 hallucination 最容易出事的地方。叫它幫你起草信件,說錯了你看一眼就知道。叫它處理 interrupt handler 的 edge case,它信心滿滿地吐一段「看起來正確」的 code,你就完了。
所以我現在對 AI 做 systems work 的看法是:跟 AI 夠不夠聰明沒那麼大關係,更關鍵的是你有沒有給它足夠的 grounding。
話說念了這麼多年 formal methods,沒想到最後反而是這些最基礎的工程素養讓 AI 能用上。博士學位可能真的快值錢了(大概
作者:十年大博士