月产2000个PR：AI Agent重构研发工作流实战

1. 一个月2000个PR到底是什么概念先把数字摊开看。一个月按22个工作日算2000个PR意味着平均每天要交付90个左右的合并请求。如果按8小时工作制算平均每5分钟就有一个PR走完从编写到合并的全流程。这个数字放在任何一个常规研发团队里都是不现实的——光是CI跑一遍、reviewer看一眼、合并冲突处理一下5分钟根本不够。所以当我第一次看到Lauren Tan这个名字和每月2000个PR绑在一起的时候我的第一反应不是这人手速真快而是她一定重构了整条交付链路。事实也确实如此。Lauren Tan是GrokBot的核心成员她做的事情不是自己疯狂敲键盘而是把AI agent深度嵌入了研发工作流让机器去承担那些重复性、机械性的代码变更人只负责判断和决策。这里有个关键认知需要先建立起来2000个PR不是2000个功能。绝大多数PR是依赖升级、类型修复、lint修正、测试补充、文档同步这类低决策密度的变更。这类工作的特点是——规则明确、模式固定、验证方式标准化恰恰是AI agent最擅长的领域。人类工程师做这些事会烦躁、会拖延、会出错但agent不会。我自己的团队从去年开始也在做类似的事情规模没这么大但思路是通的。下面我把这套方法论拆开讲包括工具选型、工作流设计、提示词工程、以及那些只有真正跑过才会知道的坑。2. 为什么是Cursor加pstack这套组合2.1 Cursor在这个工作流里扮演什么角色Cursor本质上是一个深度集成了大模型的代码编辑器。它和普通编辑器的区别在于它能理解整个代码库的上下文而不只是当前打开的文件。你可以用自然语言描述一个变更需求它直接生成diff你确认后应用。在Lauren的工作流里Cursor承担的是单点变更生成器的角色。比如某个依赖库发了新版本API有breaking change她会让Cursor扫描所有调用点批量生成适配代码。这个过程如果手动做一个中型项目可能要花半天用Cursor几分钟出结果人只需要review。但Cursor有个明显的边界它擅长给定明确指令后的代码生成不擅长自主发现需要做什么。你得告诉它改什么它才能改。这就引出了pstack的角色。2.2 pstack解决的是编排问题pstack是一个agent编排框架。它做的事情是定义任务队列、管理agent的执行顺序、处理失败重试、汇总执行结果。你可以把它理解成一个AI工人的调度系统。举个具体场景。假设你要做一次全仓库的类型注解补全。这个任务拆开是扫描所有Python文件、识别缺少类型注解的函数、为每个函数生成注解、验证类型检查通过、提交PR。pstack负责把这个流程串起来每一步调用对应的agent或工具失败了自动重试全部通过后自动开PR。Cursor负责怎么写pstack负责什么时候写、写哪些、写完了怎么办。两者配合才能把单点能力放大成流水线产能。2.3 为什么不用其他方案市面上做类似事情的方案不少。GitHub Copilot Workspace、Devin、各种自建agent框架我都试过。选Cursor加pstack这套组合核心原因是可控性。Copilot Workspace的自主性太强它经常做一些你没让它做的变更review起来反而更累。Devin的能力确实强但它是黑盒你很难精确控制它在每一步做什么。自建框架灵活性最高但维护成本也最高光是prompt版本管理和回归测试就能吃掉一个人大半精力。Cursor加pstack的好处是Cursor的变更生成是你确认才应用pstack的编排逻辑是你定义才执行。整个链路里人始终在关键节点上有否决权。这对于需要保证代码质量的场景来说比全自动方案更实用。提示工具选型没有绝对优劣关键看你的团队能承受多少意外变更。如果你们的review流程很严格宁可agent少做一点、人多确认一次也不要让agent自主发挥。3. 把PR拆成可自动化和必须人工两类3.1 判断标准是什么不是所有PR都适合交给agent。我总结了一个简单的判断框架三个维度维度适合自动化必须人工决策密度规则明确无需权衡涉及架构取舍、性能权衡验证方式有自动化测试覆盖需要人工判断视觉效果或业务逻辑变更范围模式化、可枚举跨模块、影响面不确定依赖升级、类型修复、lint修正、测试补充、文档同步、死代码清理——这些都属于规则明确、验证标准、范围可控的类别可以放心交给agent。新功能开发、架构重构、性能优化、安全相关变更——这些必须人工主导。agent可以辅助生成初稿但决策必须由人来做。3.2 一个具体的分类实例我们团队上个月处理了大约340个PR。按上面的框架分类依赖升级127个全部自动化类型注解补全68个全部自动化lint和格式化修正52个全部自动化测试用例补充41个自动化生成加人工抽检文档同步23个全部自动化新功能开发19个人工主导重构和优化10个人工主导自动化覆盖率大约在85%左右。这个比例不是一开始就能达到的是逐步调优的结果。刚开始可能只有50%随着prompt打磨和验证流程完善比例会慢慢上去。3.3 为什么不能追求100%自动化有人会问既然agent这么能干为什么不把所有PR都自动化因为自动化的收益递减风险递增。前80%的自动化能省掉大量机械劳动收益很明显。但最后20%往往涉及边界情况、特殊逻辑、跨模块影响agent处理这些的出错率会显著上升。而一旦出错修复成本可能比人工做一遍还高。Lauren在分享里提到过一个观点我特别认同agent的价值不是替代人而是把人从低价值劳动里解放出来让人专注于高价值决策。追求100%自动化本身就是个错误目标因为它假设所有工作都是等价的这显然不成立。4. 提示词工程让agent稳定输出可合并的代码4.1 为什么通用提示词不够用直接对Cursor说帮我升级这个依赖它可能会给你一个能跑但不符合团队规范的变更。比如它可能不更新changelog、不调整测试、不处理类型注解。每次输出都不一样review成本很高。解决办法是把团队规范编码进提示词。不是写一段通用指令而是针对每类任务写专门的prompt模板把必须做什么不能做什么验证标准是什么全部写清楚。4.2 一个依赖升级prompt的实际结构任务将依赖 {package_name} 从 {old_version} 升级到 {new_version} 必须完成的步骤 1. 更新 requirements.txt 或 package.json 中的版本号 2. 搜索所有 import 该包的文件检查是否有 breaking change 影响 3. 如果有 API 变更生成适配代码 4. 运行测试套件确保全部通过 5. 更新 CHANGELOG.md在 Unreleased 段落添加变更说明 6. 如果该包有类型定义确认类型检查通过 禁止事项 - 不要修改与本次升级无关的代码 - 不要删除任何测试用例 - 不要跳过任何验证步骤 输出格式 - 先列出所有将要修改的文件 - 然后逐个展示 diff - 最后汇总验证结果这个模板的关键在于步骤可枚举、验证可自动化、边界清晰。agent拿到这样的指令输出稳定性会高很多。4.3 提示词版本管理prompt是要迭代的。每次发现agent输出有问题就要回头改prompt。所以prompt本身也需要版本管理。我们的做法是把所有prompt模板放在一个独立仓库里每次修改都走PR流程。这样能追溯哪个版本的prompt导致了什么问题也方便回滚。另外prompt的修改也需要测试。我们会维护一组黄金案例——已知输入和期望输出。每次改prompt先跑一遍黄金案例确认没有回归。注意prompt不是越长越好。我见过有人把prompt写到几千字结果agent反而抓不住重点。好的prompt是该说的说清楚不该说的一个字不多。5. 验证流水线agent产出的代码怎么保证质量5.1 自动化验证的层次agent生成的代码不能直接合并必须过验证。验证分几层第一层语法和格式。lint、formatter、类型检查。这层不过直接打回。第二层单元测试。agent生成的变更必须让现有测试全部通过。如果测试失败agent要能自己修复修不了就标记为需要人工介入。第三层集成测试。对于影响面较大的变更跑集成测试确认没有破坏跨模块功能。第四层人工抽检。不是每个PR都人工看而是按比例抽检。抽检发现问题就回溯是prompt的问题还是验证流程的问题。5.2 失败重试的策略agent第一次生成失败很正常。关键是重试策略。我们的做法是失败后把错误信息喂回给agent让它基于错误重新生成。最多重试3次。3次还不行就标记为需要人工不再浪费算力。这里有个细节重试时要带上历史上下文。不能只给错误信息还要给之前尝试过的方案避免agent反复犯同样的错。5.3 人工review的注意力分配人工review的时间要花在刀刃上。对于自动化PRreviewer重点看变更范围是否符合预期有没有改不该改的地方边界情况处理是否合理测试覆盖是否充分不需要逐行看代码风格那是lint的事。也不需要验证功能正确性那是测试的事。reviewer的核心任务是判断这个变更该不该合。6. 实测中遇到的坑和应对方法6.1 agent的过度热情最常见的问题是agent做了你没让它做的事。比如你让它升级依赖它顺手把旁边几个文件的格式也改了。这种过度热情会让diff变得很大review成本飙升。应对方法是在prompt里明确写只修改与任务直接相关的文件。如果还是发生就在验证层加一个检查diff涉及的文件数超过阈值就自动打回。6.2 测试通过但逻辑错误agent生成的代码可能让测试通过但逻辑是错的。这种情况通常发生在测试覆盖不足的地方。应对方法是提高测试覆盖率。测试覆盖越充分agent出错的概率越低。这是个正向循环测试越好agent越可靠agent越可靠越敢让它做更多事。6.3 依赖升级的连锁反应升级一个依赖可能触发其他依赖的版本冲突。agent处理这种连锁反应的能力有限。我们的做法是依赖升级按批次做每批只升一组相关依赖。升级前先跑一遍依赖解析确认没有冲突。有冲突就先解决冲突再让agent做升级。6.4 prompt漂移随着时间推移prompt会越改越复杂最后变得难以维护。这是prompt漂移。应对方法是定期重构prompt。把公共部分抽出来做成模板片段任务特定的部分保持精简。每季度做一次prompt审计删掉不再需要的规则。7. 这套方法论的适用边界7.1 什么样的团队适合这套方法最适合代码库规模中等、测试覆盖良好、团队规范明确的团队。代码库太小自动化收益不明显代码库太大agent的上下文理解会出问题。测试覆盖好是前提否则agent产出的代码没法验证。团队规范明确prompt才好写。7.2 什么样的团队不适合如果团队还在快速试错阶段代码库天天大改那自动化PR的意义不大——今天自动化的东西明天可能就删了。如果团队没有测试文化那agent产出的代码就是定时炸弹。如果团队规范还在形成中prompt也没法稳定。7.3 投入产出比怎么算前期投入主要是prompt开发、验证流水线搭建、agent调优。这部分大概需要1到2个人月的投入。之后每个月的维护成本大约0.2个人月。收益方面我们团队实测下来机械性PR的处理时间从平均30分钟降到5分钟含review。按每月300个机械性PR算每月节省约125小时相当于0.8个人月。所以大约2到3个月就能回本。Lauren能做到每月2000个PR是因为她的代码库规模更大、自动化程度更高、流水线更成熟。但底层逻辑是一样的把规则明确的工作交给机器把需要判断的工作留给人。8. 从2000这个数字里能学到什么2000个PR这个数字本身不重要重要的是它背后的工作方式。Lauren Tan做的事情本质上是把研发工作流重新设计了一遍——识别哪些环节是机械的、可自动化的然后用agent去填充这些环节人只在关键决策点介入。这套思路不限于代码PR。任何有规则明确、验证标准、重复执行特征的工作都可以用类似的方法重构。关键是先想清楚哪些事必须人做哪些事可以交给机器。想清楚这个剩下的就是工程问题。我自己的体会是刚开始做自动化的时候容易贪多想把所有事都交给agent。结果就是review成本比自己做还高。后来慢慢收敛只自动化那些真正机械的部分反而效率提升最明显。少即是多这个道理在AI工作流里同样成立。