开源社区最近被一个名叫 ts-rust 的项目刷了屏。项目发起方 pingdotgg 宣布，他们用大模型把微软基于 Go 重写的原生 TypeScript 7 编译器完整移植成了 Rust 版本，不仅跑通了上游全部 181,711 个测试用例，在多项自测中比 Go 版本快了 1.61 倍。更戏剧化的是作者的附注：整个过程耗费了超 42 万美元的 Token，而且他自己“从未读过其中一行代码”。
不用人类写一行代码就搞定大型工业级编译器，听起来像是软件工程分水岭。但把这层宣发包装一层层剥开后，展现在面前的不是神迹降临，而是一场典型的算力赌局，以及一堵难以逾越的工程现实之墙。
42 万美元账本背后的数字游戏
作者在主页上详细罗列了这次移植的烧钱记录：早期使用 GPT-5.6 Sol 和 GPT 6 Astra，耗费数月、写了 130 万行 Rust 代码，调用了超 40 万美元等值 Token，结果兼容性始终卡在 84% 左右。转折点发生在他换用 Opus 5.5 之后，模型完全推翻既有产物从零起步，只用 10 个小时就交出了可运行的初代版本；最终历时两周、消耗折合约 24,047 美元的 Token 完成全部测试对齐。
这套叙事极具传播力，既有巨额账单的冲击，又有模型之间的戏剧性逆转。但只要稍微核对事实，就会发现账本里的水分。所谓的 40 万和 2.4 万美元并不是真金白银的划扣，而是按照公开发布的 API 单价理论折算的虚拟账单。作者实际使用的是订阅账号，两周消耗对应的是其 200 美元订阅周限额的 925% 到 983%。不仅如此，整个开发过程没有经过第三方财务审计，也未公开完整的 Prompt 与执行日志。把按牌价估算的理论用量直接等同于工程研发成本，本质上是一场精明的吸睛术。
- 结论.大模型确实具备在单向测试集驱动下搬运代码的惊人耐力，但虚拟账单的轰动效应远大于它证明的工程经济学可行性。
微软为什么宁选 Go 也不碰 Rust
在这个项目出现的几个月前，微软于 2026 年 7 月 8 日正式发布了 TypeScript 7.0。当时官方把延续多年的 JavaScript 编译器整体重写为 Go 原生实现，VS Code 的编译耗时直接从 125.7 秒骤降至 10.6 秒，提速 11.9 倍，大型前端项目 Sentry 也录得了 8.9 倍 的性能提升。彼时社区里最普遍的疑问就是：既然追求极致速度，微软为什么不一步到位选用 Rust？
微软核心团队当时的权衡非常清晰。类型检查器本质上充斥着复杂的相互引用、循环依赖图以及多态抽象语法树（AST）。Go 的垃圾回收机制与指针模型，能够近乎一比一地映射旧版 JavaScript 的内存与算法架构，让庞大的诊断逻辑平滑过渡；而 Rust 极其严苛的所有权和生命周期规则，在面对这种可变图结构时必须引入大量的引用计数或内部可变性，这不仅会带来系统性重构风险，还会使团队后期的维护成本呈指数级上升。
| 评估维度 | 微软官方 TypeScript 7.0 (Go) | ts-rust 实验版本 (Rust) | 判断与代价 |
|---|---|---|---|
| 内存治理 | 原生 GC，容纳复杂可变 AST 图 | 暴力映射所有权，重构难度转嫁模型 | 架构复杂度未消除，只被黑盒掩盖 |
| 跨平台 WASM | 官方主干保持完备语言功能 | 4.2 MB 模块，仅单线程，缺 LSP/Watch | 牺牲核心开发者特性换取体积妥协 |
| 基准测试表现 | 扎实多核吞吐，稳定无倒挂 | 自测快 1.61 倍（特定无输出模式） | 极端多文件场景遭遇串行化卡点 |
ts-rust 声称在 M4 Pro 硬件（12 核、48GB 内存）的自测下，面对 6 个开源项目的几何平均耗时比 TS 7 快 1.61 倍，比老旧的 TS 6 快 11.4 倍。然而，这项对比是在启用 --noEmit 且关闭增量编译（--incremental false）的狭窄场景下测得的，并且对比的 Go 版本并未包含 PGO 与 BOLT 优化。更关键的是，ts-rust 内置了 Effect-TS 0.46.1 的诊断逻辑，代码严格锁定在 2026 年 9 月 29 日的微软单一提交 673a5f17d713（7.1.0-dev）上，根本不是一个具备完整生态兼容能力的生产方案。
架构妥协从来不是因为语言跑分不够快，而是要在运行速度与人类理解边界之间找到平衡。
社区撞墙：当百万行黑盒代码遭遇真实工程
正如古语所言，多易必多难。当开源社区真正把 ts-rust 拿进复杂工程检验时，未经人工推敲的代码很快露出了马脚。
开发者 Strate 在处理包含 3000 个 Vue 组件的真实工作区时，复现出了严重的性能倒挂：原版 ts-rust 因为内容映射的串行化瓶颈耗费了 16.11 秒，而微软官方的 Go TS 只用了 6.93 秒，前者比后者慢了足足 2.3 倍。直到社区提交补丁修复了这一缺陷，其耗时才被压回 5.46 秒。一个宣称全方位超越原版的系统，在面对非典型的重型并发场景时，暴露出了大模型在全局架构设计上的盲目搬运。
与此同时，它对上游代码的机械复刻带来了另一层尴尬：不仅继承了逻辑，还原封不动地继承了缺陷。在社区实测中，ts-rust 在特定用例下精准报出了与上游 Go 提交完全一致的 TS5115 错误；在一个包含 17 个工程的 monorepo 中，比对出的 1677 个诊断信息与上游别无二致。这恰恰印证了它并没有掌握类型推断的更高层次理解，它只是一个极其庞大、极其严密的语法转录机。
项目文档中坦承的缺陷清单同样冗长：编译输出有时会在某些 monorepo 下额外生成冗余文件并误报 TS6059；缺少项目引用的工程间依赖会直接报出模块丢失；tsc -b --watch 会突发内部错误；长期编辑下内存以每千次编辑约 20 MiB 的速度缓慢泄漏；甚至命令行版本号也会误报为上游版本而非 npm 实际包版本。至于被寄予厚望的 WebAssembly 支持，生成的产物体积为 4.2 MB（压缩后 1.8 MB），却受限于单线程环境，完全不支持文件监听、LSP 服务和 API 模式，无法承载高吞吐的日常开发。
- 风险.没有任何工程师通读过的百万行黑盒代码，一旦脱离了微软官方每一步演进的逻辑脉络，在下一次上游大规模重构到来时，自动化同步很可能会在幽灵 Bug 中彻底崩溃。
站在工具链演进的角度看，ts-rust 确实完成了一次壮观的体力奇迹：在严密测试集的护航下，大语言模型展现出了惊人的单向代码转换吞吐量。但把它捧为颠覆微软官方路线的救世主，则完全错估了工业软件的本质。
代码不是写完就结束的静止纪念碑，而是需要持续维护、调优、排查暗病的生活实体。当一个作者宣称自己一行代码都没读过时，他放弃的不仅是编写的苦工，更是对整个编译系统内在因果的掌控权。机器可以烧掉成千上万的 Token 帮你把图纸转成另一种材质，但当真实世界的地基产生裂缝时，能下井去排查险情的，依然只能是那些清楚每一根管道为何如此铺设的人类工程师。