Google 把一個約 3,000 行、負責處理 GIF 圖片的 C 函式庫改寫成 Rust，表面上像是又一則「AI 會寫程式」案例；真正值得注意的，卻不是 Gemini 產生了多少程式碼，而是 Google 如何證明新舊實作足夠接近，能放進處理不可信輸入的正式環境。這起案例更精確的主題，其實是：企業能否用 AI 降低重寫遺留軟體的成本，同時把驗證強度提高到足以承擔資安風險。
從一個小型圖片函式庫，測試大規模遷移方法
根據 InfoQ 報導，Google 選擇的對象是 giflib。它的規模不大，卻經常直接解析外部提供的圖片，記憶體越界、釋放後使用等錯誤因此可能形成攻擊入口。團隊以 Gemini 將完整邏輯轉成 Rust，並保留既有匯出符號與資料結構，目標是做出能直接取代原共享函式庫的版本，而非要求所有上層程式一起重寫。原始報導見：https://www.infoq.com/news/2026/09/c-rust-rewrite/；Google 的技術說明則見：https://bughunters.google.com/blog/scaling-memory-safety。
這裡必須區分來源事實與推論。來源確認的是一次針對 giflib 的實作與部署經驗；它並未證明任意大型 C 或 C++ 系統都能用相同成本自動轉換。合理的推論是，小而獨立、輸入輸出明確、已有大量測試樣本的函式庫，特別適合成為第一批遷移標的。
關鍵不是「翻譯」，而是建立行為裁判
一般測試只能回答新版是否通過已知案例；差分測試則把同一份輸入同時交給 C 與 Rust 版本，再比較輸出、錯誤碼及狀態變化。若結果不同，就取得可重現的失敗樣本，交由工程師或模型修正。這使舊版程式在遷移期間扮演「行為規格」，即使它原本沒有完整文件。
據 InfoQ 引述的驗證資料，Google 對超過 3,000 萬個真實 GIF 進行回歸解碼，並讓差分模糊測試連續執行六天、累計超過 2 億次迭代。流程還找出 LZW 解壓縮的邊界案例，以及舊有內部 C 修補所帶入的越界寫入問題。這些數字支持「驗證規模很大」，卻不能被解讀為數學上的完全等價：模糊測試能提高發現錯誤的機率，不能證明所有可能輸入都已覆蓋。
更微妙的是，Google 公開的 giflib-rs 儲存庫本身列出數項刻意保留的差異，包括無效尺寸時設定不同錯誤碼、Rust 版會檢查寫入失敗，以及記憶體配置失敗時的處理方式不同。換言之，「語意等價」並不必然等於每個錯誤路徑逐位元相同，而是要先定義哪些差異可接受。程式碼與限制可查閱：https://github.com/google/giflib-rs。
Rust 解決一類問題，FFI 又帶回另一道邊界
giflib-rs 的核心商業邏輯沒有使用 unsafe，但為了提供相容的 C API，仍須接收來自 C 呼叫端的裸指標。Rust 編譯器無法替外部世界保證指標有效、生命週期正確或沒有多執行緒競爭。因此，ABI 相容性既是降低導入成本的條件，也是風險最集中的接縫；所有權、釋放責任與執行緒安全仍需要熟悉原系統的人審查。
這也解釋了為何 AI 的價值較像「縮短產生候選實作的時間」，而非取代資深工程師。模型可以快速搬移控制流程、資料結構與錯誤處理，但是否相容，要由編譯器、測試資料、模糊測試、效能量測與人工審查共同裁決。作者觀點是：若企業只編列生成程式碼的預算，卻沒有測試語料、可觀測性與安全審查能力，這種遷移反而可能製造更難辨識的新風險。
為何現在值得注意
這次改寫的現實意義，在於新版本不只是實驗品。InfoQ 指出，Rust 版在正式負載下維持與 C 版相當的執行效能；移除原本用來隔離圖片解碼的程序沙箱後，p99 尾端延遲反而下降。這顯示記憶體安全不一定必須以效能為代價，但效益部分來自整體架構改變，不能單獨歸功於語言。
外部漏洞資料也提供了獨立交叉驗證。Ubuntu 對 CVE-2026-26740 的紀錄指出，giflib 5.2.2 的 EGifGCBToExtension 存在緩衝區溢位，可由未妥善驗證配置大小的 Graphic Control Extension 觸發；Ubuntu 給予 8.2 的 CVSS 分數，並列出各版本修補狀態：https://ubuntu.com/security/CVE-2026-26740。Google 的 Rust 替代版本不沿用該段 C 記憶體操作，因此未受同一缺陷影響。這是特定漏洞的結果，不能延伸成「Rust 程式不會有資安漏洞」。
容易忽略的成本與台灣產業意義
最大的長期成本是分支維護。上游 C 專案新增功能、調整 ABI 或修正規格時，Rust 版本必須持續同步；若原函式庫高度依賴平台巨集、組合語言、驅動程式狀態或未定義行為，差分結果也可能難以判讀。giflib-rs 儲存庫還明確註明它不是 Google 正式支援的產品，採用者不能把公開程式碼誤認為附帶企業級維護承諾。
對台灣的韌體、網通設備、半導體工具鏈與工控團隊而言，較務實的策略不是一次重寫整套系統，而是先盤點解析外部檔案、網路封包或更新映像檔的小型 C 元件。優先選擇介面穩定、樣本充足、能讓新舊版本並行的模組，再把 AI 放在候選碼生成與失敗修補，而不是最終核准位置。
後續應觀察什麼
- giflib-rs 是否持續跟上游修補與 ABI 變更，而非停留在一次性展示。
- Google 能否把相同管線複製到規模更大、共享狀態更多的函式庫。
- 公開驗證是否增加覆蓋率、效能分布、人工審查工時與差異分類等資料。
- 企業導入後，記憶體安全事件、沙箱成本及維護負擔是否真的長期下降。
這個案例最重要的訊息不是「Gemini 已能自動把 C 變成安全的 Rust」，而是 AI 讓重寫變快之後，驗證、相容性治理與後續維護便成為真正的瓶頸。能否規模化，最後取決於組織是否建立了一套可信的裁判制度，而不是模型能否產生一份可以編譯的答案。