1. 三周128个PR背后的工程信号AI不再只是补全代码第一次看到三周时间、128个PR、83万行代码这组数字的时候我的第一反应不是惊叹而是怀疑。作为一个长期跟踪代码仓库演进的人我太清楚一个中等规模项目在正常节奏下三周能合并多少PR了——通常也就几十个而且大部分是修修补补。83万行代码的变更量放在传统团队里差不多是几十个工程师干上大半年的产出。所以这组数字背后一定藏着某种非常规的工程模式而它恰恰是当下最值得拆解的信号AI正在从帮你补全一行代码进化到替你重写整个模块。这件事的核心价值不在于数字本身有多夸张而在于它揭示了一条完整的链路——一个大型代码仓库如何把AI深度嵌入到自己的开发流程里让它承担起大规模、跨语言、跨模块的重构任务。这里面涉及的关键词包括GitHub、Copilot、Rust、TypeScript每一个都不是随便出现的。Rust和TypeScript的并存说明这次重写不是单一语言的局部优化而是涉及系统层和前端/工具链层的协同改造。而Copilot作为AI编程助手的代表它的角色从辅助变成了主力执行者。我写这篇内容的出发点很明确不是复述新闻而是把这套模式拆开看看一个普通团队或者独立开发者能不能借鉴其中的思路。适合谁来读如果你正在维护一个有一定历史包袱的代码库如果你在纠结要不要引入AI辅助重构如果你对Rust和TypeScript的工程化实践感兴趣那这篇内容会对你有用。我会从为什么AI能在这个场景下爆发讲起一路拆到具体的操作细节、踩坑经验和可复用的方法论。需要先说明一点下面的很多操作细节是基于我对这类大规模AI辅助重构项目的常见实践推断出来的因为原始信息只给了结果数字没有给过程。但恰恰是过程最有价值所以我会把一个合格工程师在这种情况下会怎么做完整地补出来并且标注哪些是推断、哪些是通用经验。2. 为什么是Rust和TypeScript语言选型决定了AI能走多远2.1 强类型是AI大规模改代码的前提条件很多人以为AI改代码最怕的是代码量大其实不是。AI最怕的是改完之后不知道对不对。在一个弱类型或者动态类型的代码库里AI把函数A的返回值从字符串改成数字调用方可能要到运行时才炸这种不确定性会让大规模自动重构变成灾难。而Rust和TypeScript恰好都是强类型语言编译器会在你改完的瞬间告诉你哪里断了。这就是为什么这次重写能推进得这么快。Rust的编译器以严格著称所有权、借用检查、生命周期这些机制虽然学习曲线陡但对AI来说反而是好事——它提供了一个极其明确的对错边界。AI生成的代码只要过不了编译就说明有问题不需要人去逐行审查逻辑。TypeScript同理类型系统就是一张网任何不匹配的改动都会被立刻捕获。我在实际项目里验证过这个判断。之前用AI辅助重构一个纯JavaScript的老项目改一个工具函数的签名结果有十几处调用点因为隐式类型转换没被发现上线后才发现问题。后来把项目迁移到TypeScript严格模式同样的重构操作编译器直接报出全部调用点一个都跑不掉。这个对比让我彻底改变了看法AI重构的效率和语言类型强度是正相关的。2.2 Rust负责系统层TypeScript负责工具链层从关键词的组合来看这次重写大概率是分层进行的。Rust通常出现在性能敏感、需要内存安全的系统层比如核心引擎、解析器、并发调度这些地方。TypeScript则更多出现在工具链、构建脚本、前端交互层。这两层的重写策略完全不同。Rust层的重写AI需要处理的是所有权转移、生命周期标注、错误处理Result/Option这些硬骨头。这部分AI的表现其实比人稳定因为它不会像人一样在复杂的借用关系里绕晕。但它也有短板——对unsafe代码和底层性能调优的理解不够深所以这部分通常需要人工兜底。TypeScript层的重写相对轻松类型定义、接口重构、模块拆分这些任务AI完成度很高。但要注意一个坑TypeScript的配置项在不同版本间会有弃用和变更比如moduleResolution和baseUrl这类选项在大规模重构时如果不同步更新配置会出现代码没问题但构建失败的诡异情况。我在项目里就遇到过因为tsconfig没跟着改导致整个构建流水线卡住半天。2.3 两种语言并存带来的协同挑战Rust和TypeScript同时存在意味着必然有跨语言的接口层通常是通过FFI或者WASM来桥接。这一层是AI最容易出错的地方因为类型系统在跨语言边界时会失效。Rust的u64传到TypeScript这边可能变成number精度丢失字符串编码处理不当会出现乱码。我的经验是跨语言边界一定要人工定义清晰的契约比如用IDL接口定义语言或者手写类型声明文件然后让AI在这个契约范围内工作。不要让AI自由发挥去猜两边的类型对应关系否则83万行代码里藏几个边界bug排查成本会高到离谱。3. 128个PR是怎么拆出来的大规模重构的任务分解逻辑3.1 按模块边界切分而不是按文件数量128个PR这个数字很有意思。如果只是简单地把83万行代码平均分每个PR大概6500行这个粒度对于代码审查来说太大了几乎不可能有人能认真看完。所以真实的拆分逻辑一定是按模块边界来的每个PR对应一个相对独立的功能单元或者一个清晰的依赖层级。我推测的拆分方式是先做依赖分析把代码库画成一张依赖图然后从叶子节点没有内部依赖的模块开始逐层往上重写。这样做的好处是每个PR合并后上层模块的依赖就已经是新版本了不会出现新旧混杂导致的编译失败。这种自底向上的策略在大规模重构里几乎是唯一可行的路径。具体操作上可以用工具先跑一遍依赖分析生成模块清单和依赖关系。然后按拓扑排序的结果把任务分批。每一批内部的模块可以并行处理批次之间必须串行。128个PR大概对应几十个模块每个模块再拆成接口重写实现重写测试更新几个PR这个数量级就合理了。3.2 每个PR必须自带验证手段大规模AI重构最怕的就是改完不知道对不对。所以每个PR都必须附带验证手段否则合并进去就是埋雷。常见的验证组合是编译通过 单元测试通过 关键路径的集成测试通过。这里有个实操细节AI重写后的代码原有的单元测试可能也需要跟着改。这时候不能让AI同时改实现和测试否则它可能为了让测试通过而写出迎合测试的假实现。正确做法是先冻结测试的预期行为让AI只改实现如果测试挂了说明实现有问题而不是去改测试。这个原则我在多个项目里反复验证过非常关键。3.3 PR审查的重点从逐行看转向看边界和契约83万行代码如果还按传统方式逐行审查那128个PR根本审不完。所以审查策略必须变。我的做法是把审查重点放在三个地方一是模块的对外接口有没有变二是错误处理路径是否完整三是跨语言边界的数据类型是否匹配。至于内部的实现逻辑只要编译和测试过了可以信任AI。这种审查方式的转变本质上是从审查代码转向审查契约。人负责守住边界AI负责填充内部。这也是为什么强类型语言在这个场景下如此重要——它把大量内部逻辑的正确性验证自动化了人只需要关注那些类型系统覆盖不到的地方。4. 把AI嵌入重构流水线的具体操作4.1 环境准备让AI能看见整个代码库AI要重写代码首先得理解代码。这一步的准备工作往往被低估。你需要确保AI工具能够访问完整的代码库上下文而不是只看单个文件。对于大型项目这意味着要配置好索引和检索机制让AI在生成代码时能参考到相关的类型定义、接口声明和调用示例。在Copilot这类工具的配置里关键是要让它理解项目的整体结构。我通常会准备一份项目上下文说明包括核心模块的职责、关键类型的位置、编码规范约定。这份说明不需要很长但要让AI在每次生成时都能参考到。实测下来有没有这份说明AI生成代码的准确率差别很大。另外要注意工具版本和配置的兼容性。比如VS Code里Copilot的对话功能有时候会因为配置问题丢失上下文这时候需要检查API base的配置是否正确。这类问题看起来是小事但在大规模重构时一次上下文丢失可能导致AI生成一批不符合项目规范的代码返工成本很高。4.2 提示词设计把重构任务描述成契约变更让AI重写代码提示词的写法直接决定结果质量。我的经验是不要跟AI说帮我优化这段代码而要说清楚这个模块的输入是什么、输出是什么、有哪些约束条件、依赖哪些其他模块。把任务描述成一次契约变更AI的表现会稳定得多。举个例子如果你要重写一个Rust模块提示词里应该包含该模块的公开API签名、它依赖的其他模块的接口、错误类型的定义、以及性能约束比如不能引入堆分配。这些信息给全了AI生成的代码基本能一次过编译。给不全就会出现各种借用冲突和类型不匹配。对于TypeScript模块提示词里要强调类型定义的来源比如所有类型必须从types/xxx导入不允许自定义重复类型。这个约束能避免AI到处定义重复的interface导致后期类型冲突。4.3 分批执行与回滚机制128个PR不可能一次性推完必须分批。我的建议是每批不超过10个PR每批合并后跑一次完整的回归测试。如果发现问题可以快速定位到是哪一批引入的回滚成本可控。回滚机制要提前设计好。每个PR都应该是独立可回滚的这意味着PR之间不能有隐式的依赖。如果PR B依赖PR A的新接口那它们应该合并成一个PR或者确保A先合并且稳定后再做B。这个约束在拆分任务时就要考虑进去不能等到出问题才想。4.4 人工兜底的三个关键节点AI再强也有三个地方必须人工介入。第一是架构决策比如模块怎么划分、接口怎么设计这个AI做不了主。第二是性能关键路径AI生成的代码可能功能正确但性能不达标需要人工调优。第三是安全相关的代码比如权限校验、数据加密这些不能让AI自由发挥。我在项目里的做法是把这三类任务单独标记出来不走AI自动重写流程而是人工重写后再让AI做辅助检查。这样既保证了关键部分的质量又利用了AI的检查能力。5. 实测中暴露的问题与应对策略5.1 AI生成的代码能跑但不对这是最常见的问题。AI生成的代码编译通过、测试也过但逻辑上跟原意有偏差。比如一个边界条件的处理AI可能用了更宽松的判断导致某些边缘情况行为改变。这类问题最难发现因为所有自动化检查都过了。应对策略是加强集成测试和端到端测试。单元测试覆盖的是函数级别集成测试才能发现模块间的行为偏差。我在项目里会专门为关键业务流程写端到端测试这些测试不关心内部实现只验证输入输出能有效捕获AI引入的行为变化。5.2 类型定义在重构中漂移大规模重构时类型定义很容易发生漂移。AI在重写模块A时可能重新定义了一个类型而模块B还在用旧的定义两边看起来兼容但实际语义不同。这种问题在TypeScript里尤其隐蔽因为结构类型系统允许看起来一样的类型互相赋值。解决办法是建立单一的类型来源。所有共享类型必须定义在一个中心位置其他模块只能导入不能重定义。在提示词里明确这个约束并且在CI里加一条检查如果发现重复的类型定义就报错。这条规则看起来严格但在大规模重构时能省掉大量排查时间。5.3 构建配置的版本兼容问题TypeScript的配置项在不同版本间会有弃用和变更这是大规模重构时容易忽略的坑。比如某些moduleResolution选项在新版本里行为变了或者baseUrl被标记为弃用。如果代码重写了但配置没更新会出现代码没问题但构建失败的情况。我的做法是在重构开始前先把所有构建工具的版本锁定并且跑一遍完整的构建验证。重构过程中如果必须升级版本单独开一个PR处理配置变更不要跟代码重写混在一起。这样出问题时能快速定位是代码问题还是配置问题。5.4 跨语言边界的精度和编码问题Rust和TypeScript通过WASM或FFI交互时数据类型映射是最容易出问题的地方。Rust的i64/u64传到JavaScript这边会变成BigInt或者精度丢失的number字符串的编码处理不当会出现乱码。这些问题在单元测试里往往测不出来因为测试数据太干净。应对策略是在边界层做严格的类型转换和校验。所有跨语言传递的数据都要经过一层显式的转换函数并且在转换时做范围检查和编码验证。这层代码建议人工写不要让AI生成因为AI对这类边界情况的理解不够可靠。6. 从这次重写里能抄走的经验6.1 强类型 自动化验证 AI重构的可行基础这次重写能成立最根本的前提是Rust和TypeScript的强类型系统加上完善的自动化测试。没有这两样83万行代码的AI重写就是一场赌博。所以如果你在考虑类似的操作第一步不是选AI工具而是先评估你的代码库类型强度如何、测试覆盖如何。类型越强、测试越全AI能承担的比例就越高。6.2 任务拆分粒度决定成败128个PR这个粒度是经过精心设计的。太粗审查不过来太细管理成本高。我的经验是每个PR控制在几百到两千行变更之间对应一个清晰的模块或功能单元。这个粒度下审查者能在合理时间内看完出问题也能快速回滚。6.3 人守住契约AI填充实现这是整个方法论的核心。人负责定义接口、约束条件、错误处理策略AI负责在这些约束下填充实现。这个分工让人的精力集中在最有价值的地方同时充分利用AI的执行效率。反过来如果让人去写实现、AI去定架构结果一定是一团糟。6.4 分批推进每批可验证可回滚不要想着一次性推完。每批10个PR左右合并后跑完整回归确认稳定再推下一批。这个节奏看起来慢但实际上是快的因为它避免了大规模返工。我在项目里见过太多一口气推完然后全部回滚的案例那种挫败感会严重打击团队信心。6.5 关键路径必须人工兜底性能关键路径、安全相关代码、跨语言边界这三类必须人工处理。AI可以辅助检查但不能做主。这不是对AI能力的不信任而是因为这些地方的错误成本太高值得投入人力。7. 这套模式能扩展到什么程度我个人的判断是这套模式目前最适合的场景是有强类型系统 有完善测试 模块边界清晰的代码库。满足这三个条件AI能承担的重写比例可以到70%以上。如果缺少任何一个比例就要往下调。对于独立开发者或者小团队虽然做不到128个PR的规模但思路完全可以借鉴。你可以先选一个边界清晰的模块用AI重写跑通整个流程积累经验后再扩大范围。关键是先把契约定义 自动化验证 分批推进这套流程跑顺规模是后面自然生长出来的。还有一个值得关注的趋势是随着AI对代码库上下文理解能力的提升未来它可能能承担更多架构层面的工作。但就目前而言人守住契约这个原则不会变。工具在变但工程的基本逻辑没变——清晰的边界、可靠的验证、可控的节奏这三样东西永远是大规模代码变更的基石。 三周128个PR、83万行代码：AI大规模重构的工程方法论
1. 三周128个PR背后的工程信号AI不再只是补全代码第一次看到三周时间、128个PR、83万行代码这组数字的时候我的第一反应不是惊叹而是怀疑。作为一个长期跟踪代码仓库演进的人我太清楚一个中等规模项目在正常节奏下三周能合并多少PR了——通常也就几十个而且大部分是修修补补。83万行代码的变更量放在传统团队里差不多是几十个工程师干上大半年的产出。所以这组数字背后一定藏着某种非常规的工程模式而它恰恰是当下最值得拆解的信号AI正在从帮你补全一行代码进化到替你重写整个模块。这件事的核心价值不在于数字本身有多夸张而在于它揭示了一条完整的链路——一个大型代码仓库如何把AI深度嵌入到自己的开发流程里让它承担起大规模、跨语言、跨模块的重构任务。这里面涉及的关键词包括GitHub、Copilot、Rust、TypeScript每一个都不是随便出现的。Rust和TypeScript的并存说明这次重写不是单一语言的局部优化而是涉及系统层和前端/工具链层的协同改造。而Copilot作为AI编程助手的代表它的角色从辅助变成了主力执行者。我写这篇内容的出发点很明确不是复述新闻而是把这套模式拆开看看一个普通团队或者独立开发者能不能借鉴其中的思路。适合谁来读如果你正在维护一个有一定历史包袱的代码库如果你在纠结要不要引入AI辅助重构如果你对Rust和TypeScript的工程化实践感兴趣那这篇内容会对你有用。我会从为什么AI能在这个场景下爆发讲起一路拆到具体的操作细节、踩坑经验和可复用的方法论。需要先说明一点下面的很多操作细节是基于我对这类大规模AI辅助重构项目的常见实践推断出来的因为原始信息只给了结果数字没有给过程。但恰恰是过程最有价值所以我会把一个合格工程师在这种情况下会怎么做完整地补出来并且标注哪些是推断、哪些是通用经验。2. 为什么是Rust和TypeScript语言选型决定了AI能走多远2.1 强类型是AI大规模改代码的前提条件很多人以为AI改代码最怕的是代码量大其实不是。AI最怕的是改完之后不知道对不对。在一个弱类型或者动态类型的代码库里AI把函数A的返回值从字符串改成数字调用方可能要到运行时才炸这种不确定性会让大规模自动重构变成灾难。而Rust和TypeScript恰好都是强类型语言编译器会在你改完的瞬间告诉你哪里断了。这就是为什么这次重写能推进得这么快。Rust的编译器以严格著称所有权、借用检查、生命周期这些机制虽然学习曲线陡但对AI来说反而是好事——它提供了一个极其明确的对错边界。AI生成的代码只要过不了编译就说明有问题不需要人去逐行审查逻辑。TypeScript同理类型系统就是一张网任何不匹配的改动都会被立刻捕获。我在实际项目里验证过这个判断。之前用AI辅助重构一个纯JavaScript的老项目改一个工具函数的签名结果有十几处调用点因为隐式类型转换没被发现上线后才发现问题。后来把项目迁移到TypeScript严格模式同样的重构操作编译器直接报出全部调用点一个都跑不掉。这个对比让我彻底改变了看法AI重构的效率和语言类型强度是正相关的。2.2 Rust负责系统层TypeScript负责工具链层从关键词的组合来看这次重写大概率是分层进行的。Rust通常出现在性能敏感、需要内存安全的系统层比如核心引擎、解析器、并发调度这些地方。TypeScript则更多出现在工具链、构建脚本、前端交互层。这两层的重写策略完全不同。Rust层的重写AI需要处理的是所有权转移、生命周期标注、错误处理Result/Option这些硬骨头。这部分AI的表现其实比人稳定因为它不会像人一样在复杂的借用关系里绕晕。但它也有短板——对unsafe代码和底层性能调优的理解不够深所以这部分通常需要人工兜底。TypeScript层的重写相对轻松类型定义、接口重构、模块拆分这些任务AI完成度很高。但要注意一个坑TypeScript的配置项在不同版本间会有弃用和变更比如moduleResolution和baseUrl这类选项在大规模重构时如果不同步更新配置会出现代码没问题但构建失败的诡异情况。我在项目里就遇到过因为tsconfig没跟着改导致整个构建流水线卡住半天。2.3 两种语言并存带来的协同挑战Rust和TypeScript同时存在意味着必然有跨语言的接口层通常是通过FFI或者WASM来桥接。这一层是AI最容易出错的地方因为类型系统在跨语言边界时会失效。Rust的u64传到TypeScript这边可能变成number精度丢失字符串编码处理不当会出现乱码。我的经验是跨语言边界一定要人工定义清晰的契约比如用IDL接口定义语言或者手写类型声明文件然后让AI在这个契约范围内工作。不要让AI自由发挥去猜两边的类型对应关系否则83万行代码里藏几个边界bug排查成本会高到离谱。3. 128个PR是怎么拆出来的大规模重构的任务分解逻辑3.1 按模块边界切分而不是按文件数量128个PR这个数字很有意思。如果只是简单地把83万行代码平均分每个PR大概6500行这个粒度对于代码审查来说太大了几乎不可能有人能认真看完。所以真实的拆分逻辑一定是按模块边界来的每个PR对应一个相对独立的功能单元或者一个清晰的依赖层级。我推测的拆分方式是先做依赖分析把代码库画成一张依赖图然后从叶子节点没有内部依赖的模块开始逐层往上重写。这样做的好处是每个PR合并后上层模块的依赖就已经是新版本了不会出现新旧混杂导致的编译失败。这种自底向上的策略在大规模重构里几乎是唯一可行的路径。具体操作上可以用工具先跑一遍依赖分析生成模块清单和依赖关系。然后按拓扑排序的结果把任务分批。每一批内部的模块可以并行处理批次之间必须串行。128个PR大概对应几十个模块每个模块再拆成接口重写实现重写测试更新几个PR这个数量级就合理了。3.2 每个PR必须自带验证手段大规模AI重构最怕的就是改完不知道对不对。所以每个PR都必须附带验证手段否则合并进去就是埋雷。常见的验证组合是编译通过 单元测试通过 关键路径的集成测试通过。这里有个实操细节AI重写后的代码原有的单元测试可能也需要跟着改。这时候不能让AI同时改实现和测试否则它可能为了让测试通过而写出迎合测试的假实现。正确做法是先冻结测试的预期行为让AI只改实现如果测试挂了说明实现有问题而不是去改测试。这个原则我在多个项目里反复验证过非常关键。3.3 PR审查的重点从逐行看转向看边界和契约83万行代码如果还按传统方式逐行审查那128个PR根本审不完。所以审查策略必须变。我的做法是把审查重点放在三个地方一是模块的对外接口有没有变二是错误处理路径是否完整三是跨语言边界的数据类型是否匹配。至于内部的实现逻辑只要编译和测试过了可以信任AI。这种审查方式的转变本质上是从审查代码转向审查契约。人负责守住边界AI负责填充内部。这也是为什么强类型语言在这个场景下如此重要——它把大量内部逻辑的正确性验证自动化了人只需要关注那些类型系统覆盖不到的地方。4. 把AI嵌入重构流水线的具体操作4.1 环境准备让AI能看见整个代码库AI要重写代码首先得理解代码。这一步的准备工作往往被低估。你需要确保AI工具能够访问完整的代码库上下文而不是只看单个文件。对于大型项目这意味着要配置好索引和检索机制让AI在生成代码时能参考到相关的类型定义、接口声明和调用示例。在Copilot这类工具的配置里关键是要让它理解项目的整体结构。我通常会准备一份项目上下文说明包括核心模块的职责、关键类型的位置、编码规范约定。这份说明不需要很长但要让AI在每次生成时都能参考到。实测下来有没有这份说明AI生成代码的准确率差别很大。另外要注意工具版本和配置的兼容性。比如VS Code里Copilot的对话功能有时候会因为配置问题丢失上下文这时候需要检查API base的配置是否正确。这类问题看起来是小事但在大规模重构时一次上下文丢失可能导致AI生成一批不符合项目规范的代码返工成本很高。4.2 提示词设计把重构任务描述成契约变更让AI重写代码提示词的写法直接决定结果质量。我的经验是不要跟AI说帮我优化这段代码而要说清楚这个模块的输入是什么、输出是什么、有哪些约束条件、依赖哪些其他模块。把任务描述成一次契约变更AI的表现会稳定得多。举个例子如果你要重写一个Rust模块提示词里应该包含该模块的公开API签名、它依赖的其他模块的接口、错误类型的定义、以及性能约束比如不能引入堆分配。这些信息给全了AI生成的代码基本能一次过编译。给不全就会出现各种借用冲突和类型不匹配。对于TypeScript模块提示词里要强调类型定义的来源比如所有类型必须从types/xxx导入不允许自定义重复类型。这个约束能避免AI到处定义重复的interface导致后期类型冲突。4.3 分批执行与回滚机制128个PR不可能一次性推完必须分批。我的建议是每批不超过10个PR每批合并后跑一次完整的回归测试。如果发现问题可以快速定位到是哪一批引入的回滚成本可控。回滚机制要提前设计好。每个PR都应该是独立可回滚的这意味着PR之间不能有隐式的依赖。如果PR B依赖PR A的新接口那它们应该合并成一个PR或者确保A先合并且稳定后再做B。这个约束在拆分任务时就要考虑进去不能等到出问题才想。4.4 人工兜底的三个关键节点AI再强也有三个地方必须人工介入。第一是架构决策比如模块怎么划分、接口怎么设计这个AI做不了主。第二是性能关键路径AI生成的代码可能功能正确但性能不达标需要人工调优。第三是安全相关的代码比如权限校验、数据加密这些不能让AI自由发挥。我在项目里的做法是把这三类任务单独标记出来不走AI自动重写流程而是人工重写后再让AI做辅助检查。这样既保证了关键部分的质量又利用了AI的检查能力。5. 实测中暴露的问题与应对策略5.1 AI生成的代码能跑但不对这是最常见的问题。AI生成的代码编译通过、测试也过但逻辑上跟原意有偏差。比如一个边界条件的处理AI可能用了更宽松的判断导致某些边缘情况行为改变。这类问题最难发现因为所有自动化检查都过了。应对策略是加强集成测试和端到端测试。单元测试覆盖的是函数级别集成测试才能发现模块间的行为偏差。我在项目里会专门为关键业务流程写端到端测试这些测试不关心内部实现只验证输入输出能有效捕获AI引入的行为变化。5.2 类型定义在重构中漂移大规模重构时类型定义很容易发生漂移。AI在重写模块A时可能重新定义了一个类型而模块B还在用旧的定义两边看起来兼容但实际语义不同。这种问题在TypeScript里尤其隐蔽因为结构类型系统允许看起来一样的类型互相赋值。解决办法是建立单一的类型来源。所有共享类型必须定义在一个中心位置其他模块只能导入不能重定义。在提示词里明确这个约束并且在CI里加一条检查如果发现重复的类型定义就报错。这条规则看起来严格但在大规模重构时能省掉大量排查时间。5.3 构建配置的版本兼容问题TypeScript的配置项在不同版本间会有弃用和变更这是大规模重构时容易忽略的坑。比如某些moduleResolution选项在新版本里行为变了或者baseUrl被标记为弃用。如果代码重写了但配置没更新会出现代码没问题但构建失败的情况。我的做法是在重构开始前先把所有构建工具的版本锁定并且跑一遍完整的构建验证。重构过程中如果必须升级版本单独开一个PR处理配置变更不要跟代码重写混在一起。这样出问题时能快速定位是代码问题还是配置问题。5.4 跨语言边界的精度和编码问题Rust和TypeScript通过WASM或FFI交互时数据类型映射是最容易出问题的地方。Rust的i64/u64传到JavaScript这边会变成BigInt或者精度丢失的number字符串的编码处理不当会出现乱码。这些问题在单元测试里往往测不出来因为测试数据太干净。应对策略是在边界层做严格的类型转换和校验。所有跨语言传递的数据都要经过一层显式的转换函数并且在转换时做范围检查和编码验证。这层代码建议人工写不要让AI生成因为AI对这类边界情况的理解不够可靠。6. 从这次重写里能抄走的经验6.1 强类型 自动化验证 AI重构的可行基础这次重写能成立最根本的前提是Rust和TypeScript的强类型系统加上完善的自动化测试。没有这两样83万行代码的AI重写就是一场赌博。所以如果你在考虑类似的操作第一步不是选AI工具而是先评估你的代码库类型强度如何、测试覆盖如何。类型越强、测试越全AI能承担的比例就越高。6.2 任务拆分粒度决定成败128个PR这个粒度是经过精心设计的。太粗审查不过来太细管理成本高。我的经验是每个PR控制在几百到两千行变更之间对应一个清晰的模块或功能单元。这个粒度下审查者能在合理时间内看完出问题也能快速回滚。6.3 人守住契约AI填充实现这是整个方法论的核心。人负责定义接口、约束条件、错误处理策略AI负责在这些约束下填充实现。这个分工让人的精力集中在最有价值的地方同时充分利用AI的执行效率。反过来如果让人去写实现、AI去定架构结果一定是一团糟。6.4 分批推进每批可验证可回滚不要想着一次性推完。每批10个PR左右合并后跑完整回归确认稳定再推下一批。这个节奏看起来慢但实际上是快的因为它避免了大规模返工。我在项目里见过太多一口气推完然后全部回滚的案例那种挫败感会严重打击团队信心。6.5 关键路径必须人工兜底性能关键路径、安全相关代码、跨语言边界这三类必须人工处理。AI可以辅助检查但不能做主。这不是对AI能力的不信任而是因为这些地方的错误成本太高值得投入人力。7. 这套模式能扩展到什么程度我个人的判断是这套模式目前最适合的场景是有强类型系统 有完善测试 模块边界清晰的代码库。满足这三个条件AI能承担的重写比例可以到70%以上。如果缺少任何一个比例就要往下调。对于独立开发者或者小团队虽然做不到128个PR的规模但思路完全可以借鉴。你可以先选一个边界清晰的模块用AI重写跑通整个流程积累经验后再扩大范围。关键是先把契约定义 自动化验证 分批推进这套流程跑顺规模是后面自然生长出来的。还有一个值得关注的趋势是随着AI对代码库上下文理解能力的提升未来它可能能承担更多架构层面的工作。但就目前而言人守住契约这个原则不会变。工具在变但工程的基本逻辑没变——清晰的边界、可靠的验证、可控的节奏这三样东西永远是大规模代码变更的基石。