夜雨聆风
AI时代的软件开发,为什么大公司只提升了10%效率?
McKinsey最近做了个调查，问了300家企业同一个问题，用了AI工具后，整体生产力提升了多少。
答案有点尴尬，平均只有5%到15%
这个数字让人困惑。
因为如果你去问任何一个正在用AI编程工具的开发者，他们都能给你讲出十几个故事，那些原本要花几天时间的任务，现在几分钟就搞定了。
个体层面的效率飞跃是真实存在的，但为什么放到整个组织，这些提升就消失了？
问题出在从个人生产力到团队协作的那道鸿沟上。
新的瓶颈正在形成
当AI工具开始大规模进入软件开发流程，一些意想不到的瓶颈开始显现。
第一个瓶颈是工作分配。
AI对不同任务的效果差异巨大，有些任务它处理得极好，有些则表现平平。
同时，团队成员对AI工具的熟练程度也参差不齐。
这让工程经理很难判断该把什么任务分配给谁，该预留多少时间。
第二个瓶颈是代码审查。
很多公司给AI的需求描述还是传统的用户故事，写得比较模糊。
AI生成的代码不一定符合预期，但审查机制还是依赖人工。
结果就是，自动化了生成环节，却制造了更多需要人工审查的工作。
第三个瓶颈是技术债务。
卡内基梅隆大学最近有份研究指出，AI生成的代码正在加速技术债务的积累。
代码量上去了，复杂度也跟着上去了。
这些瓶颈的是什么？
是我们还在用旧范式的工作方式，去承接新范式的生产力。
大多数企业的软件团队还是8到10人的规模，还在跑两周一次的敏捷冲刺，还在用几年前定义的角色和职责。
这套体系是为人类开发者设计的，现在AI进来了，这套体系成了限制。
重新设计工作流程
McKinsey和一家国际银行做了个实验，他们没有简单地给团队配AI工具，而是重新设计了整个敏捷流程。
改变从需求定义开始。
产品经理不再写长篇的需求文档，而是直接和AI一起迭代技术规格说明。
他们会让AI生成多个原型，然后在安全性、可观测性等维度明确验收标准。
这样做的好处是，开发者拿到的需求更清晰，后期返工大幅减少。
团队被按工作流重组。
一个小组专门处理小bug修复，另一个专注绿地开发。
这样做是因为AI在这两类任务上的表现模式完全不同，分开处理效率更高。
协作开销被压缩。
以前产品经理要等数据科学家提供分析才能调整优先级，现在他们直接用AI观察实时用户反馈，自己做决策。
这些调整带来的结果是，代码合并量增加了51%，AI工具的使用频次提升了60倍。
更重要的是，这些提升直接对应到了银行的业务优先级上。
角色正在重新定义
McKinsey的调查发现，那些效果最好的公司，有个共同特征，他们重新定义了团队角色。
工程师的工作从执行代码转向编排任务。
他们需要思考的是如何把工作拆解成适合AI处理的部分，如何审查AI的输出，如何把不同部分组装起来。
产品经理开始直接用代码做原型，而非在文档上反复打磨。
这个变化看起来微小，但意味着产品定义的方式从根本上改变了。
前端、后端、QA这些传统角色开始合并。
新的角色叫”产品构建者“，他们需要有全栈的理解能力，能够管理和编排AI代理，对整个代码库的架构有清晰认知。
团队规模也在缩小。
从”两个披萨”的8到10人团队，变成“一个披萨”的3到5人小组。
但这些小组的产出并没有相应减少，因为AI填补了人力的缺口。
McKinsey和另一家科技公司的合作案例显示，用同样的人数，他们组建了更多的小组，每个小组的产出保持甚至超过了原来大团队的水平。
代码质量也没有下降。
有意思的是，70%的被调查公司完全没有调整角色定义。
他们给团队配了AI工具，但期望还是按老方式工作。
这就像给马车装上了发动机，但还要求它按马车的方式运行。
规模化的真正挑战
从一个团队到几百个团队，这是完全不同的游戏。
McKinsey和一家科技公司的合作经历很能说明问题。
他们推出了覆盖产品开发全生命周期的AI工具，初期使用率上去了，但很快就掉下来。
要么不用，要么用得很糟糕。尽管不断增加用户，整体影响几乎没变。
他们不得不重启整个项目。
重启的核心是什么？McKinsey的说法是“把很多小事做对”。
这包括，重新设定期望。
对开发者来说，这意味着什么？对产品经理意味着什么？每个角色的日常工作会如何改变？
更实操的培训。
不是听讲座，而是”带着你的代码来”。
有教练在旁边，特别是最初几个冲刺周期，这是养成新习惯的关键时期。
建立测量体系。
你需要知道什么在改变，什么在改善。
设置新的认证和激励机制。
这些看起来是小事，但对驱动行为改变至关重要。
这些单独看都不起眼，但组合起来，才构成了真正的变革。
测量什么，就会得到什么
McKinsey的调查有个意外发现，表现最差的那些企业，甚至不测量速度，只有10%在测量生产力。
这解释了很多问题。
如果你不知道要往哪里去，任何路都可以。
McKinsey建议的测量体系分三层，
输入层，投入了多少钱买工具，花了多少时间做培训和变革管理。
输出层，这里大多数公司只关注AI工具的采用率和开发速度的提升。
但McKinsey认为还要看开发者的NPS评分，他们是更享受工作了还是更沮丧了。
代码的安全性、质量、韧性也要跟踪，比如优先级bug的平均解决时间。
经济结果层，这是高管层关心的，达到收入目标的时间缩短了多少，高质量功能带来的溢价是多少，客户数量增长了多少，每个小组的成本降低了多少。
这套体系的价值在于，它把AI工具的使用和业务结果连接起来。
不是为了用AI而用AI，而是为了创造可测量的商业价值。
未来会是什么样
McKinsey给出的愿景是，更短的冲刺周期，更小的团队，但团队数量更多。
这个模型的假设是，即使AI Agent变得更智能，人类变得更熟练，这个基本结构仍然成立。
人机协作的最优单元不是大团队，而是小而灵活的小组。
他们给企业的建议很直接，现在就开始。
因为这是一场人的变革，需要时间。
等到AI工具完全成熟再动手，就太晚了。
变革本身就是学习过程的一部分。
另一个建议是，找到适合自己的模式，设定大胆的目标。
不同类型的工程任务可能需要不同的人机协作模式。
比如现代化遗留代码库，这种任务上下文需求高但输出明确，适合”Agent 工厂”模式，人类提供初始规格和最终审查，中间尽量少干预。
而新功能开发，可能更适合迭代循环模式，AI作为共创者提供多种选项，加快反馈循环。
关键是要实验，要测量，要快速调整。
那些在AI时代领先的公司，不是因为他们的AI工具更好，而是因为他们更早意识到，工具只是起点，真正的变革在于如何重新组织人和工作。
从10%到50%甚至更高的效率提升，这道鸿沟的是组织能力的鸿沟。
技术已经准备好了，我们准备好面对这样的未来了吗？
