Google 用 AI 把 C 語言程式碼大規模改寫成 Rust:記憶體安全的成本曲線，正在被改寫
Google 在 Bug Hunters 部落格發表「Scaling Memory Safety」,說明如何以 AI 輔助把 C/C++ 依賴函式庫重寫為 Rust。這不只是工具更新，而是第一次讓「還清三十年記憶體安全債務」在經濟上變得可行。對以韌體與嵌入式系統立足全球供應鏈的台灣，這條遷移路徑遲早會變成客戶的硬性要求。
一場三十年的債務，出現了新的償還工具
全球資安界吵了十年的老問題:大約七成的嚴重安全漏洞源自記憶體安全缺陷，而絕大多數關鍵基礎軟體——作業系統核心、瀏覽器、加密函式庫——仍建立在 C/C++ 之上。白宮、微軟、Google 都曾呼籲改用 Rust 等記憶體安全語言，但真正動手的人一直很少。
原因很實際:重寫一個穩定運作二十年的 C 函式庫，成本高、風險高、商業誘因低。工程界心知肚明這筆債該還，卻沒有還得起的工具。
Google 的「Scaling Memory Safety」(https://bughunters.google.com/blog/scaling-memory-safety) 提出的解法，是把改寫工作交給 AI:讓模型承擔大量機械式的翻譯與介面膠合，人類工程師聚焦在驗證、測試與 API 設計。核心邏輯不在「AI 會寫程式」，而在「AI 把重寫的邊際成本壓低到企業願意負擔的水準」。
關鍵 1:瓶頸從「寫」移到「驗」
改寫 C 程式碼最難的从来不是產出新程式，而是證明新程式與舊程式行為一致。這也是為何此類計畫強調模糊測試、差異測試與漸進式替換——先包一層 Rust 介面，讓舊系統逐步換軌，而非一次砍掉重練。AI 負責量，人負責質，分工就此翻轉。
關鍵 2:從程式庫到供應鏈的連鎖效應
個別函式庫完成遷移後，效應會沿依賴鏈放大。當主流加密或壓縮庫出現可信的 Rust 版本，下游的作業系統、雲端服務、嵌入式裝置才有換軌的選項。反過來說，供應商若拿不出記憶體安全方案，未來在政府標案與大型採購中可能直接出局——美國部分聯邦採購已朝此方向傾斜。
競爭版圖:三條路線並行
| 陣營 | 路線 | 現況 |
|---|---|---|
| AI 輔助大規模改寫 | 已發布方法論並實際用於內部依賴 | |
| Microsoft | 核心元件漸進 Rust 化 | Windows 元件逐步移植，強調重點防護 |
| 開源社群 | 人工重寫為主 | 進度慢但品質受信賴，如 rustls、ripgrep 生態 |
對台灣的意義:韌體大國躲不掉這一關
台灣的競爭力有相當一塊藏在韌體與驅動程式裡——網通設備、工業電腦、邊緣裝置的底層程式碼，絕大多數仍是 C。當國際大廠開始要求供應鏈導入記憶體安全語言，台灣廠商面對的不是「要不要學 Rust」的技術問題，而是能否跟上一條正在加速的遷移曲線。AI 輔助改寫工具的成熟，對工程資源有限的中型台廠反而是好消息:門檻正在下降。
三種情境
樂觀:三年內主流 C 函式庫完成 Rust 替代，新專案預設記憶體安全。基準:遷移集中在高價值目標，舊系統長期共存。悲觀:AI 產出的改寫碼驗證不足，反而引入新漏洞，社群信任倒退。
我可能錯在哪裡
此分析假設 AI 改寫的正確率足以支撐大規模部署，但素材僅為方法論描述，實際通過長期實戰驗證的案例仍有限。若驗證工具進度跟不上生成速度，整條路線可能停在小眾應用。