Mistral 9 月 9 日公开了一份客户项目复盘，讲怎么用自家智能体把一家欧洲能源运营商的油藏模拟器从 Fortran 77 迁到 C++。整套代码 30 万行，这次动的是 4 万行。项目开始时手上什么都没有：没有测试套件，也没有集中放好的文档。
Fortran 77 难办的地方在报告里列得很清楚：没有模块，没有命名空间，没有结构化类型；程序状态存在 COMMON block 里，等于一整个程序共享的全局内存；变量按首字母隐式定型；变量名长度上限 6 个字符，读起来基本靠猜。
第一次尝试是把任务整个交给智能体自己跑，花了一周，没成。之后改成人类操作、按模块切分的做法，每个模块拆给四个角色：规划、写码、测试、代码质量审查，流程是”计划 → 实现 → 测试 → 再来一轮”。人留在环里的主要作用是卡住时把智能体解开。
先补文档，再动代码
文档这一环是用 Vibe CLI 起了一百多个智能体并行做的。每个智能体可以通过文档库和 Mistral OCR 把相关的 PDF 拉进来读——工业软件的物理假设往往只写在纸质报告或者扫描件里，这是没有集中文档的项目里最耗人的部分。
模块切分定了个经验阈值：单个模块的 Fortran 代码控制在约 1 万行以内。
用数值一致性当验收标准
撑住这个项目的是一套对等验证装置。它由三部分组成：一组能把 Fortran 代码库运行状态导出来的子程序，一个把这些检查点载入 C++ 的测试框架，加上若干 Skill.md 文件负责引导智能体正确使用前两者。
报告里给的例子很具体：智能体在 Fortran 代码里插一行，把 RHOG 变量的值打出来，那次运行是 42.71834；接着拿同一个数当参考检查点，去测迁移后的 C++ 模块。
“Numerical agreement is the cheapest, most convincing proof that a module is done.” 数值对上了，是证明一个模块迁完了的最便宜、也最有说服力的办法。
对国内读者来说，这条经验的落点可能不在 Mistral 用了哪个模型。电力、石油、气象、航空这些行业的核心计算代码里有大量七八十年代的 Fortran，同样是没测试、没文档、原作者早已退休的状态，过去十几年提”重写”通常卡在验收上：没有基线，重写出来的东西谁签字。Mistral 这套做法把签字权交给了数值检查点，这一步和用哪家的智能体没什么关系，先有可运行的旧代码就能自己搭。
前提也写在报告里。Mistral 承认这次的起始条件算有利：Fortran 代码库自包含、能跑起来。原文列了三类会明显更难的情况——依赖外部系统的、拿不到可运行基线的、以及物理假设根本没有任何文档记录的。至于比人工重写快多少，报告没有给数字。
参考来源：Mistral 官方博客、CocoLoop；据官方复盘核验代码行数、模块切分阈值、智能体角色划分与 RHOG 检查点数值。