TypeScript与AI的碰撞：编译器迁移与未来展望

近期，TypeScript与C#的创造者、微软技术专家Anders Hejlsberg指出，现有编程语言之所以更适合AI编程，并非因为它们更“先进”，而是由于它们拥有庞大的训练数据集。

对于AI，他给出了一个直接的评价：

当前的大型模型，本质上更像一个“重新复述他人成果，并在此基础上进行简单推导”的高级复读机。

此番言论来自他与GitHub研究顾问Eirini Kalliamvakou的一次对话。在这次访谈中，Hejlsberg不仅分享了TypeScript团队内部使用AI的实际经验，还回顾了TypeScript的发展历程，并展望了它未来的可能演变方向。

TypeScript 7.0核心升级：原生编译器登场，性能提升10倍

即将推出的TypeScript 7.0，最重要的变化之一是引入原生编译器。目前该版本已进入预览阶段。

Hejlsberg表示，原先的TypeScript编译器是用TypeScript自身编写的，并运行在V8 JavaScript引擎上。但随着项目规模和使用场景的扩大，这种实现方式在性能上已明显不足：“我们很快发现，原生编译器能让性能提升10倍——其中一半收益来自原生代码本身，另一半则源于对共享内存并发特性的充分利用。”

尽管看似“从头开始”更为干净，但在TypeScript的场景下，这几乎是不可能的。

Hejlsberg解释说，TypeScript的类型检查器规模庞大、逻辑复杂，且存在大量仅体现在代码语义行为中、未文档化的隐式规则：

“TypeScript拥有一个庞大且逻辑复杂的类型检查器，其诸多行为逻辑仅体现在现有代码的精确语义中，并无其他文档或形式可完整复刻。”

如果不是逐函数、逐逻辑地移植，而是采用“等价实现”的方式，那么哪怕结果只出现微小差异，都会在用户迁移时引发大量长尾问题。因此，这款全新原生编译器的设计目标非常明确：输出必须和旧编译器完全一致，甚至要包括那些历史遗留的“怪癖”。

语言选择引发争议：放弃Rust、C#，最终选择Go

在为原生编译器选择实现语言时，TypeScript团队的决定一度引发了不小的争议。

Hejlsberg透露，迁移的技术需求直接排除了Rust：Rust不支持团队迁移所需的循环数据结构，同时也没有自动垃圾回收（GC），而这些在迁移过程中是必需的。

团队最初也对C#进行了相关试验，但最终还是选择了Go语言，因为“Go与JavaScript的语法和设计思路高度相似”。

这一决定让C#社区感到困惑，不少开发者质疑：

“作为C#的创造者，Hejlsberg为何不用自己设计的语言来提升一下C#的影响力？”

Hejlsberg没有直接回答这个问题，只是表示：“确实有很多人认为我们应该选择另一种语言。但我坚信我们选择了正确的工具，过去一年的实践已经证明了这一点。”

用AI做编译器移植？现实并不理想

在AI话题上，Hejlsberg的态度同样冷静。他透露，最初团队也曾试图用AI完成从TypeScript到Go的代码迁移工作，但“效果很不理想”。

他坦言，代码迁移需要绝对确定的输出结果——团队要迁移50万行代码，且要求新代码与原代码的执行逻辑完全一致。但如果让AI直接翻译代码，输出内容很容易出现“幻觉”，哪怕只是一点点差异，也意味着必须逐行人工检查，反而得不偿失。

这个观点与许多开发者对微软Visual Studio的吐槽相呼应：微软此前弃用了确定性强的.NET升级助手，转而推出基于Copilot的升级工具，而后者的非确定性输出也让开发者头疼不已。

在Hejlsberg看来，AI在代码迁移中的正确打开方式并非直接翻译代码，而是“让AI生成辅助迁移的工具程序”：通过AI开发的工具程序执行后输出确定的结果，真正为开发提速。同时他也认可AI的技术价值并表示TypeScript的语言服务（负责代码语法检查、修复建议的核心功能）正在大幅适配AI技术，“在这个场景下AI能发挥出远超人工的效果”。

与此同时团队也找到了AI的合适应用场景：在完成原生编译器的初始迁移后需要将旧代码库中新增的PR迁移至Go代码库——而在这个工作中“AI的使用效果相当不错”。

TypeScript的未来：语言不会激进更新但工具链会彻底改变

谈到TypeScript的未来Hejlsberg表示它仍将遵循一贯路线：先跟随JavaScript的标准化进程再在其上补充必要的类型系统特性。

作为JavaScript的超集TypeScript的发展本身也在反向影响JavaScript的标准化进程因此不要期待TypeScript语言本身出现激进变化——在Hejlsberg看来TypeScript未来最大的变革将发生在工具链层面。

“我曾经觉得IDE已经是终极形态了但AI的出现彻底改变了这一切。”在他看来如今AI不再只是IDE中的一个辅助插件反而变成了开发者需要监督的核心工具甚至“不再需要传统意义上的IDE作为载体”。

但Hejlsberg也补充道AI工具仍需要语言服务的底层支持这也是MCP等机制愈发重要的原因——将语言服务与MCP打通让AI能够直接提出语义级、结构级的问题和修改建议。

“AI需要具备等同于IDE能做的那些能力但要以LLM或Agent的方式来完成。这将会彻底改变开发工具的形态。”

TypeScript的诞生：并非为了“发明一门新语言”而是为了修复JavaScript的痛点而生

最后在此次完整访谈中Hejlsberg还讲到了TypeScript的起源故事。

这门语言的最初构想来自微软的Outlook Web团队。当时该团队正使用一款名为Script#的工具通过C#编写代码并编译为JavaScript以实现在浏览器中的运行。

Hejlsberg看到了这一思路的价值但并未选择基于C#开发而是决定打造一款JavaScript的类型化超集——他的核心初衷是：“通过扩展JavaScript的能力我们并非要创造一门全新的语言而只是想修复它本身存在的问题。”

如今TypeScript已跻身主流编程语言之列但另一方面微软将其编译器从自身语言迁移至Go的举动也在无形中承认了它在性能层面的物理上限。正如RedMonk分析师Stephen O’Grady去年的疑问：

“如果一门语言连自己的编译器都跑不动了这会不会反过来影响人们对它的看法？”

而这个问题或许还需要时间来回答。