AI 编程工具改变了代码生产，却没让开发者更轻松
过去三年间，代码生成工具完成了从"高级自动补全"到"一键生成整应用"的蜕变。掌握最佳实践、熟悉语言陷阱的软件工程师，如今可以专注于创造性工作，把分号和括号这类琐事交给工具。
但一个核心问题始终悬而未决：代码变多了，软件产出的效率和质量是否真的提升了？
代码变廉价，代码审核&查验反而更贵了
在 AI 时代之前，代码之所以"贵"，是因为工程师稀缺——他们需要积累对语言、流程和范式的深度理解，才能写出好软件。相应地，业界也催生了一些简陋的生产力衡量标准：工时、代码行数、每日提交次数。这些指标容易量化，在缺乏更好替代方案的年代，看起来还算合理。
如今，AI 编程工具正在让这些旧指标卷土重来。 Arora 举了一个典型案例："我们团队有一位工程师，她产出代码量是其他人的 7 倍，而且代码质量也很高——提交记录完美，代码审核&查验也无可挑剔。 但结果是，团队其余六位同事把大部分时间都花在了审核&查验她的代码上，而不是写代码。" 这一现象揭示了一个关键矛盾：代码审核&查验是一项高度依赖全局视野的工作。 真正有价值的审核&查验，需要将单次改动放在整个系统的上下文中审视，理解其对周边模块的影响。"
你是在用自己的专业积累做担保，"Intuit 的 Carol Lee 博士如此形容审核&查验者的压力，"如果这次审核&查验出了问题，责任会被追溯到我——我是这段代码的门卫。" 这就不难理解为什么开发者普遍抵触接手遗留代码。" 每当团队接管一个旧代码库，首先想的就是重写，而不是修复，"Arora 说，"从零开始写代码，你天然理解它的逻辑；但阅读别人的代码并做出判断，难度要高出数倍。"
每个人都在变成"决策者"
Smartsheet 的调研显示，80% 的 AI 生成内容在定稿前都会经过人工编辑。这些编辑工作的核心，是补足 AI 缺失的上下文理解——没有人亲手写下那段代码，自然也就缺乏对代码意图的直觉把握。当软件工作的重心从"写代码"转移到"做判断"，所有参与者都将面临决策疲劳的困扰。
在 AI 赋能工作流之前，开发者每天本就有大量时间花在非编码任务上。如今 AI 包办了代码编写，空出来的时间被更多的审核&查验、会议和文档写作填满。Arora 将这种新角色称为 Builder（构建者）：任何能够理解客户问题、形成方案、快速原型并交付软件的人。
Smartsheet 以及加州大学伯克利分校哈斯学院的研究均指向同一结论：这种转变并没有让开发者的工作更轻松，反而让工作密度显著上升。"工时没变，但工作量密度变了，"Arora 总结道，"每天要做的决策数量、在大量信息中做出判断的频率，都与从前不在一个量级。"
当每个人都是决策者，质量天平倾向何方
对 SDLC（软件开发生命周期）后端环节的挤占最为明显：代码审核&查验、DevOps/SRE、安全审计、基础设施维护——这些原本就承受压力的岗位，如今面临着更密集的人工审核需求。Smartsheet 对企业用户的数据进一步印证了这一趋势：自动化强度同比上升 55%，整体活动量增加 46%。换句话说，工作日没有变长，只是变得更"密"了——自动化输出了更多产出，却没有消除人类对"何为正确"做出判断的刚需。
AI 编程工具的爆发让代码生成变得前所未有的简单，但一个隐忧正在浮现：生成的代码越多，人类需要做出的判断就越多，决策疲劳也随之加剧。当每位开发者都变成"全职裁判"，倦怠与错误率便开始攀升。
决策疲劳正在侵蚀代码质量
扎克伯格、乔布斯等每天做大量决策的人，习惯穿同一套衣服——减少一个决策，就能节省脑力用于真正重要的事。软件开发同样如此：资深工程师之所以资深，是因为他们积累了足够的上下文经验，知道何时该做小幅度的精准重构。
但 AI 编程时代，"提供什么上下文"变得前所未有的关键。Anthropic 产品负责人 Arora 指出："我们观察到，团队里最资深的工程师反而在加载更多上下文，然后做出更小的改动。他们处理的往往是最复杂的部分，需要的上下文远比代码行数多得多。" 问题在于，人类判断并不能充当完美的终极验证关卡。当开发者被迫整天做决策时，这些决策的质量会逐渐下降。Arora 引用了 Claude Code 产品负责人 Cat Wu 的一次访谈——她提到某次源码泄露事件本质上是人类失误。"即便有人类判断把关，错误仍可能发生，因为我们在某些环节会变得有些潦草。"
SDLC 正在被重新配置
快速生成的代码给团队协作带来了压力。组织开始重新设计软件开发流程，以缓解开发工作的强度。Arora 表示："不同公司、不同团队的成熟度参差不齐。我们正试图让工具和系统在各团队之间对齐，从而改善整体效率。" 开发效能的衡量指标已在悄然转变——从"代码行数"和"提交次数"，转向"变更失败率"和"部署频率"。行业从输入指标转向输出指标，开始关注整个流程而非个人产出。
判断验证应当端到端，而非局部
类比测试：单元测试验证某个功能或提交是否兑现了承诺，端到端测试则验证整个流程。人类判断应当成为对整体结果的验证，而不仅仅是抽查特定功能和提示词。
判断的关键关卡将出现在周期两头：
- 前端：开发者需要定义需求、护栏、规范和允许的依赖项
- 后端：需要明确成功/失败模式、安全性和可靠性
Smartbear AI 与架构副总裁 Fitz Nowlan 建议："从意图、功能和需求的角度思考，而非纠结于 API 调用或特定输入输出的底层细节。 你可以验证这些，但当开发速度提升 10 倍时，QA 速度也必须提升 10 倍——以火攻火，别无他法。" Arora 在自己的团队中已实践了端到端判断流程："我们正在打通从产品经理、设计师到工程师的整条链路，每个人都变成了构建者。 整个设计系统已集成到 Claude 和 Cursor 中。
理解客户问题的设计师直接构建原型和前端代码，然后移交给工程师检查入库。" "但目前我们的设计师还不能完全自主提交代码，仍然需要工程团队审核&查验他们的代码。 未来他们应该能够直接提交，但我们还没到那一步。" 易生成的代码带来了更难审核&查验的 Pull Request。 这些 PR 需要大量上下文和大量判断，开发者被迫更频繁地做决策——这是高强度的工作，正在导致决策疲劳和职业倦怠。
AI 问题或许终将需要 AI 解决方案来解决。模型、工具链和技术正在不断进化。你愿意信任一个仅凭一份规格说明就能端到端构建软件的 AI Agent吗？你愿意放弃对单个提交的审核&查验，换取对最终成果的审核&查验吗？如果软件工程师想在 AI 赋能的世界中高效工作，而不转行去做手工艺家具——我们或许必须学会对这两个问题都说"是"。
评论