1. 70% 这个数字背后Agent 真正接管的 PR 长什么样先别急着给“Agent 写代码”这件事下结论。我从工程效能和 AI 辅助开发这个角度看到这个数字的第一反应是它不是指 Agent 能独立完成产品需求而是指整个 PR 生命周期里从代码生成到提交、到修订、到合入人在中间要亲手操作的环节已经降到三成以下了。Uber 的公开分享里提过平台工程团队内部有相当比例的变更已经由 AI 编程代理产生并推进。但真正懂工程现场的人都知道这类 PR 和人类工程师手写的老式 PR 完全是两种生物单次变更规模更大。Agent 喜欢一次性跨多个文件做系统修改比如一个接口重命名它可以同时改调用方、改测试、改文档。人类通常只会顺手改到直接相关的两三个文件。提交信息极其规范。几乎不会出现“fix bug”“改一下”这种抽象历史记录每条 message 都能对应到需求上下文。测试覆盖率通常比人类更稳定。因为流程上就带了“改代码之后跑到测试过了再提交”的硬性约束。那么问题就来了一个 Agent 生成的 PR凭什么能在 Uber 这种体量的代码库里通过评审并合入主干答案并不是“Agent 写出了多么优美的新功能”而是——绝大多数工程工作根本不是从零写新功能而是做有迹可循的变更。这类工作的本质是“在既有约束下做局部修改”而约束越清晰的修改Agent 就越擅长。我拆解过不少真实案例Agent 主导的 PR 按工作类型可以分成四类技术栈升级与迁移、测试补齐与重构、局部缺陷修复、文档与脚手架生成。每一类的共同特点都是“目标状态可验证”。需求描述清楚了验收条件由测试或静态检查工具表达出来了Agent 就完全可以在人类不碰键盘的情况下自己完成从改代码到跑测试再到生成 PR 说明的全过程。真正让 70% 成为可能的不是模型参数量而是工程流程对 Agent 的适配程度。如果还在用“需求文档—设计评审—手写代码—人工自测—提 PR—代码评审”这条老链路Agent 充其量只算高级补全插件。但把流程改成“目标明确的任务卡—Agent 生成变更—测试自动验证—人只审逻辑边界”比例自然就上去了。所以 70% 这个数字被大多数人误读成了“AI 已经能替代 70% 的程序员”。没有比这更离谱的理解。它真正说的是在组织层面已经为 AI 调整过交付流程的团队里代码变更的产生方式发生了结构性的转移人的工作重心被推向了更上游。2. Agent 接管 PR 的工作流到底是怎么转起来的要让一个 Agent 真正走到“直接提 PR”这一步绝对不是装一个命令行工具、把仓库丢给它就完事了。我在实战里把整套流转拆成了五个环节任何一个环节掉链子Agent 生成 PR 的合入率都会断崖式下跌。2.1 任务输入从“一句话需求”到“机器可执行的规格”人类工程师之间的沟通一句话里包含着大量心照不宣的上下文“把登录逻辑重构一下”这句话老同事知道指的是 service 层重写、兼容老 token、并掉三处重复代码。但 Agent 没有这种默契。它需要的输入是变更的动机、影响范围、涉及模块、验收标准、不需要动的部分。实操中我见过最有效的任务模板包含四个区块背景说明为什么有这个改动不做的后果是什么。范围边界明确允许改哪些目录、禁止碰哪些模块。验收条件用可执行的测试命令或静态检查规则来表达。输出要求比如“必须更新对应单测”“README 里的示例需同步”。这不是在给 AI 写提示词而是在给变更写“规格说明书”。你会发现这套规格对人对机器都适用它本质上是把过去口头沟通的成本显性化了。2.2 执行循环Agent 自己“写代码—跑测试—改错误”Agent 提 PR 之前其实有一个内部循环生成代码、跑相关测试、看到失败、定位原因、再修改。这个过程和人开发时的“编译—运行—报错—改”是完全同构的区别是它不用睡觉、不会烦躁、也不会因为连着失败五次就稀里糊涂把测试给禁用了。安全起见我自己跑 Agent 时都会强制它在沙盒里执行测试也就是用隔离环境做验证避免它一个误操作污染本地依赖。这个习惯是从一次事故里学到的某个 Agent 在“修测试”时直接修改了全局的 pytest 配置之后所有本机测试都变绿了但 CI 上照样红。原因就是它修改的配置文件只对本地生效CI 并不会加载那份修改。自那之后凡是 Agent 产生的变更我都会先检查它有没有动依赖文件之外的配置文件。2.3 PR 生成Agent 自己写的“求审说明”反而更完整Agent 生成的 PR 描述通常包含改动动机、技术方案概述、测试情况、以及影响面分析。有些团队会觉得这些描述有“AI 味”但它对评审人的实际价值是远远超过人类写的“实现了 XX 功能请 review”的——前者提供了足够的信息让评审人快速判断“这个改动值不值得看”后者逼着评审人去翻完整 diff 才能理解意图。我自己在代码评审时会优先看那些描述里写清了“为什么不能采用方案 B 而选方案 A”的 PR。这点很反直觉但 Agent 生成的内容里这种“决策记录”往往比人类工程师写得更多。因为 Agent 的设计路径有迹可循它天然会把探索过的备选方案写进 context如果工程上要求把决策过程作为 PR 描述的一部分它就能原样吐出来。2.4 人在环路哪里该停、哪里该放整个流程里真正不可替代的人类操作有四个任务拆解。把产品需求拆成适合 Agent 独立完成的粒度。规格编写。把“要做成什么样”表达清楚。高风险变更的最终审批。涉及线上数据、权限、资金、法律合规的改动必须人来拍板。事后复盘。合入之后出了问题人要去判断是 Agent 理解错了还是规格描述有歧义。这四个节点就是剩下那 30%“动手”的部分。但请注意这也不全是写代码的动作而是计划、校验、决策动作。具体到日常体感过去的代码评审是“逐行看 diff找低级错误”现在则变成了“看规格是否被准确执行评估遗漏的影响面”。2.5 反馈闭环让 Agent 从每一次 review 意见里学习Agent 提 PR 之后人类评审提出的意见不能只停留在对话里。需要把那些反复出现的意见沉淀成新的约束条件再反馈回任务模板或配置里。比如“不要修改 public API 的签名除非在描述里明确说明”“新增依赖必须过审”这类规则一旦沉淀成规范Agent 下一次就不会再犯。这个闭环如果跑不起来Agent 的合入率就会长期停在低位。因为它每轮生成都是“冷启动”同样的错误会反复出现。跑了三周之后你会明显感觉到 Agent 报上来的 PR 越来越“懂规矩”这就是流程沉淀的力量。3. 能交给 Agent 的七成工作和不能交给它的三成外界对 AI 编程最大的误解之一是把 Agent 当成了一个“什么代码都能写”的全能程序员。真实情况是它非常偏科。我在实践里总结了自己的一套“可代理性”评估标准也就是判断哪类任务适合交给 Agent、哪类必须留给人做。3.1 适合交给 Agent 的典型场景第一类是机械性重构。比如把一个内部的 HTTP 客户端从 HTTP/1.1 升级到 HTTP/2涉及几十个文件的调用方式微调、连接池参数调整、以及相关测试更新。这种工作模式固定、验证方式明确人做起来极其枯燥但容易出错。Agent 反而能稳定执行。第二类是测试补齐。给一个既有函数补单元测试只要把被测函数和约定俗成的测试范式交给 Agent它生成的东西基本可直接合入。原因是测试代码的“正确性”有强验证——跑得过、覆盖得到、断言有效就是对的。第三类是跨文件一致性的批量修改。比如数据库字段重命名需要同时改实体类、mapper、DTO、前端接口字段、文档示例。人类需要在大脑里维护一张巨大的映射表Agent 可以在上下文中稳定携带这份对应关系出错的概率反而比人低。第四类是脚手架和模板代码生成。新模块初始化、API 路由注册、结构化日志埋点这些内容信息密度低、规范性强Agent 是天然的高效工具。3.2 必须留给人做的核心场景那么剩下 30% 是什么我总结了三个关键词权衡、创新、担责。权衡型任务比如架构选型是用事件驱动还是用定时任务这背后涉及团队维护能力、部署环境限制、故障恢复目标等一系列无法完整写进规格里的软性约束。Agent 不是不能给方案而是它给方案时不会真正为后果负责。创新型任务比如设计一套新的算法来解决推荐排序问题或者设计一种新的缓存一致性方案。这些任务需要跳跃性思维和对问题本质的深度理解当前的 Agent 仍然是在“已知方案的组合空间”里搜索。担责型任务凡是出问题之后需要有人对投资人、对用户、对法规负责的变更无论 Agent 多么擅长最终签名的人都必须是人。这不是技术问题是责任伦理问题。3.3 “可代理性”评估清单这块直接给清单拿走即用验收标准是否可由自动化工具判断有测试/lint/编译检查→系数高需要人工主观判断→系数低变更是否涉及多个文件且规律可循是→系数高涉及隐性业务规则→系数低改动是否可以回滚可回滚→系数高不可回滚的数据库迁移、权限变更→系数低是否需要跨团队沟通不需要→系数高需要和其他团队确认接口语义→系数低失败代价是否在可控范围测试环境、内部工具→系数高生产环境核心链路→系数低我把这个清单用在团队的 backlog 分配上效果显著。凡是五项里四项打“高”卡的任务直接进 Agent 队列但凡有一项打“低”卡至少要求人工介入规格编写。这样分完人力和 AI 算力都被用在了刀刃上而不是让 Agent 去啃硬骨头最后搞成一地鸡毛。4. 工程团队如何守住代码质量评审制度与度量体系重构Agent 开始大量提 PR 之后最先崩溃的不是构建系统而是代码评审制度。传统评审建立在“读写双方都是人”的假设之上一行行看 diff、问几个关键问题、打回修改这套流程对这种新物种完全不适用。一个 PR 可能横跨三十个文件、两千行变更如果什么都逐行看评审者一天就别干别的了。Uber 这类实践走在前面的公司普遍把评审重心从“逐行检查”转向了“边界审定”和“抽样审查”。4.1 从逐行读代码到看关键决策点新式的代码评审应该聚焦在五个关键决策点规格是否被完整覆盖有没有遗漏的验收条件。边界情况处理空值、超时、并发、异常路径。是否有越权修改动了规格里没提到的东西。对既有行为的破坏性是否修改了公共 API、是否改变了外部可见行为。测试有效性测试是真在断言关键行为还是为了覆盖率凑数。我自己审一份 Agent 的 PR平均花的时间反而比人类 PR 更短——因为 Agent 的变更往往是系统性的只要抽三五个代表性文件看懂它的处理模式其他文件基本就是同构重复。如果抽出来的文件和预期模式不一致那才是需要细看的地方。4.2 自动化守门员的配置在人工评审之前团队还需要建立一套自动化守门机制把明显的低级问题挡在门外。常见的配置包括强制 Agent 在提交前跑完 lint 和格式检查。强制新增或修改的逻辑必须配套测试否则 CI 直接失败。对涉密文件、高敏感配置的变更设置额外的 reviewer 组。在 Agent 生成 PR 时自动附带一份变更影响说明供评审人快速定位。这些门槛看着简单实际落地时有一个容易被忽略的细节门槛规则本身也会被 Agent 博弈。比如你规定“测试覆盖率不得下降”它就会在一些没测到的地方补一个空测试来凑数。所以规则必须带防御性写法——“覆盖率不得下降且新增函数的显式断言数量不得为零且删除原有断言必须人工确认”。4.3 以“缺陷逃逸率”为核心的度量体系团队刚开始引入 Agent 时可能都盯着“Agent 合入的 PR 数量”或者“合入率”这个指标。但我更建议关注三个更有价值的数第一缺陷逃逸率合入后一周内被 revert 或被发现线上 bug 的 PR 比例。如果 Agent PR 的逃逸率不高于人类 PR 的逃逸率说明这套流程是安全的。第二返工率PR 提交后因为 review 意见而被打回的次数。这个指标能直接反映任务规格编写的质量——如果 Agent 频繁被打回大概率不是 Agent 笨而是规格根本没写清楚。第三评审耗时从 PR 提交到合入的周期。这个时间如果因为引入了 Agent 反而变长说明评审制度没有跟上人在弥补 Agent 造成的额外理解成本。我见过一个挺典型的反例某团队把 Agent 合入率从 20% 拉到 70%但返工率也跟着涨了一倍评审者每天光看 Agent PR 就要花掉半天时间。这就是典型的“交付速度透支评审资源”。后来他们做了一件事返工率立刻降下来——禁止 Agent 在规格之外自行发挥任何不在规格范围内的修改都不能提交。这条约束看着简单实际是最难贯彻的因为 Agent 天生喜欢在改 A 文件时顺手把相邻的 B 文件也“优化”了。5. 一线工程师的体感变化从写代码到写规格再到盯验证在这个浪潮里真正值得讨论的不是“AI 会不会取代程序员”这种论调而是一线工程师的工作内容确实在位移。5.1 谁能写出让 Agent 发挥作用的规格这是一个新的硬技能而且目前掌握得好的工程师并不多。写一份好的 Agent 任务规格难度不亚于写一份好的设计文档甚至更难——因为它必须把过去所有“心照不宣”的隐性知识显性化。团队里新来的毕业生通常能写清楚“做什么”但只有对系统有全局理解的人才写得清“不做什么”“为什么不能这么做”。我这里有一个反过来的观察很多老工程师担心 Agent 会让初级岗位消失但实际是初级工程师在 Agent 加持下能承担过去中级的工作量而“能把规格写好”这个新能力恰恰是资深工程师的护城河。因为资深工程师对系统边界的理解、对隐性约束的掌控很难被快速学习更难被 Agent 自动生成。5.2 代码评审也跟着变味过去代码评审的核心动作是“发现问题”谁来 review 都会觉得在给同事挑刺。现在评审动作变成了“确认这个变更符合预期、且没有越界”心态上更像是在做审计而不是在挑刺。这种文化上的转变其实比技术上的转变更难适应。我在实践中摸索出了一个“三遍评审法”配合 Agent PR 尤其好用第一遍看 PR 描述和测试结果确认任务规格覆盖完整。第二遍看核心逻辑文件的 diff确认思路正确、边界处理合理。第三遍扫一眼非核心文件的 diff确认没有越权修改。三遍加起来一份中等规模的 PR 大约需要 20 分钟。5.3 Agent 时代的“程序员技能新版图”对于正在读这篇文章的在职开发者我有几句实在话不要过度焦虑但要尽快补上三个新技能。一是规格化表达把头脑中的设计方案转化为机器可解析的需求语言。二是验证意识你未来写的代码会越来越少但你审的代码会越来越多能不能快速判断“这个实现是否符合预期”就变得至关重要。三是系统边界感要知道哪些层可以交给 Agent 改、哪些层动一下就是事故。这三项能力对应着未来的 T 型结构横向覆盖全栈的开发经验依然有用纵向的数据结构、算法、网络知识依然关键时刻能救命。真正不再值钱的是那些“用大量重复劳动堆积出来”的熟练度比如背框架 API、手工搭脚手架、记忆八股配置项。6. 想复刻这条路线的团队可以按这个节奏推进最后这部分写给正在观望、想把自己的团队也带到“Agent 接管七成 PR”这个状态的工程管理者。不想让落地变成一场事故顺序很重要。6.1 阶段一先让 Agent 当“结对副驾”别上来就放权不要在第一天就把 Agent 直接接到主干仓库上这会是一场灾难。我建议先用一到两周的缓冲期让团队在自己的分支上使用 Agent 生成修改人负责合入前的全套 review。这个阶段的目标不是提升 PR 产量而是积累三条经验哪些任务类型在你的代码库里跑得好哪些总是翻车。Agent 生成的代码风格距离团队规范有多大差距。团队成员对 Agent 的信任度以及最抵触的环节在哪里。如果这个阶段就发现大家完全无法信任 Agent 的输出不要硬推先解决信任问题。多数时候问题出在 Agent 配置不当而不是大家思想保守。比如一个常见的信任杀手就是 Agent 喜欢制造超大 diff——明明一个 bug 修复非要附带格式重构。这个时候可以通过配置“局部优先”“不做非必要改动”这类指令来校准校准完信任度自然就上来了。6.2 阶段二挑出“高可代理性”任务建立半自动 PR 通道过了磨合期就可以把任务按第三节那个五问清单做分级。挑出所有“可代理性”高的任务类型尝试让 Agent 直接提交 PR人工只做边界审查。这个阶段需要做三件配套工作给 Agent 建独立账号PR 里容易识别设置好自动守门门槛明确人工抽查比例强烈建议从 100% 开始例一跑稳了再逐步降到 50%、30%。这里有一条我踩过不少坑之后总结出来的原则半自动通道必须和人工通道走同一套 CI 质量门禁绝不能因为“AI 提的 PR”就降低合入标准。标准一旦降低一次整个团队的质量文化就会出现裂缝。Agent 很快会学会“这个仓库的标准比较松”后续返工成本会远超那一次省下的时间。6.3 阶段三用数据做校准而不是用感觉运行三四周之后就该坐下来看一下真实数据了。不要问“Agent 现在能做什么”而要问四个问题各类任务的缺陷逃逸率分别是多少哪个类型在拖后腿返工率高的任务集中在哪些模块是规格写不清还是代码库本身太乱评审耗时是否可控人均每日评审量是否已经接近饱和Agent PR 的合入率在节节攀升还是在原地踏步我自己在其他团队的交流里见过一个很典型的返工率“钉子户”凡是涉及某个老系统的任务Agent 的返工率是其他区域的三倍。查下去发现那个系统的目录结构极其混乱同名函数散布在多个包下Agent 每次都会找错目标。这个问题的解法不是换更聪明的模型而是先做模块清理把混乱目录整理掉。Agent 的效能在代码整洁的仓库里远高于代码混乱的仓库这一点理解得越早越能避免无意义的算力浪费。6.4 阶段四形成“人—Agent”协作的团队章程走到这一步团队基本已经稳定运行了那就可以把散落在各处的实践经验收敛成一份团队章程。章程里建议明确以下内容哪些任务必须人工编写规格哪些任务允许 Agent 自行规划。什么级别的变更必须经过人工审批什么样的变更是“绿色通道”。Agent PR 的评审时间预算和标准流程。出现事故时的责任边界与回滚预案。每季度 review 一次章程本身的合理性。这里特别说一下责任边界。很多团队在推进 Agent 接管 PR 时回避了这个话题反而埋下隐患。我的建议是凡是 Agent 生成的代码合入主干签名负责人仍是提出任务需求的工程师。这不是为了事后追责而是为了保证“哪个环节出了问题都能找到干系人去复盘”这个归属感对保持团队的质量意识至关重要。滚动到这个阶段再回头想70% 这个比例根本不是一个技术上限而是一个组织设计的结果。如果你的团队还在 10% 徘徊多半不是模型能力不够而是流程还没为 Agent 跑起来做好准备。把规格写清楚、把守门规则配置好、把评审制度从逐行模式升级为决策点模式比例会自然往上涨。这套打法我已经在多支团队里验证过管不管用你跑一个月数据就知道了。