AI生产力落差：代码提速≠整体增效
毫无疑问，AI已经提升了工程团队的生产力，未来还将带来更大助力。但有些领导者误以为，成品功能的开发速度能赶上原型制作。遗憾的是，生产级功能的开发耗时仍与过去相差无几。难道AI不该让我们人人都成为效率翻十倍的超级开发者吗？
要理解这种AI生产力落差，我们得先搞懂开发者的真实工作时间分配。事实上，编写新功能代码并非他们的主要耗时环节，尤其是资深工程师，他们要花大量时间思考“该写什么代码”，而AI目前还无法简化这部分工作。
有时我甚至觉得，AI反而拖慢了非编码类工作的进度。比如阅读AI生成的产品需求文档，或是Linear工单，耗时比阅读人工撰写的内容更长。AI写的东西往往过于冗长，反而让人难以提炼核心信息。
不过，用AI让自己省事、却给他人添负担，就是另一回事了。暂且假设AI只发挥积极作用，即便如此，实际情况也没想象中乐观。先来看一位资深开发者的情况：若在大型科技公司任职，他的每日时间分配可能如下：
| 资深开发者 | AI普及前（小时） | AI普及后（小时） |
|---|---|---|
| 编写新代码 | 1.5 | 0.5 |
| 阅读与调试 | 1.5 | 1.0 |
| 设计与架构 | 1.0 | 1.0 |
| 代码评审 | 0.75 | 0.75 |
| 文档与行政工作 | 0.75 | 0.75 |
| 测试、CI/CD与部署 | 0.5 | 0.75 |
| 指导/结对编程 | 0.5 | 0.5 |
| 会议 | 1.5 | 1.5 |
| 总计 | 8.0 | 6.75 |
由此可见，即便AI让编码效率提升至原来的3倍（且假设因新增代码变多，测试、CI/CD与部署耗时略有增加），这位资深开发者每天也仅能节省1.25小时，效率提升约15%。1
再看一位情况类似的初级开发者：
| 初级开发者 | AI普及前（小时） | AI普及后（小时） |
|---|---|---|
| 编写新代码 | 2.75 | 1.0 |
| 阅读与调试 | 1.5 | 1.0 |
| 设计与架构 | 0 | 0 |
| 代码评审 | 0.5 | 0.5 |
| 文档与行政工作 | 0.5 | 0.5 |
| 测试、CI/CD与部署 | 0.75 | 1 |
| 学习/结对编程 | 1.0 | 1.0 |
| 会议 | 1.0 | 1.0 |
| 总计 | 8.0 | 6 |
AI为这位初级开发者每天节省2小时，效率提升约25%。这一提升幅度远超资深开发者，原因在于初级开发者的编码耗时占比更高，而这正是AI最能发挥作用的环节。
讽刺的是，既然AI对初级开发者的助力更大，我却仍听到不少领导者说：“我们只招资深工程师，因为AI能替代初级开发者的工作了。”但实际上，从AI中获益最多的恰恰是初级开发者——尤其是那些善于将AI用作学习工具，而非仅把它当成包揽琐碎工作的“热心帮手”的人。2
如果你对上述结论感到惊讶，或是认为开发者每天花在编码上的时间远不止几个小时，那你可能并未真正理解这份工作的复杂性。不妨换个角度想：假设你要招聘一位编码能力不错，但缺乏系统思维、没耐心和他人协作解决难题、也无法把模糊需求拆解成具体任务的开发者，你肯定不会录用他——因为他欠缺的，正是这份工作最核心的技能。编码能力只是入门门槛而已。
当然，AI仍在不断进化，随着它能胜任的开发者工作环节越来越多，团队生产力理应持续提升。但就目前而言，别指望生产力会出现爆发式增长——尤其是资深员工的效率，不会有太大变化。