AI 生产力陷阱：代码加速不等于交付加速

本文基于 Bjorn Roche 的《The AI productivity gap》。以下引用的百分比是作者的说明性模型，而非普遍测量。

AI 加速一个阶段——而非整个工作

科技公司中有个反复出现的期待：如果 AI 编写代码快得多，完整的交付也应该以类似的速度出现。这个前提看起来很直观，但遇到了工程师日常工作的实际构成。

写新代码只是工作的一部分。在此之前，有人需要理解不完整的需求，调查系统的行为，决定解决方案的边界，并与他人协商选择。之后，还有代码阅读、调试、审查、测试、集成、部署、文档和会议。AI 已经在这些阶段的多个环节提供帮助，但它的优势最为明显的地方正是总时间通常最少的地方：把一个相对明确的意图转化为代码。

这种加速一项活动和加速整个流程之间的差异，就是 AI 生产力的鸿沟。

Roche 的模型：资深工程师提升 15%，初级工程师提升 25%

Roche 提出了一个简单的例子。对于资深开发者，他估计 AI 出现前每天有 1.5 小时用于编写新代码。即使假设该工具将这部分时间减少到半小时——这是一个激进的速度提升——每天的总时间也只从 8 小时减少到 6.75 小时。节省下来的是 1.25 小时，大约 15%。

在初级人员的示例场景中，更多时间集中在代码编写上：AI 出现前 2.75 小时，之后 1 小时。每天会从 8 小时减少到 6 小时，提升 25%。

这些数字不应被视为基准。这个例子的力量在于计算：全球影响力受限于工具实际加速的流程部分。如果循环的 70% 仍然需要解释、决策、协调和验证，任何本地代码生成的改进都不会自动将其转变为快三倍的工厂。

瓶颈是协作推理

在更专业的工作中，时间的流向不是因为打字速度慢。它流向了那些还没有现成答案的问题：哪个问题值得解决，哪些数据是可信的，什么变更可能会破坏其他领域，什么要简化，什么要向团队解释，如何在生产中验证结果。

这些任务有本地背景、分布式后果，往往还有模糊的需求。AI 可以帮助探索替代方案、总结信号和生成草稿。尽管如此，有人需要认识到摘要是否遗漏了重要条件、计划是否符合架构，以及更改是否对用户安全。

还有一个通常从生产力报告中被忽视的成本：由 AI 生成的劣质内容。过长的规范、目标不明确的任务或看似完整但隐藏决策的文档，可能会将时间从写作者转移到需要阅读和执行的人。增加其他人工作的个人收益不是系统收益。

为什么这改变了关于招聘的对话

如果 AI 的帮助最大恰好在初级专业人士花费相对更多时间的阶段，那么"我们不再需要招聘初级员工"的结论值得谨慎。Roche 的论点是相反的：当这些人使用 AI 作为学习、审查和实验的工具时——而非理解的替代品——他们可以获益很大。

一个健康的团队仍然需要培养能够分解问题、精确请求帮助、审查输出并建立专业知识库的人。削减新专业人士的进入可能看起来在本季度很有效，但会在未来造成经验的短缺。

如何衡量生产力而不陷入代码计数

与其把生成速度作为目标，领导可以观察流程：

工作在哪里等待？ 需求、批准、环境、审查和事件表明了与"缺乏代码"不同的瓶颈。

节省的时间是否转化为了质量？ 更多有用的测试、更好的审查和更清晰的文档是具体的结果。

工具是减少了工作还是重新分配了工作？ 比较生成材料的人与之后需要解释、审查和纠正的人。

团队学到了吗？ 快速交付而没有人能够维持的结果，在下一次变更时会产生利息。

AI 倾向于随着时间的推移改进工作的更多部分。在那之前，最有用的期望不是生产力的魔幻飞跃。而是利用额外的速度来缩短学习周期、减少机械任务，并为仍然依赖技术判断和协作的工作留出更多空间。

来源：Bjorn Roche — The AI productivity gap.

For further actions, you may consider blocking this person and/or reporting abuse