先说个数字：2000 个 PR。不是一年，是一个月。GrokBot 核心成员 Lauren Tan 这个月又交付了这么多 Pull Request，从创建到合入全程亲自盯。平均每个工作日 70 个左右，意味着如果她完全靠手写代码、手动提交流程，一天 24 小时都不够用。她给我的感觉是，工作早就不是“写代码”了，而是“设计流水线”，把每一个可以交给 AI 的环节都交出去，自己只守住最核心的判断。

这篇文章就从她的工作方式出发，拆解这套 AI 辅助下的 PR 流水线到底是怎么搭的。我会把关键动作、提示词思路、自动化脚本和你可能踩的坑全部写出来。不管你是独立开发者还是团队骨干，都能直接拿几招去调整自己的开发流。下面所有内容都以 GitHub 工作流为背景，其他代码托管平台思路类似。

1. 2000个PR不是写出来的，是“流”出来的

1.1 她把每个任务都拆到“足够小”

我们先解决一个根本问题：为什么是 2000 个 PR，不是 200 个？因为她的团队把“需求”切得非常碎。一个用户反馈，可能被拆成 3 到 5 个小任务，每个任务对应一个独立 PR。比如一个登录报错，会拆成“修复空用户名导致的崩溃”“补充对应的边界测试”“更新错误提示文案”三个 PR。每个 PR 改动可能只有几十行，但彼此独立、能单独测试、单独回滚。

这不是为了凑数量，而是为了降低风险。一个 2000 行的巨型 PR，reviewer 需要半小时才能读懂，测试要跑很久，冲突概率也高。而当 PR 小到只需要几分钟就能 review 时，整个团队的反应速度就不一样了。Lauren 在分享里提到一个原则：如果一个 PR 的描述比代码还长，那就不是好 PR。小 PR 也让 AI 更容易上手——它只需要聚焦一个很小的范围，不会因为上下文太宽而跑偏。

1.2 核心是“流水线”而不是“手速”

传统印象里，能交付这么多 PR 的人一定是键盘飞起、脑力惊人的强人。但她的真实状态是：大多数代码由 AI 生成，她负责审查和决策。她每天的工作流程像一条流水线，而不是一个人单挑所有任务。

早上打开电脑，AI 已经把昨晚所有新 issue、失败测试、依赖更新汇总成一份待办清单。她花半小时看清单，勾出哪些需要人来判断，哪些可以直接交给 agent。剩下时间就是处理那些只有人能拍板的事，比如跨模块的架构调整、有争议的交互逻辑。等到下午，AI agent 已经把一批又一批的小 PR 推上来，她只需要做一次整体的 review，把不合理的打回重做，质量没问题的点一下合并。

这个流程和传统“一个人从头到尾写完一个功能再提一个 PR”完全不同。关键不在于生成速度，而在于定义清楚每个环节的输入和输出。AI 不是自动写代码的魔法棒，它是流水线上最听话的工人，但你需要把工位、工具和质检标准提前摆好。

为了更直观，我放一个对比表格，这基本就是传统单人开发流和 AI 辅助流水线的区别：

看到这个表你应该明白，她的 2000 个 PR 十有八九是设计出来的。这个思路就一句话：把工作切成小份，给每份配上 AI 工具和自动化闸门。没有这个底座，后面谈提示词和 Agent 都是空话。

1.3 小 PR 协作带来的副作用：冲突少了，复盘也快

可能有人担心，PR 拆得这么碎，会不会让分支之间冲突变多？实际正好相反。大 PR 因为长期不合并，和主干渐行渐远，冲突才最多。小 PR 从创建到合入往往在一天内完成，分支存在时间短，代码漂移很小。团队里真正痛苦的“合并地狱”，高概率是那些几周没动的大型分支。

另一个好处是复盘效率。当你想查一个线上问题，比如“为什么某个接口突然变慢”，如果最近的 PR 都很小，你很快就能定位是哪一个改动引入的回归。如果是几千行的大 PR，你可能要在一堆改动里翻很久，还容易漏掉关键点。这个视角特别适合 AI 辅助时代：AI 制造了很多小改动，而这些小改动本身就是可追溯的黑盒。

2. 用AI“代写”代码的正确姿势

2.1 给 AI 的指令要像“验收单”而不是“聊天”

很多人用 AI 写代码，习惯直接说“帮我写一个处理订单的类”。这个粒度太大了，AI 写出来的东西往往到处都是假设，你要是不改根本跑不起来。Lauren 的做法是：先把需求转成一份验收单，再让 AI 照着做。

比如一个简单的功能：“给用户信息接口增加一个可选参数 include_orders，当它为 true 时返回该用户的最近订单列表。”她会先拆解成验收项：

• 参数默认值为 false，不改变现有行为
• 响应结构增加 orders 字段，格式为数组
• 关联数据库查询，只取最近五条
• 补充单元测试覆盖默认值、true 和非法值三种情况

然后把这个验收单原样贴给 AI，要求实现代码和对应测试。实测下来，这样生成的代码命中率比直接问要高一大截。原因是AI 在没有明确边界时，会用自己的“平均经验”去填补空白，而这些空白往往不符合你的代码风格。验收单相当于把边界画死了，它只需要做填充，天马行空的概率自然就低了。

2.2 先写测试，再写实现，让 AI 被“钉”在正确轨道上

这是一个非常关键的习惯：先让 AI 生成测试，再让它生成实现，最后跑测试验证。听起来有点绕，但在她的工作流里，测试就是“质检员”。AI 生成代码经常出现“看起来没问题，一跑就崩”，因为它的输出是基于概率的，而不是真正的逻辑推理。可如果测试先行，错误就会被约束在一个小范围内，不会扩散成整个模块重写。

具体操作是这样的：

1. 你把验收单给 AI，让它先写出单元测试。
2. 人工扫一眼测试，确认断言符合预期（这一步很重要，AI 有时会写出自圆其说的弱测试）。
3. 再让 AI 根据测试补实现代码。
4. 本地跑测试，红了就把它跑出的错误原样贴回给 AI，让它修。

这里的关键是第 4 步的循环。不要让 AI 凭空猜错误，把实际报错信息作为它的下一个输入。改造后的错误能大幅提高修复准确率。我试过好多次，直接把 pytest 的输出贴进去，它甚至能自己定位到具体行数。这个反馈循环是我们在纯手写时代并不会刻意设计的工作方式，但它恰恰是 AI 辅助开发最值钱的部分。

2.3 设置边界：别让 AI 直接改你不懂的地方

很多初学者希望 AI 一把梭把整个项目都改完，但 Lauren 的经验正好相反：你越不了解一个模块，越不能让 AI 直接改。因为 AI 的生成结果需要人来判断，如果你看不懂结果，就无法判断它对错，这个环节就断了。所以她不会把核心业务逻辑交给 AI 全权处理，而是先自己理解清楚结构，再把重复性、机械性部分丢出去。

比如“升级依赖版本后修复所有报错”这类工作，非常适合 AI 做，因为错误信息明确、修改模式固定。再比如“把某个工具函数从 A 文件移到 B 文件并更新所有 import”也适合。但如果是“重新设计订单状态机的转换关系”，她会自己写，因为这里涉及大量隐性业务规则，AI 无法从概率中学会。

这一节她特别强调：AI 不是替代你思考，而是替代你走路。你把路线定好，它负责执行每一步。这个观念决定了你使用 AI 的上限。同样一个模型，有人拿来开发云成本缩减工具，有人只能拿来生成学位论文模板，差距往往不在模型本身，而在你对任务的拆解能力。

2.4 两个提示词写得不一样，结果差很远

为了让你直观感受到差距，我写两个“让 AI 修改工具函数”的 prompt 对比。第一个是自然语言聊天式：

请帮我优化一下 util.py 里的函数，让它更快。

AI 大概率会给你重写整个函数，甚至换掉你没打算改变的算法。给你的结果看起来优化了，但可能引入你没预期到的副作用。第二次换成验收单式：

util.py 里的 parse_date 函数需要优化，当前瓶颈是大量重复正则编译。请保留原函数的输入输出类型和业务语义，只修改实现方式。要求：把正则字符串在模块层编译一次；加入对 ISO 格式字符串的快速路径；新增基准测试证明至少快 30%；不得修改 parse_date 的签名。

这样它就会在指定边界内操作。前者是让 AI 替你做决定，后者是让 AI 在划好的跑道里执行。Lauren 在工作里几乎只用第二种 prompt，因为每一个输出都要对最终 diff 负责。这个原则在团队里贯彻下去，就能从源头上减少 AI 生成的返工。

3. 把 PR 的“体力活”全部自动化

3.1 一个 PR 从 10 分钟压缩到 30 秒，只靠一份模板

写代码只占 PR 工作的一部分，真正繁琐的是描述、标签、关联 issue、截图这些“体力活”。Lauren 的团队用一份标准模板把这些自动生成。模板长这样：

## 背景 这个 PR 解决的问题是：__（由 issue/用户反馈自动带入）__ ## 改动内容 - 修改了 __（文件列表自动生成）__ - 主要逻辑变更：__（由 AI 根据 diff 总结）__ ## 测试 - [ ] 单元测试已补充 - [ ] 本地测试全部通过 - [ ] 相关集成测试通过 ## 风险 - 影响范围：__（低/中/高，AI 判断）__ - 是否需要人工重点 review：__（是/否）__

有了模板之后，每个 PR 的描述都不是跪着写完的。AI agent 会读取你这次改动涉及的文件和历史提交信息，把模板里的空填好。你只需要做两件小事：检查描述是否准确，补一张必要的前后截图。整个 PR 创建过程从过去 10 分钟，压缩到不到 30 秒。

这里要提醒一句：不要小看 PR 描述。一个清晰的 PR 描述是给未来的人看的。三个月后你回来看这段代码，根本想不起来当时为什么这么改，PR 描述就是那一刻的备忘。所以“只要代码对，描述随便”的心态务必扔掉。我在项目里见过太多次，因为描述缺失，后续排障时整个团队对着 git log 猜来猜去，这种内耗才是真正的隐形浪费。

3.2 用一行命令批量创建几十个 PR

如果你是 GitHub 重度用户，一定用过ghCLI。Lauren 的工作流里，它和 AI 结合之后，能实现“批量生产 PR”。她有一个脚本，扫描本地所有以ai/前缀开头的分支，每个分支都自动创建一个 PR，并关联对应 issue。命令大概长这样：

gh pr create \ --base main \ --head "$BRANCH" \ --title "fix: $SUMMARY" \ --body "$DESCRIPTION" \ --label "ai-generated"

在脚本里，$SUMMARY和$DESCRIPTION不是手工填的，而是先由 AI 根据分支上的 diff 生成。整个循环可以跑完几十个分支，一次性把所有 PR 都推到远端。当然，批量操作的前提是你在每个分支做了足够小的改动，否则一堆几百行 diff 的 PR 飞过来，reviewer 会直接崩溃。

这种方法非常适合依赖升级、自动化格式化、批量重构签名这类机械任务。比如团队把 TypeScript 版本从 5.0 升到 5.3，会产生几十个编译错误。AI 可以逐个修复并自动生成几十个小 PR，再配上自动跑 CI，你睡觉的时候它们就在排队合并了。这里有个细节：批量 PR 的 title 类型最好用fix:或chore:，不要每个 PR 都想一个花哨标题，保持一致更容易让 review 者快速扫过去。

3.3 让 AI Agent 从 issue 直接发起 PR

现在已经有不少工具能实现“从 issue 到 PR”的闭环。像 GitHub Copilot workspace、Cursor 的 background agent、Codex 的 CLI 都能做到。Lauren 会这样给 agent 下命令：

看这个 issue #1234，它要求给 API 增加一个 rate limit 参数。请按以下验收单完成：1) 在 config 中增加可配置项；2) 在路由层读取并校验；3) 补充测试；4) 更新 swagger 文档。完成后直接创建 PR，关联 issue，并在 PR 描述里贴出测试结果。

Agent 会自己拉分支、写代码、跑测试、提交 push、创建 PR。听起来很黑科技，但实际落地时一定要给它配一个安全边界。她会给 agent 设定只允许操作特定目录，不允许直接 push 到 main，不允许动用生产密钥。否则一旦 AI 理解错了任务，它可能以闪电速度把错误代码合入主线。

这里的关键不是“是否信任 AI”，而是把风险控制放在自动化之前。只有失败被限制在可控范围内，你才敢把流水线开足马力。我见过好几个团队，给 Agent 的权限一年比一年大，出一次事故后才想起来要缩小范围，其实一开始就设计好边界成本更低。

3.4 合并规则也要分级，不然 2000 个 PR 会把人活埋

2000 个 PR 听起来很爽，但团队如果只有两三个人，review 就会成为新的瓶颈。Lauren 的做法是分级自动化：

• 低风险 PR（如文档、注释、依赖版本号修改）：由机器人自动批准，不需要人工 review。
• 中风险 PR（如新增单元测试、重构私有函数）：需要一个人 review，AI 在描述里标注“重点检查逻辑 A”。
• 高风险 PR（如修改核心模块、涉及数据库变更）：必须两个人 review，并且要附上更详细的测试说明。

这个策略听起来简单，执行起来需要约定清晰的标签体系。她和团队固定了几个标签，比如ai-generated、needs-human-review、no-ci。这样机器人才能根据标签做自动化路由，人也能在 PR 列表里一眼识别优先级。

另外，不要让 AI 审查 AI 生成的所有内容。至少保留一双人眼在关键路径上。AI review 可以发现格式、风格、明显 bug，但它很难发现“这个需求根本不该这么实现”这种问题，这类问题往往需要带着业务上下文的人才能看出来。所谓“自动化”不是要消灭人，而是把人放到更关键的位置上。

4. 真实拦过我的问题：AI 辅助 PR 的常见坑

4.1 AI 生成的代码“看起来对”，但逻辑上有一个隐蔽错误

这是我踩得最多的坑。AI 在生成循环、边界条件、空指针处理上尤其容易出错。比如让它处理一个可能为 null 的列表，它可能会先.filter再.length，看起来没问题，但如果这个列表来源于外部接口，空数组语义可能完全不一样。这类错误不会在编译期暴露，只有到运行时的特定输入才会炸。

Lauren 的办法是：强制要求 AI 生成测试的时候，把所有分支都覆盖到。她把验收单里最后一个验收项总是写成“补充边界值测试”，比如测试空数组、单元素、超长数据、非法参数。这相当于逼 AI 自己审视自己的代码。如果 AI 生成的测试不够，她会手动用代码 review 那一步拦下来。

还有一个更实用的技巧：用“反向审查”查 AI 的代码——先不去看它写了什么逻辑，而是看它的测试写了哪些场景。如果测试里没有空值和异常值，那代码基本可以判断为“没想清楚边界”。这套方法不完美，但能拦住大多数低级错误。在实践中我发现，整个过程比想象中快很多，因为检查测试比检查实现更省力。

4.2 上下文丢失导致 AI 反复改同一个错误

AI 没有真正意义上的记忆。它看着你给它的资料，但不会记得昨天你刚改过另一个文件的某个函数名。如果几个 PR 改动有依赖关系，AI 很容易在一处改对了，在另一处又引用了旧的函数名。解决这个问题的核心是“把关键信息写进 prompt 或 PR 描述”。

我会在 prompt 里主动贴相关代码片段，而不是只说“去看 src/util.ts”。因为 AI 虽然能读仓库，但搜索范围一大，它可能忽略了最重要的那几行。直接把相关类型定义、函数签名、调用处的代码贴进去，它才能给出真正能编译的结果。一个可复用的格式是：

当前项目的类型定义（参考）： ...代码片段... 请基于这段定义修改以下文件： ...文件路径和当前内容... 要求：不修改类型定义本身，只实现新的 helper 函数。

实测这样操作，生成的代码在编译阶段的错误率能下降 70%。代价只是多花十几秒复制粘贴，但比来回折腾几次方便太多了。如果团队里已经有长期维护的代码地图文档，也可以喂给 AI，让它先把关键信息摘要出来再动工，效果会更好。

4.3 流水线噪音：PR 太多也会让人麻木

当每天有几十个 PR 从 agent 那边涌过来，团队容易进入“看见 PR 就烦”的状态。每个人都点通过，遇到真正需要人盯的问题反而被淹没。这个问题，我在不少尝试 AI 辅助开发的团队里都观察到了。它不一定和 AI 有关，但 AI 把问题放大了。

应对方法是前面提到的分级合并规则，加上“噪音过滤器”。比如让机器人在 PR 标题上打上明确的类别标签，列一个“需要人工决策”的看板，把高风险的 PR 单独列出来。低风险的 PR 直接批量合并，但会记录在周报里。这样人类 reviewer 每周只需要集中看十几条真正重要的 PR，而不是在几百条自动化 PR 里翻来翻去。

另外，团队要约定什么时候可以信任自动合并。不要因为连续 10 个低风险 PR 都跑通，就放松对第 11 个的检查。自动化的意义是降低重复劳动，而不是降低质量标准。这个度需要每个团队自己摸索，但有一个底线：核心模块的合并永远要有人看。

4.4 我家的独家技巧：给 AI 一个“拒绝权”

最后分享一个我很喜欢的小技巧。在 prompt 里明确允许 AI 拒绝执行：

如果验收单里的信息不足以完成修改，请不要猜测，列出你缺少的信息，并等待补充。

乍看这会让 AI 多问问题，好像降低了效率，但它能大幅减少返工。因为 AI 在信息不足时硬写出来的代码，往往猜错了设计意图，最后还是要人来重写。与其这样，不如让它在最早期就暴露风险。我试过把这个技巧用在团队里，AI 主动提问的频率增加了，但最终改对的次数明显上升。这个思路和“小步 PR”是一脉相承的：先确认输入是对的，再让 AI 动手。

还有一个变体：给 AI 一个“撤销权”。如果它发现某个验收项和已有代码冲突，允许它暂停并提交一份冲突说明，而不是强行覆盖旧逻辑。这个机制能避免很多不可预期的覆盖，特别是在长期维护的项目里很管用。说白了，AI 不该只学会“执行”，它也要学会“说人话”。

5. 想复刻这套打法，按这个顺序启动

5.1 先从一个指标开始：平均 PR 改动行数

并不是所有人都不适合大 PR，但在引入 AI 之前，你应该先看看自己最近 20 个 PR 的平均改动量。如果动不动就上千行，说明需求拆分颗粒度太粗。这时候直接套 AI 工作流，AI 生成出的巨型 PR 会比人类写的更难审查。先把 PR 变小，这是所有自动化能跑起来的底座。

具体怎么变？把一个功能拆成“实现核心逻辑”“补充测试”“更新文档”“调整调用方”四步。你会发现每一步单独提一个 PR，代码量都很小，而且每一步之间几乎没有冲突。这个过程不需要 AI 也能做，但它是在为 AI 铺路。一旦你习惯了小 PR，再回头看那些大 PR 会觉得很别扭，这是好事。

5.2 第二步：固定 PR 模板，并用 AI 自动填充

没有模板，AI 生成的描述就会天马行空。先复制我上面那套模板，放到.github/pull_request_template.md里。然后试试用你自己在用的 AI 编程工具，让它每次在创建 PR 时按模板来。如果你用的是 GitHub CLI，可以写一个脚本，把分支名、issue 号、diff 摘要直接传给 AI 生成描述。

这个阶段的目的是减少 PR 的“创建成本”。你会立刻感觉到“提 PR”这件事不再打断思路，因为步骤已经被压缩成了“看一眼”和“点一次”。这里有个容易被忽略的细节：模板不是一次定死的，它应该随着团队踩坑不断迭代。比如你发现很多 PR 都漏写了“回滚方案”，就可以在模板里加一行，让 AI 必须写。

5.3 第三步：放权给 AI Agent，但要守着风险边界

前面两步顺畅之后，才建议把整套流程交给 AI Agent。给它一个固定的目录，限制分支命名，规定它只能提交 PR 不能直接 push main。一开始先跑几个小任务，比如依赖升级、代码格式化、注释补全。看看它的输出是否让你满意，再逐步扩大范围。

不要一上来就让它处理你完全不懂的老旧模块。你需要先积累“AI 生成的代码大概长什么样”的直觉，再让它承担更多。我见过最快的犯错方式，就是对 agent 的能力过度乐观，让它直接去重构一个核心服务。结果 agent 自信地改完，单元测试全绿，但线上流量一来就出问题。

这里可以再补充一个检查动作：每周挑一个 AI 生成的 PR，从头到尾复盘一次，看它的描述、实现和测试之间有没有真实对应关系。这能帮你发现很多“看起来完整但实际跑不通”的流程漏洞，也能让团队逐渐形成对这套自动化系统的信任边界。

我个人在踩过几次坑之后的体会是：2000 个 PR 并不是一个需要崇拜的数字，而是一个工程理念的证明。当需求拆得足够细、工具链足够顺、AI 的边界也被足够清晰地定义之后，一个人的吞吐量确实可以上一个台阶。这套流水线没有魔法，它只是把每个环节里可复用的部分都沉淀成了模板和指令，剩下的就是人在关键处做判断罢了。如果你也想尝试，不要急着追求数量，先把一个小功能跑通这条链路，再慢慢扩展。