AI让重写祖传代码变得便宜了，所以更该先做这件事

十年前，「重写」是技术团队最危险的词。老系统里那些看不出原因的特殊分支、奇怪的取整方式、没人敢删的注释掉的代码，都是十几年业务事故沉淀下来的。重写意味着把这些记忆清零。

现在，大模型能在几天内读懂一个几千行的模块，把 Java 8 迁到 Kotlin，把 jQuery 迁到 React。成本确实降了一个数量级。于是很多团队的第一反应是：终于可以重写了。

这时最该做的不是写新代码，而是先给老系统拍一份完整的证据。因为 AI 最容易丢掉的，恰恰是那些「没有理由的理由」。

为什么 AI 重写特别容易丢隐性规则

模型的训练目标是把代码写得「合理」。老系统里大量的代码不合理：

• 这个判断 if (amount > 0 && amount < 9999999) 多出的上限，是因为 2009 年某次批量导入异常；
• 这个循环看起来可以改成批量更新，但必须逐条发事件，因为下游对账系统依赖顺序；
• 这里的金额用 double 而不是 BigDecimal，是因为历史数据里有 null 被转成了 0，改动会导致大批历史订单重算差异。

模型看到这些会优雅地「修正」它们——每次修正都合理，合起来就是把业务规则改了一遍。它不知道哪个奇怪是 bug，哪个奇怪是护身符。

所以重写项目的成败，取决于你在让 AI 动手之前，采集了多少「奇怪之处的解释」。

四类必须先采集的证据

一、行为基线：老系统到底在做什么

这不是读代码，是观测运行。最有效的方式是用真实历史数据做影子运行（shadow run）：把过去 12 个月的输入重放到老系统，录下全部输出，包括中间状态、外部调用、异常分支。

这份输出就是新系统的验收标准。没有它，你无法判断「新系统和老系统不一样」是修好了还是改坏了。

实操建议：优先覆盖金额、税额、库存、账期这四类核心计算。抽样 5000 笔覆盖各种边界（零值、负数、超限、跨期、退款），比全量随机抽样更有价值。

二、例外清单：哪些怪是有原因的

组织一次「例外收集」，对象不是代码而是人。

• 找运维，看监控告警里哪些是「已知会报但不用管」的；
• 找客服，问哪类工单反复出现、每次怎么处理；
• 找财务/业务，问哪些数字他们要手工调整；
• 看代码里的 TODO、FIXME、// 不要删、// 特殊情况；
• 查版本历史里，出过生产事故的提交。

把这些整理成一份表：现象、原因、约束、如果不遵守会怎样。这份表是重写项目最重要的输入，没有任何 AI 能自动生成它。

三、隐式契约：谁在依赖你的怪行为

老系统里很多「怪」是被外部依赖的。导出的 CSV 列顺序别动、接口的错误码别改、时间字段别换成 ISO 格式、分页从 1 开始别改成 0。

采集方式：查访问日志，列出所有调用方；对每个调用方确认它依赖的字段与格式。这类信息在代码里完全不可见，只存在于别人的实现里。

四、数据形状：真实数据的脏度

AI 常常基于类型定义写实现，而真实数据里有 30% 的字段是空字符串而非 null，有手机号存了三种格式，有地址里塞了备注。

做法：在写任何新逻辑前，对每个关键字段跑一次真实数据统计——空值率、长度分布、格式分布、枚举值实际取值。把这些结果贴进给 AI 的上下文，它写的校验逻辑会立刻务实很多。

AI 在重写项目里该扮演什么角色

结论不是别用 AI，而是换位置。AI 最强的不是写出新代码，而是做三件以前极其耗时的事：

一、把老代码翻译成人能读的规格。 让它逐个方法输出「输入 → 行为 → 边界条件 → 可疑之处」，人工审阅这份规格，比读代码快十倍。可疑之处会自动浮出来，成为例外清单的候选。

二、生成差异分析器。 让 AI 写脚本，对新旧系统的输出做逐字段对比，并聚类差异模式。这个活儿手工做极其痛苦，而它对 AI 来说是最擅长的确定性任务。

三、按规格生成新实现 + 测试。 有了行为基线，AI 生成的代码就有了客观的验收标准，从「看起来对」变成「跑起来一致」。

顺序很重要：先让 AI 读，再让 AI 写。 反过来就是拿生产环境做实验。

一个判断该不该重写的简单标准

重写值得做，当且仅当：老系统的维护成本（每次改动的排查时间 × 频率）持续高于重建成本，且老系统无法通过渐进式改造继续演进。

如果只是因为「代码难看」，那用 AI 做局部重构的性价比要高得多：给它一个模块、一套测试基线，让它逐步改造，每一步都能回滚。这种「外科手术」式的做法损失的业务记忆最少，风险也可控。

小结

AI 让重写变便宜了，但它没有降低「丢失业务记忆」的代价。所以重写之前先做四件事：录下行为基线、整理例外清单、盘清外部契约、摸清数据形状。做好这四件，AI 才是在帮你重写；没做，AI 就是在帮你悄悄改业务。