AI SI Dailytsrs：AI 参与的 TypeScript Rust 移植，值得换掉 tsc 吗？
AI 重写观察首篇：梳理 tsrs 的 TypeScript 编译器移植、官方性能数据、兼容边界与试用方法，判断它目前适合谁。
用 AI 把 TypeScript 编译器移植到 Rust，已经有了可以安装试用的开源项目：tsrs。它探索的问题很明确：在尽量保持 TypeScript 行为一致的前提下，类型检查能快多少、内存能少用多少？
这是「AI 重写观察」的第一篇。本文根据项目公开资料整理，未经本站实测；文中的速度与内存数据均来自官方，资料核对日期为 2026 年 10 月 22 日。
tsrs 重写的是什么
tsrs 是 TypeScript 7 编译器与语言服务器的 Rust 移植版本，代码位于 oxc-project/tsrs。它处理的仍是 TypeScript 代码，无需把应用改写成 Rust。
按项目的兼容文档，移植以 TypeScript 的 Go 实现为参照，逐函数迁移。评估时，应分清应用使用的语言、编译器的实现语言，以及具体版本支持的行为。
项目追求与上游一致，README 也注明它并非微软背书的产品。编译器采用 Rust 实现，并不会让 TypeScript 应用自动获得 Rust 的运行时性能。
为什么列入「AI 重写观察」
最直接的记录来自 Max Schwenk 于 10 月 19 日发布的 Owner 项目复盘。作者称自己没有手写代码，而是让 Claude Opus 5.5 忠实移植 TypeScript 的 Go 实现，由 20 多个子 agent 并行工作。作者记录的首次端到端运行有 78% 的错误基线逐字匹配，补上类型打印器后达到 99.97%。这是早期开发记录，不能当作当前所有场景的兼容保证。
这套流程值得参考：先固定上游行为，再用已有测试约束迁移结果。确定目标、安排验证和取舍优化仍需要工程判断。“没有手写代码”属于作者陈述，不代表没有人工指导和后续维护。
10 月 20 日，Cloudflare 宣布与 VoidZero、Max 合作推进 tsrs，在 Oxc 工具链中孵化，并计划用 agent 跟踪上游变更。公告还提到正与 Theo Browne 推进 tsc-rs 和 tsrs 的合并，应将其理解为进行中的计划。来源：Cloudflare 公告
“最高快 8 倍”应该怎样理解
Cloudflare 公告给出的早期结果是：与 TypeScript 7.0 相比，在相同类型检查 worker 数量下，tsrs 最高快 8 倍，内存使用约少 70%。这组数字对应公告中的测试条件；同一公告也指出，TypeScript 7.1 beta 自身已有明显提速。
因此，不能把相对 7.0 的最高值当成相对所有 TypeScript 版本的固定收益。来源：公告中的性能说明
仓库公开的基准测试方法区分默认线程配置与相同 checker 数量的比较，并记录耗时、峰值内存与错误数量。自行验证时，至少记录编译器版本、硬件、线程数、项目版本和完整命令。还要检查报错是否一致：漏掉错误换来的速度没有采用价值。
另一个优势：通过 Wasm 在浏览器里检查 TypeScript
相较 tsgo，tsrs 还值得关注的是 WebAssembly（Wasm）。Go 也能编译成 Wasm，但需要携带垃圾回收运行时；Rust 的内存管理方式让它更适合低内存开销的 Wasm 场景。这也是 Cloudflare 选择 Rust 的重要原因。来源：为什么选择 Rust
项目已提供 @tsrs/wasm，可在浏览器中用内存文件完成类型检查和代码输出。对在线编辑器、教学 Playground 和 AI 编程沙箱而言，这意味着可以把检查放到用户设备上执行，无需为这一环节上传源码或安装原生编译器。
Wasm 版目前单线程运行，不支持 --watch、--lsp，浏览器集成还需自行安排 Web Worker。因此，上文原生版的速度数据不能直接套用到 Wasm 版。
兼容性要按版本核对
项目将 100% 行为一致作为最终目标。当前兼容文档列出上游提交、基线测试结果和已知差异，并区分开发中的源码更新与已发布包。
main 分支文档中的进展，未必已经包含在你安装的 npm 包里。README 明确列出不支持 --init 和 --showConfig 参数；差异清单还列出 Windows 的文件监听（watch）支持缺口，以及诊断本地化、追踪和性能分析选项的限制。评估时应记录 tsrs --version 并核对发布说明，不能只凭“可替代 tsc”的定位判断自己的流程已经兼容。
语言服务器也要单独验证：命令行检查通过后，仍需检查编辑器的诊断、跳转和重构是否满足需求。
试用操作步骤
以下命令整理自项目使用文档，本站未在真实业务仓库中运行测试。建议在独立分支中试跑，同时保留现有的 typescript 依赖与检查脚本：
pnpm add -D tsrs
pnpm exec tsrs --version
pnpm exec tsrs -p . --noEmit--noEmit 仅做类型检查，避免生成编译产物。现有 tsconfig.json 仍控制编译选项；需要查看计数与耗时时，可以运行：
pnpm exec tsrs -p . --noEmit --extendedDiagnostics接着用原有命令检查同一份代码，比较诊断和退出码，再观察耗时与内存。项目若依赖框架专用检查器，也应保留；单独调用编译器并不能证明模板或框架检查已被覆盖。
现阶段适合谁关注
大型 TypeScript 仓库的维护者、受 CI 内存限制的团队，以及开发沙箱或浏览器开发工具的作者，可以优先做小范围评估。项目如果没有检查瓶颈，等待稳定版本和更多兼容反馈通常更划算。
从研究 AI 编程的角度看，仓库里的工程笔记也值得读：其中记录了测量、设计取舍、回归和未奏效的方法，旧记录只代表特定版本与机器上的结果。追踪这些记录，比只看发布时的性能标题更能判断项目进展。
我们后续会关注：已发布版本与上游的差异是否缩小、真实项目的报错能否保持一致，以及性能优势在同配置下能否持续。目前值得试跑和跟踪，生产替换需要你自己的兼容验证。