背景
InfoQ 記者 Olimpiu Pop 根據 Google 技術文章報導，Google 安全團隊已嘗試用大型語言模型與自動化驗證流程，把以 C 語言撰寫的關鍵相依函式庫改寫為 Rust。第一個目標是 giflib，這是一套處理 GIF 圖片的函式庫，程式碼約 3,000 行，雖然規模不大，卻經常直接解析使用者提供的外部資料。對影像解碼器來說，輸入內容可能包含刻意構造的畸形檔案，只要邊界檢查或記憶體管理出錯，就可能形成遠端攻擊入口。
這次重寫之所以受到關注，是因為 Google 並沒有要求呼叫端修改 API，而是交付一個 ABI 相容的可直接替換函式庫。ABI 是應用程式二進位介面，規範函式名稱、參數排列與資料結構如何在二進位層級互動；只要 ABI 保持一致，既有程式就能連結新的 Rust 共用函式庫，不必因為底層語言更換而重寫。Google 表示，記憶體毀損錯誤約占成熟 C 與 C++ 程式碼中嚴重安全漏洞的 70%，因此若能以 Rust 取代高風險元件，便有機會從語言設計層面消除整類問題，而不是等個別漏洞被發現後再修補。
核心。
核心內容
負責這項工作的工程師 Bastian Kersting 與 Max Hils 採用三階段流程。第一步是使用 Gemini 進行單次大規模提示，要求模型把 giflib 的 C 程式邏輯完整移植成 Rust。這個作法能快速產生接近完整的初版，但語法看起來可編譯，不代表行為已經與原版完全相同。
第二階段處理 FFI，也就是外部函式介面。由於新的 Rust 函式庫必須對 C 程式公開原本的函式名稱與資料結構，邊界上仍會出現原生指標、unsafe 區塊與明確的物件釋放責任。原始 C 指標不像 Rust 參照一樣攜帶所有權、生命週期與可變性資訊，因此在封裝成指標容器或呼叫 Rust 方法之前，工程師必須檢查指標是否可能為空、物件由哪一側釋放，以及多執行緒同時存取時是否安全。Google 最初的模型輸出也曾產生不健全的指標語意，需要人工修正。
第三階段是建立自動回饋迴圈。當差異測試發現 Rust 與 C 版本的輸出、錯誤碼或邊界行為不一致，系統會把失敗案例與追蹤資料交給模型產生修補，再重新執行測試。這種架構的重點不是假設 AI 一次就能寫對，而是把 AI 放在可重複驗證的環境中，由測試結果持續縮小語意偏差。
驗證方式
Google 為 Rust 版本建立了大規模等價性驗性驗證。團隊先以超過 3,000 萬個真實 GIF 檔案執行迴歸解碼，確認新舊實作在輸出上逐位元一致。同時，差異模糊測試工具連續六天把相同輸入送進 C 與 Rust 兩個執行環境，累計執行約 2 億次，期間未觀察到功能性偏移。差異模糊測試的價值在於它不只尋找程式當機，也會比較兩套實作在異常輸入下是否產生不同結果。
測試流程還加入了對抗式 LLM 分析，讓模型檢查兩個程式碼儲存庫中可能存在、但一般測試不易覆蓋的行為分歧。這套管線找出了 LZW 解壓縮器中的邊界案例；LZW 是 GIF 用來壓縮像素資料的演算法，其解碼器必須謹慎處理壓縮碼表與邊界條件。驗證系統也發現，Google 先前對原 C 程式碼所做的一個內部修補，曾引入尚未處理的越界寫入問題。
更具代表性的結果發生在部署準備期間。一名外部安全研究人員在上游 giflib 發現堆積區越界寫入漏洞，後來被編列為 CVE-2026-26740。使用 Google 編譯之 Rust 替換版本的正式環境節點，在漏洞公開編列前已不具備相同的記憶體操作路徑，因此對該缺陷具有結構性免疫。這不是單純修掉一個 CVE，而是展示語言層級的記憶體安全保證可能提前阻斷尚未公開的漏洞。
影響與限制
Rust 的陣列與切片通常會進行邊界檢查，因此外界常質疑它可能拖慢高效能原生函式庫。Google 在全球影像解碼叢集收集的正式環境遙測資料顯示，Rust 版本的執行效能與原 C 二進位檔大致持平。更重要的是，原本需要依靠作業系統沙箱隔離解碼工作，以降低記憶體漏洞造成整個程序遭入侵的風險；改用 Rust 後，Google 能移除這層程序隔離，並降低 p99 尾端延遲。p99 代表每 100 次請求中最慢那一次的延遲水準，對大量影像服務而言，尾端延遲往往比一般平均值更能反映尖峰負載下的體驗。
不過，這個案例不代表 AI 可以無人值守地重寫所有 C 程式。FFI 邊界仍需要熟悉記憶體所有權與執行緒安全的人工審查，而逐行程式輸出即使能編譯，也可能在罕見錯誤碼、資源釋放順序或資料表狀態上產生細微偏差。把上游 C 函式庫分叉成 Rust 版本後，還要持續追蹤上游新增功能與架構修改，否則兩個儲存庫會逐漸分歧。
r/rust 與 Hacker News 的討論普遍肯定 Google 的差異模糊測試架構，特別是它能找出 Google 自己舊 C 修補中的越界寫入。不過，不少工程師也質疑單次產生完整 Rust 版本的作法，認為審查語意與修正 FFI 邊界的人力成本，可能遠高於程式生成成本。對更大、耦合更深的函式庫，另一種較穩健的路線可能是先用 c2rust 這類確定性轉譯工具保留行為，再由 AI 把結果逐步重構成安全且符合 Rust 風格的程式碼。
Google 已將成果以 giflib-rs 為名開源，作為評估自動化語言遷移的參考實作。這個案例最重要的訊號並非「AI 已能取代移植工程師」，而是當 AI 生成、ABI 相容設計、人工安全審查與高強度差異測試被整合成閉環時，小型且邊界清楚的 C 函式庫，已有可能以可控風險轉換為記憶體安全實作。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。