ChatGPT、Codex 与 Legacy Code：AI 是老系统的救星，还是压垮它的最后一根稻草？（Plus/Pro 实战观察）

每个有点年头的团队，都有一座不敢动的老系统。

代码是五年前离职的人写的。
文档停留在三年前的版本。
测试覆盖率聊胜于无。
没人完全搞得懂它，但全公司的业务都跑在它上面。

动它，怕出事。
不动，债越滚越大。

ChatGPT 和 Codex 火了之后，很多团队两眼放光：

“让 AI 来重构老系统，是不是有救了？”

答案是：有救，但顺序千万别搞反。

顺序搞对，AI 是 legacy 系统的救星。
顺序搞反，AI 会成为压垮它的最后一根稻草。

先理解：老系统真正的问题是什么

Legacy 系统的可怕，不在于代码旧。

旧代码如果行为清晰、边界明确、有测试守护，它可以再稳定运行十年。

老系统真正的问题是三个"不可知"：

行为不可知。

这段代码到底在干什么？
它为什么要这样写？
里面那个奇怪的 if 判断，是为了兼容哪个历史业务？

没人知道。
原作者早就走了。

影响不可知。

改这一行，会影响到哪里？
哪些功能隐式依赖了这个看起来没用的字段？
哪个定时任务在深夜悄悄读写这张表？

没人有完整地图。

验证不可知。

改完了，怎么确认没改坏？
没有测试，没有验收标准，甚至没有一份"系统正常行为"的清单。

改完只能靠祈祷，上线后靠用户反馈当测试。

这三个不可知，才是 legacy 系统的本质。
它们全都是知识问题，不是代码问题。

AI 改造老系统的正确顺序：先理解，再守护，后改造

直接让 Codex “帮我重构这个模块”，是最危险的用法。

AI 不理解那些没人写下来的历史原因。
它会好心地把"看起来奇怪的代码"改得"整洁优雅"。
而那份奇怪，往往正是某个血泪教训的形状。

正确的顺序是三步。

第一步：让 AI 帮你理解，而不是帮你改。

这是 AI 在 legacy 场景下最安全、也最被低估的用法。

把模块丢给 ChatGPT Pro，不是让它改，而是让它读：

“逐段解释这个模块在做什么。”
“列出这段代码的所有外部依赖和被依赖。”
“这个函数有哪些隐含的前提条件？”
“找出所有看起来奇怪、可能隐藏历史原因的写法。”

AI 读代码的速度是人的几十倍。
它能在一小时内画出整个模块的结构图——这张图，团队可能从来就没有过。

更进一步的玩法：让 AI 生成"行为档案"。

module: billing-engine ├── 对外行为：输入 X，输出 Y，副作用 Z ├── 隐式约定：依赖 order 表 status 字段必须先于 3 ├── 可疑写法：line 88 的 magic number 0.87，疑似历史汇率补偿 ├── 高危区域：退款逻辑与库存逻辑交织，修改需双重验证 └── 知识盲区：夜间对账任务逻辑，无人能确认完整行为

这份档案，把"不可知"变成"已知"。
哪怕一行代码不改，系统的风险已经下降了。

第二步：让 AI 帮你补守护网。

理解之后，不是马上改。
而是先给老代码织一张安全网：特性测试。

特性测试不问"代码写得对不对"。
它只锁定"系统现在的行为是什么"。

让 AI 做两件事：

分析代码的各种输入输出路径，生成行为覆盖的测试用例。
把当前的实际行为（包括那些看起来是 bug 但业务已依赖的行为）固化成测试。

覆盖目标 ├── 正常路径：标准订单计费 → 已锁定 ├── 边界路径：零元订单、负数退款 → 已锁定 ├── 怪癖行为：折扣四舍五入的特定方式 → 已锁定（业务依赖！） └── 异常路径：支付超时重试 → 已锁定

注意那个"怪癖行为"。

老系统里埋着大量"看起来是 bug，实际是特性"的行为。
上游报表、对账流程、合作伙伴系统，可能都依赖着这些怪癖。

测试把它们锁定之后，改造才敢说"行为不变"。

没有这张网，重构就是蒙眼走钢丝。

第三步：小步改造，每步都有测试兜底。

有了行为档案，有了守护网，现在才轮到 Codex 出场做改造。

纪律只有一条：小步。

一次改一个职责单元。
改完立刻跑全量特性测试。
绿了，提交，存档。
红了，回滚，分析。

改造循环 ├── 选定一个最小改造单元 ├── Codex 执行改造 ├── 特性测试全量跑 ├── 通过 → commit（检查点存档） └── 失败 → reset（回到存档点）

每一步都可回滚。
每一步都有行为对照。
老系统就在这个循环里，一寸一寸变得干净。

这个过程不性感，没有"AI 一夜重构十万行"的传奇故事。
但它是在生产环境上唯一负责任的玩法。

AI 时代的 legacy 新风险：技术债的生产速度加快了

说完救星的一面，必须说稻草的一面。

AI 编码有一个隐蔽的副作用：

它让"给老系统叠加新代码"变得极其容易。

以前，往 legacy 系统里加功能很痛苦——要读懂老代码，要小心翼翼，要承担心理压力。
这种痛苦，其实是一种天然的减速带，客观上限制了技术债的增速。

现在，Codex 五分钟就能在老系统上糊一个新功能。
不读全貌，不问历史，不问约定。

如果团队没有纪律，结果将是：

老系统以五倍的速度堆积新的技术债。
而且新债是 AI 生成的，连"作者自己都未必完全理解"。

一年之后，这座老系统不仅没变干净。
它还多长出了三层没人真正理解的 AI 生成代码。

所以必须立一条规矩：

AI 生成进 legacy 系统的每一行代码，都要遵守和人工代码相同——甚至更严格——的评审标准。

AI 不会为技术债负责。
负责的是引入它的人。

一个更大的图景：代码的理解成本首次低于编写成本

跳出来看，AI 对 legacy 系统最深远的改变，是一个成本结构的倒挂。

过去四十年，软件行业有一个默认事实：

读代码比写代码贵。
所以"重写"常常比"读懂再改"更有吸引力——尽管重写的灾难史罄竹难书。

ChatGPT 和 Codex 把这个成本结构打翻了：

AI 读代码又快又不知疲倦。
理解一个老模块的成本，第一次低于推倒重写的成本。

这意味着"重写派"和"维护派"争论了几十年的天平，正在倾斜。

越来越多的老系统，理性选择不再是重写。
而是：AI 辅助理解 → 测试守护 → 渐进改造。

那些曾经被判了死刑的 legacy 系统，第一次有了体面的逃生路线。

写在最后

老系统不是技术问题，是知识问题。

而 AI 最擅长的，恰恰是低成本地生产关于代码的知识：

它知道这段代码在干什么。
它知道改动会影响哪里。
它知道怎么把当前行为固化成测试。

理解、守护、改造。
顺序对了，legacy 系统有救。

反过来，拿 AI 当"快速糊功能"的工具，老系统会以前所未有的速度腐坏。

AI 不会拯救不重视知识的团队。
也不会拖垮尊重系统的团队。

它只是把团队原有的工程习惯，放大十倍。

老系统的命运，从来不在工具手里。
在团队的纪律里。