Port of the TypeScript compiler, checker and lsp to Rust, by LLM（LLM 把 TypeScript 编译器移植到 Rust）

📅 2026-10-08 | 🏷️ 工程 & Agent | ⭐ HN 109 分 / 207 评论
🔗 原文：https://github.com/pingdotgg/ts-rust

是什么

开发者把微软 TypeScript 编译器、类型检查器和 LSP（语言服务协议）整体移植到 Rust（项目名 ts-rust / tsc-rs），全程由 LLM 编写代码——作者自述「一行都没读过」。项目目前已开源，作者称在其测试过的所有真实项目中达到 100% 兼容，可作为多数应用的 drop-in 替换，但仍属早期发布。

🔍 小白解读

先说几个词

• 编译器移植：把一个程序从 A 语言改写成 B 语言，功能保持不变。相当于把一本厚书逐章翻译成另一种文字，还不能译错任何一个公式。
• 类型检查器：编程语言的「语法体检医生」，在你运行代码之前检查数据类型有没有用错。TypeScript 的类型检查是出了名的重计算，快慢直接影响开发者体验。
• LSP：语言服务协议，编辑器里「代码提示、跳转定义、报错划线」背后的通用接口。
• 兼容性：新实现和老实现行为完全一致的程度。100% 兼容意味着换上新引擎，老项目不用改一行代码。

这篇到底在说什么

打个比方：这相当于让 AI 把一台精密发动机从「汽油版」完整改造成「电动版」，还要保证装回原车照常跑。作者先用 OpenAI 的模型（GPT-5.6 Sol 与 GPT 6 Astra）干了几个月，生成了 130 多万行 Rust 代码，烧掉 40 多万美元的 API 费用，兼容率却停在 84% 左右上不去。后来他把任务交给 Opus 5.5，出乎意料的是，这个模型从零开始重写（而不是继续用之前的代码），10 小时就做出了第一个能跑的版本，用十分之一的时间走得比之前更远。最终总花费约 2.4 万美元、历时两周。作者坦承自己从未读过这些代码，还在 README 里专门划了一条「The Slop Line」，声明分界线以下的内容都是 LLM 写的。

这跟普通人有什么关系

如果你是前端开发者，未来某天你的编辑器补全和报错可能快好几倍，构建提速也不再遥远。如果你是普通打工人，这件事的意义是：AI 已经能独立完成「以年计」的大型软件工程，尽管代价和坑都不小。

为什么值得架构师关注

• 成本模型重构：同一个任务，模型选择的成本差距是 17 倍（40 万+ vs 2.4 万美元）。AI 大型任务的立项预算必须包含「模型试错成本」，而不是按 token 均价线性外推。
• 验收策略比生成能力更关键：作者不读代码、只跑真实项目兼容性测试就敢发布，靠的是 TypeScript 庞大的现成测试面。「有客观验收基准的任务」才适合交给 AI 全自动——这是选型 AI 编程任务的判断标准。
• 卡在 84% 的长尾：OpenAI 模型几个月停在 84% 兼容，说明「最后 16%」的边角案例是当前模型共同的天花板，工程排期要为长尾预留人工介入。
• 基础设施机会：高性能 Rust 版 TS 检查器 + WASM 目标，意味着 CI 流水线与浏览器内类型检查的新可能。

核心内容

• 项目将 microsoft/TypeScript（即原 typescript-go 的原生 Go 实现）的算法与行为原样移植到 Rust，保留相同的 tsc 命令行、LSP 与 API。
• 第一阶段用 GPT-5.6 Sol 和 GPT 6 Astra：花费 40 万+ 美元 token、生成 130 万行 Rust、历时数月，兼容率止步约 84%。
• 改用 Opus 5.5 后从零重写，10 小时产出可运行 v0，以 1/10 时间超过前者进度；最终 API 花费约 24,047 美元、历时两周，相当于其 200 美元套餐周限额的 925%~983%。
• 作者声明从未读过一行生成的代码，项目以「真实项目 100% 兼容」为验收口径，明确标注为早期发布并列出已知问题。
• 动机包括：测试模型能力上限、做更快的 TS 类型检查器、支持 WASM 高性能运行。

行动建议

可在 CI 上小范围试用 npx tsc-rs 对比类型检查耗时，收益明显再考虑扩大；把「成本上限 + 客观验收基准 + 人工介入点」写进团队 AI 大任务模板；短期不要让未经人工审读的 AI 生成代码直接进入核心链路。其余团队了解即可。