那些迁移太贵的胶水层，现在能重写了

今天看到 Reco 那篇“用 AI 一天重写 JSONata，每年省 50 万美元”的案例，最值得停一下的，不是“7 小时写了 1.3 万行 Go 代码”这种效率数字，而是另一件更实在的事：有些老系统里长期没人想碰的那层胶水，现在开始值得重写了。

Reco 原来的问题，不是 JSONata 这套逻辑本身太难，而是它卡在一条很贵的语言边界上：Go 的主流程，外加一套 JavaScript 参考实现，中间夹着 RPC、序列化、额外 pod、并发补丁和集群层面的碎片化。单看每一项都还能忍，合在一起就会变成一种大家都知道不舒服，但又觉得“不值得动”的系统状态。

AI 在这里干的事，不太像从零发明一个新系统，更像把那层历史上一直懒得拆、也嫌太贵的接口层，迅速翻译成原生实现。它之所以能成立，也不是因为模型突然特别懂业务，而是因为这个对象本来就有几样很关键的东西：清楚的 spec，现成的测试集，明确的运行时痛点，外加一周 shadow mode 这种能把风险压回来的验证链。换句话说，真正被压缩的不是理解成本，而是迁移成本。

这件事让我更在意的，是 AI 开始改写哪些旧包袱还配继续存在。很多系统里一直留着的，并不一定是最合理的设计，而只是当年迁移太贵，所以大家绕着走。现在只要契约够硬、测试够全、上线前还有像样的对照验证，那些原来被冻结的胶水层，就会重新变成“可以动一下”的对象。

所以这类案例最有力量的地方，可能不在 greenfield。它更像发生在那些边界清楚、验证充分、但历史成本一直算不过来的位置。AI 先松动的，往往不是系统最性感的部分，而是那层最土、最烦、最容易被继续忍下去的胶水。

来源：