AI 写代码越来越快，开发团队却越来越累

过去三年，代码生成工具已经从“高级补全”变成了“能在等待期间搭出一整个应用”的生产工具。掌握语言、架构、最佳实践和常见陷阱的工程师，确实可以把大量机械编码工作交给模型或 agent，自己把精力更多放在意图表达和约束定义上。

问题不在于 AI 能不能生成代码，而在于代码生成变便宜之后，软件交付流程里更贵的部分被放大了：代码评审、DevOps/SRE、安全、基础设施，以及最容易被忽视的一项——人的判断力。

工作时间没有明显变长，但工作密度变高了。自动化产出更多内容，人仍然要决定“什么算好”“什么该合并”“什么能上线”“什么风险可以接受”。这就是很多团队开始感受到的真正压力来源：不是写不出代码，而是要不停做决定。

为什么代码越便宜，评审反而越贵？

在没有大规模 AI 辅助的阶段，代码之所以“贵”，本质上是工程师的知识和时间贵。语言细节、抽象边界、工程约束、交付流程，这些都需要人来掌握。因此，很多团队曾经用一些很糟糕但容易统计的指标衡量产出，比如：

• 工时
• 代码行数
• 每日 commit 数

后来行业逐步转向结果指标，例如 DORA 一类度量，希望从交付结果而不是输入动作上评价研发效率。

现在，一部分旧指标正在回潮，而且因为 AI 的存在变得更容易被滥用：

• 生成了多少代码
• 新代码里有多少比例来自 AI
• 工程师使用了多少 token
• 谁“喂给模型”的上下文更多

这些指标的问题并不只是“粗糙”，而是会直接扭曲团队行为。代码变便宜后，代码量本身已经不能代表价值，反而可能意味着更高的后续成本。

一个典型场景是：某位工程师的代码产出达到团队其他人的 7 倍，而且提交质量表面上还不错，check-in 和 review 记录都很漂亮。但问题在于，团队里其他六个人的大部分时间都花在评审她的代码，而不是自己写代码。单点产出暴涨，并不等于团队吞吐提升；很多时候只是把压力转移到了 review 环节。

代码评审本来就不是简单的语法检查。有效的 code review 需要回答的是：

• 这次改动放进整个系统里是否合理？
• 有没有破坏隐含约束？
• 是否引入了维护成本更高的结构？
• 与现有依赖、部署流程、安全边界是否冲突？

这要求评审者理解更大的系统上下文，而不是只看 diff。评审者承担的实际上是“放行责任”。一旦漏掉关键问题，后果常常会回到评审者头上。这也是代码评审长期以来容易带来焦虑的原因之一。

为什么 AI 让开发工作更密、更耗判断力？

大量 AI 生成内容最终都要被编辑后才能定稿。一个关键数据是：约 80% 的 AI 生成内容在最终落地前会被修改。

对代码尤其如此。

原因很简单：如果代码不是人一行一行写出来的，那么理解其上下文的成本就会上升。为了判断一段 AI 生成代码是否可接受，往往需要同时回看：

• prompt
• 规格说明
• 任务边界
• agent 使用的上下文
• 相关依赖与系统约束

这不是减少工作，而是把工作从“编写”转移到了“理解与裁决”。

过去，工程师一天里本来就有相当比例的时间不在写代码，而是在开会、写文档、沟通需求、排查问题、处理发布和维护系统。现在 AI 能写更多代码，空出来的时间并没有变成轻松，而是被更多判断任务填满了。

于是，越来越多团队开始出现一种新角色形态：builder。这里的 builder 不局限于传统软件工程师，而是指任何真正理解客户问题、能快速做原型并把软件搭起来验证想法的人。这个角色的核心能力不再只是写代码，而是两件事：

1. 理解上下文
2. 做判断

这也是 AI 时代最稀缺的部分。

什么是决策疲劳，为什么它会变成新的研发瓶颈？

决策疲劳不是一个抽象概念。它在工程团队里的表现非常具体：

• PR 越来越多，且 diff 越来越大
• 一天内要审的东西变多
• 多个 agent 在后台并行工作，持续产生待确认内容
• 工程师一边 review 代码，一边参加会议，一边补文档和规格
• 感觉自己“很忙、很高效”，但真实产出未必同步提升

一些企业研究显示，企业用户的自动化强度同比增长了 55%，整体活动量增长了 46%。时间并没有同步增长，增长的是单位时间内需要处理的信息量和决策次数。

这就是“工作日更密了”。

高频决策会消耗认知资源。很多高决策密度岗位都会主动减少无关选择，例如固定穿着、标准化流程、多层复核，本质上都是在给关键判断保留注意力。软件工程也一样：好的判断不是灵感，而是上下文、经验、流程和验证体系共同作用的结果。

资深工程师之所以“资深”，并不是因为写得更快，而是因为：

• 建立了代码库和业务的长期上下文
• 知道哪里该小步手术式修改，哪里不能乱动
• 能区分“看起来能跑”和“真的可维护、可上线”

在 agent 编程环境里，这种能力变得更重要。经验越多的人，通常越会提供更多上下文，并让 agent 只做更小、更受限的改动；复杂任务需要喂入更多背景信息，反而不是去追求代码行数。

问题在于，人类判断不能无限扩容。随着工作密度增加、builder 们整天都在做选择，判断质量本身会下滑。决策疲劳的一个直接后果，就是更容易在局部地方变得粗糙。即便保留了“人工最终把关”，也不能假设人工一定可靠；人在疲劳状态下同样会漏掉问题，甚至造成严重事故，例如源代码泄露这类本质上由人为失误触发的问题。

所以，新的瓶颈不是模型生成能力，而是组织如何承载更多判断。

仅靠人工兜底，为什么不够？

很多团队的默认反应是：AI 可以生成，但最后必须有人审。这个原则没有错，但它不完整。

如果流程还是围绕“旧时代的交接方式”设计的，那么 AI 只会提高局部生产率，无法提高整体交付效率。典型现象包括：

• 单个开发者写得更快，团队协作反而更卡
• 生成速度远快于评审速度
• QA、发布、安全检查跟不上提交节奏
• handoff 和跨团队协调成本上升

这和当年研发效率指标从“代码行数、提交数”转向“变更失败率、部署频率”是类似的变化。指标重心从输入转到输出之后，关注范围也必须从个人动作扩展到整个过程：规划、编码、CI/CD、运维、发布和回滚。

AI 时代同样需要这个转变。真正应该被验证的，不只是某个函数、某次 prompt、某段 diff，而是从需求定义到最终交付的整条链路是否可靠。

为什么判断应该做端到端验证，而不是只盯单点检查？

把“判断”理解成测试会更容易看清问题。

• 单元测试验证某个功能或某次提交是否按预期工作
• 端到端测试验证整个流程最终是否正确

AI 辅助开发里的人工判断，也应该越来越像后者。

低阶工作被自动化之后，人的注意力应该上移到高阶问题：

• 需求是否定义清楚
• 约束和 guardrails 是否明确
• 允许使用哪些依赖
• 成功标准和失败模式是什么
• 安全、可靠性、可恢复性是否达标

换句话说，判断点应该更多放在周期的两端，而不是把所有精力都砸在中间的每个微小变更上。

前置判断：在生成之前把边界定清楚

在开发开始前，需要明确的是：

• intent：到底要解决什么问题
• functionality：系统应该具备哪些功能
• requirements：哪些约束必须满足
• guardrails：模型或 agent 不允许越过哪些边界
• allowed dependencies：允许引入哪些依赖与服务

这里的重点不是低层 API 调用细节，而是先把目标和约束表达成可执行的边界。随着开发速度提高 10 倍，QA 的验证速度也必须跟着提高；只靠人工逐项慢查，不现实。

后置判断：在交付结果上做最终验收

生成完成后，真正关键的是验证结果而不是迷信过程：

• 最终功能是否符合预期
• 是否存在明显失败模式
• 安全性是否达标
• 依赖是否可控
• 运行是否稳定、可观察、可回退

这并不意味着 commit 级 review 会完全消失，而是说它不该继续承担全部质量责任。未来更合理的方式是：局部检查保留，但核心裁决转向结果验证。

“人人都是 builder” 之后，流程该怎么改？

当产品、设计、工程都开始借助 AI 直接产出可运行原型时，传统的岗位边界会变得更模糊。

一种已经开始出现的实践是：把整个设计系统直接接入 Claude、Cursor 这类工具，让理解用户问题的人先把原型甚至前端代码做出来，再交给工程师完成 check-in 和后续集成。

这种流程有明显价值：

• 需求理解者离产出更近
• 原型验证速度更快
• 前后端协作的等待时间缩短

但边界也很清楚：不是所有角色现在都适合直接合入生产代码。比如设计师可以根据设计系统生成原型和前端实现，但在很多团队里，最终 check-in 仍然需要工程师审查。这不是保守，而是因为组织尚未建立足够成熟的验证和责任机制。

真正可行的路径通常是渐进式的：

1. 先让更多角色参与构建
2. 保留工程审查作为最终入口
3. 逐步补齐测试、依赖控制、安全检查和验收机制
4. 在验证体系成熟后，再讨论是否下放更大的提交权限

应该如何衡量 AI 时代的研发效率？

可以先明确排除几类指标：

更值得关注的是流程级和结果级信号，例如：

• 评审吞吐是否健康
• 从需求到上线的总周期是否缩短
• 变更失败率是否上升
• 回滚和修复成本是否下降
• 安全与依赖风险是否更可控
• 团队是否出现明显的 review 过载

这些指标的共同点是：它们反映的是系统是否真的更高效，而不是某个人或某个 agent 看起来有多忙。

现在最现实的结论是什么？

结论并不复杂。

第一，代码已经不再稀缺，判断力才是。
第二，AI 提升的是局部生成能力，未必自动提升团队级交付效率。
第三，研发流程的主要瓶颈正在从“写代码”转向“理解上下文、做出判断、完成验证”。
第四，只靠人工在每个 commit 上疲于奔命地兜底，不可持续。
第五，真正需要重构的是整个 SDLC，尤其是生成后的 handoff、评审、验证与验收。

如果团队已经在大规模使用 coding agents，最需要警惕的不是“AI 写错代码”，而是“组织还在用旧流程接 AI 时代的新产能”。前者是模型问题，后者是管理和工程系统问题，而后者通常更贵。

接下来更可能发生的，不是人彻底退出软件交付，而是人的职责继续上移：在前端定义意图、规格、边界和依赖，在后端验证结果、安全性与可靠性。中间大量低阶实现和重复检查，会越来越多地交给模型、agent 和自动化验证链路。

至于是否敢让 AI 按一份规格独立完成端到端开发，是否愿意把对每次提交的细粒度审查逐步让位给对最终结果的整体验收，很多团队今天还不会立刻回答“可以”。

但如果开发速度继续提升，而判断和验证体系不跟着升级，这两个问题迟早都得正面回答。

关于

关注我获取更多资讯

📢 公众号

💬 个人号