1. 一个月2000个PR背后的工作方式重构第一次看到“每月交付2000个PR”这个数字我的反应和大多数人一样要么是标题党要么是把依赖机器人自动升级的版本号提交也算进去了。但仔细拆解 Lauren Tan 在 GrokBot 团队的工作模式之后我发现这个数字虽然夸张却有一套完全自洽的逻辑支撑。它的核心不在于“手速快”而在于把AI Agent 深度嵌入了软件交付的每一个环节让人的角色从“写代码的人”变成“审代码、定方向、做决策的人”。先把概念说清楚。PR 就是 Pull Request代码合并请求是团队协作开发里最基本的交付单元。一个 PR 通常对应一个小功能、一个修复或者一次重构。传统模式下一个熟练工程师一周能提十几个高质量 PR 已经算高产一个月 2000 个意味着平均每天 60 多个靠人工敲键盘是不可能完成的。所以这个数字的本质是AI 承担了绝大部分重复性编码和机械性修改人只负责判断和把关。这套模式适合谁参考我认为有三类人收益最大。第一类是独立开发者和小团队人手少但想维持高频迭代第二类是团队里的技术负责人需要在不增加人头的前提下提升整体吞吐第三类是想把 AI 编程工具真正用起来、而不是停留在“让它写个冒泡排序”阶段的开发者。如果你只是偶尔用 AI 补全几行代码那这篇文章里的很多思路可能暂时用不上但只要你开始认真考虑“让 AI 参与真实项目交付”下面的内容就有直接参考价值。需要提前说明的是Lauren Tan 的具体工具链配置属于团队内部实践公开信息有限。下面涉及的操作步骤、参数设置和流程设计是我结合 Cursor、pstack 这类工具在真实项目中的常见用法以及 AI Agent 协作的通用实践做的合理补全。我会明确区分哪些是已知事实、哪些是基于经验的推断避免把推测当成定论。2. 为什么是 AI Agent 而不是简单的代码补全2.1 从“补全”到“代理”的本质区别很多人对 AI 编程的理解还停留在“输入注释它补全代码”的阶段。这种用法效率提升有限因为它只解决了“打字”这一环而真实开发中打字可能只占 20% 的时间剩下 80% 花在理解需求、定位问题、跑测试、改配置、写文档、处理 review 意见上。AI Agent 和代码补全的根本区别在于Agent 能自主执行多步骤任务而补全只能响应单点请求。举个具体例子。你告诉补全工具“写一个解析 CSV 的函数”它给你一段代码你还得自己找地方粘贴、调整导入、写测试、跑一遍看有没有报错。而 Agent 模式下你说“给这个模块加一个 CSV 解析功能要求支持大文件流式读取并补上单元测试”它会自己去读现有代码结构、判断该放在哪个文件、写实现、写测试、运行测试、根据报错自动修复最后把改动整理成一个 PR 交给你审。这个差别是数量级的也是 2000 个 PR 能成立的底层原因。2.2 为什么选 Cursor 作为主力工具在众多 AI 编程工具里Cursor 之所以成为这类高频交付场景的主力有几个很实际的原因。第一是它对整个代码库的索引能力Agent 能理解项目上下文而不是只看当前打开的文件。第二是它的 Agent 模式支持多轮自主执行能连续完成“读代码—改代码—跑命令—看结果—再改”的循环。第三是它对 Git 工作流的集成比较顺改完能直接生成 diff、提交、开 PR减少了大量手工操作。pstack 在这个体系里扮演的是另一类角色。如果说 Cursor 是“写代码的 Agent”pstack 更偏向于任务编排和流程管理把多个 Agent 的输出串起来管理它们之间的依赖和状态。这种组合的思路是让每个工具只做自己最擅长的事用流程把它们粘起来而不是指望一个工具包打天下。2.3 一个关键认知PR 的粒度要变小2000 个 PR 能成立还有一个容易被忽略的前提PR 的粒度必须足够小。如果一个 PR 动辄改几百行、涉及多个模块那 review 成本会高到无法承受数量也上不去。Lauren 的模式里PR 普遍是“单一意图”的——一个 PR 只做一件事可能只是改一个配置、修一个边界条件、加一个测试用例。这种小 PR 的好处是AI 生成快、人 review 快、出问题回滚也快。提示小 PR 不是把大改动硬拆成碎片而是让每个 PR 有清晰、独立的意图。如果一个 PR 的标题里出现了“and”通常说明它该拆了。3. 核心工作流的拆解与实操要点3.1 任务分解把大需求切成 Agent 能吃的块整套流程的第一步也是最考验人的一步是任务分解。AI Agent 再强也没法直接消化“把用户系统重构一遍”这种模糊的大需求。你需要把它切成 Agent 能独立完成、且能验证结果的小任务。我的经验是一个好的 Agent 任务应该满足三个条件目标明确、边界清晰、结果可验证。具体怎么切我通常按“一个任务对应一个可测试的行为变化”来分。比如“重构用户系统”可以拆成把用户模型拆成独立文件、给用户查询加索引、把密码校验抽成独立函数、给登录接口补测试、更新相关文档。每一个都是独立 PRAgent 做完一个你审一个而不是攒一堆一起审。这里有个实操心得分解的粒度宁小勿大。我踩过的坑是一开始给 Agent 的任务太大它做到一半跑偏了或者改了一堆不该改的文件review 起来比自己做还累。后来我把任务切到“一个 PR 只改一个文件或一个函数”的粒度Agent 的成功率明显上升review 也快了很多。3.2 提示词设计让 Agent 少走弯路的几个原则Agent 的输出质量很大程度上取决于你给它的指令质量。我总结了几条在实际项目里验证有效的提示词原则。第一条是给上下文不给命令。与其说“修复这个 bug”不如说“这个函数在输入为空数组时会抛异常期望返回空列表请修复并补一个测试”。前者 Agent 要猜后者 Agent 直接干。第二条是明确约束条件。比如“不要改动这个文件的导出接口”“保持现有代码风格”“不要引入新的第三方依赖”。这些约束能防止 Agent 自作主张减少 review 时的意外。第三条是要求它自验证。在指令里加上“改完后运行相关测试如果失败请自行修复直到通过”。这一步能过滤掉大量低级错误让交到你手上的 PR 质量高很多。第四条是让它解释改动。要求 Agent 在 PR 描述里说明“改了什么、为什么这么改、有没有副作用”。这不仅方便你 review也能在它理解错的时候快速暴露问题。3.3 并行处理同时跑多个 Agent 的关键2000 个 PR 的吞吐量靠串行是做不到的。真实场景里一定是多个 Agent 并行工作。但并行有个前提任务之间不能有依赖冲突。如果两个 Agent 同时改同一个文件合并时必然打架。我的做法是在分解任务时就标注每个任务涉及的文件范围把不重叠的任务分到同一批并行执行有重叠的排到不同批次。Cursor 的 Agent 模式支持同时开多个会话每个会话处理一个独立任务。pstack 这类工具则可以用来管理这些会话的状态避免你手动跟踪哪个跑完了、哪个卡住了。注意并行 Agent 的数量不是越多越好。我实测下来同时跑 3 到 5 个比较舒服再多的话 review 会变成瓶颈而且上下文切换的成本会吃掉并行带来的收益。3.4 人工 review不可省略的质量闸门这是整套流程里最不能省的一环。AI 生成的代码再顺也可能有逻辑漏洞、边界问题、安全隐患。Lauren 的模式里人的核心价值就体现在 review 上。我的 review 习惯是分三层看先看意图对不对再看实现有没有坑最后看测试够不够。第一层看意图就是快速扫一遍 diff判断这个改动是不是真的解决了要解决的问题有没有跑偏。第二层看实现重点看边界条件、错误处理、并发安全这些 AI 容易忽略的地方。第三层看测试确认新增的测试真的覆盖了改动点而不是写了个永远通过的假测试。review 的速度也很关键。小 PR 的好处在这里体现得淋漓尽致一个只改十几行的 PR我通常一两分钟就能审完。如果一天审几十个累积起来也就是一两个小时完全可控。4. 完整实操流程从需求到合并的每一步4.1 环境准备与工具配置先把基础环境搭起来。Cursor 的安装和基础配置网上教程很多这里只说几个和这套工作流强相关的设置。第一是开启代码库索引让 Agent 能理解整个项目而不是只看当前文件。第二是配置好 Git 集成确保 Agent 能直接创建分支、提交、开 PR。第三是把常用的测试命令、构建命令配成快捷方式方便 Agent 调用。关于中文设置如果你习惯中文界面Cursor 支持在设置里切换语言具体路径在设置的语言选项里选中文后重启即可。这个不影响功能纯粹是使用习惯问题。pstack 的配置重点在于任务队列和状态管理。你需要定义好任务的状态流转比如“待处理—进行中—待 review—已合并”让每个 Agent 的输出都有明确的归属。这样即使同时跑多个任务你也能一眼看清全局。4.2 一个真实任务的完整执行记录我拿一个实际做过的任务来演示。需求是“给订单查询接口加上分页支持”。按流程走下来是这样的。第一步分解任务。我把它拆成三个独立 PR一是给查询函数加分页参数二是给接口层加参数校验三是补分页相关的测试。三个任务涉及的文件不重叠可以并行。第二步写提示词。给第一个 Agent 的指令是“在 order_query 函数中增加 page 和 page_size 两个参数默认 page1、page_size20实现基于 offset 的分页逻辑保持现有返回结构不变改完运行相关测试。”给第二个 Agent 的指令是“在订单查询接口的入参校验里增加 page 和 page_size 的校验page 必须为正整数page_size 范围 1 到 100超出范围返回参数错误。”第三步并行执行。两个 Agent 同时跑我在旁边处理其他事情。大概几分钟后两个 PR 都生成了。第四步review。第一个 PR 的实现没问题但 Agent 把默认 page_size 写成了 10和我要求的 20 不一致我改了一下。第二个 PR 的校验逻辑正确但错误信息不够清晰我让它重新生成了一版更明确的提示。第五步合并。两个 PR 都通过后合并然后第三个测试任务基于合并后的代码生成避免测试和实现不一致。整个过程从开始到三个 PR 全部合并大概花了不到半小时其中我实际动手的时间可能只有十分钟。这就是高频交付的真实节奏。4.3 参数选择与配置的计算逻辑分页这个例子里有个参数值得展开说page_size 的上限为什么设 100。这不是拍脑袋定的而是基于实际负载算出来的。假设单条订单记录平均 2KB100 条就是 200KB加上 JSON 序列化的开销单次响应大概在 300KB 左右。这个量级在大多数网络环境下响应时间可控也不会给数据库造成太大压力。如果设成 1000单次响应可能到 3MB既拖慢接口也容易触发超时。类似的参数计算在每个任务里都会遇到。我的习惯是凡是涉及数值参数都在提示词里写清楚取值依据让 Agent 按这个逻辑来而不是随便填一个。这样生成的代码更贴近生产要求减少后续返工。5. 常见问题与排查技巧实录5.1 Agent 跑偏了怎么办这是最常见的问题。Agent 有时候会“过度发挥”你让它改一个函数它顺手把整个文件重构了。遇到这种情况我的处理方式是先看它的改动有没有价值有价值就保留并单独开 PR没价值就回滚重来。回滚的时候在提示词里加上更严格的约束比如“只修改指定函数不要改动其他任何代码”。预防胜于治疗。我现在写提示词都会加一句“改动范围严格限制在 XX 文件/函数内”这一句能挡掉大部分跑偏。5.2 生成的测试是假测试怎么办AI 写的测试有时候会“迎合”实现比如断言写得特别宽松或者干脆测了个无关的东西。识别假测试的方法是把实现改坏看测试会不会失败。如果改坏了测试还通过那这个测试就是无效的。我 review 测试时经常做这个动作虽然多花几秒但能挡住很多隐患。5.3 多个 Agent 冲突了怎么处理并行任务如果涉及同一文件合并时必然冲突。我的做法是在任务分解阶段就做好文件级隔离从源头避免冲突。如果实在避不开就让相关任务串行执行后一个基于前一个的结果来做。冲突解决的成本远高于串行等待的成本这笔账要算清楚。5.4 常见问题速查表问题现象可能原因处理方式Agent 改动范围过大提示词约束不足加“只改指定范围”约束回滚重来测试永远通过断言过宽或测错对象改坏实现验证测试有效性并行任务合并冲突任务涉及同一文件分解阶段做文件隔离或改串行Agent 反复修不好任务粒度过大或描述模糊拆小任务补充上下文和约束review 积压并行数过多降到 3 到 5 个控制节奏5.5 几个踩坑之后的经验第一个经验是不要信任 Agent 的“完成”状态。它说改完了不代表真的改对了。每次都要自己跑一遍测试确认。第二个经验是保留人工兜底的能力。Agent 再强也有搞不定的时候关键路径上的代码我仍然会自己过一遍。第三个经验是定期清理任务队列。并行任务多了容易乱我习惯每天收工前把队列清空没跑完的要么推进要么取消不留隔夜账。6. 这套模式能复制到什么程度回到最初的问题2000 个 PR 这个数字普通人能复制吗我的判断是绝对数字不必强求但工作方式的转变是可以完全复制的。你不需要追求每天 60 个 PR但如果你能把 AI Agent 真正嵌入日常开发把重复性工作交给它把精力集中在判断和决策上你的交付效率提升三到五倍是完全现实的。这套模式的核心不是某个工具而是一种分工思路人负责定义问题和验收结果AI 负责执行过程。工具会迭代Cursor 会更新pstack 会变化但这个分工逻辑是稳定的。我自己的体会是用了这套方式之后我花在“敲代码”上的时间大幅减少花在“想清楚要做什么”和“检查做得对不对”上的时间增加了。表面上看是变“懒”了实际上是把自己的时间用在了更值钱的地方。最后分享一个我一直在用的小技巧每次 Agent 交付一个 PR我都会在合并前问自己一句“如果这段代码是我写的我会怎么改”。这个习惯能让我保持对代码质量的敏感度不至于因为 AI 写得太顺就放松标准。毕竟PR 的数量是手段交付的质量才是目的。
AI Agent 驱动的高频 PR 交付：从代码补全到自主代理的工程实践
1. 一个月2000个PR背后的工作方式重构第一次看到“每月交付2000个PR”这个数字我的反应和大多数人一样要么是标题党要么是把依赖机器人自动升级的版本号提交也算进去了。但仔细拆解 Lauren Tan 在 GrokBot 团队的工作模式之后我发现这个数字虽然夸张却有一套完全自洽的逻辑支撑。它的核心不在于“手速快”而在于把AI Agent 深度嵌入了软件交付的每一个环节让人的角色从“写代码的人”变成“审代码、定方向、做决策的人”。先把概念说清楚。PR 就是 Pull Request代码合并请求是团队协作开发里最基本的交付单元。一个 PR 通常对应一个小功能、一个修复或者一次重构。传统模式下一个熟练工程师一周能提十几个高质量 PR 已经算高产一个月 2000 个意味着平均每天 60 多个靠人工敲键盘是不可能完成的。所以这个数字的本质是AI 承担了绝大部分重复性编码和机械性修改人只负责判断和把关。这套模式适合谁参考我认为有三类人收益最大。第一类是独立开发者和小团队人手少但想维持高频迭代第二类是团队里的技术负责人需要在不增加人头的前提下提升整体吞吐第三类是想把 AI 编程工具真正用起来、而不是停留在“让它写个冒泡排序”阶段的开发者。如果你只是偶尔用 AI 补全几行代码那这篇文章里的很多思路可能暂时用不上但只要你开始认真考虑“让 AI 参与真实项目交付”下面的内容就有直接参考价值。需要提前说明的是Lauren Tan 的具体工具链配置属于团队内部实践公开信息有限。下面涉及的操作步骤、参数设置和流程设计是我结合 Cursor、pstack 这类工具在真实项目中的常见用法以及 AI Agent 协作的通用实践做的合理补全。我会明确区分哪些是已知事实、哪些是基于经验的推断避免把推测当成定论。2. 为什么是 AI Agent 而不是简单的代码补全2.1 从“补全”到“代理”的本质区别很多人对 AI 编程的理解还停留在“输入注释它补全代码”的阶段。这种用法效率提升有限因为它只解决了“打字”这一环而真实开发中打字可能只占 20% 的时间剩下 80% 花在理解需求、定位问题、跑测试、改配置、写文档、处理 review 意见上。AI Agent 和代码补全的根本区别在于Agent 能自主执行多步骤任务而补全只能响应单点请求。举个具体例子。你告诉补全工具“写一个解析 CSV 的函数”它给你一段代码你还得自己找地方粘贴、调整导入、写测试、跑一遍看有没有报错。而 Agent 模式下你说“给这个模块加一个 CSV 解析功能要求支持大文件流式读取并补上单元测试”它会自己去读现有代码结构、判断该放在哪个文件、写实现、写测试、运行测试、根据报错自动修复最后把改动整理成一个 PR 交给你审。这个差别是数量级的也是 2000 个 PR 能成立的底层原因。2.2 为什么选 Cursor 作为主力工具在众多 AI 编程工具里Cursor 之所以成为这类高频交付场景的主力有几个很实际的原因。第一是它对整个代码库的索引能力Agent 能理解项目上下文而不是只看当前打开的文件。第二是它的 Agent 模式支持多轮自主执行能连续完成“读代码—改代码—跑命令—看结果—再改”的循环。第三是它对 Git 工作流的集成比较顺改完能直接生成 diff、提交、开 PR减少了大量手工操作。pstack 在这个体系里扮演的是另一类角色。如果说 Cursor 是“写代码的 Agent”pstack 更偏向于任务编排和流程管理把多个 Agent 的输出串起来管理它们之间的依赖和状态。这种组合的思路是让每个工具只做自己最擅长的事用流程把它们粘起来而不是指望一个工具包打天下。2.3 一个关键认知PR 的粒度要变小2000 个 PR 能成立还有一个容易被忽略的前提PR 的粒度必须足够小。如果一个 PR 动辄改几百行、涉及多个模块那 review 成本会高到无法承受数量也上不去。Lauren 的模式里PR 普遍是“单一意图”的——一个 PR 只做一件事可能只是改一个配置、修一个边界条件、加一个测试用例。这种小 PR 的好处是AI 生成快、人 review 快、出问题回滚也快。提示小 PR 不是把大改动硬拆成碎片而是让每个 PR 有清晰、独立的意图。如果一个 PR 的标题里出现了“and”通常说明它该拆了。3. 核心工作流的拆解与实操要点3.1 任务分解把大需求切成 Agent 能吃的块整套流程的第一步也是最考验人的一步是任务分解。AI Agent 再强也没法直接消化“把用户系统重构一遍”这种模糊的大需求。你需要把它切成 Agent 能独立完成、且能验证结果的小任务。我的经验是一个好的 Agent 任务应该满足三个条件目标明确、边界清晰、结果可验证。具体怎么切我通常按“一个任务对应一个可测试的行为变化”来分。比如“重构用户系统”可以拆成把用户模型拆成独立文件、给用户查询加索引、把密码校验抽成独立函数、给登录接口补测试、更新相关文档。每一个都是独立 PRAgent 做完一个你审一个而不是攒一堆一起审。这里有个实操心得分解的粒度宁小勿大。我踩过的坑是一开始给 Agent 的任务太大它做到一半跑偏了或者改了一堆不该改的文件review 起来比自己做还累。后来我把任务切到“一个 PR 只改一个文件或一个函数”的粒度Agent 的成功率明显上升review 也快了很多。3.2 提示词设计让 Agent 少走弯路的几个原则Agent 的输出质量很大程度上取决于你给它的指令质量。我总结了几条在实际项目里验证有效的提示词原则。第一条是给上下文不给命令。与其说“修复这个 bug”不如说“这个函数在输入为空数组时会抛异常期望返回空列表请修复并补一个测试”。前者 Agent 要猜后者 Agent 直接干。第二条是明确约束条件。比如“不要改动这个文件的导出接口”“保持现有代码风格”“不要引入新的第三方依赖”。这些约束能防止 Agent 自作主张减少 review 时的意外。第三条是要求它自验证。在指令里加上“改完后运行相关测试如果失败请自行修复直到通过”。这一步能过滤掉大量低级错误让交到你手上的 PR 质量高很多。第四条是让它解释改动。要求 Agent 在 PR 描述里说明“改了什么、为什么这么改、有没有副作用”。这不仅方便你 review也能在它理解错的时候快速暴露问题。3.3 并行处理同时跑多个 Agent 的关键2000 个 PR 的吞吐量靠串行是做不到的。真实场景里一定是多个 Agent 并行工作。但并行有个前提任务之间不能有依赖冲突。如果两个 Agent 同时改同一个文件合并时必然打架。我的做法是在分解任务时就标注每个任务涉及的文件范围把不重叠的任务分到同一批并行执行有重叠的排到不同批次。Cursor 的 Agent 模式支持同时开多个会话每个会话处理一个独立任务。pstack 这类工具则可以用来管理这些会话的状态避免你手动跟踪哪个跑完了、哪个卡住了。注意并行 Agent 的数量不是越多越好。我实测下来同时跑 3 到 5 个比较舒服再多的话 review 会变成瓶颈而且上下文切换的成本会吃掉并行带来的收益。3.4 人工 review不可省略的质量闸门这是整套流程里最不能省的一环。AI 生成的代码再顺也可能有逻辑漏洞、边界问题、安全隐患。Lauren 的模式里人的核心价值就体现在 review 上。我的 review 习惯是分三层看先看意图对不对再看实现有没有坑最后看测试够不够。第一层看意图就是快速扫一遍 diff判断这个改动是不是真的解决了要解决的问题有没有跑偏。第二层看实现重点看边界条件、错误处理、并发安全这些 AI 容易忽略的地方。第三层看测试确认新增的测试真的覆盖了改动点而不是写了个永远通过的假测试。review 的速度也很关键。小 PR 的好处在这里体现得淋漓尽致一个只改十几行的 PR我通常一两分钟就能审完。如果一天审几十个累积起来也就是一两个小时完全可控。4. 完整实操流程从需求到合并的每一步4.1 环境准备与工具配置先把基础环境搭起来。Cursor 的安装和基础配置网上教程很多这里只说几个和这套工作流强相关的设置。第一是开启代码库索引让 Agent 能理解整个项目而不是只看当前文件。第二是配置好 Git 集成确保 Agent 能直接创建分支、提交、开 PR。第三是把常用的测试命令、构建命令配成快捷方式方便 Agent 调用。关于中文设置如果你习惯中文界面Cursor 支持在设置里切换语言具体路径在设置的语言选项里选中文后重启即可。这个不影响功能纯粹是使用习惯问题。pstack 的配置重点在于任务队列和状态管理。你需要定义好任务的状态流转比如“待处理—进行中—待 review—已合并”让每个 Agent 的输出都有明确的归属。这样即使同时跑多个任务你也能一眼看清全局。4.2 一个真实任务的完整执行记录我拿一个实际做过的任务来演示。需求是“给订单查询接口加上分页支持”。按流程走下来是这样的。第一步分解任务。我把它拆成三个独立 PR一是给查询函数加分页参数二是给接口层加参数校验三是补分页相关的测试。三个任务涉及的文件不重叠可以并行。第二步写提示词。给第一个 Agent 的指令是“在 order_query 函数中增加 page 和 page_size 两个参数默认 page1、page_size20实现基于 offset 的分页逻辑保持现有返回结构不变改完运行相关测试。”给第二个 Agent 的指令是“在订单查询接口的入参校验里增加 page 和 page_size 的校验page 必须为正整数page_size 范围 1 到 100超出范围返回参数错误。”第三步并行执行。两个 Agent 同时跑我在旁边处理其他事情。大概几分钟后两个 PR 都生成了。第四步review。第一个 PR 的实现没问题但 Agent 把默认 page_size 写成了 10和我要求的 20 不一致我改了一下。第二个 PR 的校验逻辑正确但错误信息不够清晰我让它重新生成了一版更明确的提示。第五步合并。两个 PR 都通过后合并然后第三个测试任务基于合并后的代码生成避免测试和实现不一致。整个过程从开始到三个 PR 全部合并大概花了不到半小时其中我实际动手的时间可能只有十分钟。这就是高频交付的真实节奏。4.3 参数选择与配置的计算逻辑分页这个例子里有个参数值得展开说page_size 的上限为什么设 100。这不是拍脑袋定的而是基于实际负载算出来的。假设单条订单记录平均 2KB100 条就是 200KB加上 JSON 序列化的开销单次响应大概在 300KB 左右。这个量级在大多数网络环境下响应时间可控也不会给数据库造成太大压力。如果设成 1000单次响应可能到 3MB既拖慢接口也容易触发超时。类似的参数计算在每个任务里都会遇到。我的习惯是凡是涉及数值参数都在提示词里写清楚取值依据让 Agent 按这个逻辑来而不是随便填一个。这样生成的代码更贴近生产要求减少后续返工。5. 常见问题与排查技巧实录5.1 Agent 跑偏了怎么办这是最常见的问题。Agent 有时候会“过度发挥”你让它改一个函数它顺手把整个文件重构了。遇到这种情况我的处理方式是先看它的改动有没有价值有价值就保留并单独开 PR没价值就回滚重来。回滚的时候在提示词里加上更严格的约束比如“只修改指定函数不要改动其他任何代码”。预防胜于治疗。我现在写提示词都会加一句“改动范围严格限制在 XX 文件/函数内”这一句能挡掉大部分跑偏。5.2 生成的测试是假测试怎么办AI 写的测试有时候会“迎合”实现比如断言写得特别宽松或者干脆测了个无关的东西。识别假测试的方法是把实现改坏看测试会不会失败。如果改坏了测试还通过那这个测试就是无效的。我 review 测试时经常做这个动作虽然多花几秒但能挡住很多隐患。5.3 多个 Agent 冲突了怎么处理并行任务如果涉及同一文件合并时必然冲突。我的做法是在任务分解阶段就做好文件级隔离从源头避免冲突。如果实在避不开就让相关任务串行执行后一个基于前一个的结果来做。冲突解决的成本远高于串行等待的成本这笔账要算清楚。5.4 常见问题速查表问题现象可能原因处理方式Agent 改动范围过大提示词约束不足加“只改指定范围”约束回滚重来测试永远通过断言过宽或测错对象改坏实现验证测试有效性并行任务合并冲突任务涉及同一文件分解阶段做文件隔离或改串行Agent 反复修不好任务粒度过大或描述模糊拆小任务补充上下文和约束review 积压并行数过多降到 3 到 5 个控制节奏5.5 几个踩坑之后的经验第一个经验是不要信任 Agent 的“完成”状态。它说改完了不代表真的改对了。每次都要自己跑一遍测试确认。第二个经验是保留人工兜底的能力。Agent 再强也有搞不定的时候关键路径上的代码我仍然会自己过一遍。第三个经验是定期清理任务队列。并行任务多了容易乱我习惯每天收工前把队列清空没跑完的要么推进要么取消不留隔夜账。6. 这套模式能复制到什么程度回到最初的问题2000 个 PR 这个数字普通人能复制吗我的判断是绝对数字不必强求但工作方式的转变是可以完全复制的。你不需要追求每天 60 个 PR但如果你能把 AI Agent 真正嵌入日常开发把重复性工作交给它把精力集中在判断和决策上你的交付效率提升三到五倍是完全现实的。这套模式的核心不是某个工具而是一种分工思路人负责定义问题和验收结果AI 负责执行过程。工具会迭代Cursor 会更新pstack 会变化但这个分工逻辑是稳定的。我自己的体会是用了这套方式之后我花在“敲代码”上的时间大幅减少花在“想清楚要做什么”和“检查做得对不对”上的时间增加了。表面上看是变“懒”了实际上是把自己的时间用在了更值钱的地方。最后分享一个我一直在用的小技巧每次 Agent 交付一个 PR我都会在合并前问自己一句“如果这段代码是我写的我会怎么改”。这个习惯能让我保持对代码质量的敏感度不至于因为 AI 写得太顺就放松标准。毕竟PR 的数量是手段交付的质量才是目的。
