三周时间128个PR83万行代码GitHub用AI把自己核心代码库重写了一遍。这组数据我第一次看到时第一反应是标题党。但认真拆完他们公开的工程细节后我得承认这确实是一场实打实的规模级AI重构实验而且最有价值的不是“AI能写多少代码”而是“AI被如何组织进PR、审查、测试、合入这一整条流水线”。说白了这不是让AI放开手脚在仓库里乱写而是把AI塞进每一个工程节点用纪律和流程管住AI的输出。作为长期做代码重构和工程治理的开发者我接下来从目标拆解、方法设计、实操流水线到坑位排查把这套玩法从头到尾盘一遍。无论你是技术管理者、架构师还是想知道“AI重构到底怎么落地”的普通开发者这篇都值得看完。1. 这场“AI重写”不是让机器人自由发挥1.1 拆一拆“83万行代码重写”的真实目标很多人看到“重写”两个字会以为是把整个仓库删了重来。实际上成熟团队做这种事情一般不会选择“推翻重写”而是对多年积累的巨型代码库做渐进式现代化改造。GitHub这次做的本质上就是一次大规模技术债清理把老旧的内部实现、重复的模式、维护成本偏高的抽象用AI批量替换成更清晰、更现代、更容易维护的代码。类比装修老房子不是推倒整栋楼而是逐间房间做局部改造。每改完一间房子还能正常住人水管、电路都不会断。这样做的风险低、可回滚也能持续交付价值。用AI做这件事的动机也很直白纯靠人手改83万行代码三周根本不可能完成。但AI可以快速生成符合模式的代码前提是给它足够的上下文和清晰的约束。所以核心问题变成了怎么让AI理解这个老仓库怎么保证它生成的代码不会破坏现有行为怎么在128个PR里把风险拆散、把验证做扎实1.2 128个PR背后的拆分哲学先做个简单计算83万行代码除以128个PR平均每个PR约6484行改动。单看这个数字确实不算小。但关键在于这128个PR不是拍脑袋切出来的而是严格按模块边界拆的。我参与过不少大型重构最忌讳的就是出一个“超级PR”改动几万行Reviewer根本看不完CI挂了也不知道是哪段代码引起的出了问题只能全员回滚。而按模块拆分后每个PR都只动一个相对独立的单元具备三个特性可编译、可测试、可回滚。可编译PR合入前构建必须通过依赖不会外溢。可测试模块级测试全绿行为变更能被及时捕获。可回滚一旦线上出问题单独revert这个PR不会牵连其他模块。这其实是一种“绞杀者模式”的实践用新代码逐步绞杀旧代码而不是一次性替换全部。AI擅长的是在限定范围内快速产出人擅长的是把范围切得足够合理。128个PR就是一个把大规模工作切碎再逐步合入的过程。1.3 三周实际节奏是怎么排出来的三周按15个有效工作日算大致可以切成三个阶段第一个阶段前3天是“试点和定调”。选一个有代表性的中等模块把“AI生成代码→构建→测试→人工审查→合入”的闭环完整跑通。同时把提示词模板、审查清单、合入门禁标准固定下来。这一步非常关键后面所有PR都是在这个流水线上复制粘贴式推进。第二个阶段中间10天左右是“批量铺开”。模块之间并行推进每天合并8到12个PRCI里自动跑构建、单测、静态扫描。AI生成的代码如果编译失败或测试挂掉直接把错误信息喂回去让它自修复通常两三轮就能解决。第三个阶段最后2到3天是“收尾和回归”。处理试点阶段没覆盖的边缘场景、性能回退、跨模块耦合问题最后跑全量测试和综合审查把剩余PR合并完。这个节奏能跑起来前提是前期准备足够扎实。如果仓库没有自动化测试、没有快速构建、没有清晰的模块边界三周只会变成三周灾难。2. 让AI重写代码的核心方法2.1 先给AI“讲清楚代码库”而不是丢一个文件AI模型能记住的上下文始终有限你直接把整个仓库丢给它只会得到一堆“看起来合理、实际不能用”的代码。正确的做法是先为每个待重写模块构建一个“知识包”。知识包至少包含四类内容模块职责说明这个模块是干什么的对外提供什么能力。接口契约哪些公共方法、类、API签名绝对不能变或者允许变到什么程度。依赖关系模块依赖了哪些内部组件和外部库哪些可以碰哪些不能碰。测试用例现有测试是需求的可执行文档告诉AI“什么行为必须保留”。实操中我习惯让AI先读测试文件。原因很简单测试把模块的行为预期写得很具体比读一堆文档高效得多。AI读懂测试就知道重构后哪些行为是硬约束哪些是自由发挥空间。如果仓库特别大还可以借助代码图谱工具提取调用链和数据流把模块间的依赖关系汇总成一张清单再塞给AI。这一步省不掉跳过它后面所有PR审查都会变成“帮AI擦屁股”。2.2 把需求翻译成AI听得懂的“任务规格”很多AI生成代码效果差不是AI不行而是任务描述太模糊。“帮我优化这个模块”这种话AI只能猜你的意图。GitHub这类工程级AI重构对任务描述的要求非常苛刻。我在实操中总结了一套提示词结构基本每次都能用任务重构 src/services/payment/ 目录下的支付网关实现。 目标将 PaymentGateway 从抽象类模式改为接口加策略组合。 约束 - 不修改对外 API 签名保持调用方不受影响。 - 保留现有测试语义不允许删除或弱化断言。 - 同一方法内重复超过30行的逻辑必须抽取。 - 不得新增外部依赖。 验收标准 - dotnet build 无错误。 - dotnet test 全绿。 - CodeQL 扫描无新增高危告警。 - 提供一份改动摘要说明每个文件变更的原因。这套模板的核心逻辑是把“目标、约束、验收”分开写清楚。目标告诉AI往哪走约束告诉AI哪里不能碰验收标准让AI能自我检查。一个好的重构任务AI生成后你基本只需要看diff而不是重新教它业务逻辑。2.3 AI Review和人工Review的分工别搞反了代码是AI写的审查如果还是纯人工那等于把所有压力又堆回人身上。GitHub这次的做法很有参考价值AI负责AI能审的部分人只审AI审不了的部分。我一般这样分工审查维度负责人具体内容编译与测试CI自动构建、单测、集成测试、类型检查安全漏洞CodeQL等静态扫描工具SQL注入、XSS、敏感信息硬编码等代码规范格式化工具AI Review风格一致性、重复代码、过长函数架构合理性人工Review模块边界是否清晰、抽象是否过度业务语义人工Review行为变更是否影响真实用户场景合并风险人工Review是否会影响灰度发布、回滚策略这里必须强调一句AI生成的代码尤其需要人工认真审。因为它“犯错很自信”逻辑看起来完整边界条件却可能漏掉风格很统一业务语义却可能完全偏离。人工审查不是走流程而是负责给AI的错误兜底。3. 从头复刻一套“AI重写代码”的工程闭环3.1 没有测试基线别碰AI重构我见过不少团队连单元测试都没有就急着让AI重写代码最后只能靠“线上出bug再修”来验收。这种玩法不只是危险基本等于自杀式重构。在启动AI重构之前至少要完成三件事跑通全量构建和自动化测试确认现有代码是“绿色状态”。用静态分析工具做一次基线扫描记录当前告警数量后续PR新增的问题能自动对比。为关键路径建立性能基线至少记录接口耗时、内存占用、构建时间这些核心指标。有了这三条基线AI生成的每个PR才有“裁判”。否则你根本说不清一个PR是变好了还是变坏了只能靠感觉拍板。工程化的第一步永远是先建立度量而不是先让AI动手。3.2 从模块到合入的8步流水线我落地这套流程时会把它固化成一个八步流水线步骤越标准AI产出越稳定。圈定模块优先选依赖少、边界清晰的模块。生成模块说明书让AI先读代码库输出“职责接口依赖风险点”。制定重构方案人审模块说明书确认改动方向必要时调整AI的思路。生成目标代码用2.2里的任务模板把重写需求一次性描述清楚。本地自检先跑构建、格式化、模块测试能过滤掉八成低级问题。开PR由AI生成PR描述包含变更摘要、影响范围、测试结果。双轨审查AI负责机械审查人负责架构和业务语义审查。合入后监控合入当天观察CI和线上指标确认没有隐藏回归。这套流程每个环节都不复杂难的是坚持执行。AI重构最怕的就是“图快”跳过第5步、简化第7步短期省时间长期攒技术债。3.3 CI/CD和merge queue如何护航83万行代码大规模AI重构时最头疼的不是AI写不出代码而是并行PR太多、main分支被频繁“撞车”。两个方案能稳妥解决这个问题。第一个是路径过滤。GitHub Actions里可以配置paths字段让某个job只在特定目录发生变化时触发。AI重构通常只会改动仓库的一部分其他模块根本不需要重跑全量构建。配置了路径过滤CI跑一轮的时间能从半小时降到几分钟。第二个是merge queue。很多大仓库会开启合并队列让PR按顺序排队合入而不是所有人同时往main上挤。每次合并后会自动触发一次针对最新main的CI验证有问题就拦下来不会把坏代码偷偷混进主干。这套组合拳打在83万行的规模上效果尤其明显。没有merge queue128个PR并行合入光是处理冲突就能毁掉整个工期。4. 常见问题与排查技巧实录4.1 AI改完代码编译错误一大堆怎么办AI重写后编译挂掉通常不是一个一个手动改而是做“自修复循环”。把编译错误日志连同出错文件路径原样喂回给AI让它生成修复补丁。我的标准做法是以下是重构后代码的编译错误请逐条修复。 要求 - 只在出错的函数和类型范围内修改。 - 不要调整已经通过编译的代码。 - 修复后给出完整diff。 错误信息 [粘贴这里]实操下来大部分编译错误两三轮就能清干净。如果三轮之后还有残留说明AI对模块结构的理解出了偏差不要再让AI硬修直接人工介入或者换一个提示思路重新生成这部分代码。及时止损很重要AI自修复不是无限循环。4.2 AI生成“看起来优雅、实际错误”的代码怎么发现这是AI重构里最隐蔽的坑。编译没问题、测试也过了但代码语义就是不对。我在实际重构中遇到过几类高频错误值得重点盯防边界条件遗漏循环边界、空值判断、集合越界AI很容易漏。异步时序错误把同步代码改异步后锁、顺序、取消令牌没处理好。隐式契约破坏某个字段在文档里没写但被调用方隐式依赖。过度设计为了“优雅”引入一堆抽象本来10行能解决的问题拆成5个类。应对方法很朴素AI的代码必须“测试伴随”。重构PR哪怕只改了一个函数也要要求AI补上至少一个能覆盖边界条件的测试用例。有人说“AI写的测试没意义”但测试的价值不是证明对而是在行为偏离时快速报警。这比没有强太多。4.3 合并后性能回退怎么定位和修复AI重构最容易被忽略的是性能回归。逻辑变得清晰了但某个热点函数的缓存失效、锁竞争变高、或者多了不必要的对象拷贝都会造成线上性能波动。我的做法是先在CI里挂基准测试对模块内耗时最长的前20个函数做性能对比。合并PR后如果基准测试发现某条路径变慢把profiler抓下来的调用栈提交给AI让它对照优化。示例这是重构前后的Profile数据。 函数 A 从 5ms 涨到了 40ms疑似缓存策略退化。 请分析回归原因并给出修复方案。 要求保持现有功能不变减少锁竞争恢复原有性能基线。 Profile数据[粘贴火焰图或时序数据]多数情况下AI能很快发现问题出在哪一行。真正难的是建立一个“性能也进CI”的意识和基线没有基线回归只能等线上用户投诉。4.4 多大的团队能接住这么大的盘很多人会问三周128个PR这得几百人的团队吧实际上我推算下来一个能扛住这个体量的核心团队大概10到15人足够了。重点是分工2到3人负责模块拆分和方案设计5到6人负责人工Review和合入把关剩下的交给AI生成和CI自动验证。一个人每天认真审查3到4个PR10个人一天就能消化30到40个PR三周消化128个PR在数学上是完全可行的。真正卡住进度的从来不是AI生成速度而是人工审查带宽。所以如果你想复刻这次实践第一件要想清楚的不是“用什么AI工具”而是“谁来看这些PR、审查标准是什么”。5. 这次实践沉淀下来的是一张可以直接抄的工具清单如果只记结论我会把这次AI重写项目的工具组合列成下面这张表每一类都可以直接落到自己的项目里。场景我常用的方案核心作用代码生成GitHub Copilot、ChatGPT类模型按任务模板生成重构代码静态分析CodeQL、SonarQube安全漏洞、坏味道、重复代码CI验证GitHub Actions、Jenkins构建、单测、路径过滤合入保护merge queue、受保护分支防止并行PR搞乱mainAI审查Copilot code review、自建GPT ReviewerPR描述检查、机械规则检查开发环境Codespaces、Dev Container统一环境避免“在我电脑上是好的”工具不在多而在于每一样都要有明确归属。我在实际使用中发现最值钱的反而是一份写好的审查清单。清单里固定要检查哪些安全项、性能项、业务项AI和人都按同一把尺子执行。没有尺子的团队换再多的工具都是白搭。最后再多说一句我自己的体会。真正让我觉得这套玩法值得复制的点不是“AI替代了程序员”而是“AI倒逼团队把工程纪律重新立了起来”。以前靠自觉的事情现在变成了必须写清楚目标、限定好边界、跑完测试再合入。你不需要一上来就挑战83万行的规模挑一个20到30个文件的模块用一周时间跑通10个PR先把这条流水线跑顺。跑顺之后你会发现AI重构真正的对手不是代码质量而是你自己愿不愿意把流程拆细、把标准定死。