AI 编程的速度远超人类，这是一个不争的事实。无论是从零开始生成一个完整的应用框架，还是修复一个具体的 Bug，AI 几乎都能在几秒或几分钟内给出代码。然而，一个普遍的观察是，尽管程序员个人在编写代码的环节感受到了数倍甚至十倍的效率提升，但整个研发团队的交付效率提升却往往只在 30% 左右，远未达到人们的预期。这背后的原因，并非 AI 能力不足，而是深刻揭示了软件开发的复杂本质。
需要明确一个核心事实：编码速度不等于软件开发速度。在真实的软件工程项目中，程序员纯粹用于“敲代码”的时间占比通常不高，很多时候甚至低于 20%。更多的时间被消耗在编码之外的环节：与产品经理沟通、澄清模糊的需求；与前后端同事对齐接口定义；参与设计评审、架构讨论；编写和维护测试用例；以及处理部署、排查线上问题等。AI 极大地加速了编码这个单一环节，就好比给一辆在城市里送货的汽车换上了赛车引擎。虽然在没有红绿灯的旷野里，你可以体验到极致的速度，但在充满交通规则、路线规划和协作车辆的城市街道中，速度的瓶颈就不再是引擎本身，而是整个交通系统。团队协作中的沟通、对齐、妥协与等待，正是这些无法被 AI 自动化的“红绿灯”，它们稀释了个人编码速度的提升。
AI 将开发的瓶颈从“生产”推向了“验证”。AI 生成代码的速度越快，代码审查（Code Review）的压力就越大。过去，一个程序员一天写几百行代码，同事审查起来尚可应付。如今，在 AI 的辅助下，一个程序员一天可能产生数千行代码。这些代码虽然语法正确、逻辑看似合理，但往往隐藏着更深层次的问题。例如，AI 可能不理解项目的历史背景和技术选型，引入了不必要的依赖库；它可能为了实现功能而选择性能低下或存在安全隐患的方案；或者它写的代码虽然能通过单元测试，但在复杂的业务场景下存在边界问题。
更棘手的是，由同一个 AI 模型生成的代码和测试用例，往往存在“一致的盲区”。AI 写的代码可能不检查某个错误，而它写的测试也恰好忽略了对这个错误的验证，从而制造出“一切正常”的假象。这就要求程序员不能再像过去一样信任测试结果，必须投入更多精力去审查和验证 AI 产出的每一部分，角色从“代码生产者”转变为“代码审计员”。当审查和修改 AI 代码的时间成本，开始接近甚至超过自己动手写的时间，整体效率的提升自然会受到限制。
再者，AI 输出的质量上限，取决于使用者的认知水平。AI 并非一个能凭空创造的“许愿机”，它更像一个能力极强、但需要精确指令的“实习生”。程序员需要提供高质量、无歧义的需求描述、清晰的上下文和明确的约束，AI 才能生成可靠的代码。一个经验丰富的程序员知道如何将复杂问题拆解成 AI 可以理解的原子任务，能判断 AI 输出的优劣，并快速修正其错误。而对于经验不足或对业务理解不深的程序员，他们可能无法提出精确的需求，也看不出 AI 代码中的“坑”，最终陷入“AI 生成-运行出错-再问 AI”的低效循环。这种现象被称为“认知债务”：开发者通过 AI 跳过了对底层原理和项目架构的深入理解，虽然短期内完成了任务，但长期来看，其驾驭复杂系统的能力在退化，最终会在更关键的时刻“翻车”。
要真正释放 AI 的潜力，需要配套的工程基础设施变革。简单地给每个程序员配备一个 AI 编程工具，而不改变原有的开发流程和协作模式，是无法实现效率飞跃的。一些前沿团队发现，必须建立一套新的“驾驭”AI 的工程体系（Harness）。这包括：使用测试驱动开发（TDD）模式，先用测试用例这种形式化的语言为 AI 定义清晰的成功标准；建立明确的架构规范和代码规则，让 AI 在“轨道”上运行，而不是随意发挥；将团队的最佳实践和通用流程固化为 AI 可以调用的“技能（Skills）”，减少重复性的人工指导。当代码库本身对 AI 友好（例如模块清晰、注释完备），当工程流程能够自动化地验证 AI 的产出时，团队的整体效率才能突破 30% 的瓶颈，向着更高的目标迈进。
AI 编程带来的效率提升之所以未能达到“十倍”的理想效果，是因为软件开发是一个涉及沟通、设计、验证和协作的复杂系统工程。AI 仅仅优化了其中编码的一环，却将压力转移到了验证环节，并对使用者的能力和团队的工程实践提出了更高的要求。未来，程序员的价值将不再是写代码的速度，而是定义问题、做出判断、设计架构和保障质量的综合能力。驾驭 AI，而非被 AI 牵着走，将成为程序员新的核心竞争力。
