80 万行代码、14.5 周：GitHub 用 AI 把 Copilot 运行时从 TypeScript 换成 Rust

启动一个命令行工具要等 5 秒，是什么概念？在你敲下回车、屏幕还空着的那几秒里，足够泡一杯速溶咖啡。GitHub 决定不再忍这件事，于是把 Copilot 的整个运行时换了一种语言重写——而这活，大部分是 AI 干的。

一分钟速览

• GitHub 将 Copilot CLI、桌面应用与 SDK 的运行时从 TypeScript/Node.js 迁至 Rust
• AI 辅助重写超过 80 万行代码，耗时约 14.5 周，合并 128 个 PR
• 启动、会话创建与单轮交互的耗时从 5.25 秒降到 292 毫秒
• Rust 运行时可通过 C ABI 直接嵌入宿主应用，省掉每个客户端约 100MB 的 V8 内存开销
• 迁移期间照常发版，共发布 135 个版本（35 个稳定版、100 个预发布版）

为什么要换语言

旧架构里，Copilot 的运行时跑在 Node.js 上，依赖 V8，通过进程边界与宿主应用通信。这套方案的好处是生态成熟、迭代快；代价是启动慢、内存重。每个客户端多出约 100MB 的工作集，对桌面应用来说是实实在在的负担。

Rust 版本的差别不只是”更快”。它可以编译成库，通过 C ABI 直接嵌进宿主进程，也可以选择保留独立进程模式。这意味着架构上的自由度：同一个运行时，既能轻量嵌入，也能隔离运行。

最难的不是重写，是边跑边换

GitHub 没有采用”另起一版、写完再切”的做法，而是增量替换：一个个 TypeScript 组件被 Rust 实现逐个顶替，中间用一个临时的 N-API 互操作层把两边缝起来。这样现有的端到端测试可以在其他部分仍是 TypeScript 的情况下，直接验证新代码。

这个兼容层在最膨胀的时候，内部导出项达到 2019 个，TypeScript 侧的调用点有 3356 处。可以想象那是一种什么样的状态：两套语言、一套接口、每天都在变。

数字里的信息量

截至 8 月 21 日，运行时包含 832378 行生产用 Rust 代码，以及 468689 行 Rust 单元测试。团队记录了 4478 次直接的 cargo check 执行，其中 87.1% 一次通过。绝大部分实现代码由 AI 智能体生成，编译、测试和人工评审负责发现回归——行为差异、状态与生命周期处理、库语义变化、优化逻辑丢失，都在这道关口被拦下。

87.1% 的一次通过率听上去不错，但反过来看，意味着每 8 次里就有 1 次要返工。这个比例恰好说明了 AI 写代码的真实水平：能干活，但不能放手。

社区在担心什么

讨论的焦点不在”该不该用 Rust”，而在”怎么证明换完之后行为没变”。有开发者指出，取消、重试、背压这些场景，编译器管不了，必须靠运行时验证。另一位技术负责人则认为，小体量、便于评审的变更、兼容层，以及工程师的人工判断，是这次能成的前提。

还有一条评论更扎心：难点在于挖出遗留系统里那些从来没有文档的行为约定。这些约定不在代码里，在人脑子里。

趋势洞察

这件事的真正意义，不是 Copilot 用了 Rust，而是它演示了一种新的工程范式：AI 负责规模化的机械重写，人类负责边界、评审和那些说不清道不明的隐性契约。这种分工如果成立，未来几年会有大量”历史包袱”被重新翻修——不是因为业务需要，而是因为改造成本终于降到了可接受的范围。

但也要看到前提：GitHub 有极其完整的测试体系和一支能读懂 Rust 的团队。换一家测试覆盖薄弱的公司，同样的方法可能产出的是一个更难维护的系统。

结语

5.25 秒到 292 毫秒，是用户能感知的收益；80 万行代码背后的人机协作方式，才是这次迁移留下的真正资产。

参考链接：GitHub 博客、InfoQ 英文原文