TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
Antigravity 把 Fortran 核心搬進 Rust，59 分鐘的功勞分帳
Google 於 11 月 3 日在 Antigravity 官方部落格公開內部壓力測試全記錄：以 Gemini 4 Argon 把 FVCOM 海洋模型的核心求解器從 Fortran 移植成 Rust，全程 59 分鐘、模擬提速 1.88 倍、100 組隨機種子數值一致到小數點後 12 位，流程並開源成 google/skills 裡的 migrate-to-rust 技能。本文拆解各數字能支持什麼結論，以及提速與抓 bug 的功勞各屬於誰。
用 AI 摘要這篇文章：
11 月 3 日，Google 在 Antigravity 官方部落格公開一場內部壓力測試的完整記錄：讓 Gemini 4 Argon 在 Antigravity（Google 的代理式開發環境，代理能自己開終端機、編譯、跑測試）裡，把 FVCOM 海洋模型的核心求解器從 Fortran 移植成 Rust，全程 59 分鐘，模擬速度提升 1.88 倍，尖峰記憶體用量減少 54%，100 組隨機種子的輸出一致到小數點後 12 位。同一天，Google 把整套流程包成開源 skill 放進 google/skills 儲存庫，任何人可以在 Antigravity 裡用一行指令呼叫。
數字很搶眼，但先把判斷講完：這場展示真正值得搬走的東西，是「對的定義先寫死」的驗收設計，不是模型跑得快。提示裡預先寫了四條硬規則，基準輸出在改寫開始前就量好了，1.88 倍的最後一哩來自編譯器剖析，六個老 bug 的偵探是 Rust 的型別系統。把功勞拆開歸位，才知道自己專案該學哪一塊。
影片早了三週，技術全文才是這則新聞
示範影片其實不是新東西。Google Antigravity 頻道上那支「Gemini 4 Argon: Modernizing 40 year code」，上傳日期是 10 月 13 日，正好是 Gemini 4 Argon 隨 Antigravity 全面開放的當天，比部落格文章早了三週。當時影片只給了結果，沒講過程；11 月 3 日 08:00 UTC 發布的這篇文章（由首席工程師 Dan Gruhl 與產品經理 Prashant Nair 署名），補上的是過程裡最值錢的部分：三階段時間分配、六個 bug 的來龍去脈、42 項測試的失敗與修復紀錄，以及一張把提速拆成三段的效能表。
| 時間 | 事件 |
|---|---|
| 2026 年 10 月 13 日 | 示範影片上傳至 Google Antigravity 頻道，與 Gemini 4 Argon 開放同日 |
| 2026 年 11 月 3 日 08:00 UTC | 技術全文發布，migrate-to-rust skill 同步進 google/skills 儲存庫 |
| 截至 11 月 5 日 | 尚無第三方團隊的重現結果；數字均出自 Google 自家測試 |
受測的 FVCOM 是有限體積社群海洋模型（Finite-Volume Community Ocean Model），由麻州大學達特茅斯分校海洋科學技術學院的 Chen 等人與伍茲霍爾海洋研究所合作開發，基礎論文發表於 2003 年的《Journal of Atmospheric and Oceanic Technology》，颶風暴潮、天氣預報與計算物理背後都有這類模型的身影。Google 形容它是 40 年等級的老程式碼，這個數字指的是 1970 到 1980 年代那批 Fortran 寫法的世代：整個儲存庫 174,774 行 Fortran 90 與 C，分散在 264 個檔案裡，單一檔案可以長到 14,000 行，全域變數交錯使用。這類程式沒有人敢動的原因很實際：方程式是幾代研究者對著實測浮標與衛星資料校準出來的，改壞一步，後面全錯。
這場展示真正想對話的人，是手上握著同類程式碼的團隊：研究機構裡維護老模擬核心的工程師、被指定「把這套 Fortran 現代化」的研究助理，以及評估該不該把代理式工具引進長時程重構作業的技術主管。對一般開發者，它是一次少見的機會，能看到廠商示範影片背後的驗收細節被完整攤開。
四條硬規則：「對」是提示裡寫死的
Antigravity 拿到的提示只有一個，附帶四條硬規則：整個 Rust 工作區強制 #![forbid(unsafe_code)]、不允許任何 unsafe 區塊；熱點模擬迴圈裡不得動態配置記憶體，資料改用同類欄位連續排列的 SoA 佈局；每個檔案不得超過 400 行，每個模組都要附可執行的文件測試；分支覆蓋率至少 95%，而且 100 組隨機種子的數值輸出要與 Fortran 原版零差異。
這四條就是整場移植的憲法。「零差異」不是口號，它被做成可執行的檢查：代理在基準擷取階段先用 gfortran -O3 編譯原版，跑 100 組隨機種子，把輸出、執行時間與記憶體用量存成黃金基準；之後每一輪改寫，都拿新結果回去跟這份基準比。59 分鐘的分配是：基準擷取 11 分鐘，全庫審計與藍圖 3 分鐘，移植、測試與最佳化 45 分鐘。審計階段掃完 264 個檔案後，代理追著每個全域變數穿過二維與三維求解迴圈，先生成一份六部分的架構藍圖（連同記錄下來的潛在缺陷）才動手寫 Rust，最終核心求解器落在 13 個模組、每個不到 240 行。
Google 特別花了篇幅解釋，為什麼這件事塞不進聊天視窗。老 Fortran 的資料常放在跨檔案共用的 COMMON 區塊：某個檔案第 4,000 行改掉一個值，另外 20 個檔案在用的全域陣列就跟著變，把儲存庫切成小段餵給模型，很快就失去這張全局地圖。現代開發工具也幫不上忙，IDE、測試執行器、記憶體檢查器與 CI 遇到舊式固定欄位 Fortran 幾乎全部卡住，Google 形容新進研究生常常得先花半年跟分段錯誤和脆弱的建置腳本搏鬥，才碰得到真正的研究。人工移植的代價則更狠：差一個位的索引、浮點運算順序換一下，兩年後新程式終於編過，輸出卻對不上原版，團隊再花一年回頭找數學在哪裡漂掉。Antigravity 的角色是給代理一個能開終端機、編譯、跑測試、讀自己的堆疊追蹤、並排放兩個二元輸出互比的環境，讓這些檢查在同一個迴圈裡發生。
值得注意的範圍限定：被改寫的只有核心求解器，17.4 萬行並未全部動到。13 個模組乘上每個 240 行上限，成品的規模約三千行上下。把「59 分鐘移植 17 萬行」當結論引用，會放大這場展示的範圍。
六個老 bug 的偵探是編譯器，Argon 負責聽懂權宜之計
最有故事性的一幕發生在藍圖階段。Argon 在動量方程裡讀到一行數十年前留下的註解：H1(0) = H1(1) ! STRANGE WAY TO PREVENT DIVISION BY ZERO。沿著海岸線缺少鄰接三角網格時，原作者把索引 0 拿來代表缺格，再把第 1 格的水深複製過去避免除以零，於是邊界運算悄悄取決於哪個三角格恰好編號 1。Argon 反推出這個權宜之計存在的理由，在藍圖裡換成明確的邊界型別。
另外六個 bug 是被 Rust 的型別系統逼出來的。Fortran 容忍的記憶體寫法，換成嚴格的 Rust 型別就編不過，於是問題浮上檯面：網格建立器在複雜海岸線上會寫出 50 欄的緩衝區上限；三角邊界檢查把三個節點編號相乘，32 位元整數在超過 1,300 個節點的網格上溢位；淺水網格上垂直紊流與動量常式讀取越界的索引 0；乾涸陸地格的未初始化值被拿去算；海水密度常式對平流期間輕微變負的鹽度直接開根號。官方把這六個計為「真實存在的老 bug」，全部是幾十年前就埋下的型別與邊界問題。
抓 bug 的功勞要分帳：把問題擋下來的是 Rust「拒絕編譯」的個性，不是模型的慧眼。想在自己的老程式碼上複製這個效果，關鍵動作是換到一個會拒絕你的語言，讓編譯器當第一輪審查。
1.88 倍的最後一哩，是編譯器剖析出來的
提速也不是一句「AI 改寫變快」就能帶過。官方的效能表把它拆成三段累積，每一段的功勞者不同。
| 階段 | 執行時間 | 相對速度 | 尖峰記憶體 |
|---|---|---|---|
| 原版 Fortran 90／C（-O3） | 883 ms | 1.00x | 11.84 MB |
| 慣用安全 Rust | 682 ms | 1.29x | 6.39 MB |
| SoA 佈局＋迴圈零配置 | 548 ms | 1.61x | 5.83 MB |
| LLVM PGO | 469 ms | 1.88x | 5.48 MB |
從 883 到 682 毫秒這段，功勞屬於換到無 unsafe、無全域變數、帶邊界檢查的慣用 Rust，記憶體直接砍近一半。從 682 到 548 毫秒是代理的功勞：它發現原版在二維 Runge-Kutta 迴圈裡，每個時間步驟配置又釋放 8 個暫存陣列，重複 24 次，於是把工作區換成預先配置的 SoA 佈局（同類資料放在一起，處理器讀連續記憶體更順）。最後從 548 到 469 毫秒，做功的是 LLVM 的 PGO（Profile-Guided Optimization，剖析導引最佳化）：編譯器先觀察實際跑的路徑，再依熱點調整程式布局與向量化。換句話說，最後一哩不是模型重寫了什麼神碼，是編譯器照著真實流量重排了機器碼。
兩個讀表提醒。883 毫秒是官方選定的基準工作負載跑一次的時間，1.88 倍只在這個設定下成立，換一組模擬場景要重新量。記憶體從 11.84 MB 降到 5.48 MB（少 54%）倒是同一張表裡最不依賴場景的數字，因為它的來源是移除每步重複配置，屬結構性改變。
100 組種子一致，但「零差異」要照實引
原始規則寫的是「數值輸出零差異」，實際達成的是 100 組隨機種子全部一致到小數點後 12 位，差異量級 3.91×10⁻¹³，而且第一次比對就過了。引用時照官方數字講「12 位小數一致」最精確；轉述成「零差異」就比官方宣稱還滿。
對科學運算團隊還有一層要自己補的功課：單步 10⁻¹³ 量級的差異，在長時間多步積分裡會不會放大、放大到多少還能接受，取決於各模型的數值敏感性。Google 的基準是 100 組隨機種子的模擬跑對齊；自己的研究用途要長跑、要邊界條件極端的海況，就得先定義自己的容差，再讓代理照著驗收。
測試這關也有真實的失敗樣本，不是全綠童話。42 項單元、性質與文件測試裡，本來就包含專門設計來壓力測試求解器的邊界幾何案例。首輪 37 項單元測試過了 36 項，失敗的那項是只有單層水層的極淺海盆：垂直通量求解器想往下一層插值，踩到 Rust 的邊界檢查。代理讀了測試丟回的 panic 追蹤，打開垂直求解模組補上單層網格的防護，重跑後 42 項全過，分支覆蓋率 96.8%（分支覆蓋率指測試實際走過多少條條件路徑）。這個失敗案例值得停下來看兩眼：它正是隨機種子抽不到、只有真實世界才會餵給模型的邊界條件，也把「測試丟回錯誤、代理讀完修復、再重跑」這套循環完整走了一遍。不過它只證明這一類失敗能自癒；把它外推成「所有失敗都會自癒」，官方資料撐不起來。
範圍、自測與公開版的保守差距
盤點這場展示不能支持的結論。它是 Google 自家模型在自家平台上的內部測試，截至 11 月 5 日沒有第三方重現；「40 年」是 Google 對這類程式碼世代的形容；改寫範圍是核心求解器而非整個模型；效能數字綁在官方選定的基準上。這些限定不減損記錄本身的價值，反而是引用時的必要欄位。
公開 skill 與內部 demo 之間還有一道有意思的落差。google/skills 裡的 migrate-to-rust（Apache-2.0 授權）確實收錄了同一套流程：架構提示護欄、基準發現、缺陷審計、強制 #![forbid(unsafe_code)] 的 Rust 鷹架、自癒測試迴圈、多種子比對、PGO，以及那個會在工作區裡生成交互式 HTML 成績單的遙測產生器（59 分鐘實錄裡每完成一輪最佳化，代理就記下執行時間與記憶體遙測，成績單 artifact 就是這樣長出來的），裝進 Antigravity 後用 /migrate-to-rust <github-repo-url> 一行呼叫。但 SKILL.md 的執行契約比部落格展示保守：對外部儲存庫，代理必須先把解析出來的建置指令與執行方式攤給使用者確認，才能編譯執行；自動修復迴圈也設了最多 5 次的上限。照公開版跑，得到的是比 59 分鐘更慢但更可審查的過程。這道差距本身就是資訊：全自動的速度展示與可部署的工程工具，中間隔著安全設計。
想試的人，從一個能獨立跑的核心開始
對維護老程式碼的團隊，這則新聞的可執行部分有三件。最該搬走的是驗收設計，選哪個模型還在其次：先編譯原版、量好黃金基準、把「什麼算對」寫成提示裡的硬規則。換語言的真實收益常常是免費的審查，Rust 拒絕編譯的個性替你翻出幾十年前的越界與溢位。提速則要分段量測才知道該感謝誰，編譯器剖析與資料佈局通常比「改寫」本身貢獻更多。
這也是 Gemini 4 Argon 發布以來第三個被攤開檢視的官方案例：從把一張照片變成 3D 教堂的 Blender 示範，到 Pichai 專訪裡 Antigravity 代理工作量成長的營運數字，再到這次 Fortran 移植。三者共同的脈絡是 Google 把內部工程實踐往外搬的速度變快了，先前的 Elephant-Goldfish 規格審查外掛走的是同一條路。對照著看，會更清楚哪些數字是模型能力，哪些是工程環境的功勞。想跟這條線的讀者，從 migrate-to-rust 的 SKILL.md 讀起，挑一個輸出入邊界清楚的小核心試跑，會比直接相信 59 分鐘有用得多。
