AI辅助代码迁移实战：三周128个PR、83万行代码从TypeScript到Rust

1. 这件事到底是怎么发生的三周、128个PR、83万行代码第一次看到三周时间128个PR83万行代码这组数字的时候我的第一反应是这要么是一次大规模重构要么就是一次AI主导的代码迁移。后来仔细看下来确实是后者——GitHub 用 AI 辅助的方式把自家平台里相当一部分核心代码从一种技术栈迁移到了另一种技术栈而整个过程只用了三周。先把这组数字拆开看你就能感受到它的量级三周大约 15 个工作日如果按每天 8 小时算也就 120 个小时左右。128 个 PR平均每天要合并 8 到 9 个 Pull Request而且这些 PR 不是改改文案、修修样式而是涉及核心逻辑的迁移。83 万行代码这个体量如果靠人工一行行改一个熟练工程师一天能高质量迁移 500 到 1000 行就已经很不错了83 万行意味着至少需要 830 到 1660 个工作日也就是 3 到 6 年。所以这件事的核心不是AI 写了多少代码而是AI 把一件原本需要几年、几十人团队才能完成的事情压缩到了三周。这才是真正值得聊的地方。我自己也做过类似的代码迁移项目规模比这个小得多大概几万行的 TypeScript 迁移到 Rust 的部分模块当时用了将近两个月还踩了一堆坑。所以看到这个案例的时候我特别能理解里面那些看起来简单、做起来要命的细节。这篇文章我会从几个角度来拆为什么 GitHub 要做这次迁移背后的技术选型逻辑是什么AI 在其中到底扮演了什么角色是写代码还是审代码128 个 PR 是怎么拆的为什么这样拆实操过程中会遇到哪些坑怎么排查如果你也想在自己的项目里复现这套流程应该从哪一步开始。适合谁看如果你正在做技术栈迁移、正在尝试把 AI 引入研发流程、或者单纯好奇AI 重写大型项目到底靠不靠谱这篇应该都能给你一些可以直接抄作业的东西。2. 为什么是 Rust 和 TypeScript技术选型背后的真实考量2.1 从 TypeScript 到 Rust 的迁移动机GitHub 平台早期大量使用 Ruby on Rails后来逐步引入 TypeScript 做前端和部分服务端逻辑。TypeScript 的优势很明显开发速度快、生态成熟、类型系统够用。但它的短板也很明显运行时性能TypeScript 编译成 JavaScript 后在 Node.js 上跑遇到 CPU 密集型任务比如大规模文本处理、代码解析、diff 计算就会成为瓶颈。内存占用Node.js 的内存管理在大规模并发场景下不够精细GC 停顿会影响响应时间。并发模型JavaScript 的单线程事件循环在处理多核并行计算时需要靠 Worker Threads 绕来绕去写起来复杂调试也麻烦。Rust 恰好补上了这些短板零成本抽象、无 GC、所有权模型保证内存安全、原生支持多线程。对于 GitHub 这种需要处理海量代码仓库、diff、搜索索引的场景Rust 的吸引力非常大。但迁移不是重写一遍那么简单。GitHub 的代码库不是一个小项目里面有大量的业务逻辑、边界条件、历史遗留的兼容性处理。如果全靠人工迁移成本高到不现实。所以这次迁移的核心思路是用 AI 做批量翻译用人做关键审核。2.2 为什么不是全部重写而是逐步迁移这里有一个很重要的工程判断不要试图一次性重写整个系统。我见过太多团队一上来就说我们要用 Rust 重写整个后端结果做了半年新系统还没上线旧系统已经改得面目全非两边对不齐最后项目黄了。GitHub 的做法更务实按模块拆分逐个迁移每个模块迁移完立刻跑测试、对比行为、合并上线。这样即使某个模块出问题影响范围也可控。具体来说他们的迁移策略大概是这样的策略做法优点风险全量重写一次性用 Rust 重写所有逻辑架构干净周期长、风险高、容易烂尾逐步迁移按模块拆分逐个迁移风险可控、可回滚需要维护两套代码一段时间并行运行新旧逻辑同时跑对比结果验证充分资源消耗翻倍AI 辅助翻译AI 生成初版人工审核速度快需要严格的审核流程GitHub 选择的是逐步迁移 AI 辅助翻译 并行验证的组合。这也是我认为目前最靠谱的方案。2.3 AI 在迁移中的真实角色很多人看到AI 重写代码就会想象成AI 自己读代码、自己改、自己提交。实际上完全不是这样。在这次迁移里AI 的角色更像是一个高级代码翻译器 初稿生成器。具体流程是人工确定迁移范围和接口边界AI 根据 TypeScript 源码生成对应的 Rust 初版人工审核 AI 生成的代码重点看类型映射、错误处理、边界条件跑测试对比新旧行为修复差异合并 PR。AI 负责的是把 80% 的机械翻译工作做掉人负责的是剩下 20% 需要判断力的部分。但恰恰是这 20%决定了项目能不能成。提示不要指望 AI 一次性生成完全正确的迁移代码。它的价值在于把从零写变成改一改就能用这个效率提升是巨大的但审核环节绝对不能省。3. 128 个 PR 是怎么拆出来的迁移的工程化拆解3.1 PR 拆分的原则128 个 PR 听起来很多但如果按模块拆其实很合理。假设每个 PR 对应一个相对独立的模块或功能点128 个 PR 大概覆盖了 128 个迁移单元。拆 PR 的核心原则是每个 PR 必须可以独立审核、独立测试、独立回滚。具体来说一个好的迁移 PR 应该满足边界清晰只改一个模块或一个功能不跨模块可测试有对应的单元测试或集成测试可对比新旧逻辑的行为可以逐条对比可回滚出问题能单独 revert不影响其他 PR。我自己的经验是如果一个 PR 超过 500 行有效改动审核质量就会明显下降。所以 83 万行除以 128 个 PR平均每个 PR 大概 6500 行——这个数字看起来很大但考虑到其中很多是 AI 生成的机械翻译代码实际需要人工仔细看的部分可能只有几百行。3.2 迁移单元的选择不是所有代码都值得迁移。GitHub 在选迁移单元的时候大概率遵循了这几个标准性能瓶颈明显比如 diff 计算、语法解析、搜索索引构建逻辑相对独立不依赖太多外部状态接口清晰测试覆盖充分有现成的测试用例迁移后能快速验证业务风险可控即使出问题也不会导致核心功能不可用。反过来那些逻辑复杂、依赖多、测试少的模块大概率被排在了后面或者干脆不迁移。3.3 接口边界的处理迁移中最容易出问题的地方就是接口边界。TypeScript 和 Rust 的类型系统差异很大TypeScript 有any、undefined、nullRust 没有TypeScript 的对象是动态的Rust 的 struct 是静态的TypeScript 的异步是 PromiseRust 的异步是 Future async/awaitTypeScript 的错误是异常Rust 的错误是ResultT, E。所以迁移的时候必须先把接口边界定义清楚。常见的做法是用 Rust 定义一套与 TypeScript 对应的类型写一层 FFI外部函数接口或者用 WASM 做桥接在边界处做严格的类型转换和错误处理。这一步如果做不好后面会无穷无尽地修 bug。4. AI 辅助迁移的实操流程从 TypeScript 到 Rust4.1 环境准备与工具链如果你也想复现这套流程先把工具链搭好。以下是我实测下来比较稳的组合Rust 工具链rustupcargo建议用 stable 版本nightly 只在必要时用TypeScript 环境Node.js 20tsc或者swc做编译AI 辅助工具Copilot 或者类似的代码生成工具配置好 API base测试框架Rust 用cargo testTypeScript 用vitest或jest对比工具自己写脚本跑新旧逻辑对比输出。安装 Rust 的命令很简单curl --proto https --tlsv1.2 -sSf https://sh.rustup.rs | sh装完之后验证一下rustc --version cargo --versionTypeScript 这边如果你用的是较新的版本注意moduleResolution和baseUrl这些选项在新版本里有变化迁移前先把tsconfig.json理清楚。4.2 第一步用 AI 生成 Rust 初版假设你有一段 TypeScript 代码需要迁移比如一个简单的字符串处理函数function normalizePath(path: string): string { return path.replace(/\\/g, /).replace(/\//g, /); }你可以让 AI 生成对应的 Rust 版本pub fn normalize_path(path: str) - String { let mut result path.replace(\\, /); while result.contains(//) { result result.replace(//, /); } result }AI 生成的初版通常能用但有几个地方需要人工检查性能上面的 Rust 版本用了循环替换效率不高更好的写法是用正则或者一次遍历边界条件空字符串、只有斜杠的字符串、超长字符串行为是否一致错误处理TypeScript 版本不会抛异常Rust 版本也不应该 panic。我一般会让 AI 生成 2 到 3 个版本然后对比选最好的。实测下来AI 在机械翻译上准确率很高但在优化写法上经常给出平庸的方案。4.3 第二步人工审核的重点AI 生成的代码审核的时候重点看这几个地方审核项常见问题检查方法类型映射any被映射成serde_json::Value丢失类型信息检查所有any的来源错误处理TypeScript 的 try/catch 被忽略检查所有可能 panic 的地方异步逻辑Promise 链被错误地转成阻塞调用检查 async/await 的对应关系内存管理不必要的 clone或者生命周期错误用 clippy 检查边界条件空值、越界、溢出补充单元测试Rust 的clippy是一个非常好的工具能帮你发现很多潜在问题cargo clippy -- -D warnings4.4 第三步并行验证迁移完一个模块后不要急着删掉旧代码。正确的做法是让新旧逻辑并行跑一段时间对比输出。具体做法写一个测试 harness输入同一组数据分别调用 TypeScript 版本和 Rust 版本对比输出记录差异分析差异判断是 bug 还是预期行为变化。这一步非常关键。我在自己的项目里就遇到过Rust 版本在某个边界条件下返回了不同的结果查了半天发现是 TypeScript 的浮点数精度问题和 Rust 不一致。这种问题如果不做并行验证上线后就是线上事故。4.5 第四步合并与回滚预案每个 PR 合并前必须准备好回滚预案。常见的做法是用 feature flag 控制新旧逻辑的切换保留旧代码至少一个发布周期监控关键指标发现异常立刻切回。GitHub 的 128 个 PR 能三周内合并完说明他们的 CI/CD 流程非常成熟每个 PR 的测试和验证都是自动化的。这一点如果没有AI 生成再多代码也没用。5. 常见问题与排查技巧实录5.1 AI 生成的代码编译不过怎么办这是最常见的问题。AI 生成的 Rust 代码大概有 20% 到 30% 第一次编译会报错。常见原因和解决方法生命周期错误AI 经常忽略生命周期标注。解决方法是手动补上a或者改用 owned 类型借用检查失败AI 会写出同时可变借用和不可变借用的代码。解决方法是重构逻辑或者用RefCell临时绕过trait 未实现AI 假设某个类型实现了某个 trait实际没有。解决方法是手动实现或者换一个类型依赖缺失AI 用了某个 crate 但没加到Cargo.toml。解决方法是补上依赖。我的经验是不要试图一次修完所有错误。先让代码编译通过再跑测试再优化。分阶段处理效率更高。5.2 行为不一致怎么排查新旧逻辑行为不一致是最难查的问题。我的排查思路是缩小范围找到最小的输入能复现差异打印中间状态在关键步骤打印变量值对比两边二分查找注释掉一半逻辑看差异是否还在查文档确认两边对同一个操作的定义是否一致。常见的不一致来源字符串编码UTF-8 vs UTF-16浮点数精度正则表达式的方言差异排序算法的稳定性时间处理的时区问题。5.3 性能反而变慢了怎么办Rust 不一定比 TypeScript 快。如果迁移后性能变慢检查这几个地方不必要的 cloneRust 的所有权模型下clone 是显式开销锁竞争多线程下锁用多了性能反而下降内存分配频繁的String和Vec分配编译优化release 模式下有没有开--release。用perf或者flamegraph做性能分析找到真正的瓶颈。5.4 常见问题速查表问题可能原因解决方法编译报生命周期错误AI 忽略生命周期手动补标注或改 owned测试通过但线上出错边界条件未覆盖补充边界测试性能下降clone 过多或锁竞争用 perf 分析优化热点内存泄漏循环引用或未释放用 valgrind 或 heaptrack异步逻辑死锁Future 未正确 await检查 async 调用链注意AI 生成的代码永远不要直接合并到主分支。必须经过人工审核、测试、并行验证三个环节。6. 如果你想复现这套流程从哪开始6.1 小规模试点不要一上来就迁移整个项目。先选一个 500 到 1000 行的小模块走一遍完整流程用 AI 生成 Rust 初版人工审核并修复编译错误写测试对比新旧行为合并观察一段时间。这个过程大概需要 1 到 2 周。走通之后再逐步扩大范围。6.2 建立审核规范AI 生成的代码审核必须有规范。我自己的规范是所有unsafe代码必须人工逐行审核所有涉及内存分配的地方必须检查所有错误处理必须明确所有公共接口必须有文档注释。6.3 自动化测试是基础没有测试AI 迁移就是灾难。迁移前先确保单元测试覆盖率 80% 以上有集成测试覆盖核心流程有性能基准测试。6.4 团队协作的注意事项每个 PR 指定一个审核人不要多人同时审审核人必须懂 Rust不能只看逻辑不看实现建立共享的迁移踩坑文档记录常见问题和解决方法定期同步进度避免多个 PR 冲突。我在实际项目里踩过最大的坑就是低估了接口边界的复杂度。TypeScript 的动态类型和 Rust 的静态类型之间有一层看不见的鸿沟。AI 能帮你填平大部分但剩下的那部分必须靠人对业务的理解来补。三周 128 个 PR 听起来很猛但背后是成熟的工程体系在支撑。如果你也想试先把测试和 CI 搭好再让 AI 上场。