1. 一个月2000个PR到底是什么概念先把数字摊开来看。一个月按22个工作日算2000个PR意味着平均每天要交付90个左右的合并请求。如果按8小时工作制算每小时要产出超过11个PR也就是每5分钟就有一个PR从创建到合并走完全流程。这个数字放在任何一个常规研发团队里都是不可能靠人力堆出来的。我第一次看到这个数字的时候第一反应是这统计口径肯定有问题。后来仔细琢磨了一下这里的PR大概率不是指那种几百行改动、需要多轮review的大型功能合并而是包含了大量小颗粒度的改动配置调整、文档更新、小bug修复、依赖升级、测试用例补充、代码格式化等等。这类PR单个看价值不大但累积起来对项目的健康度维护非常关键。那问题就来了即便都是小PR一个人一天手动提交90个也是天方夜谭。答案只有一个——AI Agent在承担绝大部分的重复性工作。Lauren Tan作为GrokBot的核心成员她的工作模式本质上已经从自己写代码转变成了设计流程、编排Agent、审核产出。这个转变的意义比数字本身大得多。它意味着一个工程师的产出上限不再取决于他打字的速度和对API的熟悉程度而是取决于他能不能把工作拆解成AI可以执行的原子任务并且建立起一套可靠的自动化流水线。我自己的体会是当你开始用AI Agent处理日常开发任务之后你的角色会发生三个明显变化从执行者变成编排者你不再逐行写代码而是写让AI写代码的指令和约束从单线程变成多线程你可以同时推进多个Agent处理不同任务自己只做关键决策从产出导向变成质量导向PR数量上去了但每个PR的质量把关反而更需要你的判断力注意2000这个数字不应该被当成目标去追。它是流程优化到极致之后的自然结果而不是一个可以硬凑的KPI。如果你为了凑数量让AI批量生成低质量PRreview成本会反过来吃掉所有收益。2. 拆解这套工作流的核心组件2.1 Cursor在这个体系里扮演什么角色从热搜词里频繁出现的Cursor来看它大概率是这套工作流的主力编辑器。Cursor的核心能力不是简单的代码补全而是它内置的Agent模式可以理解整个代码库的上下文然后根据自然语言指令直接修改多个文件、创建新文件、运行终端命令。我实际用下来的感受是Cursor最值钱的地方在于它把理解代码库这件事做成了基础设施。传统的AI编程工具你给它一段代码它帮你补全但Cursor是你告诉它把用户模块的错误处理统一改成新的异常体系它能自己找到所有相关文件逐个修改还能跑测试验证。在Lauren Tan这种高产出的场景下Cursor的使用方式大概是这样几个层次第一层单文件编辑。选中一段代码用CmdK直接下指令修改。这是最基础的用法适合快速修bug或者重构一个小函数。第二层多文件Agent模式。用CmdI打开Composer描述一个跨文件的需求让它自己规划修改方案并执行。这个层次开始体现出效率优势了。第三层规则驱动。在项目根目录配置.cursorrules文件把团队的编码规范、项目架构约定、常用模式都写进去。这样每次Agent执行任务时都会自动遵循这些规则减少来回纠正的成本。第四层工作流编排。把常见的任务类型比如新增一个API端点、修复一类bug、升级一个依赖做成标准化的提示词模板配合脚本实现半自动化甚至全自动化。2.2 pstack和Agent编排的关系热搜词里出现了pstack这个词在AI编程圈子里通常指的是一种提示词栈的思路——把复杂的任务拆解成多层提示词每一层负责一个特定的处理阶段层层叠加最终完成整个任务。打个比方这就像工厂的流水线。你不能指望一个工人从原材料到成品全包了而是把流程拆成若干工位每个工位只做一件事做完传给下一个。pstack的思路就是给AI Agent也建一条流水线需求解析层把模糊的需求翻译成明确的技术任务描述方案规划层根据代码库现状确定要改哪些文件、按什么顺序改代码生成层逐个文件执行修改验证层跑测试、跑lint、检查类型提交层生成commit message、创建PR、填写描述每一层都可以是一个独立的Agent调用也可以是一个提示词模板。关键是把职责分离清楚这样出问题的时候容易定位是哪一层的指令不够精确。2.3 为什么是PR而不是直接push这里有个细节值得说。2000个PR意味着所有改动都走了代码审查流程而不是直接推到主分支。这说明即便在高度自动化的场景下人工审核这一关没有被跳过。PR在这个体系里的作用已经变了。传统意义上PR是请别人审查我的代码但在AI辅助的工作流里PR更像是AI产出的变更记录自动化检查的触发点。CI流水线会在PR上跑测试、跑类型检查、跑安全扫描这些自动化检查承担了大部分质量把关的工作人工只需要看那些自动化检查覆盖不到的地方。我自己的做法是给PR设置分级审核策略PR类型审核方式典型场景文档/注释更新自动合并README修改、代码注释补充依赖小版本升级CI通过后自动合并patch版本更新测试用例补充人工快速过一遍新增测试覆盖业务逻辑修改必须人工详细review功能变更、bug修复架构级改动多人review设计文档模块重构、接口变更这套分级策略的核心逻辑是把人的注意力集中在真正需要判断力的地方而不是浪费在那些自动化工具能搞定的事情上。3. 从需求到PR的完整流水线怎么搭3.1 任务拆解的颗粒度控制这是整个流程里最考验经验的地方。拆得太粗AI一次要处理太多信息容易出错或者遗漏拆得太细你自己的管理成本反而上去了。我的经验法则是一个PR只做一件事且这件事可以用一句话描述清楚。比如给用户列表接口加上分页参数校验是一个合适的颗粒度优化用户模块就太粗了给第47行的if条件加上null检查又太细了。实际操作中我会先用一个规划Agent把大任务拆成小任务列表每个小任务标注涉及文件、预期改动类型、验证方式。然后逐个把小任务丢给执行Agent去完成。这样做的好处是每个PR的diff都很小review起来快出问题的时候容易回滚不会牵连其他改动CI跑得快反馈周期短并行处理多个小任务比串行处理一个大任务效率高3.2 提示词模板的沉淀高频任务一定要做成模板。我目前积累的模板大概有二十多个覆盖了日常开发80%以上的场景。举几个例子新增API端点的模板大致包含这些信息端点路径和HTTP方法、请求参数和校验规则、响应结构、需要更新的路由注册文件、需要新增的测试文件路径、错误处理约定。修复bug的模板则要求bug的现象描述、复现步骤、相关日志或错误信息、疑似涉及的模块、修复后需要补充的回归测试。依赖升级的模板需要包名和目标版本、changelog里需要关注的breaking change、需要同步修改的调用点、验证方式。这些模板不需要写得多复杂关键是把每次都要重复交代的信息固化下来。你可以把它们存在项目的.prompt-templates/目录下用的时候直接引用。3.3 自动化验证的关卡设计AI生成的代码最大的风险是看起来对但实际有问题。所以验证环节必须做厚。我通常设置这几道关卡类型检查TypeScript项目跑tsc --noEmitPython项目跑mypy。类型错误是最容易被AI忽略的问题。Lint检查ESLint或者Ruff确保代码风格一致。这个可以在Cursor的rules里提前约束减少后期修正。单元测试要求AI在修改代码的同时补充或更新对应的测试用例。测试通过是最基本的门槛。集成测试对于涉及接口变更的PR跑一遍集成测试确保没有破坏上下游。人工抽查随机抽取一定比例的PR做详细review检查AI有没有偷懒——比如该处理的边界条件没处理该加的日志没加。提示验证关卡不是越多越好。每多一道关卡就多一份维护成本。我的建议是从类型检查单元测试这两道最基础的开始跑顺了再逐步加。4. 高产出的背后哪些环节最容易被忽略4.1 上下文管理比提示词技巧更重要很多人研究AI编程的时候把大量精力花在怎么写出更好的提示词上。但实际用下来给AI提供正确的上下文比提示词本身重要得多。什么叫正确的上下文就是让AI在动手之前能看到所有它需要知道的信息相关的代码文件、项目的目录结构、已有的类似实现、团队的编码约定、当前分支的状态。Cursor在这方面做得比较好它会自动索引整个项目。但自动索引不等于AI每次都能找到正确的参考。我的做法是在提示词里显式指定参考文件。比如参考src/api/user.ts里的错误处理模式给src/api/order.ts加上同样的处理。这样AI就不用猜了直接照着已有的模式来。4.2 处理AI的自信错误AI最危险的地方不是它不会而是它不会的时候也表现得很自信。它会生成一段看起来完全合理的代码语法没问题逻辑也说得通但就是不符合你项目的实际情况。我踩过几次坑之后总结出来的应对方法关键路径的代码必须人工过一遍。什么叫关键路径涉及资金、权限、数据一致性的代码。这些地方AI可以帮你写初稿但最终判断必须是人做的。让AI解释它的改动。在创建PR的时候要求AI在描述里写清楚为什么这样改和有没有其他方案。如果它的解释逻辑不通那代码大概率有问题。对比测试。对于重构类的改动保留旧实现写一个对比测试确保新旧行为一致。4.3 什么时候该停下来手动写不是所有任务都适合交给AI。我总结了几种AI搞不定或者搞起来不划算的情况需要深度业务理解的改动AI不了解你的业务规则强行让它改容易出逻辑错误涉及外部系统交互的调试需要看真实日志、抓包分析的问题AI帮不上忙性能优化需要profiling数据支撑的优化决策AI只能给通用建议紧急线上问题时间紧迫的情况下自己上手比给AI解释问题更快判断标准很简单如果你给AI解释这个任务的时间比你自己动手做的时间还长那就别用AI。5. 这套模式对个人和团队意味着什么5.1 个人开发者的效率天花板被抬高了以前一个独立开发者能同时维护的项目数量是有限的。现在有了AI Agent的辅助一个人可以覆盖的代码量至少翻了两三倍。这意味着独立开发者可以承接更复杂的项目或者用同样的时间做出更完整的产品。但这里有个陷阱产出增加不等于价值增加。如果你用AI生成大量低质量的代码后期维护成本会指数级上升。真正有价值的是用AI处理那些重复性的、模式化的工作把自己的精力释放出来做架构设计、技术选型和关键决策。5.2 团队协作模式需要调整当团队里有人开始用AI大规模产出PR的时候review的人会最先感受到压力。如果还是按传统方式逐个仔细reviewreview者会变成瓶颈。我们团队的做法是调整PR的粒度标准鼓励小PR但要求每个PR自带充分的上下文说明强化自动化检查把能自动化的检查全部自动化减少人工review的负担建立AI产出的标记机制让review者知道哪些PR是AI生成的需要重点关注什么定期回顾AI产出的问题模式把常见问题反馈到提示词模板和rules里5.3 代码审查的重点在转移以前review代码大量时间花在这个变量名起得不好、这里少了个空行、这个函数太长了这类风格问题上。现在这些都可以通过lint和格式化工具自动解决review者的精力可以集中在这个改动是否真正解决了问题有没有遗漏的边界条件对现有功能有没有潜在影响测试覆盖是否充分这个转变对工程师的能力要求其实更高了。以前你可以靠代码写得漂亮获得认可现在代码风格的事AI帮你搞定了你得靠判断得准确来体现价值。6. 我实际跑这套流程时踩过的坑6.1 一开始贪多结果PR堆积如山最开始我尝试让AI一次性处理一个大模块的重构生成了几十个文件的改动。结果PR大到没人愿意reviewCI跑了四十分钟才出结果中间还挂了三次。最后这个PR被拆成了十几个小PR才合并进去。教训就是AI能一次处理很多文件不代表你应该让它一次处理很多文件。PR的大小应该由review的便利性决定而不是由AI的能力上限决定。6.2 提示词写得太聪明反而坏事有段时间我试图写非常详细的提示词把每一步操作都规定死。结果AI变得很死板遇到提示词没覆盖到的情况就卡住了。后来我改成给方向不给步骤——告诉AI目标和约束条件具体怎么做让它自己判断。这样灵活性强很多出错的概率反而降低了。6.3 忽略了AI的上下文遗忘在一个长对话里AI可能会忘记前面几轮交代过的约束。比如你一开始说了所有日期都用UTC聊了十几轮之后它可能就忘了开始用本地时间。解决办法是把关键约束写进.cursorrules文件这样每一轮对话它都会重新读取这些规则不会遗忘。6.4 测试没跟上bug漏到了生产环境有一次AI修改了一个工具函数的返回值类型从string | null改成了string但忘记更新调用方的null检查。类型检查没报错是因为调用方用了非空断言单元测试没覆盖到这个分支。结果上线后遇到null的情况直接崩了。从那以后我定了一条规矩AI修改任何函数的签名必须同时更新所有调用点和对应的测试。这条规矩写进了提示词模板里每次都会提醒AI执行。7. 如果你想复制这套模式从哪开始7.1 先把手动流程跑顺不要一上来就追求自动化。先用手动的方式走几遍完整流程接到任务、拆解、用AI生成代码、验证、提交PR。跑顺了之后你自然就知道哪些环节可以固化、哪些环节需要灵活处理。7.2 从最高频的任务开始模板化统计一下你日常工作中出现频率最高的任务类型挑前三个做成提示词模板。不要贪多先把这三个打磨好用出效果了再扩展。7.3 建立自己的检查清单每个PR合并前需要检查什么列一个清单。刚开始可以手动对照检查熟练之后可以把清单里的自动化检查项配置到CI里。我的清单大概长这样类型检查通过Lint通过单元测试通过且覆盖率没有下降没有引入新的依赖除非PR目的就是升级依赖变更描述清晰说明了改了什么和为什么改涉及接口变更的上下游已同步更新7.4 定期回顾和迭代每隔一两周花半小时回顾一下哪些PR被打回了、打回的原因是什么、提示词模板需要怎么调整、有没有新的高频任务值得做成模板。这个迭代过程比一次性搭建完美流程重要得多。注意不要照搬任何人的流程包括我这套。每个人的项目类型、团队规模、技术栈都不一样适合的流程也不一样。把别人的经验当成起点根据自己的实际情况调整才是正确的做法。8. 关于AI辅助编程的一点个人看法用AI写代码这件事最大的价值不在于写得快而在于它强迫你把脑子里的隐性知识显性化。以前你知道这个模块的代码应该这样写但你说不清楚为什么。现在你要让AI帮你写你就必须把为什么讲清楚。这个过程本身就在帮你梳理和沉淀知识。另一个感受是AI辅助编程把工程师的工作重心从实现推向了判断。实现这件事正在变得越来越廉价而判断什么值得实现、什么实现方式是好的、什么改动是安全的这些判断力的价值在快速上升。Lauren Tan一个月2000个PR这个数字表面上看是效率的胜利但底层其实是流程设计和质量判断的胜利。AI只是执行者真正决定产出质量和数量的是背后那套经过反复打磨的工作流。你想复制这个结果要学的不是怎么用Cursor而是怎么设计一套让AI能稳定产出高质量代码的流程。这个能力目前还没有任何AI能替你掌握。
