AI 降低重写成本，测试资产仍是关键

AI 能快速生成代码，是否就能放心重写旧系统？dev.to 的一篇文章借 Claude agents 编写编译器、Cloudflare 用 AI 重建框架 API 的案例指出：两个项目在生成代码之前，都已有可复用的测试资产。代码写得便宜了，确认新旧行为一致的工作仍然要做。

目前能确认什么

据原文节选，编译器项目使用了 GCC torture 测试集，后期还加强了 CI 检查，阻止新提交破坏已有功能；vinext 则移植了 Next.js 仓库中的测试，并在每次 pull request 中运行测试。

这些案例也有明确边界：编译器成果仍是研究产物，不能直接替代生产编译器；vinext 被标为实验项目，尚未经过有意义的大规模流量验证。

作者由此重提 Joel Spolsky 在 2000 年对重写的警告：旧代码里看似杂乱的分支，可能保存着多年线上故障留下的修复。AI 缩短编码时间，并不会自动把这些知识完整迁移过去。

特征测试（characterization test）就是记录现有软件实际行为的一种办法。它先固定系统当前的输入输出，即使其中某些行为并不理想，也能帮助团队发现重写造成的变化。

我的判断

评估 AI 重写，先看能否验证兼容性，再看生成代码有多快。

对内部业务模块，具体的准备工作应是追查历史修复，把特殊输入、边界条件和对应输出变成可重复执行的测试。否则，一句「保持原有行为」很难成为验收标准。

但测试通过也有边界：它只能覆盖已写进测试的场景，API 覆盖率也不能直接证明生产可替代性。节选尚未给出后续如何组织这些测试的完整方案，也不足以判断两个案例的全部迁移与维护成本。因此，把它们的 token 费用直接套到自家模块上，作为重写预算，依据还不够。