1. 一个月2000个PR到底是什么概念先把数字摊开来看。一个月按22个工作日算2000个PR意味着平均每天要交付90个左右的合并请求。如果按8小时工作制算平均每5分钟就有一个PR走完从创建到合并的全流程。这个数字放在任何一个正常研发团队里都是不现实的——光是CI跑一遍、reviewer看一眼、合并队列排个队5分钟都不够用。所以当我第一次看到Lauren Tan这个名字和每月2000个PR绑在一起的时候我的第一反应不是这人手速真快而是这背后一定有一套完全不同的工作流。后来陆续看到一些关于GrokBot团队工作方式的讨论加上自己在AI辅助编程这条路上摸爬滚打了一年多慢慢拼凑出了这套玩法的轮廓。这篇文章不是要神话某个人或者某个工具。我想做的事情是把月交付2000个PR这个结果倒推回去拆解出它背后可能的工作流、工具链、协作模式以及哪些部分是普通开发者可以借鉴的哪些部分是特定团队规模下才成立的。关键词里的GrokBot、AI、PR、Cursor、pstack这几个词基本覆盖了这套工作流的核心要素。如果你是一个正在尝试把AI引入日常开发流程的工程师或者是一个在思考AI到底能帮团队提效多少的技术负责人这篇文章里的拆解应该能给你一些具体的参考。我不会只讲用AI写代码很快这种废话而是会落到具体的操作层面PR的粒度怎么切、AI在哪个环节介入、review怎么做、CI怎么配合。2. 拆解2000个PR背后的工作流重构2.1 传统PR模式和高频小PR模式的本质差异大多数团队对PR的理解是一个功能开发完了开一个PR等review改几轮合并。一个PR可能涉及几百行甚至上千行改动reviewer需要花半小时甚至更久去理解上下文。这种模式下一个人一天能开3到5个PR就算高产了。但2000个PR/月的模式本质上不是写得快而是PR的定义变了。在这种工作流里PR不再是一个功能的交付单元而是一个可独立验证的最小变更。可能只是修了一个类型错误、调整了一个配置项、补了一个边界条件的测试用例、更新了一处文档注释。每个PR的改动量可能只有几行到几十行但每一个都是完整、可合并、可回滚的。这种模式能成立的前提是AI承担了从识别变更点到生成变更内容的大部分工作。人类工程师的角色从写代码的人变成了定义问题和审核结果的人。2.2 为什么PR粒度必须切到这么细这里有一个很多人会忽略的逻辑AI生成代码的质量和变更的上下文范围强相关。你让AI在一个几千行的文件里改一个函数它很容易改出连锁问题但你让AI只改一个明确的、边界清晰的小点它的准确率会高得多。把PR切细实际上是在降低每次AI介入的复杂度。每个PR只做一件事AI的提示词可以非常具体reviewer的认知负担也很低——看一眼diff就知道对不对不需要在脑子里构建整个模块的心智模型。另一个好处是回滚成本。一个几十行的PR出了问题revert一下就完事了不会牵连其他变更。这在AI生成代码的场景下特别重要因为AI偶尔会产出看起来对但实际有微妙问题的代码小粒度PR让这种风险可控。2.3 这套模式对团队协作的隐性要求高频小PR不是一个人闷头就能干成的。它对团队的基础设施有硬性要求CI必须快。如果CI跑一次要20分钟一天90个PR根本排不过来。这类团队通常会把CI拆成多层lint和类型检查在秒级完成单元测试在分钟级集成测试异步跑。合并队列必须自动化。不能靠人工点合并得有自动化的merge queuePR通过所有检查后自动入队合并。review文化要变。不能每个PR都要求两个人仔细看得建立低风险PR快速通道机制比如只改测试、只改文档、只改配置的PR可以单人approve甚至自动approve。这里有个常见的误区很多人以为高频PR就是不管质量猛开。恰恰相反能跑通这套流程的团队对每个PR的质量门禁卡得非常死只不过门禁是自动化的不是靠人肉review堆出来的。3. AI在PR流水线里的具体介入点3.1 从issue到代码AI怎么理解要改什么这套工作流的第一步不是打开编辑器写代码而是把需求拆成AI能理解的原子任务。Lauren Tan在公开分享里提到过一个做法她会把一个大需求先拆成若干个变更意图每个意图用一句话描述清楚输入、输出和边界条件然后把这些意图分别喂给AI。举个例子假设要加一个用户配置项。传统做法是开一个PR里面包含类型定义、默认值、读取逻辑、校验逻辑、测试、文档。但在高频小PR模式下这会变成5到6个独立PR一个加类型定义一个加默认值常量一个加读取函数一个加校验一个加测试一个加文档。每个PR的提示词都非常聚焦。这里的关键技巧是提示词里要包含不要做什么。AI很容易过度发挥你让它加一个读取函数它可能顺手把校验也写了。明确告诉它只改这个文件、只加这个函数、不要动其他任何东西能大幅降低PR的噪音。3.2 Cursor在这套流程里扮演的角色Cursor在这类工作流里的价值不只是补全代码快。它真正的优势在于对代码库的上下文理解和多文件编辑能力。当你需要在一个PR里同时改类型定义和它的使用点时Cursor能基于整个项目的索引给出一致的修改建议而不是像传统补全那样只看当前文件。我自己的使用习惯是把Cursor的Composer模式多文件编辑用在一个PR涉及2到3个文件的场景把行内补全用在单文件小改的场景。对于高频小PR来说大部分PR其实只需要行内补全就够了因为改动范围本来就很小。有一个细节值得注意Cursor的.cursorrules文件在这套流程里非常关键。你可以把团队的代码规范、命名约定、测试写法都写进去这样AI生成的代码天然符合团队标准减少了review阶段的来回。很多人忽略了这个文件结果AI生成的代码风格和项目格格不入reviewer光改格式就要花好几分钟。3.3 pstack这类工具解决的是什么问题pstack这个词在热词里出现结合上下文来看它应该是指一类PR堆叠管理工具。高频小PR模式会带来一个新问题PR之间有依赖关系。比如PR B依赖PR A的类型定义PR C依赖PR B的函数。如果A还没合并B和C就没法独立合并。传统做法是等A合并了再开B但这样串行下去效率很低。堆叠PR工具的思路是允许你基于未合并的PR继续开新PR形成一个PR链。当底层的PR合并后上层的PR会自动rebase到主分支。这样你就可以并行推进多个有依赖关系的变更不用干等。这类工具在单人高频PR场景下几乎是必需品。没有它2000个PR/月根本排不开因为大量时间会浪费在等待依赖合并上。4. 让AI产出可合并PR的提示词工程4.1 提示词的结构比内容更重要很多人写AI提示词的习惯是把要求一股脑写出来但在高频PR场景下提示词需要有固定的结构这样才能保证每次输出的稳定性。我自己总结下来一个能稳定产出可合并PR的提示词通常包含四个部分上下文锚定明确告诉AI当前在哪个文件、哪个函数、哪个模块里工作。变更意图用一句话说清楚这次要做什么越具体越好。边界约束明确列出不要做什么比如不要改其他文件、不要重构现有逻辑、不要加额外的依赖。验收标准告诉AI什么样的输出算是完成了比如类型检查通过新增测试覆盖X场景。这四部分里边界约束是最容易被忽略但最重要的。AI的默认行为是尽量帮忙你不限制它它就会到处改。一个没有边界约束的提示词产出的PR可能需要reviewer花10分钟去甄别哪些改动是必要的、哪些是AI自作主张的。4.2 针对不同类型PR的提示词模板不同类型的变更提示词的侧重点不一样。下面是我在实际使用中总结的几个模板可以直接拿去改类型定义类PR在当前文件中为X功能添加类型定义。 要求 - 只修改类型定义部分不要动任何运行时逻辑 - 命名遵循项目现有的PascalCase约定 - 可选字段用?标记不要用| undefined - 不要导出新的类型除非现有代码已经导入了它测试补充类PR为X函数补充单元测试。 要求 - 只添加测试文件或在现有测试文件中追加不要修改被测函数 - 覆盖以下场景正常输入、空输入、边界值 - 使用项目现有的测试框架和断言风格 - 每个测试用例的命名要描述清楚测的是什么Bug修复类PR修复X函数在Y条件下的错误行为。 要求 - 只修改X函数不要重构周边代码 - 修复后补充一个能复现原bug的测试用例 - 在PR描述里说明根因和修复思路 - 不要引入新的依赖这些模板的核心思路是一样的把AI的行动范围框死。框得越死产出的PR越干净review越快合并越顺。4.3 提示词泄露事件给我们的启示热词里出现了cursor提示词泄露这个词我没去追具体是什么事件但这类事情反映了一个共性问题很多人把提示词当成了秘密武器但实际上提示词的价值在于迭代不在于保密。真正让高频PR模式跑通的不是某一条神奇的提示词而是一整套写提示词、看结果、调提示词的循环。你今天写了一条提示词AI产出的PR被reviewer打回来了你就要分析是哪里没说清楚然后改提示词。这个循环跑上几十次你自然就有一套适合自己项目的提示词库了。所以与其去关心别人的提示词长什么样不如在自己的项目里建立这个迭代循环。别人的提示词放到你的代码库里大概率是不work的因为上下文不一样。5. Review和CI怎么跟上这个节奏5.1 自动化门禁必须覆盖80%的检查项一天90个PR如果每个PR都需要人工reviewreviewer会直接崩溃。所以这套工作流的前提是绝大部分检查项由自动化完成。具体来说以下几类检查必须自动化不能靠人看检查类型工具触发时机代码格式Prettier/ESLintpre-commit CI类型检查TypeScript compilerCI单元测试Jest/VitestCI构建验证项目构建脚本CI依赖检查依赖分析工具CIPR描述规范自定义脚本PR创建时这些检查全部通过之后PR才进入人工review环节。人工review只关注自动化检查覆盖不到的东西业务逻辑对不对、边界条件考虑全不全、有没有更好的实现方式。5.2 人工review的注意力应该放在哪里在高频小PR模式下人工review的时间预算是很紧的。我的经验是review一个PR的时间应该控制在2分钟以内。超过2分钟说明这个PR要么太大了要么改动太复杂了应该打回去重新拆分。2分钟内能看什么基本上只能看diff的整体形状对不对、关键逻辑有没有明显错误、测试用例是否覆盖了主要场景。这就要求PR本身足够小、足够聚焦。如果一个PR需要你花5分钟去理解上下文那它就不符合高频小PR的标准。这里有一个实操技巧在PR描述里让AI自动生成变更摘要和验证步骤。reviewer先看摘要30秒内判断这个PR要不要仔细看。如果摘要显示只是改了一个常量或者补了一个测试那扫一眼diff就可以approve了。5.3 合并队列和冲突处理高频PR模式下主分支的变更非常频繁冲突是常态。如果靠人工rebase一天90个PR根本处理不过来。所以必须有自动化的合并队列。合并队列的工作方式是PR通过所有检查后进入队列队列按顺序逐个将PR合并到主分支。如果某个PR合并时产生冲突队列会暂停并通知作者处理。处理完之后重新入队。这套机制的关键在于队列的吞吐量。如果队列一次只能处理一个PR那90个PR排下来要很久。好的合并队列实现会支持批量合并和并行验证把吞吐量拉上去。另外一个细节是PR的创建时间要分散。如果所有PR都集中在某几个时间点创建CI和合并队列会出现峰值压力。理想情况下PR应该随着开发进度自然产生而不是攒一批一起提交。6. 这套模式不是万能药适用边界和踩坑记录6.1 什么类型的项目适合高频小PR高频小PR模式在以下场景下效果最好代码库有完善的类型系统和测试覆盖。AI生成的代码需要快速验证类型检查和单元测试是最快的验证手段。如果项目没有这些AI产出的代码就只能靠人看效率优势就没了。变更以增量为主而非架构级重构。加功能、修bug、补测试这类增量变更适合拆成小PR。但如果是大规模重构拆成小PR反而会增加协调成本。团队对自动化门禁有共识。如果团队里有人坚持每个PR都要人工仔细看这套模式跑不起来。反过来以下场景要慎重项目处于早期探索阶段架构还没稳定频繁的小变更会导致大量返工。代码库缺乏测试覆盖AI生成的代码没有快速验证手段。团队规模很小1到2人PR的协调成本本身就低高频小PR的收益不明显。6.2 我踩过的三个坑第一个坑PR切得太碎导致上下文丢失。有一次我把一个功能拆成了十几个PR结果每个PR单独看都没问题但合在一起之后发现接口对不上。后来我学乖了拆分之前先画一个简单的接口约定确保每个PR都遵守同一个约定。第二个坑过度依赖AI导致review松懈。有一段时间我因为AI产出的代码质量还不错review的时候就比较随意结果漏掉了一个边界条件上线后出了个小问题。从那以后我给自己定了个规矩不管PR多小测试用例必须仔细看因为测试是最后一道防线。第三个坑CI太慢导致PR积压。刚开始搞高频PR的时候CI要跑15分钟结果PR排了一长串。后来把CI拆成了快慢两层lint和类型检查控制在1分钟内单元测试控制在3分钟内集成测试异步跑情况才好转。6.3 关于AI替代人这件事的实际观察回到Lauren Tan和GrokBot这个话题。2000个PR/月这个数字很容易被解读成AI可以替代工程师了。但从这套工作流的拆解来看实际情况是AI替代的是写代码这个动作但定义问题、拆分任务、设计验证方案、判断结果是否正确这些工作仍然需要人来完成而且要求更高了。在传统模式下一个工程师的核心能力是能把代码写出来。在高频AI辅助模式下核心能力变成了能把问题拆成AI能执行的原子任务和能快速判断AI的输出是否可用。这两种能力的要求是不一样的后者更偏向于架构思维和质量判断。所以我的看法是这套模式不是让工程师变得不重要而是让工程师的工作重心发生了转移。能适应这个转移的人产出效率会大幅提升适应不了的人可能会发现自己用AI也用不出效果。7. 如果你想在自己的项目里试这套模式7.1 从小范围开始别一上来就全面铺开我的建议是先选一个模块在这个模块里试行高频小PR模式。选模块的标准是测试覆盖比较好、变更频率适中、不是核心链路。在这个模块里跑上两周感受一下PR粒度、提示词写法、review节奏然后再决定要不要推广到其他模块。一开始不要追求2000个PR/月这种数字那没有意义。先追求每个PR都能在2分钟内review完并且合并这个目标达到了效率自然就上去了。7.2 工具链的最小可用配置如果你现在就想开始试这是我认为的最小可用配置编辑器Cursor或者类似的AI辅助编辑器关键是支持多文件编辑和项目级上下文。提示词管理用一个简单的Markdown文件维护你的提示词模板按PR类型分类。CI确保lint、类型检查、单元测试能在5分钟内跑完。PR模板在PR模板里加入变更摘要和验证步骤两个必填项让AI自动填充。合并策略如果团队规模允许开启auto-merge让通过所有检查的PR自动合并。这套配置不需要额外的付费工具大部分都是现有工具的重新组合。关键是工作流的改变不是工具的改变。7.3 一个具体的起步练习如果你想找一个具体的切入点我建议从补测试开始。原因很简单补测试是纯增量变更不会破坏现有逻辑风险极低同时它能让你快速熟悉写提示词、看AI输出、调整提示词这个循环。具体做法是找一个测试覆盖率不高的模块让AI分析哪些函数缺少测试然后针对每个缺失的测试场景开一个独立的PR。一个模块可能能开出十几个测试PR每个PR只加一个或几个测试用例。跑完这一轮你对高频小PR的节奏就有感觉了。等你对补测试的节奏熟悉了再逐步扩展到bug修复、小功能开发、重构等场景。每一步都保持PR小、验证快、合并顺的原则不要贪多。这套模式的核心不是AI有多强而是你把工作流设计得让AI能发挥出它的能力。工具是死的工作流是活的。同样是用Cursor有人一天开3个PR有人一天开30个差距不在工具在于怎么拆任务、怎么设约束、怎么建验证闭环。这个道理放在任何AI辅助编程的场景里都成立。 月交付2000个PR：AI辅助编程的高频小PR工作流拆解
1. 一个月2000个PR到底是什么概念先把数字摊开来看。一个月按22个工作日算2000个PR意味着平均每天要交付90个左右的合并请求。如果按8小时工作制算平均每5分钟就有一个PR走完从创建到合并的全流程。这个数字放在任何一个正常研发团队里都是不现实的——光是CI跑一遍、reviewer看一眼、合并队列排个队5分钟都不够用。所以当我第一次看到Lauren Tan这个名字和每月2000个PR绑在一起的时候我的第一反应不是这人手速真快而是这背后一定有一套完全不同的工作流。后来陆续看到一些关于GrokBot团队工作方式的讨论加上自己在AI辅助编程这条路上摸爬滚打了一年多慢慢拼凑出了这套玩法的轮廓。这篇文章不是要神话某个人或者某个工具。我想做的事情是把月交付2000个PR这个结果倒推回去拆解出它背后可能的工作流、工具链、协作模式以及哪些部分是普通开发者可以借鉴的哪些部分是特定团队规模下才成立的。关键词里的GrokBot、AI、PR、Cursor、pstack这几个词基本覆盖了这套工作流的核心要素。如果你是一个正在尝试把AI引入日常开发流程的工程师或者是一个在思考AI到底能帮团队提效多少的技术负责人这篇文章里的拆解应该能给你一些具体的参考。我不会只讲用AI写代码很快这种废话而是会落到具体的操作层面PR的粒度怎么切、AI在哪个环节介入、review怎么做、CI怎么配合。2. 拆解2000个PR背后的工作流重构2.1 传统PR模式和高频小PR模式的本质差异大多数团队对PR的理解是一个功能开发完了开一个PR等review改几轮合并。一个PR可能涉及几百行甚至上千行改动reviewer需要花半小时甚至更久去理解上下文。这种模式下一个人一天能开3到5个PR就算高产了。但2000个PR/月的模式本质上不是写得快而是PR的定义变了。在这种工作流里PR不再是一个功能的交付单元而是一个可独立验证的最小变更。可能只是修了一个类型错误、调整了一个配置项、补了一个边界条件的测试用例、更新了一处文档注释。每个PR的改动量可能只有几行到几十行但每一个都是完整、可合并、可回滚的。这种模式能成立的前提是AI承担了从识别变更点到生成变更内容的大部分工作。人类工程师的角色从写代码的人变成了定义问题和审核结果的人。2.2 为什么PR粒度必须切到这么细这里有一个很多人会忽略的逻辑AI生成代码的质量和变更的上下文范围强相关。你让AI在一个几千行的文件里改一个函数它很容易改出连锁问题但你让AI只改一个明确的、边界清晰的小点它的准确率会高得多。把PR切细实际上是在降低每次AI介入的复杂度。每个PR只做一件事AI的提示词可以非常具体reviewer的认知负担也很低——看一眼diff就知道对不对不需要在脑子里构建整个模块的心智模型。另一个好处是回滚成本。一个几十行的PR出了问题revert一下就完事了不会牵连其他变更。这在AI生成代码的场景下特别重要因为AI偶尔会产出看起来对但实际有微妙问题的代码小粒度PR让这种风险可控。2.3 这套模式对团队协作的隐性要求高频小PR不是一个人闷头就能干成的。它对团队的基础设施有硬性要求CI必须快。如果CI跑一次要20分钟一天90个PR根本排不过来。这类团队通常会把CI拆成多层lint和类型检查在秒级完成单元测试在分钟级集成测试异步跑。合并队列必须自动化。不能靠人工点合并得有自动化的merge queuePR通过所有检查后自动入队合并。review文化要变。不能每个PR都要求两个人仔细看得建立低风险PR快速通道机制比如只改测试、只改文档、只改配置的PR可以单人approve甚至自动approve。这里有个常见的误区很多人以为高频PR就是不管质量猛开。恰恰相反能跑通这套流程的团队对每个PR的质量门禁卡得非常死只不过门禁是自动化的不是靠人肉review堆出来的。3. AI在PR流水线里的具体介入点3.1 从issue到代码AI怎么理解要改什么这套工作流的第一步不是打开编辑器写代码而是把需求拆成AI能理解的原子任务。Lauren Tan在公开分享里提到过一个做法她会把一个大需求先拆成若干个变更意图每个意图用一句话描述清楚输入、输出和边界条件然后把这些意图分别喂给AI。举个例子假设要加一个用户配置项。传统做法是开一个PR里面包含类型定义、默认值、读取逻辑、校验逻辑、测试、文档。但在高频小PR模式下这会变成5到6个独立PR一个加类型定义一个加默认值常量一个加读取函数一个加校验一个加测试一个加文档。每个PR的提示词都非常聚焦。这里的关键技巧是提示词里要包含不要做什么。AI很容易过度发挥你让它加一个读取函数它可能顺手把校验也写了。明确告诉它只改这个文件、只加这个函数、不要动其他任何东西能大幅降低PR的噪音。3.2 Cursor在这套流程里扮演的角色Cursor在这类工作流里的价值不只是补全代码快。它真正的优势在于对代码库的上下文理解和多文件编辑能力。当你需要在一个PR里同时改类型定义和它的使用点时Cursor能基于整个项目的索引给出一致的修改建议而不是像传统补全那样只看当前文件。我自己的使用习惯是把Cursor的Composer模式多文件编辑用在一个PR涉及2到3个文件的场景把行内补全用在单文件小改的场景。对于高频小PR来说大部分PR其实只需要行内补全就够了因为改动范围本来就很小。有一个细节值得注意Cursor的.cursorrules文件在这套流程里非常关键。你可以把团队的代码规范、命名约定、测试写法都写进去这样AI生成的代码天然符合团队标准减少了review阶段的来回。很多人忽略了这个文件结果AI生成的代码风格和项目格格不入reviewer光改格式就要花好几分钟。3.3 pstack这类工具解决的是什么问题pstack这个词在热词里出现结合上下文来看它应该是指一类PR堆叠管理工具。高频小PR模式会带来一个新问题PR之间有依赖关系。比如PR B依赖PR A的类型定义PR C依赖PR B的函数。如果A还没合并B和C就没法独立合并。传统做法是等A合并了再开B但这样串行下去效率很低。堆叠PR工具的思路是允许你基于未合并的PR继续开新PR形成一个PR链。当底层的PR合并后上层的PR会自动rebase到主分支。这样你就可以并行推进多个有依赖关系的变更不用干等。这类工具在单人高频PR场景下几乎是必需品。没有它2000个PR/月根本排不开因为大量时间会浪费在等待依赖合并上。4. 让AI产出可合并PR的提示词工程4.1 提示词的结构比内容更重要很多人写AI提示词的习惯是把要求一股脑写出来但在高频PR场景下提示词需要有固定的结构这样才能保证每次输出的稳定性。我自己总结下来一个能稳定产出可合并PR的提示词通常包含四个部分上下文锚定明确告诉AI当前在哪个文件、哪个函数、哪个模块里工作。变更意图用一句话说清楚这次要做什么越具体越好。边界约束明确列出不要做什么比如不要改其他文件、不要重构现有逻辑、不要加额外的依赖。验收标准告诉AI什么样的输出算是完成了比如类型检查通过新增测试覆盖X场景。这四部分里边界约束是最容易被忽略但最重要的。AI的默认行为是尽量帮忙你不限制它它就会到处改。一个没有边界约束的提示词产出的PR可能需要reviewer花10分钟去甄别哪些改动是必要的、哪些是AI自作主张的。4.2 针对不同类型PR的提示词模板不同类型的变更提示词的侧重点不一样。下面是我在实际使用中总结的几个模板可以直接拿去改类型定义类PR在当前文件中为X功能添加类型定义。 要求 - 只修改类型定义部分不要动任何运行时逻辑 - 命名遵循项目现有的PascalCase约定 - 可选字段用?标记不要用| undefined - 不要导出新的类型除非现有代码已经导入了它测试补充类PR为X函数补充单元测试。 要求 - 只添加测试文件或在现有测试文件中追加不要修改被测函数 - 覆盖以下场景正常输入、空输入、边界值 - 使用项目现有的测试框架和断言风格 - 每个测试用例的命名要描述清楚测的是什么Bug修复类PR修复X函数在Y条件下的错误行为。 要求 - 只修改X函数不要重构周边代码 - 修复后补充一个能复现原bug的测试用例 - 在PR描述里说明根因和修复思路 - 不要引入新的依赖这些模板的核心思路是一样的把AI的行动范围框死。框得越死产出的PR越干净review越快合并越顺。4.3 提示词泄露事件给我们的启示热词里出现了cursor提示词泄露这个词我没去追具体是什么事件但这类事情反映了一个共性问题很多人把提示词当成了秘密武器但实际上提示词的价值在于迭代不在于保密。真正让高频PR模式跑通的不是某一条神奇的提示词而是一整套写提示词、看结果、调提示词的循环。你今天写了一条提示词AI产出的PR被reviewer打回来了你就要分析是哪里没说清楚然后改提示词。这个循环跑上几十次你自然就有一套适合自己项目的提示词库了。所以与其去关心别人的提示词长什么样不如在自己的项目里建立这个迭代循环。别人的提示词放到你的代码库里大概率是不work的因为上下文不一样。5. Review和CI怎么跟上这个节奏5.1 自动化门禁必须覆盖80%的检查项一天90个PR如果每个PR都需要人工reviewreviewer会直接崩溃。所以这套工作流的前提是绝大部分检查项由自动化完成。具体来说以下几类检查必须自动化不能靠人看检查类型工具触发时机代码格式Prettier/ESLintpre-commit CI类型检查TypeScript compilerCI单元测试Jest/VitestCI构建验证项目构建脚本CI依赖检查依赖分析工具CIPR描述规范自定义脚本PR创建时这些检查全部通过之后PR才进入人工review环节。人工review只关注自动化检查覆盖不到的东西业务逻辑对不对、边界条件考虑全不全、有没有更好的实现方式。5.2 人工review的注意力应该放在哪里在高频小PR模式下人工review的时间预算是很紧的。我的经验是review一个PR的时间应该控制在2分钟以内。超过2分钟说明这个PR要么太大了要么改动太复杂了应该打回去重新拆分。2分钟内能看什么基本上只能看diff的整体形状对不对、关键逻辑有没有明显错误、测试用例是否覆盖了主要场景。这就要求PR本身足够小、足够聚焦。如果一个PR需要你花5分钟去理解上下文那它就不符合高频小PR的标准。这里有一个实操技巧在PR描述里让AI自动生成变更摘要和验证步骤。reviewer先看摘要30秒内判断这个PR要不要仔细看。如果摘要显示只是改了一个常量或者补了一个测试那扫一眼diff就可以approve了。5.3 合并队列和冲突处理高频PR模式下主分支的变更非常频繁冲突是常态。如果靠人工rebase一天90个PR根本处理不过来。所以必须有自动化的合并队列。合并队列的工作方式是PR通过所有检查后进入队列队列按顺序逐个将PR合并到主分支。如果某个PR合并时产生冲突队列会暂停并通知作者处理。处理完之后重新入队。这套机制的关键在于队列的吞吐量。如果队列一次只能处理一个PR那90个PR排下来要很久。好的合并队列实现会支持批量合并和并行验证把吞吐量拉上去。另外一个细节是PR的创建时间要分散。如果所有PR都集中在某几个时间点创建CI和合并队列会出现峰值压力。理想情况下PR应该随着开发进度自然产生而不是攒一批一起提交。6. 这套模式不是万能药适用边界和踩坑记录6.1 什么类型的项目适合高频小PR高频小PR模式在以下场景下效果最好代码库有完善的类型系统和测试覆盖。AI生成的代码需要快速验证类型检查和单元测试是最快的验证手段。如果项目没有这些AI产出的代码就只能靠人看效率优势就没了。变更以增量为主而非架构级重构。加功能、修bug、补测试这类增量变更适合拆成小PR。但如果是大规模重构拆成小PR反而会增加协调成本。团队对自动化门禁有共识。如果团队里有人坚持每个PR都要人工仔细看这套模式跑不起来。反过来以下场景要慎重项目处于早期探索阶段架构还没稳定频繁的小变更会导致大量返工。代码库缺乏测试覆盖AI生成的代码没有快速验证手段。团队规模很小1到2人PR的协调成本本身就低高频小PR的收益不明显。6.2 我踩过的三个坑第一个坑PR切得太碎导致上下文丢失。有一次我把一个功能拆成了十几个PR结果每个PR单独看都没问题但合在一起之后发现接口对不上。后来我学乖了拆分之前先画一个简单的接口约定确保每个PR都遵守同一个约定。第二个坑过度依赖AI导致review松懈。有一段时间我因为AI产出的代码质量还不错review的时候就比较随意结果漏掉了一个边界条件上线后出了个小问题。从那以后我给自己定了个规矩不管PR多小测试用例必须仔细看因为测试是最后一道防线。第三个坑CI太慢导致PR积压。刚开始搞高频PR的时候CI要跑15分钟结果PR排了一长串。后来把CI拆成了快慢两层lint和类型检查控制在1分钟内单元测试控制在3分钟内集成测试异步跑情况才好转。6.3 关于AI替代人这件事的实际观察回到Lauren Tan和GrokBot这个话题。2000个PR/月这个数字很容易被解读成AI可以替代工程师了。但从这套工作流的拆解来看实际情况是AI替代的是写代码这个动作但定义问题、拆分任务、设计验证方案、判断结果是否正确这些工作仍然需要人来完成而且要求更高了。在传统模式下一个工程师的核心能力是能把代码写出来。在高频AI辅助模式下核心能力变成了能把问题拆成AI能执行的原子任务和能快速判断AI的输出是否可用。这两种能力的要求是不一样的后者更偏向于架构思维和质量判断。所以我的看法是这套模式不是让工程师变得不重要而是让工程师的工作重心发生了转移。能适应这个转移的人产出效率会大幅提升适应不了的人可能会发现自己用AI也用不出效果。7. 如果你想在自己的项目里试这套模式7.1 从小范围开始别一上来就全面铺开我的建议是先选一个模块在这个模块里试行高频小PR模式。选模块的标准是测试覆盖比较好、变更频率适中、不是核心链路。在这个模块里跑上两周感受一下PR粒度、提示词写法、review节奏然后再决定要不要推广到其他模块。一开始不要追求2000个PR/月这种数字那没有意义。先追求每个PR都能在2分钟内review完并且合并这个目标达到了效率自然就上去了。7.2 工具链的最小可用配置如果你现在就想开始试这是我认为的最小可用配置编辑器Cursor或者类似的AI辅助编辑器关键是支持多文件编辑和项目级上下文。提示词管理用一个简单的Markdown文件维护你的提示词模板按PR类型分类。CI确保lint、类型检查、单元测试能在5分钟内跑完。PR模板在PR模板里加入变更摘要和验证步骤两个必填项让AI自动填充。合并策略如果团队规模允许开启auto-merge让通过所有检查的PR自动合并。这套配置不需要额外的付费工具大部分都是现有工具的重新组合。关键是工作流的改变不是工具的改变。7.3 一个具体的起步练习如果你想找一个具体的切入点我建议从补测试开始。原因很简单补测试是纯增量变更不会破坏现有逻辑风险极低同时它能让你快速熟悉写提示词、看AI输出、调整提示词这个循环。具体做法是找一个测试覆盖率不高的模块让AI分析哪些函数缺少测试然后针对每个缺失的测试场景开一个独立的PR。一个模块可能能开出十几个测试PR每个PR只加一个或几个测试用例。跑完这一轮你对高频小PR的节奏就有感觉了。等你对补测试的节奏熟悉了再逐步扩展到bug修复、小功能开发、重构等场景。每一步都保持PR小、验证快、合并顺的原则不要贪多。这套模式的核心不是AI有多强而是你把工作流设计得让AI能发挥出它的能力。工具是死的工作流是活的。同样是用Cursor有人一天开3个PR有人一天开30个差距不在工具在于怎么拆任务、怎么设约束、怎么建验证闭环。这个道理放在任何AI辅助编程的场景里都成立。