把幾十年的科學程式碼從 Fortran 77 搬到 C++，不只是換語法。Mistral 在 2026 年 9 月 9 日發布的案例中，幫一家歐洲能源營運商遷移了 4 萬行物理密集的水庫模擬器，沒有測試套件、沒有集中式文件。真正的挑戰在於：Fortran 77 的結構限制（全域 COMMON 區塊、隱式型別、6 字元變數名）讓逐行對照幾乎不可能，而現代化要求把全域狀態重構成物件導向設計。
先建對等測試框架，再讓代理動手
Mistral 團隊沒有直接開始翻譯，而是先建立一個「parity harness」：在 Fortran 端加入匯出狀態的子程式，在 C++ 端建立載入檢查點的測試框架，並用 Skill.md 檔案引導代理正確使用。代理在遷移工作流程中成功插樁 Fortran 程式碼以傾印狀態快照，並用 C++ 測試框架驗證模組正確性。
這個順序是關鍵。數值對等（輸出數值完全一致）是最便宜、最有說服力的完成證明。Mistral 明確建議：任何程式碼現代化專案的第一步都應該是建立對等測試框架。這呼應了我們之前在 FDE 的真正價值：不是幫你部署，而是幫你學會自己營運 中談到的思維——工具的目的是建立可驗證的能力，而不是依賴。
用代理理解並記錄舊程式碼
文件散落在舊 PDF 和 Fortran 註解中。Mistral 利用程序式程式碼的特性：整個程式可以畫成一棵呼叫者-被呼叫者樹。他們用自訂解析器產生這棵樹，然後用 Vibe CLI 啟動超過一百個代理來記錄每個節點。每個代理可以透過文件庫和 Mistral OCR 拉取相關 PDF。
從樹的葉子開始向上處理，每個節點產生一個子代理來記錄並開 PR。一個審查代理在 cron 排程上循環執行，尋找新開的 PR、審查並在必要時安排修復任務。這個階段的副產品是文件與程式碼的整合，大幅降低了後續遷移的認知負擔。
全自動失敗，結構化工作流程成功
第一次嘗試給代理完全自主權：一個代理負責一個 Fortran 子程式，各自獨立翻譯成 C++，跑了一週。結果功能正常，但稱不上現代化——COMMON 區塊變成一對一的全域結構體，GOTO 控制流原封不動。看起來只是把 Fortran 用 C++ 語法重打一遍。
第二次嘗試加入結構：每個模組由規劃者、編碼者、測試者和程式碼品質審查者協作。品質大幅提升，但複雜度讓代理卡住：遇到 bug、嘗試幾次修復後就停滯，沒有人介入。
最終方案是中間路線：人類操作一個由編碼者、測試者和審查者代理組成的工作流程，逐模組遷移。這保留了第二次嘗試的程式碼品質，同時加入人類檢查點來解除代理的阻塞。
可複製的工作流程
與客戶的水庫工程師合作，Mistral 用呼叫者-被呼叫者樹識別獨立模組（經驗上小於約 1 萬行 Fortran 的自包含子樹）。每個模組執行相同流程：
- 產生目標 C++ 架構
- 與水庫工程師審查
- 核准後拆成任務佇列
- 每個任務執行子工作流程：規劃 → 實作 → 測試 → 重複
- 人類審查 PR 並要求修改直到合併
第一個衝刺涵蓋核心功能：30 萬行中的 4 萬行。Fortran 程式碼是自包含且可執行的，這是有利的起點。依賴外部系統、缺乏可執行基線、或物理知識無處記錄的遷移會帶來額外挑戰。
三個可攜帶的原則
Mistral 總結了三個適用於任何大型舊系統遷移的教訓：
- 先建對等測試框架，再寫遷移程式碼——數值一致是最便宜的完成證明。
- 先整理文件，再依賴代理——你無法遷移沒人能讀懂的程式碼。
- 在這個規模下，結構化工作流程加上人類審查關卡，勝過全自動或純手動。
這個案例的價值不在於 Fortran 或 C++，而在於它示範了如何把 AI 代理的自主性限制在可驗證的框架內。對產品開發者來說，真正的問題不是「代理能不能做」，而是「你如何證明它做對了」。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。