摘要： Mistral 公開替一家歐洲能源營運商把 4 萬行 Fortran 77 水庫模擬器遷移到 C++ 的案例。團隊先建立數值對等測試並補齊文件，再以人類審查關卡配合編碼、測試與審查代理逐模組遷移。第一個衝刺完成 30 萬行中的 4 萬行，這次有利的起點是程式本身可執行且自包含。
把一段累積數十年的科學計算程式碼從 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 控制流也原樣留著。整體看起來，就只是拿 C++ 語法把 Fortran 重打一遍。
第二次嘗試把結構加進來：每個模組由規劃者、編碼者、測試者和程式碼品質審查者分工。品質明顯變好，但複雜度反而讓代理動彈不得：一碰上 bug，試了幾次修復就停滯下來，而沒有任何人能介入。
最後的方案走中間路線：由人類操作一套編碼者、測試者與審查者代理組成的工作流程，一個模組一個模組地遷移。第二次嘗試的程式碼品質被保留了下來，同時多了人類檢查點，用來解開代理卡住的地方。
一套可重複套用的工作流程
Mistral 與客戶端的水庫工程師合作，用呼叫者-被呼叫者樹找出彼此獨立的模組——經驗法則是約略小於 1 萬行 Fortran 的自包含子樹。每個模組都走同一套流程：
- 產出目標 C++ 架構
- 與水庫工程師一同審查
- 取得核准後拆解成任務佇列
- 每個任務各自跑一遍子工作流程：規劃 → 實作 → 測試 → 重複
- 由人類審查 PR，要求修改直到合併
第一個衝刺涵蓋了核心功能：30 萬行中的 4 萬行。這裡有個有利條件——Fortran 程式碼本身自包含且可執行。若遷移對象會依賴外部系統、缺少可執行的基線，或物理知識根本沒有留下紀錄，挑戰就會更多。
三個帶得走的原則
Mistral 歸納出三點教訓，適用於任何大規模的舊系統遷移：
- 對等測試框架要早於遷移程式碼——數值一致是成本最低的完成證明。
- 先把文件整理好，再去依賴代理——你無法遷移沒人能讀懂的程式碼。
- 在這種規模下，結構化工作流程加上人類審查關卡，勝過全自動，也勝過純手動。
這個案例的價值不在 Fortran 或 C++ 本身，而在它示範了一件事：如何把 AI 代理的自主性圈在可驗證的框架內。對產品開發者來說，真正的問題向來不是「代理能不能做」，而是「你如何證明它做對了」。