用AI两周把TypeScript重写成Rust：TSC-RS背后的真相

一位开发者宣布了一个听起来近乎疯狂的项目——TSC-RS（TypeScript Rust），一个用 Rust 完整重写 TypeScript 编译器、类型检查器和 LSP 的项目。更戏剧性的是作者的自述：他让 AI 智能体干了五个月，烧掉 40 万美元的 Codex token 却毫无进展，而换用 Opus 5.5 后，仅两周、约 2 万美元就做成了。整个过程中，他声称自己"没有读过一行代码"。

这个项目表面上是一次炫技式的"vibe coding"实验，但剥开 42 万美元的标题噱头后，它触及了几个真正值得关注的工程问题：AI 现在到底能做多难的任务？为什么 Rust 版本比官方 Go 版本还快？以及作者真正想要的东西——在浏览器 V8 隔离环境里跑完整开发体验——究竟意味着什么。

从 JavaScript 到 Rust，为什么这事一直被认为不可能

要理解这个项目的难度，得先理解 TypeScript 编译器的两个部分。把 TypeScript 转成 JavaScript（transpile）其实很简单，近乎 trivial，只需要把类型标注删掉。ESBuild 这类工具早就把这件事做得飞快。真正难的是类型检查（type checking），这也是耗时最多的环节。

TypeScript 的类型系统是图灵完备的，它要忠实编码 JavaScript 的所有古怪行为——变量类型在运行时可变、原型链、对象的各种隐式特征。作者打了个精妙的比方：用英语解释英语，比用西班牙语解释英语容易得多。把类型检查器从 JavaScript 迁移到另一种语言，天然就是逆水行舟，因为编码语言和被编码语言不是同一种时，复杂度要乘以一百倍。

正因如此，这个任务长期被当作"不可能"的试金石。作者坦言，他最早启动这个项目就是为了找一件模型"绝对做不到"的事，用它来测试每一代新模型的能力边界。用 OpenAI 的模型，最远只能做到约 84% 的兼容性，而且越接近完成，剩下的边缘情况越难啃。

TypeScript 类型系统的图灵完备性并非夸张说法。它意味着仅凭类型层面的表达式，就能模拟任意计算——包括条件类型（A extends B ? C : D）、递归类型、映射类型等组合使用时，理论上可以在类型层面运行任何程序。这一特性使得类型检查器本质上需要解决一个不可判定问题：在有限时间内推断任意复杂类型表达式的结果。官方 TypeScript 编译器用启发式策略和深度限制来规避这一理论瓶颈，但任何要实现完整兼容的替代品，都必须忠实重现这些边界行为，而不只是覆盖常见路径。这也是为什么"84% 兼容性"和"100% 兼容性"之间存在巨大鸿沟——剩下的 16% 往往集中在那些极端的类型体操场景，而这些场景在真实大型项目（如 effect、tRPC）中并不罕见。

Opus 为什么能成功：它选择移植 Go 而非 JavaScript

真正的转折点藏在实现细节里。作者进入代码仓库时发现了一个"可疑"的决定：仓库里有一个把 Go 标准库逐行移植到 Rust 的 go-std，甚至包括用 Rust 重新实现的 goroutine。

这揭示了成功的关键——Opus 并不是从 JavaScript 移植 TypeScript，而是从微软官方用 Go 重写的 TS Go（TypeScript v7）逐行忠实移植到 Rust。Go 作为起点远比 JavaScript 合适，因为微软团队已经手工把 TypeScript 的所有诡异行为编码进了 Go。AI 做的是语言到语言的翻译，而非语义重建，这难度要低得多。

一个有趣的旁证是：首次运行时 TS Rust 比 Go 版本慢 2 到 3 倍，因为逐行移植连 goroutine 这类机制都重新实现了。作者于是下达目标"每方面至少快两倍"，让它跑了两周，最终做到了。更黑色幽默的是，官方 TS Go 当时有五个已知 issue，这个 Rust 版本忠实地把其中的 bug 也一起移植了过来——六个 issue 里只有一个是 TS Rust 独有的，其余五个都是 TypeScript 本身的 bug。这反而证明它是一个高保真的 drop-in 替代品。

微软的 TS Go（TypeScript v7）项目是理解本文的重要背景。2024 年底微软官方宣布用 Go 重写 TypeScript 编译器，目标是将大型项目的类型检查速度提升约 10 倍，同时保持与现有 TypeScript 生态的完整兼容性。选择 Go 的核心原因是工程务实性：Go 的并发模型（goroutine）、内存布局和代码风格与原始 TypeScript 编译器的设计理念更为接近，便于团队成员理解和维护，且 Go 拥有成熟的原生编译和垃圾回收支持。然而 Go 的垃圾回收机制给 WebAssembly 编译带来了显著障碍：GC 需要运行时支持，导致 WASM 产物体积膨胀、暂停延迟不可控，在浏览器和边缘计算环境中表现不佳。这正是 TSC-RS 项目存在意义的前提——Go 解决了性能问题，却放弃了"随处运行"的能力，而 Rust 则两者兼得。

性能对比与成本的真实账本

按作者给出的数据，TS Rust 相比 TSC 6（最后一个 JS 版本）快约 12.5 倍，部分场景可达 20 倍；相比微软官方的 Go 版本 TS Go，快约 2 倍。

关于那个耸人听闻的 42 万美元标题，作者算了笔更真实的账。真正起作用的 Opus 5.5 工作量，若按完整 API 价格计算约 5.4 万美元，但他用的是订阅制。折算下来大约消耗了一个账号约 10 个"周限额"的用量，按订阅成本粗算约 500 美元。也就是说，"42 万美元"主要是前期用 OpenAI 模型打水漂的沉没成本和满额 API 的名义价格，真正高效的产出只花了约 500 美元订阅额度。

值得一提的是，这不是孤例。Bun 也推出了 Bun Check，同样是 Rust 重写的类型检查器，速度甚至更快。但作者指出 Bun Check 在 effect、Sentry、tRPC 等重度依赖复杂类型的大型项目上会漏报或误报错误，保真度不够；而 TS Rust 把 effect 的类型检查插件直接内建，在 T3 Chat 的实际场景里反而比 Bun 快约 4 倍。他的结论颇为中肯：新项目用 Bun 全家桶时 Bun Check 是好选择，但要高保真替代官方编译器，TS Rust 更可靠。

真正的目的：把完整开发体验塞进 V8 隔离层

作者反复强调，性能并不是他真正想要的。真正的理由是 WebAssembly。

Go 的垃圾回收机制让它很难被打包成小体积、高性能的 WASM，这也是为什么 TS Go 失去了原本 JavaScript 版本"随处可运行"的能力。Rust 则天然适合 WASM。有了 Rust 版的类型检查器，一个大胆的设想就变得可行：让整个 TypeScript 开发循环——编辑、编译、类型检查——全部运行在 V8 隔离环境（isolate）里，而不是传统的虚拟机。

作者展示的 demo 中，一个由模型构建的完整应用全部跑在 V8 isolate 里，连文件系统设为只读也照常工作，整个过程峰值内存不到 260MB、CPU 占用约 4%。这里借鉴了 Vercel 的 Just Bash——一个在内存中为智能体伪造完整 bash 环境的库，让 agent 以为自己拥有真实的文件系统和进程。

为什么这件事重要？作者给出了一个关于成本趋势的判断：推理（inference）价格正在以每年 10 倍甚至更快的速度下降，而 AI 对内存的疯抢让 VM 和内存的租用成本每年上涨 25% 到 30%。两条曲线正在交叉——很快，运行 agent 的那台虚拟机会比 agent 本身的推理还贵。

这就引出了 Cloudflare 式架构的价值。传统云（AWS、Heroku 等）在应用层叠加 Docker 和操作系统，每个实例都吃掉大量资源；而 Cloudflare Workers 把代码跑在 V8 isolate 里，共享同一个事件循环和调度器，代码空闲时几乎不耗 CPU。谷歌为 V8 投入的巨额资金，意外地让整个生态受益——一个 Chrome 标签页比一个 Docker Postgres 实例轻得多。TS Rust 正是把完整开发体验搬进这种廉价隔离层所缺的最后一块拼图。

V8 隔离（V8 isolate）是 Chrome 和 Node.js 底层 JavaScript 引擎 V8 的一个核心概念。每个 isolate 是一个完全独立的 JavaScript 执行环境，拥有自己的堆内存和垃圾回收器，彼此之间无法直接共享内存。Cloudflare Workers 和 Deno Deploy 等平台正是利用这一机制，在同一个进程内同时运行数千个"租户"的代码，而传统的 Docker 方案需要为每个租户分配独立的操作系统进程乃至虚拟机，开销相差数个数量级。一个冷启动的 V8 isolate 通常只需几毫秒和数 MB 内存，而一个最小化的 Docker 容器启动往往需要数百毫秒和数十 MB 额外开销。这种密度差异正是作者判断"VM 成本将超过推理成本"的技术基础——当每个 AI agent 任务都需要一个隔离执行环境时，容器化方案的固定开销会变得难以承受，而 isolate 方案的边际成本接近于零。

对软件工程意味着什么

作者的态度带着明显的"AI 狂热"色彩，但他的核心论断值得严肃对待：这类"YOLO 项目"本不该可行，连通过测试都不该做到，更别说成为可用的 drop-in 替代品。而现在它成了。

他特别点出，自己在这个项目里的真正贡献不在于写出"高 IQ 的提示词"，而在于搭建环境——设置并行工作流、通过 SSH 调度多台机器、持续审计瓶颈和失败模式，让多个 agent 能并行工作而不互相干扰。他把自己的角色类比为管理者：不下场写代码，而是确保团队有一切所需去高效工作。这或许是对"AI 时代工程师角色"最务实的描述之一。

需要清醒看待的是，这篇素材本质是作者的单方自述，42 万美元、12.5 倍提速等数字均来自其个人估算，缺乏第三方验证，读者应保留判断。但即便打足折扣，"AI 把被认为不可能的编译器移植在两周内做成"这件事本身，已经足够说明工具能力的跃迁速度。

作者最后的感慨颇具代表性：过去这些疯狂想法只能停留在脑海里，顶多讲给更聪明的人听、期待五年后有人实现；现在他只需告诉 Opus"去做"，然后看它成不成。工程的面貌正在被重新定义，而这种变化的节奏，确实令人难以想象明年会走到哪里。