2026年10月30日，东京大学与日本国立环境研究所的研究人员在arXiv发表了一篇NICAM迁移论文。他们利用Claude Code辅助迁移全球非静力大气模拟模型NICAM，将约14万行Fortran代码所涉及的计算功能迁移为约3.5万行C++/Kokkos模型代码。在研究选定的生产配置下，迁移版本经受了两套各100成员的集合模拟检验，并在NVIDIA GH200平台上实现了相对原有Fortran/OpenACC版本1.71倍的应用级加速。[1]
14万行Fortran代码听起来像一场彻底的自动改造，论文记录的却是细密的人机协作。研究人员没有把整套系统交给AI后转身离开；他们为迁移定义范围、审核计划、逐模块检查结果，还建立了从例程输出到系统集成、再到统计集合模拟的验证体系。Claude Code负责大量代码迁移与编译调试工作，人类负责物理意义、架构取舍与验收边界。整个过程中，科研人员发出了797条指令，智能体产生了6007条回复，涉及23个活跃工作日。论文按API标价估算的模型调用成本约5589美元，但没有完整记录人力工时，不能据此计算整个工程的开发总成本。[1]
这样的工作方式让人想到制造业的“黑灯工厂”。当生产线具备自运行、自检测、异常回退与质量追溯能力，人不再需要站在每个工位反复执行动作，而是转向工艺设计、设备维护和品质管理。工业软件研发会不会发生同样的变化？从需求分解、旧代码理解、接口改造、并行化、构建、验证到性能分析，过去高度依赖资深工程师逐项推进的复杂任务，正在被组织成智能体可以连续执行的工程流水线。NICAM实验提供了一个带有成本与验证数据的早期样本；软件研发距离无人值守还有一段路。
一、14万行到3.5万行，难点在数值行为与工程约束
Fortran至今仍广泛用于数值计算。流体力学、天气气候、结构分析、计算化学、材料模拟以及大量工业求解器，都积累了跨越数十年的Fortran资产。这些软件积累的是方程离散、求解算法、边界条件、收敛控制、经验修正，以及真实工程中的验证经验。一个求解器可能从上世纪就开始迭代，经过多代处理器、编译器和并行计算架构的演变，今天仍然承担着研究机构或企业极其重要的计算任务。对于这类系统，代码是科学知识的一种固化形式，也保存着长期工程经验。
NICAM属于这类长期演进的科学软件。它使用二十面体网格与非静力方程开展全球大气模拟，开发历史超过二十年。此次研究覆盖选定生产配置中的动力核心和七个物理过程模块，包括云微物理、辐射、湍流、重力波阻力、陆面与海洋等相关模型。研究人员原有的版本已经采用OpenACC实施GPU加速，这次面对的是已有GPU加速基础的程序。迁移工作涉及数据结构、并行执行模型、内存管理、计算顺序与运行配置的一系列调整。论文报告的“14万行到3.5万行”描述的是本次迁移范围及目标模型源码规模，不能据此推算完整NICAM系统的所有历史功能都缩减了75%。尚未迁移的选项分支会被明确拒绝，后续还计划扩展支持更多组件。[1]
论文对旧代码的评价相当具体：它的源代码维护良好，数据结构比较一致，已有的OpenACC与OpenMP指令为智能体理解并行区域提供了重要线索。这些工程基础让智能体更容易找到迁移路径。对企业来说，AI擅长处理大规模而规则明确的迁移任务，维护良好的工程资产有助于智能体发挥作用；缺失文档、行为依赖隐性约定、接口长期失控的系统，仍然可能让智能体陷入反复猜测与修复。迁移成本可能下降，架构约束和工程纪律仍要有人负责。
二、1.71倍加速，从哪里来？
数值软件的重构通常被看作降低维护成本的工作，这次实验同时给出了性能数据。研究人员在东京大学与筑波大学使用的Miyabi-G系统上，以NVIDIA GH200为硬件平台，运行120个时间步，原Fortran/OpenACC版本耗时81.0秒，新的C++/Kokkos版本耗时47.3秒，应用级加速比为1.71。AMD MI300A平台上的C++/Kokkos/HIP版本耗时52.6秒，相比GH200上原始Fortran实现为1.54倍。1.54倍参照的是GH200上的原Fortran基线，比较跨越了两种硬件平台；论文这里没有提供MI300A上旧版与新版的同卡对照。上述应用时间不包括I/O，也不代表所有工作负载、网格规模和并行节点数都会获得相同提升。[1]
性能改善不能归结为编程语言的天然快慢。研究人员进一步测量GPU内核执行时间：GH200上从每步441.6毫秒降低到320.6毫秒，内核层面的加速为1.38倍。应用级的1.71倍明显高于纯内核加速，说明收益还来自CPU与GPU之间的调度、数据整理及同步开销的下降。旧实现沿袭了较多面向CPU组织数据的习惯，需要按区域将模型状态收集到工作数组，再执行计算与同步；新实现更多地让状态数据留在设备端，减少重复搬运，调整并行循环的范围，并在一些位置融合相邻计算。论文还报告，地表通量与湍流相关内核的计算开销从每步58.8毫秒降至28.5毫秒，而某些辐射计算反而变慢，说明优化收益高度依赖具体模块。[1]
改造工业计算软件时，性能问题往往藏在数据流里。现代GPU性能由并行任务划分、内存带宽、数据布局、核函数启动次数和设备间通信共同决定。旧算法中一些出于当年CPU缓存、内存容量或程序组织方式而形成的结构，今天可能已经成为瓶颈。人类工程师若要重新审视几万行乃至几十万行代码中的数据流和调用关系，往往需要投入大量精力。智能体可以让逐模块分析、重写、构建、测试、剖析和再修改持续执行。不过，智能体在这里依然依赖人类给出性能目标与正确性约束；语言迁移完成后，仍要针对GPU逐项检查数据布局和执行开销。
三、黑灯工厂的雏形是一条可验证的软件生产线
工业领域谈到黑灯工厂，人们往往首先想到机器人、自动化产线和熄灯后的连续运转。成熟产线还要控制工艺参数，测量关键尺寸，并识别、隔离不合格品。设备状态同样要能追踪。把这一逻辑迁移到软件工程，代码生成只是其中一个工位；源代码理解、依赖分析、迁移计划、自动构建、单元验证、系统集成、性能回归、安全扫描、结果归档和版本发布，组成了更完整的工艺路线。
NICAM的迁移按模块推进，验收也分段进行。人首先定义工程目标及操作限制，Claude Code分析原有Fortran代码并提出迁移计划，经审核后按模块推进。每迁移一个模块，智能体编译运行目标程序，将计算结果与原版输出比较；通过后重新执行累积的回归测试，随后进行30步或60步的短时集成模拟。人类在关键节点检查结构决策、调用顺序以及数值表现，符合要求后才放行下一个阶段。全部选定模块完成后，再以集合模拟检验整个耦合系统。一个曾经需要工程师在多个工具间手工切换的工作过程，已经具备了可重复、可追踪、可持续迭代的雏形。[1]
如果将这个模式向前推进一步，工业软件研发中心未来可能出现类似制造执行系统的Agent工程平台。需求代理读取变更请求与设计资料，架构代理识别受影响的模块与依赖，迁移代理修改代码，测试代理生成与维护验证用例，仿真代理调用求解器和标准算例，性能代理在不同硬件上运行基准测试，审计代理汇总差异、许可证、依赖安全和测试证据。调度系统依据质量门禁决定是否允许进入下一阶段，不符合阈值的任务退回修改；涉及核心算法、生产环境或交付版本的关键决策由授权工程师签署。重复操作交给系统，签署责任留在工程师手中。
四、编译通过以后，怎样检验数值结果
工业求解器输出的是数值近似解，核对起来比业务记录复杂得多。流体模拟中的压力分布、结构有限元中的应力集中、热处理过程中的温度场以及疲劳寿命预测，都会受到离散格式、舍入误差、并行归约顺序和收敛条件影响。程序可以编译成功，甚至展示出一张非常漂亮的云图，却在物理守恒、局部极值或者特殊边界条件上存在严重问题。这样的错误比普通业务程序中的页面显示异常更危险，因为它可能悄悄进入后续的设计决策。
NICAM研究采用了三个层次的验证。第一层是例程级对照：从原始Fortran程序导出输入和输出，给迁移后的对应例程输入相同数据，以严格的数值容差进行比较，典型接受标准为相对误差不超过10的负13次方或绝对误差不超过10的负12次方。第二层是短时集成测试，检查模块耦合、初始化、调用顺序和守恒相关诊断。第三层则是气候模拟特别需要的统计验证：原版和迁移版分别执行100个集合成员，每个成员模拟10个模式日，比较59项诊断量在后半段模拟中的分布。每套集合共有5900个“成员—诊断量”得分，其中95.3%落在两个标准差的区间内。研究人员据此认为，在已测试配置、诊断量和时长范围内，两种实现的统计行为保持一致。[1]
集成测试曾抓到一个初始化错误：单独测试某个物理例程时，它拿到的表面温度是从原程序导出的正确数据，因此测试顺利通过；到了完整耦合模拟中，新程序却遗漏了一段表面温度重建流程，最终引发向下长波辐射的系统性偏差。例程对照没有发现遗漏，完整耦合模拟才暴露了偏差。旧版本可以作为迁移参照，但也可能保留自身的物理或实现问题。对于工业求解器，还应增加解析解、制造解、网格收敛、物理守恒、实验数据和真实工况验证，以便识别旧程序自身可能遗留的问题。
五、软件工程的瓶颈，正在从写代码转移到审核与验收
整个实验记录了797条人工指令及6007条智能体回复，横跨23个活跃工作日。论文估算的模型用量折合API标价约5589美元，研究人员实际使用的是订阅方案，账面API成本只是为了说明用量，并不是实验的最终账单，更不包含研究人员投入的工时、计算集群、验证环境和长期维护支出。研究人员承认没有完整记录人类工作小时数，单纯用这些数字去计算“一个AI替代多少名程序员”，并无可靠依据。[1]
项目的瓶颈已经出现在审核环节：智能体能够生成代码的速度，已经快于人类检查数值逻辑与模块集成的速度。研究团队花费大量精力审核计算路径、确认数据依赖、审查设计选择，进度也受到使用额度和上下文连续性约束。这会改变大型重构的资源配置。过去大型重构项目要先估计需要多少开发人员逐行迁移代码；未来更需要提前估计能够准备多少基准数据、运行多少验证任务、配置多少领域专家审查关键风险。自动生成能力越强，未经验证的变更积压就可能越快。更重要的是把领域知识写成可执行的测试和验收规则，使大量修改有能力被自动过滤、比较与回退。
工程师的工作重心也会随之变化。熟悉Fortran、C++、MPI、CUDA、HIP以及求解器内部结构的人员仍然重要，只是其高价值工作会逐渐从机械翻译与重复调试转向数值方法设计、计算架构、性能诊断、验证体系和工程责任。拥有几十年行业经验的老工程师，其对算法适用范围、异常工况和结果可信度的判断，可能随着智能体的普及而更加稀缺。企业如果只把AI当作减少编码人手的工具，最后可能发现最困难的部分依旧没有人能承担。
六、从大气模拟到工业仿真，下一批会被改造的是什么？
其他科学计算项目也在尝试类似迁移。2026年6月公开的FESOM2研究将约7.4万行核心Fortran海洋—海冰模型代码，在领域专家指挥下先迁移到C，再迁移到C++/Kokkos，采用分阶段验证控制风险，报告了多年度模拟的物理一致性与GPU上的生产级计算能力。[2] 2026年7月的ORB5X工作则以受控核聚变等离子体模拟为对象，将原有Fortran程序迁移到C++/Kokkos，保留主要数值算法并展示了跨不同计算平台的运行能力。[3] 连同NICAM，这些案例分别涉及大气、海洋和等离子体模拟。代码助手开始处理数值算法、异构并行和长期科学软件的维护任务。
把视角转向工业软件，最先受到影响的很可能是那些计算内核相对独立、具有成熟基准算例、同时面临硬件适配压力的领域。例如，CFD中的流动与传热求解模块，CAE中的线性代数、网格处理和迭代求解模块，工艺仿真中的材料本构与温度场计算，电机电磁分析中的场求解与参数扫描，以及工业优化中的批量计算与多工况评估。它们通常具备可复用的数学结构，也容易积累一批经过多年验证的参考输入输出。对于使用传统CPU集群的软件，智能体辅助的并行化和GPU迁移还可能带来更大的硬件选择空间。Kokkos本身支持CUDA、HIP、SYCL、OpenMP等执行后端，为跨架构的计算程序提供了统一抽象；具体性能仍取决于编译器、驱动、数据布局和针对硬件的优化。[4]
对国内工业软件企业，存量程序的改造同样是切入口。过去自主研发一个成熟工业求解器，意味着长期投入数值算法、工业知识、验证数据库和工程软件基础设施。如今，存量代码迁移、模块重组与硬件适配的部分工作成本有机会显著下降，可能为既有科研成果工程化、行业软件二次开发和国产算力适配打开新的空间。迁移速度无法代替自主算法能力；兼容并行框架后，各类国产硬件仍需逐一适配。难点还包括高质量工业算例、材料参数、复杂边界条件、工程现场对照数据、技术责任与软件可信度。AI有可能降低进入软件实现环节的门槛，却未必会缩小掌握物理模型与产业验证资产的企业优势。
七、传统工业软件厂商最需要改变的，或许是研发组织本身
过去十几年，工业软件厂商习惯了漫长的产品周期：关键求解器维持稳定，小规模团队谨慎修改内核，新硬件支持需要专门的移植项目，复杂接口依赖多年积累的开发经验。这样的模式有它的历史合理性。企业用户购买工业软件，首先要求结果稳定、流程可靠、版本可控。与此同时，层层叠加的历史兼容、插件体系、特定硬件绑定和封闭开发流程，也可能使升级成本越来越高。到了智能体开始能够大规模理解和改写代码的阶段，许多曾被视为不可避免的工程投入，正在面临重新估价。
我们更愿意看到工业软件企业把智能体接入内部研发、测试与持续交付流程，而不是只在现有系统外围包装一个文档问答助手。让它理解算法模块之间的依赖，能够调用构建系统和仿真平台，能够执行标准算例，能够读取剖析数据，能够把一个性能回归问题定位到具体内核与数据搬运路径，并且将每次修改的证据保存下来。这样的Agent拥有明确的工程目标、工具权限、执行反馈和验收条件，它与只给工程师提供补全建议的Copilot存在实质差别。未来领先的工业软件企业，可能同时拥有两套能力：一套是被长期验证的物理模型与工业知识，另一套是围绕它们持续演进的自动化研发工厂。
在这个过程中，软件产品的价值构成也会发生变化。过去代码实现本身占据很高的稀缺性，谁拥有庞大的程序、谁能维护复杂的软件栈，谁就拥有相当程度的市场壁垒。随着程序理解、代码迁移和常规工程实现日益自动化，用户会更重视可验证的计算精度、行业工况覆盖、求解效率、可审计性、与实际制造业务的结合以及服务响应速度。厂商需要从漫长的“功能开发—版本发布”节奏转向连续可验证的能力交付。工业软件的竞争不只发生在功能菜单和许可证模式上，还会发生在谁拥有更好的测试体系、更丰富的工况资产、更可靠的求解结果和更快的技术迭代能力上。
八、企业敢不敢让AI动核心祖传代码？答案应当从一条小产线开始
对一家拥有多年核心工业软件资产的企业，可以先避免让智能体直接修改生产主干，选取一个边界清晰、价值明确、可独立构建、能够对照验证的模块，建设一条“软件重构试验产线”。第一批对象可以是独立的矩阵计算模块、网格前处理工具、老旧文件格式转换器、批量仿真脚本或者某个性能瓶颈明显的物理计算内核。企业先整理源代码权属、依赖与编译环境，建立可复现的原版基线；随后准备正常工况、极端工况和历史故障案例，定义数值容差、性能指标与接口兼容要求；智能体在受控环境中完成分析、迁移、编译和反复测试，测试不过自动退回，专家审核通过后再进入更大范围的集成环境。随着证据逐步积累，扩大其可自主执行的任务范围。
围绕这条试验产线，企业至少需要三类长期资产。其一是工程知识资产，包括算法解释、数据结构、模块依赖、编译配置和历史缺陷；其二是验证资产，包括金标准算例、物理实验、测试脚本、性能基线与验收阈值；其三是治理资产，包括代码访问权限、智能体操作日志、依赖许可审查、版本签署和异常回滚机制。涉及商业机密、客户设计数据或核心算法源代码时，企业还需要在部署方式、代码可访问范围、模型服务边界和数据保留策略上作出明确规定。对于必须做到数据不出厂的业务，应在方案设计时确定受控的本地研发环境和可审计工具链。
有了这些基础，研发团队可以逐渐形成双向闭环：一端让智能体不断改进计算软件，另一端让仿真任务和生产现场的结果反过来更新测试集。当新算法在标准算例上通过，却在真实泵阀的汽蚀工况、铸造凝固缺陷或设备异常振动场景中出现偏差时，系统会把问题转化为可追溯的工程任务，推动下一轮模型修正。这种机制如果持续运转，工业软件就开始拥有类似自动化制造产线的迭代能力。人类的角色也随之上移：研究计算方法、制定验收标准、解释复杂物理现象、处理软件系统无法自己消除的不确定性。
九、衡量这条产线，还得看可信变更
工厂的产出受工艺、设备、质量系统与供应链共同影响。工业软件研发也可以借用这种产线视角。代码当然依然重要，尤其是数值求解器中经过严密优化的关键内核；但大量围绕代码展开的理解、迁移、集成和验证工作，正在拥有新的自动化可能。未来的软件研发中心，可能不再用开发人员写下多少行代码衡量产能，而是用完成多少个可信变更、通过多少项独立验证、覆盖多少类工业工况、降低多少计算成本来衡量交付能力。
NICAM给出了14万行代码的迁移范围、双平台性能测试、两套各100成员的集合模拟和AI调用成本，也记录了人类审核负担与测试盲区。评价“黑灯工厂”时，我更在意每次交付是否留下可复核的证据：我们凭什么相信它交付的结果？
如果验证体系能持续回答这个问题，研发流水线就有机会减少那些延续多年的重复劳动。软件仍要构建、运行、对照和优化；工程师可以把更多时间留给计算方法、异常工况和结果判断。这是我理解的工业软件黑灯工厂时代。
参考资料
- Xuanzhengbo Ren, Takashi Shimokawabe, Hisashi Yashiro. Migrating a Legacy Scientific Application with an AI Coding Agent: NICAM from Fortran to Kokkos. arXiv:2610.41313, 2026-10-30. https://arxiv.org/html/2610.41313 （预印本；本文关于NICAM的数值和过程均据此整理）
- Nikolay V. Koldunov et al. An Ocean Model Ported by a Large Language Model: Experience and Lessons from FESOM2 (Fortran to C to C++/Kokkos). arXiv:2606.11356, 2026. https://arxiv.org/abs/2606.11356
- Mohsen Sadr et al. ORB5X v1.0: a performance-portable global electromagnetic gyrokinetic PIC code in C++/Kokkos built using Agentic AI. arXiv:2607.17363, 2026. https://arxiv.org/abs/2607.17363
- Kokkos Project. Kokkos Core Documentation. https://kokkos.org/kokkos-core-wiki/
本文完稿：2026年11月4日。关于未来研发模式的段落为作者分析与展望。