1. 效率怪物的 AI 工作流到底是什么样第一次看到 Lauren Tan 这个数字——每月交付 2000 个 PR说实话我是持怀疑态度的。干过开源、带过团队的人都知道PR 不只是写代码从分支切分、diff 审查到 CI 跑通、合并回主干这一整套流程里非代码的杂活占比相当高。2000 是什么概念按一个月 22 个工作日算每天接近 100 个 PR哪怕每个 PR 只改动十几行光提交、同步、处理 CI 失败这些动作人肉操作就足够把一天耗光。后来我花了不少时间研究她的公开分享和技术栈才意识到一个关键区别她不是写得快而是把 PR 生产的流水线整个重写了。在她那里PR 的生命周期是半自动化的——AI 负责从 issue 到代码骨架的生成她负责审查、校正和决策而中间大量的机械劳动分支同步、提交信息规范化、触发测试、处理小规模冲突全部交给自动化工具链消化。这件事对我最大的启发是AI 提效的真正杠杆不在让 AI 多写代码而是让 AI 把代码周围的那堆事全部接走。大多数人用 AI 的方式是开个对话框让它写函数这当然有效但天花板很低。真正的效率竞赛发生在你不再需要手动做那些和写代码无关、但没它又不行的事情的时候。这背后的设计思路值得展开讲一讲因为它基本代表了过去一年 AI 编程工作流从辅助补全升级到半自动生产线的一个典型样本。1.1 为什么是代理模式而不是聊天模式我用 Copilot Chat 这类工具的时间不短坦白讲在写工具函数、单元测试和配置文件的场景下它确实很强但要让它多步连续作业——比如读 issue、改代码、补测试、提交并推送——传统聊天模式撑不住。原因不复杂聊天上下文是轮次制的每轮对话都基于上一轮的输出你很难把这是一个由 issue 驱动的任务一次性表达清楚更没法让它自己拆解执行计划、自己检查结果。Lauren 的解法是切到代理模式agent mode。核心变化在于你给的不再是帮我写个函数而是一个任务描述加一堆约束条件agent 自己决定先做什么、后做什么、什么时候停下来确认。她常用的工具链里有开源的 OpenHands原名 OpenDevin配合 Claude 模型也有商业的 Cursor 后台代理模式整个思路是相通的。我实际对比下来代理模式带来的提升最直观的一点是回合数大幅减少。以前写一个中等复杂度的模块聊天模式下可能要来回拉扯七八轮让它生成初版、跑测试、发现报错、把报错丢给它、它改了又有别的错……每一轮都有上下文切换成本。而代理模式下我可以直接告诉它这个模块要支持 A/B 两种配置格式如果 A 格式转换失败要回退到 B测试在 tests/test_config.py 里它自己会浏览代码、定位相关函数、修改并跑测试最后给我一个可审查的 diff整个链路里我只需要出现两三次。当然代理模式不是银弹。它对任务描述的颗粒度要求其实更高——你越能准确描述出验收标准它执行得就越靠谱。如果你自己都没想清楚边界条件agent 就会替你脑补这往往就是 bug 的温床。1.2 小步快跑机器操作和认知判断的解耦另一个让我印象很深的点是她反复强调的小步快跑。这个说法本身不新鲜持续集成时代就一直在讲但她是把人和机器能并行的那部分彻底分开了才算真正跑出效果。具体来说她把 PR 拆成两类。一类是低认知密度但高操作频次的比如依赖升级、文档修正、错误信息改进、格式化调整另一类是高认知密度、需要领域判断力的比如功能新增、架构调整、性能优化。前者她几乎全部交给 agent 批量处理自己只做抽查和合并。后者则保留人工深度介入AI 只作为辅助研究和草稿生成工具。这个拆分非常关键。大部分人用 AI 编程低效不是因为 AI 不行而是因为没有先分辨哪些任务适合让 AI 干、哪些不适合。让 AI 负责高认知密度的任务它容易一本正经地胡说八道反而加重审查负担让人类手动执行低认知密度的任务又是在浪费最稀缺的注意力和时间。我照着这个思路调整了自己的工作方式之后体感差别非常明显。以前有依赖升级的任务我要手动 clone 仓库、切分支、逐个看 changelog、改版本号、跑兼容性测试一个 PR 折腾大半天。现在我把这些流程变成统一的 agent 提示词模板遇到同类任务直接套用从动手到提交 PR 的时间压缩到十几分钟而且几乎不占用我自己的心流状态。2. 把 PR 当工业品而不是艺术品来搞受 Lauren 的思路启发我在自己团队里也搭了一套类似的PR 工厂工作流。说实话刚开始阻力不小组里有人觉得让 AI 提交 PR 是不是太激进了也有人担心代码质量滑坡。但跑了两三个迭代之后大家的顾虑慢慢消除了——不是因为我们说服了他们而是因为 AI PR 的代码审查通过率和人写的差距小得可以忽略而效率优势又太明显。这套流程的核心框架并不复杂概括起来就是三件事标准化的 PR 模板、自动化工具链的嵌入以及严格的合并前审查。任何一个环节做不好整个流水线的收益都会被侵蚀。2.1 一套可以套用的 PR 模板PR 模板是我认为性价比最高的基础建设。很多团队根本没有模板开发者在写 PR 描述时全凭心情有的写一行修复了一些问题有的能写出小论文。这在传统开发流程里只是效率问题但在 AI 辅助的流程里直接决定成败——因为 agent 生成 PR 描述时完全依赖模板结构来组织信息。我自己设计的 PR 模板长这样## 变更概述 用两到三句话说明这个 PR 要解决的问题和核心思路 ## 关联 issue 明确写出 issue 编号方便追踪上下文 ## 变更内容 - 列出主要改动点按文件或模块分组 - 每个要点最好能对应到具体函数或配置项 ## 测试计划 - 说明改动涉及的测试用例跑了哪些结果如何 - 如果涉及手工验证写清楚验证步骤 ## 潜在风险 - 诚实地列出可能的副作用、兼容性影响或性能隐患这套模板看着普通实际用起来效果出奇地好。原因是它逼着 agent 在提交 PR 之前做一次自我梳理——变更概述和潜在风险两栏尤其有用我审查时能一眼看出这个改动是否有清晰的逻辑链路。如果 agent 在风险栏里写无而改动涉及公共 API 或核心数据流那基本可以判定它在偷懒直接打回重做。2.2 自动化工具链怎么嵌进日常流程PR 工厂的第二块拼图是自动化工具链。这部分我强烈建议从轻量方案起步不需要一上来就上重型 CI/CD 系统。目前我们内部跑通的一条主线是GitHub Actions 负责最基础的验证——代码格式化检查、lint、单元测试、构建这些全部用现成的 action 组合起来配置一次就能持续复用。AI agent 则负责更轻量但频繁的琐碎 PR——依赖升级和文档修正这两类几乎可以全自动生成、自动提交。举一个具体例子我们每周都要处理一批依赖升级的 PR以前是专人花半天手动操作现在完全交给 agent 批量执行。我的提示词模板大概是这样的请对以下依赖进行升级pytest 从 7.4.3 升到 8.0.0。 要求 1. 更新 pyproject.toml 和 lock 文件中的版本号 2. 运行完整测试套件 3. 如果测试失败检查失败原因优先尝试调整测试代码适配新版本 API 4. 提交信息遵循 conventional commits 规范 5. 不要直接合并创建 PR 等待人工审查实测下来大约七成依赖升级 PR 是 agent 一次搞定的剩下的三成需要人工介入处理兼容性问题但即便如此整体耗时也从半天压缩到一小时以内。这里有一个细节值得单独说一下提交信息规范。很多团队不重视这一点但在 AI PR 流水线里提交信息的规范性直接决定了你后续能不能做自动生成 changelog、自动关联 issue、自动触发特定 CI 任务。我们在初始化仓库时就把 commitlint 接进去了conventional commits 规范强制执行AI 生成的提交信息如果不合规本地钩子直接拦截省掉很多后续维护的麻烦。2.3 合并前审查这关AI 也不能全权代理说到这我必须泼一盆冷水PR 工厂里最不该自动化的环节就是最终审查和合并。这不是保守而是风险评估后的必然选择。Lauren 的分享里也专门强调过这一点。她虽然每月交付 2000 个 PR但真正合并进主干的 PR每一个都有至少一道人工审查关卡——要么她自己过要么代码所有者过。AI 的定位是最大化每个 PR 的准备工作而不是替代人对代码负责。我们的做法是双重审查制度。第一层是 agent 自查——AI 在生成 PR 时会先跑一遍自己代码库里的静态检查工具把明显的错误过滤掉第二层才是人工审查——合进主干前至少一名团队成员逐行看过 diff重点关注 AI 最容易犯的几类错误边界条件处理不当、过度修改无关代码、隐式依赖新行为。这里有个我踩过的坑想分享出来。有一回 agent 升级一个序列化库测试全都通过了审查时我也没细看结果上线后线上环境报错。后来排查发现是 agent 在顺手把几个配置文件的默认值改了本地测试用的是测试配置没覆盖到生产默认值场景。这事之后我定的规矩是AI PR 的 diff 必须逐文件核对凡是和任务无关的改动一律打回。3. 提示词工程不是玄学是系统方法聊完流程该聊聊跟 AI 直接交互的那层了。Lauren 在分享里有一句话我特别认同提示词工程不是写一段奇妙的咒语而是把上下文、约束和验收标准打包成机器能理解的形式。很多人觉得提示词工程是玄学甚至有人专门卖万能提示词模板说实话这些模板大多没啥用。真正有价值的是你自己对你项目的理解——你越清楚你的代码库结构、测试策略和人员习惯你的提示词就越精准。这里我把自己的方法拆成几个可复用的层次。3.1 三层提示词结构角色、任务、验收标准我写提示词固定用三层结构不管任务大小都这么组织。第一层是角色定位。不是那种你是一个资深工程师的空话而是给出具体的技术背景——你熟悉 Python 生态、熟悉 FastAPI 框架、了解我们的代码库采用 MVC 结构。这样做的目的是在开箱时就把模型的回答范围约束在合理区域内避免它给出完全不着调的方案。第二层是任务描述。核心要求是给足上下文但不给多余信息。我见过太多人把整个文件全部丢给 AI然后让它在里面找问题这既消耗上下文窗口又容易让模型迷失在无关信息里。正确的做法是把相关函数的签名、调用链和边界条件放进去其他的都省略。第三层是验收标准。这是最容易被忽略但最重要的部分。不要只说实现一个 XX 功能而是要说清楚什么样的输出算完成。举个例子我让 AI 写一个缓存模块时验收标准是这样的完成标准 - 支持 LRU 和 TTL 两种淘汰策略 - 并发访问时不会出现数据竞争 - 命中率和未命中率都要有对应 metrics 埋点 - 单元测试覆盖率达到 85% 以上 - 所有新代码通过 mypy 严格模式检查有了这层AI 输出的质量会高一个档次因为它不再靠猜而是有了明确的目标函数。你审查时也轻松因为对照验收标准逐项检查就可以了。3.2 Batch Mode把琐碎 PR 批量喂给机器这个技巧我从 Lauren 的分享里学来后用在自己的工作流中效果极佳。Batch Mode 指的是把多个性质类似的小任务打包到一次会话里让 agent 逐个处理而不是每个任务都开一次新对话。为什么 Batch Mode 效率高因为它充分利用了模型对上下文的连续性理解。比如你要修十个 markdown 文档里的格式问题逐个开新对话意味着每次都要重新描述背景、约束和输出格式而打包在一次会话里agent 从第二个任务开始就自动沿用之前的处理模式几乎不需要重复解释。我处理文档类维护任务时提示词大概长这样以下是 10 个需要统一格式的文档列表每个文档都要求 1. 将标题层级按规范重新整理 2. 更新过期的使用说明 3. 修正链接指向 每次处理完一个文档简要说明改动内容再继续下一个。实测下来这类纯机械任务的耗时基本和文档数量成线性关系每个文档两三分钟10 个文档半小时内完成而且出错率比手动改还低。因为模型在执行重复性任务时非常稳定不会像人一样因为疲劳而漏掉细节。Batch Mode 还有一个隐藏收益它天然适合复用提示词模板。我维护了一个提示词模板库里面按任务类型分类比如依赖升级文档修正测试补全配置迁移。每次遇到同类任务直接复制模板、替换变量、丢给 agent 就行不需要从零开始组织语言。3.3 上下文注入的边界感最后聊聊上下文注入的边界。我注意到一个普遍现象很多人在 AI 编程时要么给的信息不够要么给得太多。信息不够导致 agent 只能瞎猜信息太多又让它淹没在噪声里抓不住重点。我的原则是只注入与任务直接相关的事实不注入背景故事和无关痛痒的偏好。比如我让 agent 在某个模块里加一个新接口我会告诉它这个模块的输入输出格式接口签名调用方对这接口的依赖哪个服务在等这个返回已有的类似接口实现让它照着风格来这个接口的失败处理策略是抛异常还是返回空值但不会告诉它这个项目是我们团队三个月前从旧系统迁移过来的主要为了解决历史债务问题——这种背景故事对模型执行当前任务毫无帮助只会挤占宝贵的上下文窗口。另外上下文注入要分阶段。如果是一个多步骤任务不要一次性把所有信息全塞进去而是随着步骤推进逐步补充。比如第一步只需要代码库结构和目标接口定义等第一步完成后再告诉它测试环境的具体配置和预期输出。这种逐步解锁的方式不仅让模型表现更稳定也让你在审查时更容易对齐预期。4. 实测数据说话AI PR 流水线的投入产出比理论说了这么多没有数据支撑总显得虚。我们团队内部过去两个月完整跑了一遍 PR 工厂工作流这里把真实数据贴出来给想入手的读者一个参照系。先说明背景我们是一个 6 人的后端研发小组负责一个中等规模的服务端项目代码量约 30 万行以 Python 和 TypeScript 为主。过去两个月里所有 PR 尝试按 AI 辅助流水线执行但保留了完整的审查流程。需要强调的是这不是严格的对照实验数据仅供参考但趋势足够说明问题。指标采用 AI 流水线前采用 AI 流水线后变化每人每月 PR 数量183594%PR 从创建到合并的平均耗时3.2 天1.4 天-56%代码审查通过率一次通过61%55%-6%线上 bug 数量每月43-25%4.1 效率提升的真相瓶颈在哪里从数据能清晰看到PR 数量和合并速度都上去了但审查通过率反而降了一点。这其实是预料之内的事情——AI 生成的 PR 在逻辑完整性上不如老手写的尤其容易在边界条件和异常路径上偷懒。我深入看了一批被驳回的 AI PR发现的典型问题非常集中第一类开心路径综合征。AI 倾向于实现最顺利的那条路径一旦涉及异常处理、重试机制、并发冲突它就本能地回避。这个靠审查兜底基本能拦住但会在审查环节多花时间。第二类上下文健忘症。在多步任务里agent 做到后半程时容易忘记前面设定的约束条件。比如前面明说不要在公共接口里引入新的依赖但到实现环节它还是顺手 import 了一个新库。第三类测试保守倾向。AI 生成的测试用例往往只覆盖主路径和基础断言对边界输入、压力场景和故障注入的覆盖明显不足。4.2 通过率的优化手段审查通过率下降 6 个百分点看着不多但在小团队里就意味着每周多了几次返工。我们后面做了一轮针对性优化效果还算明显通过率从 55% 拉回到 63% 左右。优化手段有三条第一条强制 AI 在提交前自评。在提示词里加了一步自查清点要求 agent 逐一核对自己是否满足验收标准、是否覆盖了异常路径、是否只改了任务相关的文件。简单说就是在 PR 描述里必须有一个已知缺陷小节逼着它正视自己没做好的地方。这个做法让 AI 的自检认真了许多很多明显问题在生成阶段就被筛掉了。第二条审查清单前置。我们只允许 AI PR 在满足审查清单条件时才进入人工环节不然直接退回重做。清单包括相关测试是否运行通过、变更范围是否和任务描述一致、是否有未使用的新增 import这个很能暴露问题、代码风格是否和现有模块一致。因为清单是自动化的agent 在提交前就会过一遍挡住不少低质量问题。第三条增加人工抽查比例。对于低风险类型文档、依赖升级、配置调整人工不会逐行审查改为按 20% 比例抽查。抽查不通过的 PR连同它涉及的同类 PR 一起打回重审让 agent 有一种抽查威慑。我不知道 AI 有没有害怕这种情绪但这个策略确实显著提高了低风险 PR 的质量一致性。4.3 AI 能力的分工边界数据给出了答案跑完这两个月我对AI 在 PR 流水线里到底能干什么、不能干什么有了比较清晰的答案。用数据说话就是AI 最适合干的低认知密度、高操作频次的机械任务。这类任务它干得又快又好比如依赖升级成功率约 70%、文档同步成功率 90% 以上、格式化调整几乎 100%、简单 bug 修复约 60% 一次通过。AI 不太适合干的高认知密度、强领域判断的任务。这类它容易一本正经地胡说八道比如架构设计、性能调优、复杂并发问题我们试过让它独立处理通过率不到 30%而且审查成本极高。我发现一个清晰的规律——任务越靠近改一行AI 越强任务越靠近做决策AI 越弱。这个规律决定了我怎么分配任务所有能拆成改一行的事情都扔给 AI 批处理所有需要做决策的事情留给我和团队里的资深同事。5. 踩坑实录那些 AI PR 流水线翻车的瞬间讲完数据把我自己踩过的坑分享一遍。这些坑解决之后流水线才算真正稳定下来希望你能绕过这些弯路。5.1 依赖升级翻车小版本也会破坏行为第一个踩得比较深的坑是依赖升级。本来以为小版本升级比如 1.2.3 到 1.2.4是纯机械操作交给 AI 完全没问题。结果有一回升级一个 HTTP 客户端库agent 跑完全部测试都过了合并后才在线上发现新版本默认改了连接超时行为导致某些慢接口频繁报 504。这个问题的根源在于测试环境没有模拟真实网络状况而 agent 只看测试结果不会考虑测试是否覆盖了所有生产路径。我的规避方案是将依赖升级分成两类纯补丁类patch version直接让 agent 自动创建 PR 并合入次版本升级minor version则强制要求额外人工评估变更日志确认是否有行为变更。这个流程改完类似事故没有再发生过。5.2 上下文污染让 AI 改错文件第二个坑是上下文污染。有次我给 agent 派了个改文档的任务结果它顺手把代码仓库里所有 markdown 文件的格式都改了一遍理由是我们统一的文档规范。它觉得自己在做正确的事但项目里有些文档是给外部客户看的格式风格有自己的要求不允许被统一。这类问题怎么防最有效的办法是划分明确的任务边界。我在提示词里会特意写明只修改以下文件列表中的内容其他文件一律不允许改动。这个约束一开始列出来之后犯错的概率大幅下降。如果 agent 仍然改了范围外的文件审查阶段直接打回并提示它重新基于原始分支创建 PR。5.3 过度依赖 AI 导致团队能力退化这个坑不是机器的问题是人的问题。在 PR 工厂流水线跑了一两个月后团队里有些年轻同事开始习惯性把任务直接丢给 AI然后花大量时间在审查上。这样做的结果是他们越来越难独立完成一个模块的设计和编码。我后来做了一次调整新人和中级工程师必须每周至少手写 20% 的代码量——不是传指令而是真刀真枪地写、调试、优化。这个要求在团队内部引起了一些讨论但我坚持执行。因为 AI 再强你至少得有能力判断它的输出对不对。如果你自己都不会写怎么可能看出 AI 写的代码哪里有问题5.4 提示词模板的过期问题最后一个坑是关于提示词模板的。模板不是写一次用一辈子的它需要根据项目演化持续更新。我们项目的 API 结构改版之后老的提示词模板里还引用着旧的函数名和目录结构agent 拿到模板后一脸懵要么报错要么生成完全用不上的代码。我现在的习惯是每次项目有重大结构调整或者工具链版本升级比如 Python 版本、ORM 版本、CI 流程就顺手更新一遍相关任务的提示词模板。这个维护成本平均下来每周十几分钟但能避免无数次agent 用了过期信息导致返工的低级意外。6. 把这套方法搬到自己项目里的落地清单聊到这里如果你想把这套思路迁移到自己的项目里我整理了一份可直接照做的落地清单。需要说明的是这是我们团队在实践中验证过的流程不一定适合所有场景但至少是一个靠谱的起点。6.1 第一步盘点任务类型划出 AI 的作业区动手之前先在项目里盘一遍有哪些任务是低认知密度、高操作频次的我的经验是先从三个最容易出成果的领域入手依赖升级每周固定处理一批规则清晰、试错成本低、影响范围可控文档维护格式统一、过期内容更新、链接修正这类任务对人类是纯消耗对 AI 却是舒适区简单 bug 修复那些错误信息明确、栈地址清楚、改动逻辑直接的 bug不建议一开始就让 AI 去处理新功能开发或者重构类任务这类任务认知密度太高、边界的模糊地带太多AI 会需要你大量的引导和纠偏整体收益反而为负。6.2 第二步搭好审查基础设施再让 AI 进场AI 开始大规模产出 PR 之前团队必须先把审查基础设施搭好。核心是 AI 做无用功的最小化”——如果审查时一眼扫过去全是格式问题那整个流程的价值就大打折扣。我们落地时的顺序是先部署 pre-commit 钩子包含 lint、格式化、类型检查然后配置 GitHub Actions 跑单元测试和构建最后引入一个自动化 bot专门检查 PR 描述完整性、关联 issue、变更范围是否包含非预期文件。这三层基建就位后AI 生成的 PR 再进来首先过机器关卡接下来才轮到人。6.3 第三步写一份团队可复用的提示词模板模板不用复杂关键是写清楚约束。我强烈建议每类任务维护一份模板团队内部共享而不是每个人自己写一份私有的。这样出一份质量稳定的模板好过十个形态各异的模板。我们的模板仓库里的结构大致这样prompt-templates/ ├── bugfix/ │ └── simple-bugfix.md ├── dependency/ │ └── patch-upgrade.md ├── documentation/ │ └── markdown-cleanup.md └── testing/ └── unit-test-completion.md6.4 第四步设定迭代节奏一周一复盘最后一条建议是设定固定的复盘节奏。我们每周五下午花半小时看流水线数据PR 数量、一次通过率、AI 返工率、线上 bug 数。哪些任务类型的通过率在下降哪些模板需要更新自动化审查清单有没有漏掉的新问题类型有了这个复盘习惯PR 工厂就能持续进化——不是搭完一套就完事而是像一个真实的生产系统一样根据反馈不断调参。我个人的体会是这个持续迭代的过程比最初搭建框架本身更能拉开团队间的效率差距。真正高效的组织是在人机协作这件事上跑出了属于自己节奏的那一批。