Mistral於9月9日公布一份客戶專案回顧,說明如何用自家AI Agent把一家歐洲能源業者的油藏模擬器從Fortran 77遷移到C++。整套程式碼共30萬行,這次動的是4萬行。專案開始時手上什麼都沒有:沒有測試套件,文件也沒有集中整理。
報告把Fortran 77難搞的地方列得很清楚:沒有模組、沒有命名空間、沒有結構化型別;程式狀態存在COMMON block裡,等於整個程式共用的全域記憶體;變數依開頭字母隱含定型;變數名稱長度上限6個字元,讀起來幾乎只能用猜的。
第一次嘗試是把任務整個交給AI Agent自己跑,花了一週,沒有成功。之後改成由人主導、按模組切分的做法,每個模組拆給四種角色:規劃、寫程式、測試、程式碼品質審查,流程是「規劃→實作→測試→再來一輪」。人留在流程裡的主要作用,是在AI Agent卡住時幫忙解套。
先補文件,再動程式碼
文件這一環是用Vibe CLI一次啟動上百個AI Agent並行處理。每個AI Agent都能透過文件庫和Mistral OCR把相關PDF抓進來讀——工業軟體的物理假設往往只寫在紙本報告或掃描檔裡,這是沒有集中文件的專案裡最耗人力的部分。
模組切分訂了一個經驗門檻:單一模組的Fortran程式碼控制在約1萬行以內。
用數值一致性當驗收標準
撐住這個專案的是一套對等驗證機制,由三部分組成:一組能把Fortran程式庫執行狀態匯出來的子程式、一個把這些檢查點載入C++的測試框架,加上幾份Skill.md檔案負責引導AI Agent正確使用前兩者。
報告舉的例子很具體:AI Agent在Fortran程式碼裡插一行,把RHOG變數的值印出來,那次執行的結果是42.71834;接著拿同一個數字當參考檢查點,去測試遷移後的C++模組。
"Numerical agreement is the cheapest, most convincing proof that a module is done."
數值對上了,是證明一個模組遷移完成最便宜、也最有說服力的辦法。
這件事的看點,或許不在於Mistral用的是哪家模型。電力、石油、氣象、航空這些產業的核心運算程式碼裡,還留著大量七、八十年代寫的Fortran,同樣是沒測試、沒文件、原作者早就退休的狀態。過去十幾年,只要提「重寫」通常就卡在驗收上:沒有基準,重寫出來的東西誰要簽字負責。Mistral這套做法把簽字的依據交給了數值檢查點,這一步和用哪家的AI Agent沒什麼關係,只要有能跑的舊程式碼,自己也能搭起來。
前提條件報告裡也寫得很清楚。Mistral承認這次的起始條件算有利:Fortran程式庫本身自成一體,而且能跑得起來。原文列了三類明顯會更難的情況——依賴外部系統的、拿不到可執行基準的,以及物理假設完全沒有任何文件記錄的。至於比人工重寫快多少,報告並沒有給出具體數字。
參考來源:Mistral官方部落格、CocoLoop;依官方案例回顧核實程式碼行數、模組切分門檻、AI Agent角色分工與RHOG檢查點數值。