如何有效推动大规模技术迁移?

前阵子有读者来信问到「目前在公司负责开发的专案因为初始建置时没有选用 TypeScript，因此一直使用 JavaScript 至今，因为目前各个趋势都显示 TypeScript 的重要性，而自己对 TypeScript 十分初学、需要实际应用经验，想请问在这种情况下，有建议办法让我有机会在公司用 TypeScript 吗？」

针对读者的这个问题，一个有效的解法是让公司知道「迁移的成本没有预期中的高」。借此让公司或团队愿意投入去迁移。

然而，要如何做到呢?

事前调查可用的工具

事前调查可用的工具，会是一个有效的关键。在进行程式码库迁移时，如果只是手动的一行行重新用新的技术写，那会是最耗时间成本的。要能够用最有效率的方式进行迁移，务必要善用相关的工具。因此，推荐在实际执行迁移前，先调查有哪先可以用的工具，让迁移能用效率更好的方式完成。

举例来说，在《Migrating millions of lines of code to TypeScript》一文当中，Stripe 团队分享了从 Flow 迁移到 TypeScript 的经验，并提到透过 Codemod 工具 (连结)，做语法上面的转换。因为许多语法是固定的，所以透过写 Codemod 的脚本，可以用程式的方式来做大范围的迁移。

事实上，在更早之前 Airbnb 团队有开源 ts-migrate (连结)，这个工具可以直接把整个 JavaScript 迁移成 TypeScript。当然一开始会有很多 any ，但这可以一步步慢慢修，只是最起码确保专案在迁移后，新的程式码都是用 TypeScript 来写。

用这种方式，就可以让初期的迁移成本几乎为零 (虽然有一点小代价是会有很多 any 在程式码库中)，但是这样做让接下来都能改用 TypeScript 写，成果面来看很值得。

透过 AI 加速

除了传统的软体工具外，在 AI 时代，透过 AI 工具来加速大规模技术迁移，也是很有效的方式之一。

举例来说，Google 在 2025 年发表的《How is Google using AI for internal code migrations? 》谈到在 Google 内部用 LLM 协助进行程式码迁移。而 Amazon 在《Evaluating Human-AI Partnership for LLM-based Code Migration》也谈到内部用 LLM 迁移上百万行 Java 程式码，从 Java 8 升级到 Java 17。此外，前面有提到的 Airbnb，在近期进行大规模的测试程式码迁移时，也透过 LLM 大幅加速 (连结)。

之所以 LLM 在程式码迁移有帮助，是因为许多传统的软体工具，在迁移时的帮助有限。因为传统软体能做的，是去写某些规则，但因为程式码很常会是有多种变异的，所以用固定的规则，在某些清况下会不足以应付。而 LLM 在这种有变异性的状况下，发挥会比较好。

首先我们看到 Google 的做法，LLM 在过程中有几个作用，首先是找寻要被迁移的程式码，在找到后会写一个新的版本，接着会跑测试，假如测试没过 LLM 会迭代下一轮继续修改直到测试通过。而最后程式码会由工程师来做 code review。透过这样的流程，上百万行程式码的迁移时间，省下超过 50%。

在《How is Google using AI for internal code migrations? 》这篇发表中，有谈到几个过程中运用上的方法，分别包含

在迁移过程不仅用 LLM，而是搭配 AST 工具来确保正确性，同时降低成本。之所以能降低成本，是因为很多固定的东西，可以由 AST 相关工具处理，所需的运算资源远低于 LLM，在百万行程式码的迁移下，累加能省的成本不少
为 LLM 设计工具包 (toolkit)，包含测试档案(test files)、接口档案 (interface files)、相关依赖的资讯，透过这个方式，模型会有比较充足的脉络来进行迁移
分治法 (divide and conquer)，如同许多演算法会把东西先拆小然后分别击破，在用 AI 协助迁移时，这个方法也很有帮助。一次要 AI 处理百万行程式码，在现行技术仍做不到，但是如果把问题拆小，然后把一个个小部分完成迁移，这样累加起来也能完成大规模迁移

事前调查可用的工具

透过 AI 加速

阅读更多