没逐行读过代码就把 TypeScript 搬进 Rust：重点是「验收」而非「能跑」
结论先行
一个名为 ts-rust（tsc-rs）的项目，参照微软用 Go 重写 TypeScript 的原生实现，把编译器、类型检查器与语言服务器（LSP）再移植到 Rust。作者在仓库里明说：代码全部由 LLM 编写，自己并未逐行读过。 这条新闻真正的价值，不是「Rust 版能不能用」，而是它给「大规模 AI 生成代码」提供了一个可检验的真实样本。
三个要点
- 它之所以可行，是因为编译器「规格足够硬」。 TypeScript 有海量官方测试与真实仓库可做回归，正确性可以在很大程度上被外部证据定义，而不依赖作者的逐行理解。这是「免读」能成立的前提。
- 但这套方法不可迁移到规格模糊的地方。 业务逻辑、权限判定、财务计算没有一份测试能替你定义正确性。在那里，「我没读代码」等于把风险留给下一个维护者。
- 两件事不要混为一谈。 用 Rust 重写是为了性能与生态，AI 只是把「写」的成本压低了；它并没有降低「验」的成本。发布一个包，验证、安全与许可证的账一分没少。
- 它也顺带说明了一件事：语言与运行时的边界正在被重新讨论。 过去「把大型编译器换个语言重写」是十年量级的工程，需要一整个团队稳定投入。现在这个门槛被压低之后，真正稀缺的变成了评审能力——谁的团队能审得动这类产出，谁就能吃到红利。
对团队的建议
- 只在测试覆盖足够密的模块上，放开「AI 生成 + 人工免读」。 覆盖率是决定风险敞口的开关。
- 每个 AI 生成的 PR 必须附可执行的验证证据：测试、基准、与现有实现的差分对拍。不接受的只有一句话——「看起来对」。
- 在动工前先回答「谁来维护」。 生成成本下降了，维护成本没有。一个原作者不读代码的仓库，issue 响应与安全修复的责任必须提前说清楚。
- 顺带提醒许可证与归属问题：移植项目的上游许可条款通常带有传染性，发布前值得让法务看一眼。
一句话：AI 让产出的速度变了，但软件工程的评判标准没变——能不能被验证、由谁负责维护，这两条仍然是硬门槛。
参考来源
延伸阅读：Agent 代码沙箱怎么选：差别不在「能跑」，在「隔离到哪一层」 · GitHub 发布 ReviewBench：AI 代码审查开始有「考纲」，这是好事 · 321B 开源安全模型解出 40/60：真正看点是每次 6 美分