三周时间128个PR83万行代码——当这三个数字第一次出现在我时间线上的时候我的第一反应是“这又是营销号在制造焦虑吧”。但把这次 GitHub 让 AI 重写自己的实践拆开来看你会发现这其实是一场被流程和工具链牢牢托底的大规模代码重构而不是什么科幻电影。所谓“让 AI 重写自己”不是让模型不分青红皂白地把整个系统推倒重来而是把存量代码库里那些高重复、可枚举、低创新性的重构任务像是废弃 API 迁移、死代码清理、规范统一、测试补全交给 AI 去做批量处理。我一直在关注 AI 工程化方向看完公开资料后也动手在内部项目上复刻过一部分打法所以想把这次事件的拆解、工具选型和实操避坑写成一篇可以照着抄的文章。这篇东西适合三类人看准备把代码库现代化改造提上日程的技术负责人、想搞清 AI 到底能接管多少脏活的高级工程师、以及正在搭建 AI 辅助开发流程的 DevOps 团队。如果你觉得 AI 写代码不过是自动补全的升级版那这篇可能会改变你的看法。1. 这次“AI 重写自己”到底在做什么1.1 83 万行代码来自哪存量代码库的普遍欠账先说一个基本盘一个有一定历史的软件仓库经过多年迭代之后通常都会欠下几笔雷打不动的技术债。第一笔是框架和依赖的版本账。老项目里一定会堆着大量已经被上游标记为 deprecated 的 API 调用比如某个 HTTP 客户端从 v2 升到 v3方法签名变了、异常类型变了、超时配置方式也变了牵一发动全身。这种改动纯粹是“机械式翻译”但量极大靠人手一个个改改到怀疑人生。第二笔是重复实现和风格不统一。同一个十行代码的逻辑可能在十几个模块里以不同名字、不同缩进、不同错误处理方式各写了一遍。想统一又不敢动怕动坏了没人负责。第三笔是测试欠账。老模块往往只有核心路径的少量测试边界条件基本裸奔。重构最怕的不是改代码而是改完没有回归保障出了问题只能靠线上故障来发现。把这三笔账加起来一个中等规模的仓库攒出几十万行需要改造的代码太正常了。GitHub 这次给自己做的“AI 重写”本质上是把这三类“确定性较强、重复度较高”的存量问题交给 AI 在有限时间内批量清掉。83 万行不是一次重构的产物而是整个项目范围内可被机械改造的总工作量128 个 PR 则是把这么大工作量按可审查、可回滚的粒度切分出来的结果。1.2 哪些任务被交给 AI哪些被迫留下人工这件事很多人最容易踩的坑是“让 AI 全权处理一切”。真正的做法是在项目启动第一天就把任务清单拆成三档AI 的授权范围写在纸面上。第一档是 AI 全自动完成的任务。典型包括删除确认无引用的死代码、统一 import 顺序和格式化风格、把旧 API 调用按等价映射改写为新 API、为纯函数生成单元测试用例。这些任务的共同点是“规则明确、产出可验证、出错影响面小”AI 的错误率可以压得很低就算出错了CI 和测试也能先兜住。第二档是 AI 生成初稿、人工审核后合入的任务。典型包括跨模块的函数签名调整、模块内部的结构重排、部分业务逻辑的等价重构。这类任务需要一定上下文理解AI 能完成百分之八十的编码工作但最终取舍要人来看。第三档是禁止 AI 直接碰的任务。典型包括涉及安全校验的关键代码、对外协议和数据结构变更、性能热点路径、以及任何“改错了会造成资损或事故”的逻辑。不是 AI 不够聪明而是这些地方出错的成本太高不值得用机器去赌。一个合理的分配比例大致是第一档占 60% 左右的 PR第二档占 30%第三档占 10%。这样既能最大化 AI 的产能又不会让整条主线失去人的判断。1.3 三周排期怎么做到张弛有度三周时间听起来很赶但拆到三个阶段就很清晰。第一周是盘点周不做大规模改动只做代码扫描、任务分类、依赖关系梳理和白名单/黑名单确认第二周是批量改造周把第一档的机械性任务大量生成和合入让 AI 产能跑到峰值第三周是攻坚周集中处理跨模块的复杂重构同时把前两周引入的回归问题全部消化干净。这个顺序背后的逻辑是第一周用低风险动作换全局信息第二周用高频低风险动作冲量第三周用高风险动作收尾。如果没有第一周的依赖分析就直接上 AI 批量改大概率会出现改到一半发现 A 模块的改动被 B 模块的旧调用挡住又得回滚重新拆整体进度反而更慢。2. 工具链与流水线怎么让 AI 从“会写”到“能干活”2.1 选型原则不是只靠一个大模型很多人以为这次是“打开 Copilot让它自己生成 83 万行”。真这么干的话别说三周三年都未必稳。实际起作用的是一套组合拳至少包含四个角色。第一个角色是代码生成器负责按提示输出单个文件或单个函数的改造结果它解决的是“写”的问题。第二个角色是静态扫描器负责在改造前找出所有需要改的调用点并在改造后检查是否还有遗漏它解决的是“找”的问题。第三个角色是测试生成器负责为改动过的代码补测试把回归网织密它解决的是“证”的问题。第四个角色是 CI 流水线负责在每次 PR 合并前自动执行编译、单测、覆盖率检查和代码规范校验它解决的是“守”的问题。这四个角色缺一不可。只靠代码生成器AI 会写下第一个错误后一路错下去只靠静态扫描器扫描结果不会自动变成可合入的补丁只靠测试生成器没有代码改动时它什么也测不了只靠 CI问题都已经发生了它只是最后一根稻草。组合起来之后AI 才不是“一个会写代码的聊天机器人”而是一条有输入、有产出、有质检的改造流水线。2.2 Prompt 是这次工程的“设计文档”在真正的大规模重构里写给模型的提示词不是几段自然语言而是一份结构化的“改造工单”。这份工单写得越严谨AI 产出越稳定。我复刻这套打法时整理过一个可复用的 Prompt 模板核心结构是这样的任务类型API 迁移 目标任务将旧库 httpclient 3.x 的 getResponseBody() 调用 迁移为 httpclient 4.x 的 getEntity() EntityUtils.toByteArray() 模式 迁移范围 - 仅限 src/main/java/com/example/order/ 目录 - 不改动测试目录、resources 目录 映射规则 - getResponseBody().length - getEntity().getContentLength() - getResponseBody() 单独使用 - EntityUtils.toByteArray(getEntity()) 禁止改动 - 任何业务逻辑分支 - 异常关键字 catch 块结构 - 方法注释和日志文案 输出要求 - 输出完整 diff - 每个文件单独列出 - 不解释原因只输出代码这个模板里最关键的不是“映射规则”而是“禁止改动”和“范围限制”。模型对上下文的理解天然有限你给了它边界它就不会自作主张去格式化别人的注释、调整别人的缩进、顺手“优化”一下别人写了好几年的逻辑。我自己见过太多 AI 重构翻车案例几乎都是因为 Prompt 里只写了“把 A 换成 B”没写“除此之外什么都不准动”。另外Prompt 要按文件组拆分不要一次性把全仓库的内容塞进去。AI 的注意力是有限的硬塞一份 10 万行代码的上下文给它结果是该看的没看不该改的乱改。按目录拆开每个 Prompt 只管几十个文件准确率会显著提升。2.3 CI 护栏128 个 PR 不炸主分支的底线当一批一批 AI 生成的 PR 涌向仓库的时候唯一能拦住事故的就是 CI。这次实践给 CI 加了三道硬性门槛。第一道是编译和静态检查门槛PR 合并前必须通过全量编译、Lint、类型检查任何一条失败直接打回。第二道是测试门槛必须跑完单测和核心集成测试且覆盖率不得低于改动前水平防止 AI 把测试删了或者少写了分支。第三道是变更范围门禁每个 PR 的改动文件必须跟声明一致比如任务单说只改 order 目录PR 里如果冒出了支付模块的改动自动拦截并标记异常。这三道门槛加起来的效果是AI 出错可以被及时发现而且错误会被挡在合入之前。速度有上限但安全没有下限。宁可一天少合几个 PR也不能让一个带病 PR 混进主线。3. 128 个 PR 的拆法与合并节奏3.1 为什么是 128 而不是 8 个或 800 个这个数字不是随手定的它是任务粒度与人工审查能力之间的折中。拆成 8 个超级 PR每个 PR 改动十几万行看起来 PR 数量很少但 Review 的人根本没法逐行看出错以后定位问题像大海捞针一旦中间某一步要回滚几乎等于整个分支废掉。反过来拆成 800 个 PR每个 PR 只改一两个文件审查负担又太重三周内根本没有足够的 Reviewer 来消化。128 个 PR 意味着平均每个 PR 改动几千行左右换算下来大概是 20 到 50 个文件。这个量级刚好是“一个人能认真看完并且在一个小时内给完反馈”的上限。还有一个隐藏优势每个 PR 都有足够独立的任务边界单独 revert 不会波及其他任务出问题可以精准拆除而不是连带伤及旁边正在进行的改造。3.2 风险分级与 Review 过载控制三周 128 个 PR按 21 个工作日算平均每天要处理 6 到 7 个。如果每个 PR 都要求两个资深工程师坐下来逐行评审团队其他活就全停了。所以实际操作上必须做风险分级。我把 PR 分成三级。A 级是低风险机械改造比如 import 排序、死代码删除、格式化统一这类 PR 由自动化工具检查后直接合入不占人工评审B 级是中等风险的 API 迁移和测试补全安排一个 reviewer 过一遍关键 diff重点看有没有漏改、错改、越界改C 级是高风险重构安排两个人交叉 review并且必须在合入前本地跑一遍相关模块的验证。三周执行下来A 级大概占了一半B 级占三成C 级占两成。这个结构保证了资深工程师的精力主要花在最需要判断力的 C 级 PR 上而不是被机械性任务淹没。现实里很多团队恰恰相反资深的人天天在看格式化问题新手反而在重构核心逻辑风险和效率两头吃亏。3.3 合并顺序、冲突控制与回滚演练128 个 PR 如果全部并行推进合并冲突会在第三周集中爆发。这次的做法是提前画一张“依赖拓扑图”被依赖的底层工具模块最先改上层业务模块排到后面。底层模块的 PR 合并之后上层分支立即同步主干再做改动。这就像拆一栋楼先拆承重墙会出事但从顶层往下逐层拆每一步都有结构支撑。我复刻时学到的另一个细节是每个高风险 PR 合并前先在临时分支上模拟一次回滚。做法很简单记录该 PR 的完整反向 diff并预跑一遍“选中 PR 反向应用后主干是否还能编译、测试是否通过”。这听起来有点繁琐但在三周这种高压周期里它能保证一旦上线出问题最快两分钟就能把改动摘掉而不是花两小时去 studio 一个已经滚了好几轮的分支。4. 三周实操复盘每天到底在干嘛4.1 第一周盘点、打标、建白名单第一周看起来产出最少其实信息增量最大。团队做的第一件事不是让 AI 写代码而是让静态扫描器把所有需要改的位置跑出来生成一份“待改造清单”。我当时做了一份类似的清单字段大概是任务编号、涉及目录、改动类型、风险等级、依赖模块、当前状态。第一周结束时的目标是让这份清单覆盖率超过 90%并且让所有高风险项都经过人工确认。举个例子扫描器会标记出“这个函数看起来没有调用者”但如果是通过反射调用的静态扫描就会误报所以对这类条目要单独建黑名单提示 AI 不要动。这一周我踩过的最大坑是太信任扫描结果。有次我让 AI 删掉一堆“未被引用”的方法结果有个方法是通过 Spring 的配置文件按名称注入的编译期根本看不出来上线后接口直接 404。后来我学乖了凡是静态分析标记为死代码、但改动涉及公共方法或类名的方法一律先走一遍全局搜索和运行日志确认再决定是否删除。第一周白名单的意义就在这它不是限制 AI而是保护 AI 不要凭局部信息做出全局判断。4.2 第二周批量改造的高峰期第二周是 AI 产能最猛的一周也是最需要盯紧的一周。这一阶段的操作节奏是每天早上用脚本从任务清单里捞出一批 A 级任务逐个生成改造 PR然后丢给 CI 跑门禁。CI 过了合入CI 没过根据失败原因决定是修复提示词再生成还是直接弃用该 PR。在团队内部的实际数据里第二周生成的 PR 合入率大概在 70% 到 80% 之间剩下的要么是 AI 改错了边界条件要么是 CI 发现覆盖率下降被拦截。我一开始觉得 70% 有点低后来想明白了剩下的 20% 到 30% 并不是浪费它们证明了这套 CI 护栏是真正在工作。如果 AI 生成的 PR 百分之百通过反而说明门禁太松危险会在不知不觉中堆积到第三周。这一周还要注意节奏控制不要一股脑把几十个 PR 同时塞到 reviewer 门口。我当时的做法是每天上午合并一批下午集中清 review 队列凌晨让自动化跑全量测试保证隔天早上主干永远是干净的。4.3 第三周啃硬骨头的联合攻坚到了第三周简单的机械任务基本清零剩下的都是难啃的角色。比如跨模块函数签名调整、状态机逻辑重构、某些模块的边界条件补全。这些任务的共同点是需要理解业务语义AI 单打独斗容易把逻辑等价性改坏。我的策略是人机分工先让 AI 生成“当前逻辑的详细注释版”把函数内部的分支、循环、异常处理路径全部用注释标出来人阅读后确认逻辑理解无误然后由人给出目标结构的改造方案再让 AI 按方案逐段执行。这样 AI 执行的是细节人掌握的是方向两边的优势都用上了。第三周的 PR 数量会明显下降可能一天只有一两个但每一个都需要反复修改好几个版本。有一次我们改一个订单状态流转的核心方法AI 连续生成了五版都不对最后发现问题出在旧的并发锁语义没在 Prompt 里体现。把这条语义补进去之后第六版一次通过。这件事给我的启发是复杂任务的 Prompt 不是一次写好的而是随着排查深入不断迭代的把每一次失败的原因都吸收进去最后一次才会成功。5. 踩坑记录与问题排查经验5.1 我见过的典型翻车现场边做边踩坑的过程里我整理了一张问题速查表都是真实发生过、并且大概率会再次发生的坑。现象根因解决方式单测过了集成测试挂了AI 只关注单文件缺少跨文件上下文增加契约测试和调用链检查合入前跑集成测试AI 改完风格与团队规范不一致Prompt 里没写风格约束在 Prompt 中增加“遵循现有代码风格”合入前跑 formatterPR 数量激增reviewer 忙不过来任务粒度太细风险分级缺失按风险分级A 级自动化合入人工聚焦 C 级改了 A 文件依赖它的 B 文件编译失败合并顺序违反了依赖拓扑先生成依赖关系图底层模块优先合并死代码被误删反射或动态加载找不到符号静态分析产生误报高危公共方法加入黑名单删除前人工确认覆盖率不降反升但关键分支反而没测到测试生成器只顾增量代码忽略存量关键路径为关键路径单独写种子测试再让 AI 补齐分支这些坑很难完全避免但每条都有对应的预防动作。我做下来的体会是不要求 AI 不出错而是要让错误在最低成本的位置暴露。越早暴露修复成本越低。5.2 让我印象最深的一次排查第二周有个 PR 夜里合入后第二天早上全量测试突然挂了一片报错全指向同一个公共工具类。排查链路是这样的先看 CI 日志发现是某处空指针异常再查改动记录发现这个工具类的返回逻辑被 AI 从“返回空对象”改写成了“返回 null”再往前查 Prompt发现映射规则里根本没问题问题是 AI 在生成过程中自己“脑补”了一个等价优化。当时我们讨论了两个方案方案 A 是加一条更明确的 Prompt 约束禁止改动方法返回值语义方案 B 是加一条自动检测凡是涉及返回值类型可空性变化的改动一律进入人工复核。最后两个都做了因为单纯的 Prompt 约束对模型的约束力有限必须靠机器规则兜底。这类经验多了之后你会明白AI 重构里真正保证质量的是“机器规则 人工抽查 测试回归”三位一体的机制而不是对模型的盲目信任。5.3 几条值得写进团队手册的避坑经验第一个经验是给每个 PR 打标签标明是“机械改造”“半自动重构”还是“人工重构”。有了标签后续排查问题时能快速判断哪些 PR 的风险等级高优先从高风险 PR 查起。第二个经验是让 AI 先生成测试再生成实现。这个顺序乍看很怪但实际效果很好。先生成测试相当于先给定验收标准AI 生成实现时会不自觉地向测试约束靠拢生成结果的质量明显更高。如果反过来先生成实现再补测试AI 很容易写出一堆和实现同构的“应声虫测试”错误实现配错误测试CI 照样全绿。第三个经验是为 AI 改造设置冷却期。低风险 PR 合入后不要当天立刻上线让它在主干上“冷静”一晚跑一遍完整的夜间测试第二天再进入发布队列。三周时间的快节奏下这个“慢动作”反而避免了大量返工。6. 这套打法的边界与后续扩展6.1 同样打法还能用到哪些场景这次“AI 重写自己”的流水线换个外衣可以复用到很多场景。最直接的三大类依赖和框架升级、代码规范统一、测试体系补全。依赖升级对应的是把几百个调用点从旧库迁到新库代码规范统一对应的是把全仓库的异常处理风格、命名风格、日志风格拉齐测试体系补全对应的是给存量核心模块生成边界测试。更深一层这套“盘点—拆分—批量生成—门禁守护—风险分级审查”的流程本质上就是一套 AI 驱动的代码库治理方法论。同样的思路还可以用来做单体应用的模块边界梳理先让 AI 标注模块间调用关系再辅助拆出独立服务。我身边已经有团队在用类似的方式做微服务拆分的前期分析效率比纯人工静态分析高很多。6.2 想在自己的仓库复刻建议先做哪三件事如果你也想在自己的仓库里跑一轮这样的实践我强烈建议不要一上来就定“三周 83 万行”这种目标而是先把下面三件事做扎实。第一件事先找一条体量适中的目录试点建议包含至少两个模块、依赖关系清晰、并且有基本的测试覆盖。用一周时间跑完从扫描到合入的全流程把 Prompt 模板、CI 门禁和风险分级规则打磨顺。第二件事把失败 PR 的原因全部留档建一个“AI 改造失败模式”清单。这个清单会是你后续扩大规模时最值钱的资产比任何教程都有用。第三件事和团队对齐“AI 改造范围”的预期明确哪些目录三个月内不允许 AI 动哪些目录这个季度必须清完。先划清边界再谈效率否则很容易出现 AI 把不该动的地方也顺手优化了一遍然后整个团队都在给它的“顺手优化”买单。这三件事做完之后再考虑放大规模。放大时保持一个原则AI 产量增长的速度不能快过 CI 护栏和人工审查能力的增长速度。如果一天只能消化 5 个 PR那就不要让 AI 一天生成 20 个多出来的 15 个只会堆积成另一笔新的技术债。最后再分享一个小技巧。三周项目结束后别急着把流水线拆掉把它保留成常驻的“技术债务清理通道”。每两周固定跑一轮扫描把新产生的死代码、不规范调用、测试缺口丢进清单让 AI 在日常迭代中顺手清理。技术债这种东西攒着不还只会越来越贵有了这条通道至少不会继续滚雪球。我个人实际做下来的感受是AI 重写代码库这件事真正决定成败的不是模型跑得多快而是你有没有把任务拆成它能理解、能验证、能回滚的小单元。只要流水线搭对了三周 83 万行并不是极限后面完全可以根据团队消化能力继续加码。
