正在加载，请稍候
一家欧洲能源运营商的 4 万行油藏模拟代码交给智能体，第一次产出的是「用新语法重打的老代码」。复盘里最值得抄的不是提示词，而是三个反直觉决定。
一家欧洲能源运营商的油藏模拟器，4 万行 Fortran 77，没有测试套件，没有集中文档，最早的作者早已离开。2026 年 9 月这份迁移复盘公开，里面最值得抄的，不是提示词。
把代码从一种语言翻成另一种，基本已经是解决了的问题。主流模型翻一段并非完全冷门的语言，几次迭代就能收敛到可用结果。真正的分歧出在「过程式 → 面向对象」这一步：那不是翻译，是重构。
1977 年标准化的那门语言，代码结构直接刻着当年的硬件约束。没有模块，没有命名空间，没有结构化类型；状态塞在 COMMON 块里，也就是全程序共享的全局内存；变量类型靠首字母隐式决定，I 到 N 开头的名字默认是整数——一个拼错的变量名不会报错，只会静默地新建一个变量；变量名长度上限 6 个字符。
对应的现代写法长这样：输入输出不再是全局变量，参数显式带类型，结果用返回值传出。
double gasDensity(const GasProperties& gas, double pressure) {
size_t i = lookup(gas.pressure, pressure);
return gas.density[i] + gas.slope[i] * (pressure - gas.pressure[i]);
}麻烦在于，这种改写没有逐行对应关系。散的全局数组变成一个参数，网格循环被提到调用方，行与行之间对不上——这正是「迁移有没有做对」难以验证的根源。
同类的超大规模改写已有先例：Bun 用 64 个智能体在 11 天内把 53.5 万行 Zig 重写成 Rust。但那是「重写」，不是「迁移」——重写不必证明新旧两版算得一样，迁移必须。
常规顺序是「先迁，迁完再测」。这次反着来：在让任何模型碰代码之前，先搭一套能证明新旧两版数值一致的框架。
具体到某次运行，老代码里 RHOG 在一点的数值是 42.71834，迁完之后就拿这个数当参考检查点。复盘对这一步的定性是「净收益投资」：它让长时自动化运行变得安全，而数值一致性是一个容易验证、也很有说服力的论据。
我们自己在企业项目里踩过的坑恰好相反。几年前做过一次老系统改造，团队嫌写回归脚本「看不到进度」，直接动手改，上线后某个边界条件算错，排查花了两周——那两周的成本，远超当初省下的三天写脚本时间。
三次尝试的对比很扎眼。
第一次，完全自主。一个子程序配一个执行者，各自在一周内独立完成翻译。结果是「能用」。全局块变成一对一的全局结构体，跳转驱动的控制流原样保留，没有重构成循环或提前返回。说白了，那是用新语法重打了一遍老代码。
第二次，给结构而不只是给自主权。规划者、编码者、测试者、质量审查者四个角色协同处理每个模块。代码质量比第一次明显提升，但源码复杂度最终压垮了流程：执行者撞上一个 bug，试几次修不动就停在那里，而现场没有人能介入。
第三次是折中。由人类操作一个由编码者、测试者、审查者组成的工作流，逐个模块推进。质量保住了，同时多了人工检查点，卡住的时候有人解围。
人工检查点不是流程装饰。缺了它，产出会以另一种方式反噬——一次 1721 行的 diff 提交，审查者看完直接关掉了 PR，这件事我们单独拆过。
值得记下来的判断是：自主度不是一个「越高越好」的旋钮。旧代码里那些沉默的隐式约定——隐式类型、全局内存、六字符变量名——恰恰是模型最容易「合理猜测」错的地方，也正是最需要人看的地方。
这个项目的文档散在两处：旧的 PDF，和老代码里埋着的注释。
过程式代码有一个便利性质，整个程序可以画成一棵调用者—被调用者树。团队用自定义解析器把代码库解析成这棵树，然后派出上百个执行者逐节点写文档：从叶子节点开始向上推进，每个节点派生一个子执行者为自己写说明并提 PR；一个审查执行者按定时任务循环跑，发现新 PR 就审，必要时安排修复任务。
写文档在多数项目里是被砍的第一项。但在这个场景里它同时解决两件事：一是把「原来那个人怎么想的」从注释和 PDF 里捞回来，二是给后续所有迁移动作提供上下文——没有这层上下文，执行者只能靠代码字面猜意图。
反过来看，文档与结构长期缺位留下的债，在 AI 编程密度上来之后会更隐蔽——因为它不再表现为「没人看懂」，而是表现为「它理解得很像，但就是不对」。
| 决策点 | 常见做法 | 这次的做法 | 代价与收益 |
|---|---|---|---|
| 验收标准 | 迁移完成后再补测试 | 动代码前先建数值一致性校验台 | 多花前期时间，换来长时运行的安全性与可证明的正确性 |
| 自主程度 | 尽量全自主，减少人工介入 | 人工在环，逐模块推进 | 速度慢一些，但产出的是能合并进主干的重构代码 |
| 知识载体 | 边迁边补文档 | 先成体系补文档，再开始迁移 | 前期投入大，但把隐性知识从人脑搬回代码旁边 |
| 人力结构 | 让执行者独立完成任务 | 人负责调度与解围，执行者负责落地 | 人的角色从写代码转为定标准、盯卡点 |
三类情况不值得照搬。
还有一层判断：如果老代码里没有不可再生的数值算法或行业知识，那「重写」大概率优于「迁移」。这次之所以走迁移路线，是因为那 4 万行里沉淀了三十年的领域计算经验，重写等于把经验清零。
能完成相当一部分，但这次复盘给出了边界：完全自主那一版产出的是「能跑但不像重构」的代码。把角色拆开（规划、编码、测试、审查）会明显改善质量，而复杂模块卡住时仍然需要人介入。合理定位是人调度、执行者落地。
因为新旧两版之间往往没有逐行对应关系：全局数组变参数、循环外提，行号对不上。这时唯一可靠的判据是数值或行为一致。先有判据，自动化才能长时间跑而不是盲跑。这次的做法是把老代码的中间量导出来当参考检查点，例如某点密度 42.71834。
加在模块边界。每迁完一个可独立验证的单元就人工过一遍，比按时间巡检有效得多——卡点通常出现在隐式约定密集的地方，也就是模块内部状态交接处。
公开复盘没有给出总工期。可确认的是，单次尝试里「一个子程序配一个执行者、一周内完成翻译」是走得通的节奏，但那一版需要返工。加上文档化和校验台的前置投入，实际周期会显著长于纯翻译。评估时建议按模块数估，而不是按代码行数估。
这类项目的另一半成本不在代码本身，而在运行环境与组织协作。2026 年 9 月 5 日腾讯云 DBTalk 北京站讨论的正是底座这一层，主题是面向智能体开发的数据库新范式，集中在权限、隔离、回退与多执行者协作时的状态共享。同期 InfoQ 的另一场讨论把问题指向组织层：企业 AI 项目为什么总卡在 Demo 与生产之间，FDE 这类角色能否弥合，目前没有共识。
先稳定、再提速这个次序，和我们在AIcoding 落地路径里写的是同一套逻辑：工具可以一步到位，流程必须一步一步来。落到企业软件定制上，我们把它压成了三条可直接抄的规矩。
如果你手上正有一套没有测试、原作者已离职的老系统，建议先从「行为与数值一致性校验」这一件事开始。广州市蓝曜炬辉科技有限公司在做 AI 软件开发与遗留系统现代化交付时，第一步基本都从这里切入，具体交付方式可以看关于我们，或直接联系我们说明你的代码规模与技术栈，我们先给一版迁移可行性评估。