50 万行代码不敢交给 AI?TypeScript 之父直言:它就像是个“高级复读机”

文章核心观点 - 编程语言更适合AI编程的关键在于其拥有最大的训练数据集,而非语言本身的先进性 [1] - 当前大语言模型本质上是基于已有内容进行复述和简单推演的高级复读机 [2] - TypeScript 7.0将引入原生编译器,预计性能提升10倍 [5] - TypeScript团队选择Go语言而非Rust或C来重写原生编译器,并解释了选型理由 [7] - 在编译器代码迁移中,直接使用AI翻译代码效果不理想,但AI在生成辅助迁移工具和后续PR同步方面表现良好 [9][10] - TypeScript的未来发展将遵循现有路线,语言本身不会激进更新,但AI将彻底改变开发工具链的形态 [11][12] - TypeScript的诞生初衷是修复JavaScript的问题而非创造新语言,其编译器迁移至Go也引发了关于语言性能上限的讨论 [13] TypeScript 7.0 核心升级 - 即将发布的TypeScript 7.0将引入原生编译器,目前版本已进入预览阶段 [5] - 现有编译器由TypeScript编写并运行在V8引擎上,性能已无法满足项目规模扩大的需求 [5] - 原生编译器预计带来10倍的性能提升,其中一半收益来自原生代码,另一半来自对共享内存并发特性的利用 [6] - 新编译器的设计目标是输出必须与旧编译器完全一致,包括所有历史遗留的“怪癖”,以确保用户迁移的平滑性 [6] 编译器重写的语言选型 - 团队排除了Rust,因其不支持移植所需的循环数据结构且缺乏自动垃圾回收(GC) [7] - 团队最初试验了C,但最终选择了Go语言,原因是Go与JavaScript的语法和设计思路高度相似 [7] - 这一选择在C社区引发了不解和质疑,但团队坚信选对了工具,过去一年的实践已证明其正确性 [8] AI在代码迁移中的应用与局限 - 团队曾尝试用AI完成从TypeScript到Go的50万行代码迁移,但效果很不理想 [9] - 直接使用AI翻译代码容易产生“幻觉”,输出不确定,导致需要逐行人工检查,得不偿失 [9] - AI在代码迁移中的正确应用方式是生成能输出确定结果的辅助迁移工具程序 [10] - AI在将旧代码库新增的PR迁移至Go代码库的工作中,使用效果相当不错 [10] - TypeScript的语言服务正在大幅适配AI技术,在此场景下AI能发挥远超人工的效果 [10] TypeScript的未来发展方向 - TypeScript将继续遵循先跟随JavaScript标准化进程,再补充类型系统特性的路线 [11] - 不要期待TypeScript语言本身出现激进变化,未来最大的变革将发生在工具链层面 [11] - AI的出现彻底改变了开发工具形态,AI不再只是IDE中的插件,而变成了需要开发者监督的核心工具,甚至可能不再需要传统IDE作为载体 [11] - AI工具需要语言服务的底层支持,因此MCP等机制愈发重要,旨在让AI能直接提出语义级、结构级的问题和建议 [11] - AI需要具备等同于IDE的能力,但要以LLM或Agent的方式完成,这将彻底改变开发工具的形态 [12] TypeScript的起源与现状 - TypeScript的最初构想来自微软Outlook Web团队使用Script工具的经验 [13] - 其核心初衷是通过扩展JavaScript的能力来修复它本身存在的问题,而非创造一门全新的语言 [13] - TypeScript已跻身主流编程语言之列,但其编译器从自身语言迁移至Go的举动,无形中承认了它在性能层面的物理上限 [13]

50 万行代码不敢交给 AI?TypeScript 之父直言:它就像是个“高级复读机” - Reportify