先说个反常识的数字一个普通维护者一个月能合入 20 个 PR已经算得上高产。2000 个 PR 是什么概念按每月 22 个工作日算平均每天要合入将近 100 个。这早就超出了人类手工开 PR 的极限。但如果你去翻某些大型开源项目的提交记录会发现确实存在这样的账号——它们不是人而是 AI 驱动的自动化机器人。GrokBot 核心成员 Lauren Tan 在一次团队内部分享里聊到了这套玩法。她把“每月交付 2000 个 PR”的关键总结成一句话不要把 AI 当成人肉加速器而要把 PR 本身当成流水线上的产品。这句话我琢磨了很久今天结合她分享的细节和我自己折腾过的实践把背后的工作流、工具边界、质量护栏一次性拆开讲清楚。1. 2000 个 PR 的真相它不是“写代码”而是“批量生产变更”先说清楚 2000 个 PR 到底从哪来。很多人第一反应是“一个人怎么可能每个 PR 都自己写”答案是不可能也没必要。Lauren 的团队把 PR 分成了四类只有一小部分需要人类介入PR 类型来源典型任务占 2000 个 PR 的比例依赖维护自动化扫描触发升级 npm/pip 包、修复 CVE 漏洞约 60%批量重构规则引擎触发废弃 API 替换、日志格式统一、框架迁移约 25%安全补丁安全策略触发密钥轮换、权限收紧、依赖锁定约 10%新功能/修复人工或 Agent 提出用户 issue 转化、小范围功能迭代约 5%注意这四类任务的共同点是变更模式高度可预测。依赖升级后调用点要跟着改废弃 API 要换成新写法日志格式要从旧标准变成新标准——这些都是模子里刻出来的活。Lauren 分享了一个典型场景团队手上有 300 个仓库都引用同一个内部库这个库发了一版 breaking change普通做法是开一个 issue然后等维护者手工更新 300 处调用。她们的做法是让 AI Agent 读取新版本的变更日志自动定位每个仓库里需要改的代码生成 300 个各不相同但模式一致的 PR然后在三天内分批合入。这就是 2000 这个数字的来源不是一个人写了 2000 个 PR而是 20 个自动化任务各带了 100 个 PR。关键认知在“批次”两个字。你的目标不是让 AI 写一个完美 PR而是让它把一类变更重复执行 100 遍每遍都要有测试保护和可追溯的说明。少了这个思维你拿 AI 写一个 PR 和一个工程师写一个 PR效率差距可能就是 2 倍有了批量思维效率差距才能拉开到 50 倍以上。1.1 依赖自动更新为什么是 PR 量产主力我们平时在 GitHub 上看到的 Dependabot 或 Renovate基本只能帮你把package.json里的版本号改了再跑一下npm install然后生成一个“chore: bump xxx from 1.0 to 1.1”的 PR。这种 PR 能不能合能但如果新版本改了接口CI 大概率会挂最后还是得人工去改调用点。Lauren 团队的做法更进一步AI 会先去读新版本的CHANGELOG、迁移指南和对比 diff把“哪些 API 变了、新签名是什么、常见的迁移写法是什么”总结成一份上下文说明再带着这份说明去看仓库里所有使用该 API 的文件逐个生成适配后的代码。这样一来依赖升级 PR 就不只是“版本号变更”而是“一次完整的语义化迁移”。她说她团队里 80% 的依赖升级 PR 可以直接通过自动测试并合入不需要人工改动。剩下 20% 是因为测试环境本身不完善或者涉及跨仓库的复杂调用链到这一步才会转给人类处理。1.2 批量重构与“技术债消除”型 PR比依赖升级更有价值的是批量重构。比如某天你决定把整个代码库里的console.log统一换成结构化日志组件传统做法是改写一个 codemod跑一遍然后手动检查所有输出。但 codemod 写起来费劲而且很多重构并不是简单的字符串替换——它需要理解“这段代码的意图是什么应该对应到新组件的哪个方法”。Lauren 的团队把这类任务交给 AI 的方式是先给 AI 三个“范例 PR”分别展示旧代码、新代码和对应的测试然后让它对仓库里所有相似片段执行同样的转换。不是说让 AI 自己发挥想象力而是让它模仿范例的改动风格。他们把这种模式叫“批量教改”只批改前 10 个 PR 做人工抽检确认模式一致后剩下的全自动生成。这套办法用在“消除技术债”上效果极好——因为这些活本质上是体力活人类做容易倦怠AI 做反而稳定。2. AI 在 PR 流水线中的角色划分能确定性的就别让 AI 自由发挥Lauren 分享里最让我受用的一个观点是AI 不应该被放在“从零写代码”的位置上而应该被放在“处理语义模糊”的位置上。她们的 PR 流水线拆成四层每层用的工具完全不同流水线层核心任务用什么工具为什么不用 LLM 全包发现层找出“哪个仓库、哪个文件、哪段代码”需要变更依赖扫描器、废弃 API 检测脚本、issue 规则这些任务有确定性的规则用正则和 AST 更精准执行层根据发现结果生成具体改动的代码Codemod / LLM 混合能用 codemod 的地方用 codemod只有需要理解语义时才让 LLM 介入验证层跑测试、检查 lint、评估覆盖率CI、测试框架、静态分析LLM 不适合做验证它会说谎工具不会描述层生成 PR 标题、正文、变更说明LLM这活儿没有标准答案这是 LLM 的强项为什么要这样分因为 LLM 最大的问题不是“不会写代码”而是“会在没有上下文的地方编造代码”。如果你让 AI 从头写一个完整的 PR它需要理解整个仓库的架构、模块边界、编码风格、隐式约定——这些信息通常散落在几十个文件里超出了窗口限制所以它只能给你一个“看起来差不多”的版本。这个版本可能能通过测试但代码风格和仓库里其他文件格格不入review 起来极其难受。Lauren 的团队做过一个对比实验让同一个 LLM 自由发挥写 100 个功能型 PR结果有 30 个PR因为风格、边界处理或者过度设计需要返工但把同样任务改成交给 LLM“在指定的函数内部、按照相邻代码的风格、只修改明确给出的 TODO 段落”返工率直接降到 5%。这就是角色划分的力量LLM 只需要做“填空”不需要做“审题”。审题由规则和人来完成。2.1 描述层为什么必须交给 AI这部分可能很多人忽略。她提到在 2000 个 PR 里每一份 PR 描述都要回答三个问题这次改了什么为什么这么改影响范围有哪些人工写一份高质量 PR 描述要 5 分钟2000 份就是一整个工时。但 LLM 生成一份只要 30 秒因为 diff 和测试日志就是现成的上下文。她们的做法是给 LLM 塞入本次改动涉及的文件列表、统一 diff、以及 CI 上挂掉的测试日志要求它输出结构化描述——包括背景、变更列表、测试结果、潜在风险。生成完毕后再拼上自动生成的变更粒度标签比如“依赖升级”“安全修复”“重构”这样维护者刷 PR 列表时只看标题和第一个段落就能决定要不要点进去看细节。2.2 为什么不让 AI 直接提交代码这里有个安全边界。就算 LLM 写出来的代码测试全绿也不能让它直接推送到 main。Lauren 说她们内部有个铁律AI 可以产出一个完整 PR但合入的决定权永远握在人和规则手里。对于低风险 PR规则会自动合并对于任何涉及敏感模块支付、权限、数据删除的 PR哪怕 AI 写了 99% 的代码也必须有一个人点击“批准”按钮。这不是不信任 AI而是出了事故之后团队需要有一个明确的 accountable owner。用她的话说“如果 AI 自己批准自己那出了问题你都不知道该找谁。”3. 质量护栏2000 个 PR不会让 main 分支烂掉的设计真正让“每月 2000 个 PR”从神话变成工程实践的不是 AI 生成能力而是质量护栏。没人能人工 review 每天 100 个 PR所以必须把一部分 review 工作自动化同时保证合入速度和质量之间的平衡。以下是 Lauren 分享里最核心的三道防线。3.1 提交前AI 自评论与“变更规格”每个由 AI 生成的 PR在创建时都会附带一条机器人评论内容不是程式化的“cla: yes”而是一份变更规格。它长这样## 变更规格 - 涉及文件src/api/client.ts, test/api/client.test.ts - 触发原因内部库 v2.0 移除了 send() 方法的 async 参数 - 改动逻辑将 send(payload, asyncFlag) 改为 sendWithAsync(payload, { async: true }) - 测试覆盖新增 3 条用例验证 async 回调行为 - 风险等级低仅影响内部 API 调用层这份规格由 LLM 根据 diff 和 issue 自动生成规则引擎会检查它是否满足模板要求。如果 LLM 写不出清晰的“改动逻辑”这个 PR 会被自动打回要求重新生成。这个动作的本质是强制 AI 在提交之前先用文字向人类解释自己做了什么。人脑可以快速扫一眼“变更规格”就建立起信任感而不是点开 27 个 diff 文件慢慢猜。3.2 合并前基于测试矩阵的自动合并策略不是所有 PR 都需要人工审批。Lauren 团队把 PR 分成了“可自动合并”和“需人工审批”两类。自动合并必须同时满足以下条件关联的 CI 全绿包括单元测试、集成测试、静态检查覆盖率对比 base 分支没有下降变更规格中风险等级为低或中且未涉及敏感文件路径白名单没有冲突且 base 分支在 PR 创建后没有发生过大规模改动PR 标题和类型标签符合命名规范。满足这五个条件PR 会在通过测试后 15 分钟内自动合并。不满足的进入人工队列。人工审批同样不是逐行看代码——对于低风险 PR只抽检“变更规格”里的逻辑说明和 diff 统计只有高风险 PR 才要求 reviewer 逐行 review。这样做的结果很直观2000 个 PR 中大约 75% 走自动合并流程剩余 25% 里又有大半只需要几分钟抽检真正需要长 review 的 PR 不到 5%。3.3 出问题怎么办回滚机器人与“灰度合入”自动合并最大的风险是翻车。Lauren 强调她们在部署 AI 合入机制前首先搭好了回滚机制。具体来说每个自动合并的 PR 上都有独立的 revert 按钮同时一个监控机器人盯着合入后的 CI 失败率和新 issue 关键词。一旦某项指标超过阈值最常见的是“某个模块的测试失败率在 1 小时内上升 5%”机器人会立刻 revert 最近 30 分钟内合入的所有 PR并在 main 分支上打一个 tag 标记“已回滚到稳定点”。另外她们还会做“灰度合入”对于影响面较大的重构类 PR先合入到一个小范围的分支比如next-release在那里全量跑 12 小时的集成测试确认稳定后再合入 main。这套机制保证了“即使有 PR 出问题坏代码在 main 分支上存续的时间不会超过一小时”。想玩这套方案的人我建议先把回滚脚本写好再让 AI 开闸顺序反了会很难受。4. 可复制的实操流程把 Lauren 的方法移植到你的项目你不需要有 300 个仓库也能从这套思路里捞到实惠。我照着她们的方法在自己的项目里跑了一个简化版到现在每周能稳定产出 30~50 个自动化 PR。下面是完全可以落地的步骤。4.1 最小可运行示例一个自动升级依赖并适配的 Pipeline假设你有一个 Node.js 项目你想让 AI 在依赖出新版本时自动生成“升级适配”的 PR。可以按下面几步来扫描依赖版本差异用npm outdated --json或脚本读package.json找出所有版本号落后且不为beta/rc的包。提取变更上下文给 AI对每个待升级包把CHANGELOG.md、官方迁移文档、以及当前项目里引用该包的文件列表拼成一段上下文文本传给一个支持长上下文的 LLM。生成适配后的代码提示 LLM“基于下列变更记录替换当前项目中所有旧 API 调用保持代码风格与相邻文件一致不要改动无关内容”让 LLM 输出一个文件补丁列表。应用补丁并跑测试把 LLM 输出的补丁用git apply到工作区然后跑npm test和npm run lint。如果失败把失败日志反馈给 LLM让它迭代修改最多迭代 3 次。创建 PR 并附带变更规格测试通过后用 GitHub CLI 创建 PR标题按“fix(deps): upgrade xxx from v1.1 to v1.2”格式正文用前面第 3.1 节的变更规格模板。配置自动合并在 GitHub 分支规则里允许“CI 通过 无冲突 变更文件白名单”的分支自动合入敏感目录比如src/payment排除在自动合入之外。这个流程跑通之后你可以把触发频率从“每天一次”改成“每个 PR 被合并后自动检查”最后你的机器人就能做到一个包发新版十几分钟内就有个准备好的 PR 躺在那儿等你点头。4.2 AI 生成 PR 提示词的核心结构很多人在这一步踩坑提示词过于笼统。给你一个经过验证的结构模板你可以直接改吧改吧用你是一个代码迁移助手。任务将 {repository_name} 中所有使用 {old_api} 的代码迁移到 {new_api}。 背景 - 新 API 的官方变更说明{changelog_text} - 旧 API 的常见调用模式{old_pattern_examples} - 新 API 对应的写法{new_pattern_examples} - 项目编码规范{style_guide_summary} 约束 1. 只修改与此次迁移相关的文件不要改动无关代码。 2. 保持每个修改文件的现有缩进、命名风格和注释习惯。 3. 对每个修改点在代码前增加一行注释说明“为什么要这样改”。 4. 输出格式为 JSON 数组元素包含字段file_path, new_content, reason。 请先扫描仓库中可能的调用点再输出结果。这个结构里最重要的是“约束”部分。你让 AI 做迁移的时候它最大的毛病就是顺带给你“优化”其他代码。加了“只修改相关文件”和“保持现有风格”它的输出才会像一个保守的工程师写的而不是一个魔术师写的。5. 踩过坑之后我学到的三件事最后说说我自己按照这套方法实践大半年后的一些感受也算是对“怎么用 AI”这个问题的最深体会。第一件事先有自动测试再谈 AI 提速。我最初在某个老项目上跑这套流程第一周就产出 40 个 PR结果有 5 个因为项目根本没有单测而直接漏进了 main引发线上小事故。后来补全了核心路径的测试再让 AI 跑效果立刻不一样。没有测试兜底的 AI 生成代码本质上是盲人骑瞎马所以别迷信 AI 本身先请 CI 把屁股坐稳。第二件事不要追求 AI 全流程自主人机协作才是效率最高的。我试过让 AI 从 issue 直接到 PR 全自动发现它经常会误解产品意图方向错了还振振有词。现在我把流程改成人写清楚“任务边界”AI 负责执行和描述最后人来抽样审批。这套模式虽然看起来还是有人的参与但 AI 负责了 90% 的重复劳动人的精力全部放在例外情况上。Lauren 团队能用 5% 的力量撑住 95% 的运行靠的就是这个分工。第三件事每周必须清理“半成品 PR”。我早期图快AI 一天能生成 50 个 PR但我一周只 review 两次。结果大量 PR 挂在分支上和 main 的差异越来越大最后冲突解决的成本比重新写一遍还高。现在我会在周五用脚本把超过 3 天没合入、且不是标记为“waiting-for-review”的 PR 自动关闭并把分支清理掉。保持队列短、变更小才是流水线稳定运转的前提。按照我的实际体验把 PR 当流水线产品来经营比让 AI 帮你写一个“完美 PR”重要得多。如果你也在折腾 AI 辅助开发建议先挑一个特定类型依赖升级、日志迁移、废弃 API 替换跑通闭环再慢慢扩展到更多场景。毕竟2000 个 PR 不是目标持续稳定地交付变更才是这套玩法真正值钱的地方。
