AI自主提交128个PR重构83万行代码的工程方法论

前几天看到 GitHub 那波"AI 自己给自己提交了128个PR、改了83万行代码"的消息时，我第一反应是：又来了个噱头。但把三周时间线、PR列表和自动化验证的细节翻了一遍之后，我发现真正值得聊的其实不是"AI 重写自己"这个标题，而是它背后那一整套工程方法论。AI 生成代码这件事大家都见过，可"AI 自主发现代码库问题、自己拆任务、自己提交PR、自己跑验证、自己根据失败反馈修正"这套闭环，才是真正把 AI 从"补代码的工具"推到了"维护大型仓库的协作者"的位置上。这篇文章我想拆的就是这件事，适合正在做 AI 落地方案、或者被"AI 写代码越来越多但不敢让它碰核心仓库"困扰的人看，我会从事件拆解讲到复刻路径，尽量给你能直接用的东西。

1. 这波重写项目，到底干了件什么事

1.1 一次"AI 给自己当包工头"的大规模代码重构

先把这个事件的内容还原清楚。GitHub 做了一件听起来很循环的事情：让 AI 智能体去改动 GitHub 自己的工程仓库。这个仓库不是某个玩具 Demo，而是支撑 GitHub 日常开发和技术栈演进的核心代码库之一。AI 在约三周内提交了 128 个 PR，累计改动 83 万行代码，把一批历史遗留问题清理掉了，比如过时 API 替换、重复代码整理、不合规的调用方式收敛，以及一些已经被替代但仍然残留在代码里的旧逻辑。

这个事件最值得注意的点不是"AI 写了多少行"，而是"AI 以完全符合开源协作规范的方式完成了代码治理"。它没有直接把一大坨代码塞进主分支，而是拆成 128 个彼此独立的 PR 提交。每个 PR 都有明确的改动意图和可验证的边界，该跑测试跑测试，该走 review 走 review，完全不像我们想象中"AI 一次性生成大量代码然后人不知道该怎么检查"的样子。

我在看到这些信息时想的第一个问题是：这和我们平时用 Copilot 补全一个函数、让 ChatGPT 写一段工具脚本，到底有什么区别？区别在于角色反转。以前 AI 是"回答问题的助手"，你说一个需求，它给你一段代码；而这次 AI 是"仓库的治理者"，它自己要判断哪些代码该改、怎么改、改成什么样才算完成，并且要为一个长期维护的大型代码库负责。这个模式一旦跑通，意味着过去那种"人类定义需求、AI做具体实现"的单向协作关系，变成了"人类设定治理目标和安全边界、AI自动执行和验证、人类做最终决策"的双向协作关系。

1.2 128个PR和83万行代码，这几个数字意味着什么

接下来我从工程直觉出发，聊聊这几个数字的分量。

三周时间是 21 天。128 个 PR 均摊下来，每天大约要完成 6 个 PR。如果每个 PR 是一个独立的重构单元，那么一天就要完成"发现问题、想出方案、改完代码、通过本机验证、提交 PR、等待 CI 反馈"这一整套流程六次。对人力团队来说，这是一个很难维持的节奏，因为人脑在多个上下文之间切换是有成本的，你上午还在改 A 模块的 API 替换，下午突然切到 B 模块的依赖整理，光找回状态就要半小时。AI 没有这个上下文切换成本，每个 PR 都可以是全新的起点。

83 万行代码更是很夸张的量级。很多中小型项目的代码总量也就是几十万行，而这里只是"被改动"的量就已经这么大了。能支撑这么大改动的底层逻辑是：AI 的每个 PR 改动都足够小且聚焦。比如一个 PR 可能只改 300 行，关键是它能够连续稳定地制造这么多小而精准的 PR，而不是制造一个 80 万行的超级 PR。这也反过来证明，AI 在执行层面的稳定性已经达到了一个挺高的水平。

我用一张表来呈现这个量级到底意味着什么：

当然，数字大不代表质量一定好。如果背后没有一套严格的自动化验证和人工复核机制，83 万行改动可能不是财富而是灾难。这也是我后面几章花重笔墨写验证链路的原因：没有那套机制，128 个 PR 就是 128 个定时炸弹。

2. 为什么这个案例值得单独拆一遍

2.1 从"AI 写代码"到"AI 维护大型仓库"的分水岭

我一直觉得，AI 编程这件事有几个完全不同的难度层级。第一层是补全，比如 IDE 里一个函数写了一半，AI 帮你补完；第二层是生成，你给出比较明确的需求描述，AI 给你一段可以运行的代码；第三层是改造，在一个既有的大仓库里，你已经知道哪里需要改，让 AI 做局部修改并保证不破坏其他功能。而这次 GitHub 的事件，实际上已经把脚踩到了第四层的门槛上：让 AI 自主发现哪里需要改，自主决定怎么改，自主验证，最后交付给人类做裁决。

第四层和前几层最本质的区别不在模型能力，而在工程架构。你让 AI 补一个函数，它只需要理解你写的上文；但让 AI 维护一个大型仓库，它必须理解仓库的整体结构、构建方式、测试约定、代码风格、甚至仓库里那些"约定俗成但没写进文档"的黑话。这些信息没法靠模型参数全部记住，必须通过工具去实时检索和验证。也就是说，第四层的核心是给 AI 搭了一套"手和眼睛"：它能看到代码库的全貌，能执行命令，能跑测试，能通过 CI 拿到反馈，然后基于反馈调整自己的行动。

这个分水岭还有个副作用：它改变了 code review 的形态。以前 review 一个 PR，人类 reviewer 会从 diff 角度去检查"你改得对不对"。但当改动量上升到 83 万行，逐行 diff review 就不再可能。reviewer 必须把自己的工作重心转移到"看意图、看边界、看验证"上：这个 PR 为什么要改这些地方？有没有改到不该碰的模块？CI 和自动化检查是不是覆盖了这次改动的关键风险？如果这三件事能管住，逐行看代码反而没那么重要了。

2.2 先厘清"重写"的范围：改动面、风险面、为什么没翻车

看到"83 万行代码"这种描述，有些人会脑补成"AI 把整个仓库推倒重来了"，这完全不是一回事。这次事件里的"重写"本质上是结构性的治理与重构，不是一个全新的项目从零生成。它更像我家里请了个很靠谱的整理师，把多年堆积的杂物分门别类打包，而不是直接把房子推了重建。

我梳理了一下这类重写通常会覆盖的改动类型：

• 替换已废弃或被取代的 API 调用，让代码基线与新版本依赖对齐。
• 删除不可达代码、死分支、被注释掉且早已无用的逻辑。
• 将重复逻辑统一收敛到公共函数或工具模块。
• 调整不符合仓库既有风格约定的写法，让新代码和老代码保持一致。

这四种改动的共同特征是：它们的行为对用户来说应当是透明的。你替换了一个 API，原来的功能不能变；你收敛了重复逻辑，输出的结果不能变；你删除了死代码，程序行为更不能变。正因为目标是"行为保持不变"，自动化验证才能发挥最大作用：你可以通过跑测试来证明"改前和改后行为一致"。真正的"推倒重写"反而很难用自动化验证兜底，因为行为预期本身就是新的，根本没有测试可以证明你写对了。

所以这次"重写"没有翻车，不是因为 AI 大模型突然厉害到不会出错了，而是因为工程上给 AI 选了一个非常适合发挥的赛道：行为保持型重构。这个赛道里，验证系统能接住 AI 的大部分错误，剩下的通过小步 PR 和人工复核接住。这是我在拆解这个案例时最想先讲清楚的一件事，很多人容易把"AI 自主改代码"神话化，却忽略了背后的任务选型和安全设计。

3. 让 AI 自主改代码的触发条件与初始架构

3.1 从单点任务到批量重构，能力边界是怎样一步步撑大的

要做到"AI 自己给自己提交 PR"，首先得给 AI 搭一个能干活的环境。单纯把代码库丢给模型去"阅读"是不够的，语言模型本质上是一个概率生成器，它不知道仓库实际编译是否通过，也不知道某个改动在另一个文件里会不会造成隐性破坏。所以工程上要给 AI 配上几类关键能力：

第一是检索与观察能力。AI 需要能够查看文件树、阅读文件内容、搜索某个符号在哪些地方被引用。这一步通常通过工具调用完成，比如由代码索引服务提供支持，或者直接封装一批命令供 AI 调用。没有这个能力，AI 就等于是盲人摸象，只能靠训练数据里那些泛泛的编程知识瞎猜。

第二是修改能力。AI 需要能实际改文件、新建文件、删除文件。这件事听起来简单，但工程上要处理很多细节：并发修改时怎么避免与其他 PR 冲突、文件权限怎么处理、格式化怎么统一。这里的关键不是"能不能写文件"，而是"怎么保证写文件的过程可控且可回顾"。

第三是验证能力。AI 要能运行构建、跑单元测试、执行静态分析。这块是整个闭环里最硬的一关，也是决定 AI 是否值得信任的基础。如果 AI 改完代码之后只能靠"自我感觉良好"来确认正确性，那它和碰运气没什么区别。只有当测试通过、静态检查干净、构建成功，AI 才真正拿到了"我的改动是对的"的证据。

第四是交付能力。AI 要能基于改动内容创建一个标准的 PR，包括规范的 commit message、PR 描述、相关标签和评论。这个能力决定了一个 AI 生成的改动是否能无缝融入人类已有的开发流程。如果还要人来帮它创建 PR，那效率就折半了。

这四个能力合在一起，才是这次事件里 AI 能连续稳定产出 128 个 PR 的基础设施。实际上，GitHub 自己也做过很多类似的前置工作，比如在编码助手里逐步引入多文件编辑、终端命令执行、代码库问答等能力，它们本质上都是在给 AI 补齐这四块拼图，只是一步步从"单点辅助"走到了"批量自主"。

3.2 工程框架要点：拆任务、定边界、设护栏

站在一个想落地同类方案的人的角度，我会把这个案例抽象成三个工程关键词：拆任务、定边界、设护栏。

先说拆任务。AI 没有全局规划能力之前，千万不要让它一次性处理一大片代码。拆任务的核心思路是把一个大的治理目标拆成多个互相独立、改动面可控的小任务。假设目标是"把仓库里所有旧日志框架的调用换成新框架"，如果直接让 AI 一次性全改，任何一个小失误都会波及整个仓库；但拆成按模块、按目录、按依赖关系分批进行的多个 PR 后，任何一个 PR 出问题，都可以被单独回滚，不影响其他进度。128 个 PR 不是单纯的数量展示，它本身就是一种风险管理策略。

再看定边界。这个边界既包含文件系统边界，也包含行为边界。文件系统边界是限制 AI 只能动某个目录或某类后缀的文件，避免它跑题去改掉一些不应该碰的配置文件；行为边界则是告诉 AI "你只能做行为保持型重构，不能顺手加新功能，也不能改变已有函数的入参和返回语义"。给边界这件事听起来像限制，实际上是在帮 AI 提高成功率，因为它把搜索空间缩小了，AI 犯错的可能性自然就下来了。

最后是设护栏。护栏指的是那些不管 AI 如何操作都一定会生效的硬性检查。它可能是一条分支保护规则，要求必须通过所有 CI 检查才能合并；也可能是一套自动生成的变更摘要，让维护者一眼看出这个 PR 动了哪些文件；还可能是一些代码量级的阈值告警，比如一个 PR 改动超过 1000 行就自动要求人工介入。护栏的意义在于：即便 AI 在某个环节产生幻觉，护栏也能拦住最坏的结果，让人有机会喊停。

这套"拆任务、定边界、设护栏"的组合，让我想到一个挺贴切的类比：你把一个实习生安排到团队里，最怕的不是他能力不够，而是他不知道哪些事可以做、哪些事不能做、做错了要怎么发现。你给他一份细化到每小时的活儿，再划清楚工作范围，再配上代码审核人，他就能在安全范围内把事做出来。AI 在这次事件里扮演的就是那个足够听话、足够快、足够稳定的实习生，而工程架构就是那个靠谱的导师。

4. 128个PR背后的自动化验证与人工复核

4.1 验证链路设计：单测、集成、回归三层过滤

任何声称"AI 改了几十万行代码没问题"的说法，如果背后没有自动化验证体系，都是不可信的。我在复盘这次事件时，把整套验证链路按三层来理解，这是我觉得所有想复刻这个模式的人都应该重点花时间的地方。

第一层是单测，也就是针对函数、方法、最小逻辑单元的行为验证。对于重构类改动，单测的价值在于锁死那些被替换、被平移、被收敛的函数的局部行为。比如 AI 把某个公共函数里的重复分支抽成了单独函数，单测会验证原函数输入输出是否完全一致。这一层是三层中最容易跑快的一层，但覆盖范围也是最局部的。

第二层是集成测试，重点验证模块与模块之间的协作是否正常。有时候单测全绿，但一个模块修改后，另一个依赖它的模块的对接逻辑就对不上了。集成测试就是把 API 级别的协作重新测一遍，捕捉那些"局部正确但整体错误"的问题。对于一次大规模重构来说，这一层往往是最容易暴露问题的地方，因为改动涉及面广，模块边界的隐性假设极容易被打破。

第三层是回归测试，也就是在更大范围内跑既有测试用例，确认旧功能没有被新改动破坏。严格来说，回归不是一个独立的测试层级，而是一种测试策略。在许多大仓库里，全量回归跑完需要很长时间，所以工程上往往只挑与本次改动相关的关键路径来跑，同时在合并后再跑完整预案。但不管怎么裁剪，"改动之后旧行为仍然正确"这个命题必须被验证到。

三层验证之外，还有一类非功能性检查同样值得纳入体系：静态分析、类型检查、格式校验、依赖漏洞扫描。它们不验证功能正确性，但能保证代码库的卫生状况不至于因为大量 AI 改动而急剧恶化。在这次事件中，这类检查扮演的角色更像是"入场券"，如果这些基础项不过关，PR 根本不会进入人工 review 队列。

4.2 人工复核的重点不是逐行看代码，而是看意图和边界

很多人听到"AI 提交了 128 个 PR"之后，第一反应是"那 review 的人岂不是累死了"。但实际上的 review 策略完全可以不一样。既然每个 PR 都是一个聚焦单一意图的小改动，人工 review 的重点就应该放在四个问题上，而不是去逐行比对代码。

第一个问题是意图是否合理。看到一个 PR 的标题和描述后，reviewer 要判断：它想做的事情，是不是我们当前确实需要做的事情？比如"用新 API 替换旧 API"这个意图本身合理吗？如果旧 API 还有大量调用链，替换顺序有没有讲究？这个问题很多工具都无法自动回答，必须靠人对仓库演进方向的理解来判断。

第二个问题是改动范围是否超界。AI 定了边界，不代表它每次都能完美遵守。reviewer 要在 diff 统计层面快速扫一遍，确认 AI 没有夹带私货。比如一个本应只改模块 A 的 PR，如果突然改到了模块 B 的公共配置，这就属于超界，要打回去重做。

第三个问题是关键文件是否有明显错误。这里的关键文件，一般指接口定义、公共工具函数、核心数据结构。这些文件哪怕是一个小错误都可能引发连锁反应，所以值得 reviewer 花时间细读。

第四个问题是验证是否充分。reviewer 要检查 CI 状态、测试覆盖范围、以及 AI 有没有在 PR 描述里解释它是怎么验证自己的改动的。如果 AI 无法说明验证方式，那么再漂亮的 diff 也不能合并。

我自己的经验是：人工复核和自动化验证之间不是替代关系，而是流水线关系。自动化验证解决的是"对不对"的问题，人工复核解决的是"该不该"的问题。把这两件事分开，人类的工作量才能从逐行检查中解放出来，真正去做只有人才能做的判断。

5. 实测拆解：从一个 PR 的诞生到合并全过程

5.1 一个代表性 PR 的完整生命周期

如果只从最终成果看，整个过程好像稀松平常，但把一个 PR 从诞生到合并的完整生命周期拉出来看，就会发现其中每一步都有明确的工程决策。这里我以"移除一段已废弃的兼容逻辑"为典型场景，模拟一下过程中可能的真实状态。

最开始，AI 会在代码库扫描或任务清单中发现某段兼容逻辑已经没有任何调用方了。它需要先通过代码搜索确认引用为零，然后将任务描述写下来，这个描述要包含三样东西：修改目标、修改原因、验证计划。比如"移除 legacy_utils 模块中的 fallback 兼容函数，当前仓库已无任何调用方，验证方式是跑全量单测并通过 lint 检查"。

接下来 AI 生成代码改动。它会基于搜索与检索结果实际修改文件，可能是删除整个文件，也可能是删除文件中的部分函数。改动完成后，AI 在本地运行验证命令。这里有一个经常被忽略的细节：AI 并不是等所有命令都跑完再提交，而是会在验证失败时自动分析日志、调整代码、重新运行，形成一个小版本的内循环，直到验证通过。

然后 AI 把改动推送到远端，创建 PR。PR 描述会按照设定好的模板生成，包括改动摘要、验证结果、相关 issue 链接。CI 机器人在远端继续跑更全量的检查，包括编译、测试、代码扫描。如果 CI 失败，AI 会收到失败反馈，它会基于失败信息继续修改，并追加一个修复 commit 到原 PR，而不是重新开一个 PR。这部分非常重要，因为一个干净的 PR 历史会让后续人工 review 轻松很多。

最后是人工 review。在这个阶段，人类维护者并不需要重跑 AI 已经跑过的验证，而是先看 PR 描述和变更范围，再抽查关键文件。如果所有检查通过，PR 被合并，随后经过部署管道进入生产环境，并在监控指标上确认没有异常。到这一步，一个 AI 驱动的 PR 才算真正走完了全生命周期。

5.2 过程中出现过的失败、回滚与重试策略

这次事件并不是一路顺风。只要真实地去跑这种规模的重构，失败几乎是必然的，关键是如何设计失败处理策略。我从工程经验出发，总结了在类似流程里最常见的几类失败模式，以及对应的应对方式。

第一类是验证失败。新版代码可能在某处依赖了不兼容的 API，或者某个边界测试没有通过。这类失败通常不需要关闭 PR，只需要让 AI 读取失败日志，定位到具体文件，做针对性修复，再重新触发验证。对 AI 来说，这份失败日志就是最宝贵的训练信号，它比任何提示词都更能指导 AI 往正确的方向修正。

第二类是范围失控。AI 在修改过程中可能跑偏，比如本来只改 A 文件，结果连带把 B 文件的一个不相关格式也改了。这种 PR 不一定会被自动检查拦下来，但会被人工 review 拦下来。应对方式就是打回并指示 AI 撤销附带改动，只保留原目标。

第三类是合并冲突。因为多个 PR 可能并行推进，某些文件被多个 PR 同时修改，就产生了冲突。处理冲突既可以通过 rebase 解决，也可以直接让 AI 基于最新主分支重新生成改动。但这里有个经验：如果冲突发生频率太高，说明任务拆得不够干净，应该调整后续 PR 的生成顺序，尽量让同一时间窗口内的 PR 落在不同文件区域。

还有一类更隐蔽的失败，是测试本身不够强。如果仓库的测试覆盖很低，或者测试断言写得太宽松，AI 改完代码后看起来全绿，实际上行为已经变了。这种情况最危险，因为它不会暴露在任何一层验证中，只能依赖人工的领域知识去提前识别。所以，在启动大规模 AI 重写前，先补测试覆盖率是性价比最高的准备工作，没有之一。

回滚策略方面，我认为最重要的原则是"宁可频繁小回滚，不愿大回滚"。每个 PR 独立合并、独立部署，就可以做到小时级别的问题发现与回滚，而不是等到 128 个 PR 全部合并后才去检查整体质量。这种小步快跑的模式不仅适合人类团队，也特别适合 AI 驱动的开发，因为它能把 AI 犯错的影响面限制到最小。

6. 你要是想复刻这套流程，应该怎么做

6.1 最小可复现版本：单人 + 一个仓库 + 一周

看再多的案例拆解，都不如自己动手跑一遍。我建议想深入理解这个模式的人，不要一开始就想着搞一个多大规模的项目，而是先做一个最小可复现版本。条件可以简化到：一个有点历史负担的中小型仓库、一台能跑构建的机器、一个有工具调用能力的编程智能体、以及你本人作为唯一的 reviewer。

目标可以这样设置：在一周之内，让 AI 提交 5 到 10 个 PR，每个 PR 只做一种行为保持型重构，比如统一字符串拼接方式、删除某个废弃函数、收敛重复的错误处理逻辑。第一大部分工作是搭好验证环境，包括编译、单测、lint 这类绝不能省的基础检查。如果这些检查在你人肉改代码时都不能给你信心，那也别指望能兜住 AI 的错。

然后是写任务说明书。这个环节很多人会省略，但我觉得恰恰是决定成败的关键。任务说明书不需要那种"A 项目你要变好"的模糊描述，而要足够具体：要改哪个目录、动机是什么、验收标准是什么、允许触碰哪些文件、绝对禁止改哪些文件。说明书越具体，AI 跑偏的概率越低。

接下来就可以开跑了。让 AI 一次只处理一个任务，处理完提交 PR 后，你先以 reviewer 身份做一轮复核。前 3 个 PR 先不合并，把它们当成校准样本：观察 AI 的行为模式，看它哪里容易错，然后调整提示词或增加新的护栏，比如"禁止修改超过 200 行的文件""PR 里如果出现与目标无关的文件必须列出"。等 3 个 PR 行为稳定了，再放开让它批量跑。这个过程通常一周足够，但你的收获会比看一百篇案例文章都大。

6.2 可以直接抄的自动化验证清单

我在实际搭建这类流程时，会固定一套验证清单，在这里直接分享出来。你不需要完全照搬，但可以参考它的检查维度，再结合自己仓库的特点做增删：

• 构建/编译检查：仓库能否在干净环境下成功编译。
• 类型检查：TypeScript、Java、Rust 等强类型语言必跑，能拦下一大类低级错误。
• 单元测试：锁定最小逻辑单元的行为，全量或按改动范围圈选。
• 集成测试：验证模块间协作不被破坏。
• 静态分析：检查未使用变量、不可达分支、明显的不良模式。
• 格式检查：统一代码风格，避免 AI 生成大量格式噪音。
• 变更范围检查：改动文件数量、diff 行数是否超出预设阈值。
• 改动清单摘要：每个 PR 必须自动生成"我改了哪些文件、为什么改"的摘要。
• 目标文件白名单：AI 只能动约定的目录，超出则自动警示。
• CI 强制合并门槛：必须全绿才能合并，不存在人工特批通道。

这套清单的核心思路就是：把"AI 是否把事情做对"的判断，尽可能交给确定性的工具，只在最后留少量决策空间给人。这样即使 AI 在某个细节上犯了错，你也能在它进入主分支之前把它拦下来。

6.3 三个容易翻车的坑

把最小复刻跑完之后，我建议你再看看这三个我踩过的坑，能少走很多弯路。

第一个坑是任务拆分过大。你可能会觉得，既然 AI 这么能干，为什么不直接让它一次改整个模块？这个想法非常危险。任务越大，AI 在做局部决策时就越容易丢掉全局约束，它可能为了清理一个方法，顺手改变了另一个方法的行为，而且自己毫无察觉。我的经验是：任务拆分到"每个 PR 都能用一句话说清楚改了什么"才够小。一句话说不清楚的任务，一定要继续拆。

第二个坑是测试覆盖不足。我前面说过，测试是 AI 重构的安全网，但这个安全网只有在覆盖足够时才有效。如果你的仓库本来就没什么测试，AI 改了代码后看起来全绿，那很可能是因为"没有测试会变红"。为了绕开这个坑，我习惯在启动 AI 重写前，先人工或半自动地把核心模块的测试补齐，尤其要补那些用来锁行为的快照测试和边界用例。补测试本身花的时间，会在后续的 AI 重构效率上几十倍地赚回来。

第三个坑是过于信任模型的"解释"。AI 在 PR 描述里写"本改动已在本地验证通过"时，它可能只是跑了一次不完整的命令，甚至只是想象自己跑了。所以你不要只看它说什么，要直接看 CI 的状态和测试报告。凡是不能由系统自动确认的证据，都只能当成参考信息，不能当作合并依据。这是我个人觉得最实用的一条经验：在 AI 协作开发这件事上，信任要靠系统和证据去建立，而不是靠在对话框里多问几句。

整套流程跑过一遍之后，我的体会是：AI 是否"自主重写代码"这件事，最关键的变量往往不是模型本身，而是工程系统允许它犯多大的错、又能多快地把错兜住。把任务拆小、把边界画清、把验证做重、把人类留在决策的关键节点上，这样组合出来的 AI 开发流程，才是真正值得长期投入的方向。