几乎每家有点年头的企业，都有那么一套"谁都不敢动"的系统。财务用它出月报，仓库靠它出库，但它跑在早就不生产了的硬件上，用市面上招不到年轻人的语言写成，当年敲下这些代码的人早就退休了。所有人和供应商说同一句话：先别碰它，能跑就行。
但"能跑就行"这四个字，是企业 IT 支出里最贵的一句话。这篇想聊清楚三件事：遗留系统到底贵在哪里、业内公认的三条现代化路径各自的真实成本区间与适用边界、以及一个可以直接拿去开会的选择判据。文中的数据来自几家机构的公开研究：美国问责局（GAO）2023 年关于联邦遗留系统支出的报告、Gartner 关于技术现代化项目的预算结构研究、Anthropic 在 2026 年 2 月关于用 AI 改造 COBOL 代码库的官方博客，以及咨询机构对遗留应用维护成本占比的调研。成本区间部分引用的是行业公开报价范围，实际项目差异很大，只能当作量级参考，不能当报价单用。
一、最贵的不是改代码，是"搞清这段代码在干什么"
Anthropic 那篇博客里有一句话，把整个行业停滞多年的原因说得很准：几十年来，遗留系统现代化一直停滞不前，因为理解旧代码的成本，已经超过了重写代码的成本。
这句话值得反复读。它的意思是，阻碍你改造老系统的技术瓶颈从来不是"重写有多难"，而是"你必须先知道要重写什么"。而这件事的成本，在绝大多数老系统上是失控的。GAO 2023 年的报告给了一个结构比例：美国联邦政府每年花费超过 100 亿美元维护遗留 IT 系统，而其中约 70% 的成本并不是花在开发和改功能上，是花在代码解读、需求对齐和风险排查上——也就是"搞清楚现在这套东西到底承担了什么业务规则，改这里会影响哪些地方"。
七成成本花在理解上，只有三成花在改动上。这个比例解释了为什么很多现代化项目一开局就卡住：项目预算按"改造工作量"排，结果全部消耗在前期的考古式调研，真正动手时已经没有余量。
咨询机构对这个问题给出了另一个角度的数字：在不少企业里，遗留应用的维护会消耗掉高达 90% 的 IT 预算。这并不意味着这些企业的运维团队低效，恰恰相反——它意味着预算的结构已经被老系统吃满了，留给新业务、新技术的余量只剩不到一成。Gartner 关于技术现代化项目的研究观察到的，正是这个结构在被强行扭转时的表现：一个现代化项目最常见的结果，是把 IT 预算中 15 到 25 个百分点从"维持业务运转"这一侧，转移到别处。
这三个数字放在一起，就能看清遗留系统的真实代价了：它不是"技术选型老了"这种体面的问题，而是一台持续占用现金和人才的机器。你为它付的钱，主要不是用来改进业务，是用来供养对它的理解。
二、为什么这类系统特别难处理：规模、依赖与人才断层
遗留系统里最典型的例子是 COBOL。它在 1950 年代末被设计出来用于商业数据处理，到今天仍在生产环境跑着。Anthropic 在博客里给出了两个量级：美国约 95% 的 ATM 交易依托 COBOL 运行；每天有数千亿行 COBOL 代码在生产环境中执行，支撑着金融、航空和政府部门的关键系统。行业里另一个常被引用的估计是，COBOL 每天处理的金融交易规模在数万亿美元量级。
这些系统为什么不能停、也不能随便动？原因不在技术上，在结构上。第一，它们承担的是不可中断的结算与记录职责——银行核心系统的日终批处理一旦出错，影响的是真实资金。第二，业务规则埋在代码里，没有任何一份文档能与代码同步。第三，掌握这些知识的人逐年减少，形成一个单向漏斗：懂的人越来越老，新人接不上，而每一次系统故障，都在消耗那批人剩余的时间和耐心。
一个在大行做过多年核心系统维护的工程师有过一句很直白的描述：这一行的工作其实不是写代码，百分之八十的时间都在给新入职的人、给外包厂商、给审计方，解释十年前二十年前写下的某一行代码到底是干什么的。这不是段子，这是 GAO 那个"七成成本花在解读上"的具体人间版本。
三、三条路径，三种完全不同的成本结构
业内处理遗留系统，通常归纳成三条路径。它们的差别不是"保守还是激进"，而是把钱和风险压在哪一侧。
第一条：就地改造（重构与平台迁移）。代码基本保留，改的是运行环境、数据库、局部架构，或者做代码级的整理与文档补齐。它的好处是业务规则不会丢——因为代码本身就是一份可执行的业务规则说明书。风险在于改造过程中新旧行为难以逐项比对，以及"改完之后依然没人真正看懂它"这个问题一点没被解决。
第二条：包裹（API 化 / 绞杀者无花果树模式）。老系统一行不动，在外面罩一层接口层，把它的功能当作内部服务能力对外暴露；然后新功能一律建在接口层之上，老功能逐个被新实现替换，直到老系统承担的部分缩小到可以下线。这是目前风险最低的一条路，因为它把"一次性大切换"变成"无数次小切换"，任何一步都可以停下来。代价是需要同时维护两套体系，而且总周期长——它买的是安全，付的是时间。
第三条：推倒重写。看起来最干净，实际上最贵、最容易失败。原因回到了开头那句话：你必须在动手之前，把老系统隐含的全部业务规则重新发现一遍，否则重写出来的东西跑不了真实业务。而"发现全部业务规则"这件事，按 GAO 的比例，正是那个吃掉七成成本的部分。
成本和周期上，行业公开报价给出的量级值得看一眼。以 COBOL 现代化为例，按代码行计价，范围大致在每行 1 到 25 美元之间：结构良好、可以自动化转换的老程序，落在 1 到 3 美元一端；而包含评估、转换、测试、切换和迁移后稳定化的全方位转型服务，可以到 10 到 25 美元甚至更高。折算下来，一个一百万行的 COBOL 系统，总成本可能落在 100 万美元到 2500 万美元这个跨度里——二十五倍的区间宽度，本身就是这个行业的真实写照：在评估做完之前，没有人能给你准确报价。
周期也是同样量级的差别。针对独立应用的定向转换，通常需要 3 到 12 个月；而涉及核心银行或政务系统的企业级项目，普遍要 2 到 5 年，并且必须分阶段交付，以保证生产系统在全程中持续运行。
四、怎么选：三个问题，不用打分表
面对一个具体系统，与其讨论方法论，不如依次回答这三个问题。它们的顺序是有意排的。
第一个问题：这套系统的业务规则，现在还有人能说清楚吗？如果答案是"有一个老师傅能说清"，那么优先动作根本不是现代化，是把老师傅脑子里的东西变成可查的资产——文档、决策表、带注释的模块说明。如果答案是"没人说得清"，那么任何重写方案都应当被暂时排除，因为你没有重写的输入。这时候唯一合理的路径是先包裹、先观察：把接口立起来，同时用真实调用摸清哪些功能在被谁用、用来做什么。
第二个问题：这个系统承载的业务，未来三年会变还是不变？规则稳定的部分（会计恒等式、日终对账逻辑）适合就地固化，不值得重写；规则高频变动的部分（促销算法、费率、审批流、合规口径）才是把逻辑从代码里搬出来、变成可配置项的收益所在。这一问能避免最常见的浪费：花大钱重写了那些本来就不需要改的东西。
第三个问题：能不能接受"两套并存"这一段过渡期？如果不能——预算、人力、心态上都要求一次了断——那么你很可能会选重写，而上面那些数字已经说明了这个选择的风险。能接受并存的，包裹路径几乎总是更稳的答案。这条判据之所以关键，是因为它决定了你是用钱换确定性，还是用确定性换钱。
把三问答完，路径基本就定了：说不清又必须继续用的，先包裹；规则变动大且业务重要的，逐步替换；只有那些规模小、边界清楚、且能一次性验证的独立模块，才值得直接重写。
五、被低估的变量：AI 正在改写"理解"这一侧的成本
回到开头那句判断。如果"理解旧代码的成本高于重写"是过去几十年现代化停滞的根因，那么这个根因正在被动摇。Anthropic 在那篇博客里的核心主张是：AI 可以梳理数千行代码之间的依赖关系、自动生工作流程文档，并识别出"人类分析师需要数月才能发现"的风险点；换句话说，AI 把"理解"这一侧的成本压下来了，而这一侧原本占七成。
这件事的实际意义，比"AI 帮人写代码"要具体得多。它意味着现代化项目的预算结构可能被重排：原本要花大半年做代码考古的部分，可以大幅压缩；而原本最省不出钱来的环节（依赖关系梳理、隐藏业务规则提取、迁移前风险定位），第一次有了可以批量处理的手段。同一段时期，IBM 这类以遗留系统维护咨询为核心利润来源的公司，其股价因为这类工具的出现而剧烈波动，也从侧面说明市场认为这块业务的成本结构会被重估。
但必须说清楚边界。第一，AI 降低的是解读成本，不降低切换风险——生产系统真金白银的日终批处理，不会因为文档生成得快就允许你少做一轮并行验证。第二，解读结果本身需要验证，一段被 AI 解释过的老代码，其正确性最终还是要靠真实数据的比对结果来说话。第三，涉及金融、政务这类强监管领域，可审计性与责任归属不会因为工具变强而消失。合理的使用位置是：把它用来扩大你在改造前能看到的信息面，而不是替你做上线决定。
所以这篇的结论，其实是一个很朴素的排序动作。遗留系统现代化的失败，很少是因为技术路线选错了，多数是因为在"没人看得懂"的状态下就启动了改造，把全部预算交给了考古，然后在中途停摆。真正务实的开工顺序应当是：先花小钱把这套系统的业务规则变成企业资产（谁在用、改一处会牵连什么、哪些规则是死的、哪些是活的），再决定它值不值得改造、以及用哪条路改造。在这个顺序里，Gartner 说的那 15 到 25 个百分点预算迁移，才是一次有意义的投资，而不是一次被迫的救火。
