月产2000个PR：AI编程工作流重构实战

1. 一个月2000个PR到底是什么概念先把数字摊开看。一个月按22个工作日算2000个PR意味着平均每天要交付90个左右的合并请求。如果按自然日30天算每天也有将近67个。这个量级放在任何一个常规研发团队里都是不现实的——一个普通工程师一天能提3到5个质量过关的PR已经算高产了。所以当我第一次看到这个数字的时候第一反应不是这人真勤奋而是这背后一定有一套完全不同的工作方式。勤奋解决不了数量级的差距只有工作流的重构才能做到。Lauren Tan是GrokBot的核心成员这个项目本身就和AI深度绑定。她公开分享过自己的工作方式核心思路可以概括成一句话把AI当成一个能并行处理任务的工程团队而不是一个帮你补全代码的输入法。这个认知差异是整件事的关键。大多数人用AI编程工具的方式是打开编辑器写一半卡住了让AI补全剩下的或者选中一段代码让AI解释一下。这种用法下AI是一个加速器你的产出上限还是被你自己的时间和精力锁死。而2000个PR的工作方式里AI承担的是执行层的角色。人负责定义问题、拆解任务、审查结果AI负责把每一个具体任务落地成可提交的代码变更。这两者的产出效率不在一个维度上。这里要先说清楚一个前提2000个PR不等于2000个从零到一的大型功能。其中大量PR是文档更新、配置调整、依赖升级、测试补充、小范围重构这类原子化的变更。理解这一点后面的方法论才站得住脚。2. 把工作拆成AI能独立完成的原子任务2.1 为什么大任务是AI协作的天敌很多人让AI帮忙做一件事描述是这样的帮我实现一个用户登录功能。然后AI给出一大坨代码你复制进去跑不起来改了半天最后放弃。问题不在于AI能力不够而在于任务颗粒度太粗。一个登录功能里面包含了路由定义、参数校验、密码哈希、数据库查询、token生成、错误处理、单元测试等至少七八个独立关注点。让AI一次性处理这么多关注点它会在某个环节做出你不认可的假设然后整块代码都要返工。Lauren的做法是把任务拆到一个PR只做一件事的程度。比如登录功能会被拆成添加登录接口的路由定义空实现实现请求参数的结构体校验接入密码哈希工具函数实现数据库用户查询生成并返回token补充登录接口的单元测试更新API文档每一个任务都是独立的、可验证的、边界清晰的。AI拿到这样的任务几乎不会跑偏因为它不需要做任何架构层面的决策只需要在一个明确的上下文里完成一件明确的事。2.2 拆解任务的实操判断标准怎么判断一个任务拆得够不够细我总结了一个简单的检验方法如果你没法用一句话写清楚这个PR的验收标准那它就还不够细。比如实现密码哈希工具函数的验收标准是输入明文密码输出bcrypt哈希值相同输入每次输出不同验证函数能正确比对。这个标准清晰到你可以直接把它作为AI的提示词。而实现登录功能的验收标准是什么你很难一句话说清楚因为里面涉及太多决策点。这种任务就必须继续拆。实际操作中我建议按这个顺序拆先列出这个功能涉及的所有变更点——新增哪些文件、修改哪些文件、每个文件里改什么把每个变更点单独拎出来判断它是否能独立提交且不破坏现有功能如果不能独立提交比如改了接口但调用方还没改就把有依赖关系的变更合并成一个PR但仍然保持一个PR一个逻辑单元这套方法用熟了之后你会发现拆任务本身就是一种设计活动。拆得越细你对整个系统的理解反而越清晰。2.3 给AI的任务描述要包含哪些信息拆好任务之后下一步是把它交给AI。这里有个常见的误区很多人觉得任务描述越短越好让AI自己发挥。实际上恰恰相反给AI的任务描述要像给一个新入职同事交代工作一样详细。Lauren分享过一个她常用的任务描述模板我根据自己的实践调整后大概是这个结构背景这个PR要解决什么问题属于哪个模块 现状相关文件现在是什么状态有哪些已有的工具函数可以复用 目标这个PR完成后代码应该是什么样 约束用什么语言、什么框架、遵循什么代码风格、不能引入哪些依赖 验收怎么验证这个PR是正确的这个模板看起来啰嗦但它能极大降低AI跑偏的概率。尤其是约束和验收这两项很多人会忽略结果AI用了一个项目里根本不存在的库或者写出来的代码风格和项目完全不搭。一个实用技巧把项目里已有的类似实现作为参考样例贴给AI。比如你要新增一个API接口就把已有的另一个接口的完整代码贴进去告诉AI按照这个模式实现新接口。这比任何文字描述都有效。3. 并行化让AI同时处理多个任务流3.1 串行工作流的效率天花板拆好任务、写好描述之后如果你还是一个一个地让AI做做完一个审查一个那效率提升是有限的。因为AI生成代码需要时间你审查代码也需要时间这两段时间是串行的。假设一个任务从描述到AI生成完成需要2分钟你审查和调整需要3分钟那一个任务就是5分钟。一天工作8小时理论上最多处理96个任务。这已经接近2000个PR的日均上限了但还没算上你思考、拆解、沟通的时间。所以必须并行化。3.2 多任务并行的具体操作方式Lauren的做法是同时开启多个AI会话每个会话处理一个独立的任务。这在操作上意味着用支持多标签或多窗口的AI编程工具每个窗口对应一个任务一次性把5到10个任务的描述都写好批量提交给AIAI生成期间你去处理其他事情比如审查上一批已经生成好的代码一批生成完成后集中审查集中提交PR这个流程的关键在于批量。不要写一个任务描述就提交一个而是攒一批一起提交。这样AI生成的时间就被你审查其他代码的时间覆盖了整体效率是叠加的。我用这个方式实测下来同时跑6到8个任务是比较舒服的区间。再多的话审查环节会变成瓶颈而且容易漏看问题。3.3 并行化带来的新问题上下文污染并行跑多个任务有一个很容易踩的坑上下文污染。具体表现是你在处理任务A的时候AI生成的代码里突然出现了任务B相关的变量名或逻辑。这通常是因为你在同一个会话里切换了任务或者你把多个任务的描述混在一起提交了。避免这个问题的方法很简单一个任务一个独立会话绝不混用。任务完成后这个会话就关掉不要在里面继续下一个任务。虽然这样会损失一些上下文延续的便利但换来的是每个任务的干净隔离。另外如果你用的是支持项目级上下文的工具要注意检查它自动索引了哪些文件。有时候它会把你正在改的其他文件也纳入上下文导致生成结果受到干扰。这种情况可以在工具设置里手动排除掉不相关的目录。4. 审查环节才是真正的瓶颈4.1 为什么不能跳过审查AI生成的代码哪怕任务描述再清晰也一定会有需要调整的地方。可能是变量命名不符合项目规范可能是错误处理不够完善可能是边界条件没考虑到。如果你不审查直接提交短期看PR数量上去了但很快会积累大量技术债后面修复的成本远高于当初审查的成本。而且一旦线上出问题追溯起来会发现根源都是那些看起来没问题的AI生成代码。所以审查不是可选项而是整个流程里最核心的质量关卡。4.2 高效审查的检查清单审查AI生成的代码和审查人类同事的代码关注点不太一样。人类同事容易犯的错是逻辑错误、边界遗漏AI容易犯的错是看起来对但实际不对——它生成的代码往往语法正确、结构清晰但可能在业务逻辑上做了错误假设。我常用的审查清单是这样的检查项具体看什么常见问题业务逻辑是否符合需求描述AI自行脑补了未说明的规则边界条件空值、极值、异常输入只处理了正常路径错误处理异常是否被正确捕获和传递吞掉异常或抛出无意义错误命名规范是否符合项目约定用了通用命名如data、result依赖引入是否引入了不必要的库用了项目里没有的第三方包测试覆盖是否有对应的测试用例测试只覆盖了happy path这个清单用熟之后审查一个PR大概只需要1到2分钟。对于简单的文档更新或配置调整甚至30秒就能过。4.3 把审查意见反馈给AI的正确方式审查发现问题后不要自己动手改。自己改的话你就又回到了人写代码的模式效率立刻降下来。正确的做法是把审查意见整理成明确的修改要求交回给AI。比如这个PR的问题 1. 第23行的错误处理直接返回了nil应该返回具体的错误信息 2. 缺少对空字符串输入的校验 3. 测试用例只覆盖了正常情况补充一个空输入的测试 请修改后重新生成。这样AI会基于你的反馈重新生成你再审查一遍。通常一到两轮就能达到可提交的状态。注意如果同一个问题你反馈了两次AI还是改不对那就不要继续纠缠了直接自己改。AI在某些特定场景下确实会反复犯同一个错误这时候人工介入反而更快。5. 工具链的选择与配置5.1 AI编程工具的核心能力要求市面上的AI编程工具很多但真正能支撑这种高强度并行工作流的需要满足几个硬性条件多会话管理能同时开多个独立会话互不干扰项目级上下文能理解整个项目的结构而不只是当前文件代码库索引能快速检索项目里已有的函数、类型、模式批量操作能一次性生成多个文件的变更版本控制集成能直接创建分支、提交、开PRLauren在分享中提到过Cursor和pstack这类工具它们在这几个维度上做得比较成熟。Cursor的优势在于编辑器体验流畅、上下文理解准确pstack则在任务编排和批量处理上有独特的设计。5.2 配置中最容易忽略的几个点工具装好只是第一步配置才是决定效率的关键。以下几个配置项是我踩过坑之后觉得必须调整的上下文窗口大小。默认配置通常比较保守导致AI只能看到当前文件的一小部分。对于需要理解项目结构的任务要把上下文窗口调大让它能索引更多相关文件。但也不能无限大否则会引入噪音反而降低生成质量。忽略规则。项目里的node_modules、dist、.git这些目录一定要加到忽略列表里否则AI会去索引这些无关文件浪费上下文空间还可能生成奇怪的代码。代码风格配置。把项目的lint规则、格式化配置接入工具让AI生成的代码自动符合规范。这能省掉大量格式调整的时间。模型选择。不同任务适合不同模型。简单的代码补全用轻量模型就够了复杂的逻辑实现用能力更强的模型。全部用最强模型的话成本和延迟都会上去。5.3 提示词的复用与管理在2000个PR的工作流里提示词是核心生产资料。每次写新的提示词都是浪费应该把常用的提示词模板化、可复用。我的做法是建一个提示词库按任务类型分类新增API接口的提示词模板补充单元测试的提示词模板重构函数的提示词模板更新文档的提示词模板修复bug的提示词模板每个模板里留出变量位置用的时候填入具体的任务信息就行。这样写提示词的时间从几分钟缩短到几十秒。6. 这套方法论的适用边界6.1 什么场景下效率提升最明显不是所有开发工作都适合这套方法。根据我的实践以下场景的效率提升最显著重复性高的模式化工作比如按照已有模式新增接口、新增页面、新增测试边界清晰的独立任务比如升级依赖版本、修复已知的lint问题文档和配置类工作比如更新README、调整CI配置、补充注释小范围重构比如重命名变量、提取函数、调整目录结构这些工作的共同特点是不需要复杂的架构决策有明确的参考模式验收标准清晰。6.2 什么场景下这套方法会失效反过来以下场景用这套方法效果很差甚至适得其反需要深度架构设计的任务比如设计一个新的子系统涉及多个模块的交互需求本身不明确的任务你自己都没想清楚要做什么AI更不可能做对强依赖业务背景的任务需要理解大量业务规则和历史决策的工作性能敏感的核心逻辑AI生成的代码往往不是最优解需要人工深度优化这些场景下AI可以作为辅助比如帮你查资料、生成草稿但不能作为主要执行者。6.3 长期使用后的能力变化用这套方法工作一段时间后我发现自己作为工程师的能力结构发生了变化写代码的熟练度提升变慢了因为大部分代码是AI写的。但任务拆解能力、代码审查能力、系统设计能力提升很快因为这些变成了我每天花时间最多的事情。这个变化本身是中性的关键看你怎么应对。如果你意识到这个趋势主动去补强架构设计和业务理解这些AI替代不了的能力那长期来看是正向的。如果你只是享受PR数量带来的快感忽略了底层能力的建设那几年后可能会发现自己离开了AI就干不了活了。一个建议每周留出一些时间不用AI纯手写代码。保持手感也保持对代码的直觉。这个直觉在审查AI代码的时候特别有用——很多时候你能感觉到这段代码不对劲虽然一时说不出哪里不对但深入看下去往往真有问题。7. 从2000个PR里能提炼出的通用原则7.1 人的角色从生产者变成编排者这是最根本的转变。在传统工作流里工程师是代码的生产者产出直接等于你写了多少代码。在AI协作工作流里工程师是任务的编排者产出等于你定义了多少任务、审查了多少结果。这个转变要求的能力完全不同。生产者需要的是编码熟练度、调试技巧、框架熟悉度编排者需要的是任务拆解能力、清晰表达能力、质量判断能力。很多人在AI编程上遇到瓶颈根本原因就是角色没转变过来。他们还在用生产者的思维用AI——让AI帮自己写代码而不是让AI替自己执行任务。7.2 质量控制在流程中的位置前移传统开发流程里质量控制主要靠测试和code review发生在代码写完之后。在AI协作流程里质量控制必须前移到任务定义阶段。因为AI会严格按照你的描述执行你描述里没提到的约束它就不会遵守。所以你在定义任务的时候就要把所有质量要求写进去代码风格、错误处理规范、测试覆盖要求、性能约束。这其实是一件好事。它强迫你在动手之前就想清楚要做什么、做到什么标准。很多人类工程师写代码时的问题恰恰是没想清楚就开始写。7.3 可验证性比可维护性更优先在AI协作场景下一个任务的可验证性比可维护性更重要。因为AI生成的代码你需要快速判断它是否正确。如果一段代码很难验证你就需要花大量时间去理解它效率优势就没了。所以拆任务的时候要优先选择那些结果容易验证的拆法。比如新增一个函数并补充测试就比重构一个模块更容易验证因为前者有明确的测试结果后者需要你通读所有改动。这个原则也会影响你的技术选型。类型系统强的语言、测试覆盖率高的项目、模块化清晰的架构在AI协作场景下优势更明显因为它们让验证变得更容易。7.4 批量处理是效率的关键杠杆单个任务的效率提升是线性的批量处理的效率提升是指数的。因为批量处理能让你把等待AI生成的时间利用起来去处理其他任务。这个道理和工厂生产是一样的。单件生产的效率永远比不过流水线因为流水线把等待时间变成了并行处理时间。实际操作中批量的规模要控制好。太小了效率提升不明显太大了审查环节会积压。我的经验是保持正在生成的任务数和待审查的任务数大致相等这样整个流程是流畅的不会出现某个环节堵住的情况。8. 一些具体的避坑经验8.1 不要让AI做它不擅长的决策AI很擅长在明确的约束下生成代码但很不擅长做开放式决策。比如这个功能应该用什么架构、这个数据应该怎么建模、这个接口应该怎么设计这些问题让AI回答得到的往往是看起来合理但实际不可用的方案。正确的做法是你自己做完这些决策把决策结果作为约束告诉AI让它在这个约束下生成代码。8.2 警惕看起来对的代码AI生成的代码有一个特点它往往写得很漂亮——命名规范、结构清晰、注释完整。这种漂亮很容易让人放松警惕觉得代码没问题。但实际上漂亮的代码和正确的代码是两回事。我踩过好几次坑都是因为看代码写得太规整了扫了一眼就提交了结果里面有个逻辑错误。所以审查的时候不要被代码的外观迷惑要逐行看逻辑。尤其是涉及条件判断、循环边界、错误处理的地方一定要仔细。8.3 保持PR的原子性一个PR只做一件事这个原则在AI协作场景下尤其重要。因为如果PR里混了多个变更审查的时候你就需要同时理解多个逻辑效率会大幅下降。而且原子性的PR还有一个好处如果某个PR出了问题需要回滚回滚的影响范围是可控的。如果PR里混了多个变更回滚的时候就会很麻烦。8.4 定期清理技术债AI生成代码的速度很快如果不加控制技术债积累的速度也会很快。所以需要定期停下来专门处理技术债。我的做法是每周留出半天时间专门审查过去一周的PR找出那些当时觉得没问题但现在看起来有问题的代码集中修复。这个习惯能防止技术债滚雪球。8.5 不要追求100%的AI化有些工作就是适合人工做强行AI化反而降低效率。比如复杂的调试、性能优化、架构设计这些工作人工做比AI做快得多。判断标准很简单如果一件事你自己做只需要5分钟但给AI描述清楚需要10分钟那就自己做。AI协作的前提是它能带来效率提升如果描述成本高于执行成本那就没有意义。9. 我自己的实践体会我从去年开始尝试这套工作方式PR数量从每月几十个提升到每月几百个。虽然没有达到2000这个量级但效率提升是实实在在的。最大的体会是这套方法的核心不是AI而是你自己。AI只是一个执行工具真正决定效率的是你的任务拆解能力、你的质量判断能力、你的流程设计能力。我见过很多人装了最先进的AI工具但产出没有明显提升。也见过有人用很基础的工具但通过优化工作流效率翻了好几倍。工具是必要条件但不是充分条件。另一个体会是这套方法对自律的要求更高了。因为AI让生成代码变得极其容易你很容易陷入不停生成、不停提交的循环忽略了思考和学习。所以需要刻意留出时间去做那些AI替代不了的事情——读源码、学新东西、思考架构。最后分享一个我最近在用的技巧每周选一个AI生成的PR把它当作面试题来对待——假设这是一个候选人提交的代码你会怎么评价它这个练习能帮你保持审查的敏锐度也能让你更清楚地看到AI代码的常见问题模式。