AI写了80万行Rust，最值得学的却是它花十倍精力读代码
内容提要
GitHub 用 AI 将 Copilot 运行时迁移为 80 万行 Rust，复盘发现 Agent 读代码、搜索和诊断的活动约为编辑的十倍。项目采用原地原子迁移，每个 PR 只迁移一个组件并删除旧实现，保持主干可发布。瓶颈不在生成代码，而在理解系统、验证行为不变。回归仍靠工程判断，需强测试资产和可验证切片。
延伸解读
AI迁移的真实成本：理解而非生成
文章指出，Agent在读取、搜索和诊断上的活动约是编辑的十倍，说明大规模AI开发的主要瓶颈是理解移动中的系统并证明行为不变，而非生成语法。这提醒团队，评估AI编码效率时不能只看代码生成量，更要关注Agent在探索和验证上的投入。
原地原子迁移：小步快跑降低风险
GitHub采用每个PR只迁移一个组件的策略，用薄适配层从TypeScript调用Rust并删除旧实现，保持主干可发布。这种做法的价值在于让每次变化足够小，问题能与最近版本关联。但边界耦合的组件需先拆边界、补测试，不能指望Agent一次吞下。
性能提升需谨慎解读
官方测试显示，客户端、会话、单轮交互从5.25秒降至292毫秒，恢复32轮会话从5.64秒降至264毫秒。但文章强调，不同部署路径、硬件和测量条件会影响数字，不能当作Rust对Node.js的通用倍数。读者应关注具体场景下的基准，而非简单类比。
回归与测试神谕：AI无法替代工程判断
团队修复了数十个迁移回归，涉及状态生命周期、行为契约和资源所有权。文章特别指出“测试神谕”问题：旧测试可能把历史Bug当正确行为，或漏掉时序、内存与取消语义。迁移前应将协议兼容、错误类型等写成契约，由不同层级测试守住，这需要工程判断而非AI自动完成。
Q&A
GitHub用AI迁移Copilot运行时，为什么说瓶颈不在生成代码？
因为Agent在读文件、搜索和诊断上的活动约是编辑的十倍，大规模AI开发的瓶颈是理解移动中的系统并证明行为没有变，而不是把语法写出来。
GitHub迁移Copilot运行时采用了什么技术策略？
采用原地原子迁移，每个PR只迁移一个组件，用薄适配层从TypeScript调用Rust并删除旧实现，所有现有端到端测试立刻跑在新组件上，保持主干始终可发布。
Agent在迁移过程中主要做了哪些操作？
日志显示Agent调用PowerShell约63万次、查看文件约59万次、使用rg搜索约28万次，读取、搜索和诊断活动约是编辑工具的一个数量级，还进行了Git检查约30万次、pnpm test约1.38万次、cargo test约8437次。
迁移后性能提升了多少？
官方测试中，客户端、会话、单轮交互从5.25秒降到进程内Rust的292毫秒；恢复32轮会话从5.64秒降到264毫秒。但不同部署路径、硬件和测量条件会影响数字，不能当作Rust对Node.js的通用倍数。
迁移过程中出现了哪些回归问题？
截至9月14日，团队追踪并修复了数十个已知迁移回归，包括不完整迁移、状态与生命周期、行为契约不一致、宿主边界和错误测试神谕。有的实现深拷贝260MB事件日志，有的在持续事件流中保留异步句柄直到V8堆耗尽。
什么是测试神谕？为什么它重要？
测试神谕是判断输出对不对的规则。旧测试如果把历史Bug当成正确行为，新实现越忠实，问题越会被永久保留；旧测试只看返回值，也可能漏掉时序、内存与取消语义。迁移前应把协议兼容、错误类型、日志副作用、资源释放和并发顺序写成契约，再让不同层级测试分别守住。
这种AI迁移方式适合哪些系统？不适合哪些？
适合边界可以逐步隔离、已有端到端测试、能频繁发布的系统。不适合缺乏观测、数据迁移不可逆、协议含大量隐式兼容行为的核心系统。安全或财务代码还需要领域专家复核，不能仅依赖Agent互审。
如果想试点AI迁移，应该从哪些模块开始？
可先挑解析器、序列化、格式化或纯计算模块；冻结输入输出样例；让Agent先解释现有行为，再实现新版本；同时运行基准、属性测试和模糊测试；预发布后观察真实错误渠道。目标不是一周写十万行，而是一周完成一个可证明等价的切片。
