AI驱动开发是一种将AI技术融入从需求定义、设计、实现到测试的整个开发流程中，并由人类进行判断和监督的开发方法。尤其是在实现阶段，利用AI辅助编码的技术在过去一年取得了显著进步，代码编写速度大幅提升。然而，许多人可能会感受到，虽然编码速度加快，但从开发到发布的时间并未显著缩短。
这种变化无法仅用传统的“代码行数”或“合并请求数量”来衡量。虽然AI加速了编码过程，但工作负担正逐渐转移到需求和设计决策、代码审查、测试以及AI监督等环节。
换言之，AI驱动开发不仅改变了代码编写速度，开发瓶颈和生产力的衡量方式也在发生根本变化。
本系列文章将基于实际AI驱动开发的经验，从需求定义到测试，梳理当前开发现场的变化。本文第一部分将从上游、下游、认知负荷和开发指标四个角度，探讨整体开发的变革。
代码生成速度领先提升
根据JetBrains的开发者调查，85%的开发者日常使用AI工具。日本国家Google Cloud发布的2025年DORA报告显示，90%的技术人员在工作中使用AI。MCP服务器注册数截至2026年8月已超过7万台。
OpenAI内部案例中，3名工程师利用Codex，在5个月内生成了约100万行代码和约1500个合并请求。人类开发者更多地专注于向AI下达指令和审查成果，而非直接编写代码。
组织层面上，Faros AI分析了22000名开发者和4000多个团队，发现AI使用率高的团队中，每位开发者完成的史诗任务数量提升了66%，任务吞吐量提升了33.7%。
但同一调查也显示，代码审查开始时间延长了156.6%，审查所需时间增加了441.5%。这表明当前并非整体开发速度提升，而是实现阶段加速，负担转移至上游和下游环节。
在AI驱动开发中，编码负担下降的同时，决定“做什么”的上游环节和确认“生成内容是否正确”的下游环节变得更加重要。此外，能够同时处理的任务增多，也可能导致开发者的认知负荷加重。
上游环节：决策负担加重
上游环节整体并未变慢。Vella和Blincoe的研究显示，设计阶段所花时间略有减少。
但根据日本国家Jellyfish 2026年报告，AI主要用于“编写代码”的比例为53.1%，而“需求分析”为35.8%，“规格制定”为24.2%，说明上游环节尚未完全交由AI处理。
人类面对模糊需求时，往往会停下来询问“是A还是B”，而AI代理则会推测缺失的前提，生成看似合理的代码。因此，上游的模糊性可能不会以提问形式出现，而是以自动生成的代码体现。
随着实现成本降低，错误的需求或设计决策也会被快速实现。关键不在于规格书的篇幅，而是明确区分哪些判断交给AI，哪些由人类负责。
下游环节：从“制造”转向“验证”
代码生成越快，判断“是否允许这次变更”的工作量就越大。
LinearB对810万条合并请求的分析显示，AI生成的合并请求接受率为32.7%，而人类编写的为84.4%。因此，AI写代码并非开发的终点。
Vella和Blincoe的研究也表明，82%的开发者认为编码时间减少，但40%和42%的开发者在代码审查和测试上花费的时间有所增加。这表明开发工作正从“制造”向“验证”转变。
传统的代码审查是人类审阅他人编写的代码，而AI驱动开发中，需要验证大量“看似合理”的代码是否符合需求和设计意图。
人类认知能力成为新瓶颈
使用AI代理后，单个任务所需时间缩短，但开发者需要同时管理多个任务的输出和测试结果，进行多条合并请求的审查。
虽然动手操作负担减轻，但判断和上下文切换的负担增加。Vella和Blincoe的研究显示，84%的开发者感受到生产力提升，但感受到开发体验恶化的比例从14%上升到27%。
Margaret-Anne Storey提出的“三级负债模型”从软件健康角度分析了这一问题：
- 技术负债：架构和代码质量上的积累问题
- 认知负债：人类对系统理解和推理能力的缺失
- 意图负债：目标、约束、规格和设计决策未被保留
AI生成代码时，开发者缺少实现过程的亲身体验，难以形成“为何采用该结构”“修改某处会影响什么”的理解。
AI能并行处理更多任务，但人类理解和判断能力的提升速度有限。
AI时代如何衡量生产力？
代码量增加并不等同于代码质量提升。
随着AI改变工作形态，单纯用时间、代码行数、提交次数来衡量生产力已不适用。应关注从需求到发布的交付周期、审查等待时间、返工次数、缺陷率，以及最终交付的价值。
总结
AI驱动开发的核心变化不仅是编码速度的提升。
实现成本降低后，开发瓶颈转移到上游的决策、下游的验证以及人类的认知能力。
未来关键在于准确决策“做什么”，有效验证AI生成成果，并保持团队对开发内容的理解，最终转化为价值。
开发者的角色正从代码实现者转变为AI的指挥者、成果的判定者和开发流程的监督者。相应地，开发方法和生产力衡量方式也需重新设计。
