大家好，我是蓝戒。本篇我们来聊聊：“AI两周重写TS编译器”。
如果有人在前几年跟你说：“给大模型两周时间和两万多美元 Token，它能从零用 Rust 完整重写一套工业级的 TypeScript 编译器，而且能把微软官方的 18 万个严苛测试用例一个不落全跑通”，你大概率会觉得这人喝高了在吹牛。
因为编译器这玩意儿，向来是软件工程里公认最难啃的“硬骨头”之一。
复杂的 AST 抽象语法树、嵌套递归的类型推导、成千上万个历史边缘 Corner Case。哪怕是资深编译器工程师团队，把几百万行复杂的类型检查器跨语言重写一遍，往往也需要耗费数年心血。
但这件看似天方夜谭的事情，在过去两周里真实地上演了。
根据 AI News 官方要闻通报 与科技社区 dev.to 深度评测报告，知名全栈技术极客 Theo Browne（@t3dotgg）正式开源了基于 Rust 重写的项目——tsc-rs（基于 Rust 的完整 TypeScript 7 编译器、类型检查器与 Language Server）。
整个项目的代码，几乎全部由 Claude Opus 5.5（依托 Claude Code 终端）在两周内全自主推进完成。
最让整个技术界哑口无言的硬核指标在于：原版极其庞大的 181,711 个测试用例，100% 编译通过！
更具戏剧性的是 Theo 在社交平台上的幕后自白：
在此之前，他曾尝试用别的模型烧了近 40 万美元的 Token，结果卡在 84% 的兼容性死胡同里彻底烂尾；而这一次换用新的调度方式与执行模型，只花了大约 2.4 万美元，两周就冲过了终点线。
抛开网络上那些夸张的情绪宣泄，今天蓝戒就以一线开发者的视角，带大家深度复盘这场工业级重构的底层技术秘密：
面对 18 万个庞大测试，AI 为什么没有陷入死循环？它是怎么做到不被上下文撑爆的？我们又能从中偷师到什么？
奇迹复盘：面对 18 万个测试，AI 为什么没有被绕晕？
很多自己写过 Coding Agent 的朋友都知道，让大模型写代码，最怕的就是“越跑越乱”：
遇到几个报错，模型开始在死循环里打转；给它塞的代码一多，上下文迅速被撑满，接着开始胡乱删改之前写好的正常文件。
重写编译器面临的更是这种地狱级难度：
改动一个类型推导规则，往往会引发连锁反应，导致后面几千个用例瞬间满屏飘红。
Claude Code 是怎么抗住这 18 万次压力测试的？
核心秘密非常纯粹：Theo 根本没有让 AI 去“凭感觉猜代码”，而是为它套上了一套极其冷酷的自动化 TDD（测试驱动开发）闭环。
整套流水线的运转逻辑严密得像一台高精度钟表：
- 测试先行，立下不可动摇的法官：团队第一件事不是让 AI 动键盘写 Rust，而是把官方原版测试集完整平移过来。测试用例就是唯一的客观真理，改得对不对，全凭测试说了算；
- 极小步切片，严禁全局污染：面对 18 万个测试，系统绝不把所有用例一股脑倒进上下文。而是每次只挑一组失败的特定模块（比如某类泛型推导），只把该模块相关的 AST 片段和报错日志喂给模型；
- 红绿循环与自动回滚机制：
- 捕获失败的单测；
- 让 Agent 编写 Rust 补丁；
- 自动在沙箱里执行
cargo test； - 一旦发现新补丁虽然修好了当前用例，却导致之前通过的用例发生了倒退，底层控制环毫不犹豫地执行 Git 强制回滚，换一种思路重新推演。
没有天马行空的自由发挥，只有在窄门里不断试错、验证与收敛。这才是能啃下几十万行巨型项目的真实工程底色。
客观实测：跑通了测试，它就真的能直接替代官方编译器吗？
根据 Theo Browne / tsc-rs GitHub 仓库 披露的数据，它的表现确实令人惊艳：
- 在实际跑大型开源项目（如 TanStack Query 核心库与 Hono 框架）时，它输出的类型检查诊断报告与微软官方版本几乎完全一致；
- 得益于 Rust 语言的底层性能优势，实际编译速度比原版 TypeScript 快了大约 1.6 倍，比老旧版本快了 11 倍。
但作为清醒的技术人，我们绝不能只看光鲜的宣传，必须直面作者在文档里极其坦诚公开的几个现实缺陷：
1. 长会话下的轻微内存增长
在长时间高频编辑的语言服务场景下，每进行 1000 次代码修改，内存占用大约会有 20MB 的非预期增长，说明底层的资源释放和生命周期管理依然存在不够老练的瑕疵。
2. 大型单体仓库（Monorepo）的构建时序波动
在面对极其复杂的跨项目多包依赖引用时，偶尔会出现编译缓存过期的风险，多工程协同的健壮性还需要经历更多工业级现实考验。
3. “能跑通测试”不等于“能长期免维护”
测试集覆盖的永远是已知的行为。当未来 TypeScript 规范继续推出新语法特性、底层抽象演进时，依然需要具备顶级系统架构能力的资深人类工程师去为它掌舵。
开发者借鉴指南：普通人如何用这套打法重构老旧系统？
看完这场惊人的战役，我们最应该思考的是：如果明天老板让你把公司一套五年前的老旧遗留服务换个现代语言重写，你该怎么借力 AI？
Theo 这套经过两万美元真金白银验证的工作流，给我们指明了三条绝不踩坑的铁律：
铁律一：没有自动化测试保护的代码，坚决不让 AI 碰
不要直接把一个几万行老项目的源码扔给大模型说“帮我转成 Go 或 Rust”。
正确的做法是：先让 AI 或者你自己，把原有系统所有核心接口的请求响应与边界测试，全部固化成一组组确定性的自动化单测。没有裁判入场，盲目开工等于自杀。
铁律二：每次只给它一块巴掌大的战场
把大工程拆解成几十个细粒度的功能切片。每次只让 Agent 专注于让 5 到 10 个测试用例由红变绿，完工一个立刻提交一个原子 Commit。永远保持上下文极度清爽，绝不给模型胡思乱想的机会。
铁律三：必须给 Agent 配上“自动撤销的安全带”
在本地配置好脚本，只要改动引入了新的回归报错，立刻自动触发版本回退。千万不要顺着错误一路硬修下去，沉没成本越滚越大，最终只会把整个工程拖入泥潭。
软件工程正在重归“纪律与确定性”
回顾过去这一年多，互联网上充斥着两种极端的声音：
一种人盲目吹捧“程序员明天就要失业，敲敲键盘万物皆可生成”；
另一种人则冷嘲热讽“AI 写的全是玩具，复杂逻辑根本指望不上”。
而 tsc-rs 的诞生，恰恰给这两种声音上了一堂极其清醒的公开课：
大模型确实拥有不可思议的工程潜力，但前提是——人类必须退回架构师和裁判员的位置，为它建造一套足够严丝合缝的制度铁轨。
跑通 18 万个测试的奇迹，表面上看是底座大模型单兵作战能力的胜利，但往深了看，真正获胜的，是测试驱动开发（TDD）这一经典软件工程方法论在新时代的伟大复兴。
学会为 AI 制定规则、设立门禁、管理上下文，把不确定的生成式智能装进确定性的工程轨道里，这才是每一位工程师在智能时代最硬核的看家本领。
文章评论