1. 当CTO问我这套Fortran系统能不能用AI重构时我沉默了三十秒去年冬天一家制造业客户的CTO把我拉进会议室投影上是一张架构图——核心计算模块是上世纪九十年代写的Fortran外面裹着几层Java服务再外面是近几年补的Python胶水层。他问我现在AI这么强能不能直接让大模型把这套东西重写一遍我没有立刻回答。因为过去三年里我参与过四个大型遗留系统的AI辅助迁移项目踩过的坑足够写一本小册子。有的项目顺利落地计算精度误差控制在1e-12以内有的项目在第三个月被迫回滚因为AI生成的代码在边界条件下出现了微妙的数值漂移测试团队花了六周才定位到问题。这篇文章想聊的就是AI重构大型遗留系统这件事到底该怎么干。不是概念科普不是工具罗列而是从一个实际操盘者的角度把迁移过程中那些文档里不会写、但一定会遇到的问题摊开来讲。如果你正好是CTO、技术总监或者被指派负责迁移的技术负责人这些经验应该能帮你少走几个月的弯路。先说结论AI在遗留系统迁移中确实能大幅提效但它不是一键重构的魔法按钮。它更像一个极其勤奋但缺乏领域常识的初级工程师——写得快、写得多但你需要给它划定边界、建立验证机制、设计回退路径。下面这十条建议每一条背后都有真实的项目教训。2. 第一条建议先做可迁移性分级别一上来就啃最硬的骨头2.1 为什么不能从核心计算模块开始很多团队拿到迁移任务后的第一反应是核心模块最重要先搞定它。这个直觉在传统重构中可能成立但在AI辅助迁移的场景下恰恰是最危险的策略。原因在于AI模型对代码的理解依赖于训练数据中的模式密度。业务逻辑代码、CRUD操作、API封装这类模式重复度高的代码AI生成的质量相当可靠。但核心计算模块往往包含大量领域特定的数值算法、历史遗留的优化技巧、甚至依赖特定编译器行为的隐式假设——这些内容在训练数据中极其稀疏AI生成的代码看起来对但跑起来错的概率非常高。我在一个气象数据处理项目中见过典型案例原系统有一段Fortran代码利用特定编译器的浮点运算顺序来保证结果可复现。AI重写成Python后逻辑完全一致但因为浮点运算顺序变了最终输出的气象模型在第七位小数上出现偏差导致下游的集合预报系统整体偏移。这种问题在单元测试中根本发现不了只有端到端的数值对比才能暴露。2.2 可迁移性分级的四个维度我的做法是先花一到两周做一次系统性的可迁移性分级从四个维度给每个模块打分维度低风险特征高风险特征逻辑复杂度线性流程、条件分支少深层嵌套、状态机、递归领域特异性通用业务逻辑专有算法、行业公式外部依赖标准库为主特定编译器、硬件指令、第三方二进制测试覆盖有完整单元测试无测试或仅有集成测试每个维度按1-5分打分总分低于8分的模块优先迁移8-14分的模块需要人工深度介入14分以上的模块建议暂时保留、只做接口封装。这个分级过程本身就是一次极好的系统梳理。很多CTO反馈说光是做完这个分级团队对系统的理解就上了一个台阶——因为过去没人系统地评估过哪些代码是真正危险的。2.3 一个反直觉的发现在四个项目中我发现一个规律代码行数最多的模块往往不是最难迁移的代码行数最少但注释最少的模块才是。原因很简单行数多说明逻辑被拆解得比较细AI有足够的上下文来理解意图而行数少、注释少的模块往往是某位已经离职的工程师在某个深夜写下的魔法代码里面藏着大量隐式假设。这类模块我建议直接标记为人工优先不要让AI碰。3. 第二条建议为AI准备领域知识包而不是直接喂代码3.1 裸喂代码的失败率有多高我做过一个对比实验同一个Fortran数值计算模块分别用两种方式让AI迁移。第一种直接把源代码贴给模型要求翻译成Python第二种先给模型一份领域知识包包含算法背景、输入输出范围、精度要求、已知边界条件然后再让它翻译。结果第一种方式的代码首次通过测试的比例是23%第二种是71%。差距接近三倍。这个实验说明了一个关键问题AI缺的不是编程能力而是领域上下文。它不知道这个计算模块是用于实时控制的对延迟敏感还是用于离线分析的对精度敏感不知道输入数据的物理意义不知道哪些边界条件是不可能出现但必须处理的。3.2 领域知识包应该包含什么我通常会让团队准备一份结构化的知识包包含以下内容算法说明这个模块解决什么问题输入输出的物理含义是什么精度要求哪些计算需要保持双精度哪些可以接受单精度边界条件已知的极端输入、历史bug记录、特殊处理逻辑性能约束是否有实时性要求允许的最大延迟是多少依赖说明依赖了哪些外部库、编译器特性、硬件指令测试用例至少三组输入-期望输出的对照数据这份知识包不需要写得很长但必须准确。我见过太多团队为了赶进度跳过这一步结果在后期调试上花的时间是准备知识包的五倍以上。3.3 知识包的维护是个持续过程有一点需要提醒知识包不是一次性文档。在迁移过程中每当你发现AI生成的代码出现了某种类型的错误就应该把这类错误的特征补充到知识包里。比如你发现AI总是忽略某个特定的空值处理就把这条规则明确写进去。我在一个金融风控系统的迁移中知识包从最初的12页扩展到了最终的47页。这47页后来成了团队最宝贵的资产——因为它完整记录了这套系统的隐性知识即使将来不用AI迁移新人接手也能快速上手。4. 第三条建议建立AI生成-人工审查-自动验证的三层质量门4.1 为什么单靠人工审查会崩溃AI生成代码的速度远超人工审查的速度。一个中等规模的遗留系统AI可能在一周内生成数万行代码但人工审查这些代码需要数月。如果质量门设计不当要么审查成为瓶颈要么审查流于形式。我的做法是设计三层质量门每层拦截不同类型的问题第一层静态检查。用lint工具、类型检查器、安全扫描器自动过滤明显问题。这一层能拦截大约40%的低级错误比如语法问题、未定义变量、类型不匹配。第二层自动验证。用预先准备好的测试用例包括正常用例和边界用例自动运行对比输出结果。这一层能拦截大约35%的逻辑错误。关键是要建立黄金数据集——从原系统采集一批真实的输入输出对作为验证基准。第三层人工审查。只审查通过了前两层的代码且审查重点放在AI无法验证的部分架构合理性、可维护性、是否符合团队编码规范、是否有隐藏的性能问题。4.2 黄金数据集的采集技巧黄金数据集的质量直接决定了第二层质量门的有效性。我的经验是从生产环境采集不要用测试数据。生产数据的分布才是真实的。覆盖至少一个完整的业务周期。比如金融系统要覆盖月末、季末、年末的特殊场景。包含至少5%的异常输入。这些是历史上出过问题的数据最能暴露AI的盲区。输出对比要有容差设置。浮点计算不可能完全一致需要根据业务要求设定合理的误差范围。在一个电力调度系统的迁移中我们采集了整整一年的调度记录作为黄金数据集。结果发现AI生成的代码在负荷突降场景下会出现计算偏差——这个场景在测试数据中从未出现过但在生产数据中每年会出现几次。4.3 人工审查的二八原则人工审查时间有限必须用在刀刃上。我的做法是80%的审查时间花在20%的高风险代码上。高风险代码的识别标准包括涉及金额计算的、涉及安全控制的、涉及状态变更的、涉及外部系统交互的。这些地方的错误代价最高值得投入最多审查资源。相反那些纯数据转换、日志记录、参数校验的代码只要通过了自动验证人工审查可以快速扫过。5. 第四条建议Fortran和COBOL这类老古董AI能帮上什么忙5.1 AI在Fortran迁移中的真实表现Fortran是遗留系统迁移中最常见的硬骨头之一。我在三个项目中处理过Fortran代码的迁移AI的表现可以总结为擅长的部分语法翻译。把Fortran的do循环、if-else、数组操作翻译成Python或CAI做得又快又准。特别是Fortran 90之后的模块化代码AI的翻译质量相当高。不擅长的部分数值语义保持。Fortran的数组索引从1开始、列优先存储、特定的浮点运算顺序这些细节AI经常搞错。更麻烦的是很多老Fortran代码依赖特定编译器的优化行为比如某些编译器会自动做循环展开或向量化改变代码后结果就变了。完全搞不定的部分隐式类型转换和COMMON块。老Fortran代码中大量使用隐式类型变量名以I-N开头默认为整数AI翻译时经常误判类型。COMMON块这种全局共享内存的机制翻译成现代语言需要重新设计数据流AI给出的方案往往过于简单。5.2 一个实用的Fortran迁移策略基于这些经验我总结了一个分阶段的Fortran迁移策略第一阶段接口封装。不改动Fortran核心代码用现代语言写一个封装层通过FFI外部函数接口调用Fortran编译出的动态库。这个阶段的目标是让老代码能被新系统调用风险最低。第二阶段逐模块翻译。从最独立的模块开始用AI翻译成目标语言用黄金数据集验证。每个模块翻译完成后替换掉原来的FFI调用。第三阶段核心算法重写。对于性能关键或精度关键的模块不依赖AI翻译而是由领域专家和工程师合作重写。AI在这个阶段的作用是辅助——生成测试代码、生成文档、做代码审查。这个策略的好处是风险可控。每个阶段都有可回退的方案不会出现翻译到一半发现走不通的情况。5.3 关于Fortran工具链的提醒在实际操作中Fortran的编译和链接环境本身就是一大坑。不同版本的编译器对同一段代码的处理可能不同某些老代码依赖特定版本的运行时库。我建议在迁移开始前先花时间把原系统的编译环境完整记录下来——编译器版本、编译选项、链接库版本、环境变量设置。有一个项目我们忽略了这一步结果AI翻译后的代码在测试环境跑得好好的一上生产就出问题。排查了两周才发现生产环境的数学库版本和测试环境不一致导致某些特殊函数的计算结果有微小差异。6. 第五条建议迁移不是重写能封装就别翻译6.1 封装优先原则的经济账很多CTO对迁移的期待是彻底替换掉老系统但从投入产出比来看能封装就别翻译往往是最优策略。我做过一个粗略的统计对于一个10万行的遗留系统如果全部翻译成新语言AI辅助下大约需要6-9个月投入5-8人。如果采用封装部分翻译的策略只翻译核心业务逻辑约3万行其余部分通过接口封装保留时间可以压缩到3-4个月投入3-4人。更重要的是风险差异。全量翻译意味着所有代码都要重新验证而封装策略下未翻译的部分保持原样运行风险为零。6.2 什么情况下必须翻译当然封装不是万能的。以下情况必须翻译运行时环境无法维持比如依赖的操作系统或硬件平台即将停止支持性能瓶颈老代码的性能无法满足当前业务需求安全合规老代码使用的加密算法或协议不再符合安全要求人才断层团队中已经没有人能维护这门语言除了这四种情况其他场景下封装都是更务实的选择。6.3 封装的技术实现要点封装的核心是设计一个稳定的接口层。我的经验是接口要粗粒度。不要为每个函数都设计一个接口而是按业务能力划分一个接口对应一个完整的业务操作。接口要无状态。老系统的全局状态是迁移的最大障碍封装层要负责管理状态转换。接口要可观测。每个接口调用都要有日志、有指标、有追踪方便排查问题。接口要可降级。当封装的老系统出现问题时新系统要能优雅降级而不是整体崩溃。在一个银行核心系统的迁移中我们用了封装策略把老系统的账户计算模块完整保留只在新系统前端做了接口适配。整个迁移只用了三个月而且上线后零故障。后来这个封装层稳定运行了四年直到业务需求变化才逐步替换。7. 第六条建议AI生成的代码必须过数值一致性这一关7.1 数值一致性为什么容易被忽略在业务系统迁移中数值一致性问题相对少见——金额计算通常是精确的逻辑判断是确定的。但在科学计算、工程仿真、金融风控这类领域数值一致性是生死线。AI生成的代码在数值一致性上有几个典型问题浮点运算顺序改变AI翻译时可能调整了运算顺序导致浮点误差累积不同精度降级AI可能把双精度计算改成单精度因为它觉得没必要数学库差异不同语言的数学库实现不同同一个函数的结果可能有微小差异并行化引入的不确定性AI可能自动引入并行计算导致结果不可复现7.2 建立数值一致性验证体系我的做法是建立一套分层的数值验证体系第一层单元级验证。对每个计算函数用黄金数据集验证输出。容差根据业务要求设定科学计算通常要求相对误差小于1e-10工程计算可以放宽到1e-6。第二层模块级验证。把多个函数组合起来验证模块级的输出。这一层能发现函数间的接口问题。第三层系统级验证。端到端的全流程验证用真实业务场景的数据跑完整流程。这一层能发现跨模块的累积误差。第四层统计验证。对于随机性算法或大规模数据用统计方法验证输出分布是否一致。比如比较均值、方差、分位数等统计量。7.3 一个真实的数值一致性事故在一个地震数据处理系统的迁移中AI翻译的代码通过了所有单元测试和模块测试但在系统级验证时出现了问题处理后的地震剖面在深层反射界面出现了相位偏移。排查了整整三周最后发现是AI在翻译一个傅里叶变换函数时把原来的实数FFT改成了复数FFT虽然数学上等价但因为浮点运算的差异在特定频率上产生了微小相位误差。这个误差在单次变换中只有1e-8弧度但经过后续的多轮迭代处理后被放大到了可观测的程度。这个事故的教训是数值一致性验证必须覆盖完整的处理链路不能只看单点。8. 第七条建议给迁移项目设熔断机制别等到不可收拾8.1 什么情况下应该暂停或回退AI辅助迁移项目最容易犯的错误是沉没成本谬误——已经投入了三个月不甘心放弃于是继续投入直到彻底失控。我建议在项目启动时就设定明确的熔断条件进度熔断如果某个模块的迁移时间超过预估的200%暂停并重新评估质量熔断如果自动验证的通过率连续两周低于60%暂停并检查知识包和测试用例成本熔断如果实际投入超过预算的150%暂停并重新做投入产出分析人员熔断如果核心成员流失超过30%暂停并重建团队熔断不是失败而是及时止损。我见过一个项目在熔断后调整策略把全量翻译改成封装部分翻译最终反而提前两个月上线。8.2 回退路径的设计熔断机制要有效前提是有可回退的路径。我的做法是代码级回退每个模块的迁移都在独立分支上进行主分支始终保持可运行状态数据级回退迁移过程中产生的中间数据要保留方便对比和回退环境级回退保留原系统的完整运行环境随时可以切回流程级回退设计双跑机制新老系统并行运行一段时间对比结果后再切换在一个保险核心系统的迁移中我们用了双跑机制新系统上线后每笔业务同时在新老系统处理对比结果。运行了三个月发现并修复了17个差异问题然后才正式切换。这三个月看似浪费但避免了一次可能影响数十万保单的事故。8.3 熔断后的决策框架触发熔断后不要急于做决定。我通常建议团队花一周时间做一次系统性复盘回答三个问题问题的根因是什么是技术问题、流程问题还是人员问题如果继续需要什么条件这些条件能否在合理时间内满足如果回退损失是什么回退后有没有替代方案这三个问题的答案往往能让决策变得清晰。9. 第八条建议团队配置比工具选型更重要9.1 迁移团队的理想配置AI辅助迁移项目的团队配置和传统开发项目有很大不同。我的经验是一个高效的迁移团队应该包含以下角色领域专家1-2人最了解老系统业务逻辑的人负责编写知识包、审核AI生成的代码、判断数值一致性迁移工程师2-4人负责具体的迁移工作包括准备提示词、运行AI生成、执行验证、修复问题测试工程师1-2人负责设计测试用例、维护黄金数据集、执行自动化验证架构师1人负责整体架构设计、接口定义、技术选型、熔断决策这个配置中领域专家是最稀缺也最关键的。我见过太多项目因为领域专家投入不足导致AI生成的代码看起来对但实际错后期返工代价巨大。9.2 领域专家的时间投入领域专家不需要全职投入但必须保证固定的时间投入。我的建议是项目启动阶段全职投入2-3周完成知识包编写和可迁移性分级迁移执行阶段每周投入2-3天审核高风险代码、解答团队疑问验证阶段全职投入1-2周参与系统级验证和问题排查如果领域专家无法保证这个投入我建议推迟项目启动或者缩小迁移范围。9.3 团队的知识传递迁移项目还有一个隐性价值知识传递。老系统的知识往往集中在少数人手里迁移过程正好是把这些知识显性化、文档化的机会。我通常会在项目中安排定期的知识分享会由领域专家讲解业务逻辑迁移工程师讲解技术实现测试工程师讲解验证方法。这些分享不仅帮助团队协作也为后续的系统维护积累了文档。10. 第九条建议别忽视非功能需求的迁移10.1 性能、安全、可观测性同样重要大多数迁移项目把注意力集中在功能正确性上忽略了非功能需求。但实际生产中非功能需求出问题的概率往往更高。性能AI生成的代码可能在功能上正确但性能远不如原系统。我见过一个案例AI把一段优化过的Fortran循环翻译成了Python的列表推导功能完全正确但运行时间从2秒变成了45秒。对于实时系统这是致命的。安全老系统可能有一些隐式安全——比如依赖网络隔离、依赖输入数据的可信性。迁移到新系统后这些隐式假设可能不再成立需要显式地加上安全控制。可观测性老系统可能没有日志、没有指标、没有追踪。迁移到新系统时要趁机补上这些能力否则出问题时无从排查。10.2 非功能需求的验证方法非功能需求的验证比功能验证更复杂我的做法是性能验证建立性能基准对比新老系统在相同负载下的表现。关键指标包括响应时间、吞吐量、资源占用。安全验证做威胁建模识别新系统可能引入的安全风险。重点检查输入验证、权限控制、数据加密。可观测性验证模拟故障场景验证日志、指标、追踪能否帮助快速定位问题。在一个电商订单系统的迁移中我们在性能验证阶段发现新系统的数据库查询次数是老系统的三倍。排查后发现AI生成的代码在循环中反复查询数据库而老系统用了批量查询。修复后性能恢复正常但如果没做性能验证这个问题可能在上线后才暴露。10.3 非功能需求的优先级非功能需求也有优先级。我的建议是安全最高优先级任何安全问题都不能妥协性能根据业务要求设定阈值超过阈值必须优化可观测性至少保证关键路径有日志和指标可维护性代码规范、文档、测试覆盖这些可以逐步完善11. 第十条建议迁移完成不是终点而是新起点11.1 迁移后的稳定期管理很多团队在迁移完成后就解散了这是大忌。迁移后的3-6个月是稳定期需要专门的团队来监控和处理问题。稳定期的主要工作包括监控告警建立完善的监控体系及时发现异常问题响应快速响应生产问题区分是迁移引入的还是原有的性能调优根据实际运行数据持续优化性能知识沉淀把迁移过程中的经验教训整理成文档11.2 老系统的退役策略老系统不能一迁完就关掉。我的建议是保留至少6个月作为热备份。如果新系统出现严重问题可以快速切回。退役老系统前要做几件事数据归档把老系统的数据完整归档确保可追溯文档整理把老系统的文档、配置、运维手册整理归档人员培训确保运维团队了解新系统的架构和运维方法应急预案制定新系统故障时的应急处理流程11.3 迁移经验的复用一个成功的迁移项目最大的价值不是迁移本身而是积累的经验和方法论。我通常会在项目结束后做一次系统性的复盘把以下内容整理成可复用的资产知识包模板领域知识包的结构和编写方法验证框架数值一致性验证、性能验证、安全验证的方法和工具提示词库针对不同迁移场景的提示词模板熔断机制熔断条件的设定和回退路径的设计团队配置角色分工和协作流程这些资产在下一个迁移项目中能直接复用大幅降低启动成本。12. 一个CTO最该问的问题我们真的需要迁移吗最后聊一个可能不太受欢迎的话题不是所有遗留系统都需要迁移。我见过太多项目迁移的动机是技术太老了团队不想维护了领导要求上云而不是业务需要。这种动机驱动的迁移往往投入巨大但收益有限。在决定迁移之前CTO应该问几个问题老系统还能稳定运行多久如果还能跑5年迁移的紧迫性有多高迁移的收益是什么是性能提升、成本降低、还是能力扩展迁移的风险是什么如果失败对业务的影响有多大有没有替代方案比如封装、部分重构、逐步替换我个人的经验是只有当老系统成为业务发展的瓶颈时迁移才是必要的。否则把资源投入到新业务上可能回报更高。在一个制造企业的项目中客户原本计划迁移一套运行了15年的MES系统。做完可迁移性分级后我们发现核心模块的风险极高而业务上并没有迫切需求。最终建议客户只做接口封装和部分模块优化把节省下来的资源投入到新的数据分析平台。这个决策后来被证明是正确的——新平台带来的业务价值远超系统迁移。迁移是手段不是目的。AI是工具不是魔法。把这两件事想清楚比任何技术方案都重要。