AI 让代码产出速度提升 10 倍，为什么我们的软件交付成功率却停滞不前？

最新推荐文章于 2025-12-02 15:55:42 发布

原创最新推荐文章于 2025-12-02 15:55:42 发布 · 580 阅读

13 ·

CC 4.0 BY-SA版权

文章标签：

#人工智能 #低代码

大家好，我是Tony Bai。

AI 编程助手、自动化代码生成、Agentic 开发系统……我们正目睹一场由 AI 引领的软件生产力革命。代码的产出速度正以 5 倍、10 倍甚至更高的倍率疯狂增长。理论上，我们应该能更快、更好地交付软件。但现实却给了我们一记响亮的耳光：我们的软件交付成功率，数十年来几乎毫无寸进，甚至有所倒退。

这就是 AI 时代软件开发的核心悖论：我们获得了前所未有的“产出”速度，却未能将其转化为更高的“成功”概率。最近，一篇题为《我们是否应该在 AI 时代重温极限编程？》的文章深入探讨了这一现象。文章作者尖锐地指出，我们可能正陷入一个“速度陷阱”，用最先进的工具去解决一个早已不是瓶颈的问题。

本文将和大家一起解读一下这篇文章的核心论点，探讨为何“速度”本身无法带来成功，以及为什么作者认为，那条通往高价值交付的道路，可能需要我们重温极限编程（Extreme Programming, XP）的智慧。

产出的幻觉：我们一直在加速，却在原地打转

文章的核心论点始于一个简单而深刻的观察：代码的生成速度，从来就不是软件开发的根本瓶颈。作者回顾了过去几十年的技术演进，从高级语言到 DevOps，再到云原生，每一次变革都极大地提升了代码产出效率，而 AI 只是将这条“加速”之路推向了极致。

为了支撑这一观点，文章引用了多项权威数据，揭示了一个残酷的现实：

根据长期运行的 Standish CHAOS 研究报告和麦肯锡的分析，超过 70% 的数字化项目仍以失败告终。
从 1994 年到 2020 年，尽管工具链发生了翻天覆地的变化，但项目按时、按预算成功交付的比例净增长微乎其微。

作者由此得出结论：我们只是在更快地制造砖块，却不知道如何用它们建起一座坚固、美观且符合用户需求的房子。当 AI 将制造砖块的成本降至接近于零时，设计的蓝图、工匠的协作和地基的稳固，就成了决定成败的唯一关键。

失控的熵增：AI 如何放大我们最坏的习惯

在文章的分析中，最一针见血的部分莫过于其对 AI 风险的论述。作者认为，当代码生成变得毫不费力时，一个更致命的风险随之而来：我们生产软件垃圾的速度，远远超过了我们验证和清理它的速度。

在没有严格约束的情况下，文章指出 AI 会成为“坏习惯”的放大器：

快速堆积技术债: AI 可以迅速生成大量未经深思熟虑的逻辑，形成一个无人能懂、难以维护的“意大利面条式”代码迷宫。
固化错误的假设: 作者引用了近期研究，表明大语言模型（LLM）的准确性会随着上下文窗口的增长而下降。这意味着 AI 极易在长链条的生成中引入微小错误，并基于这些错误继续构建，最终导致整个系统的脆弱性。
绕过人类协作: 文章还表达了一种担忧，即开发者可能会倾向于“与 AI 结对”，而不是与同事协作，这将严重削弱团队的共享上下文（Shared Context）——这是解决复杂问题、确保软件长期健康的最宝贵资产。

文章的观点是，AI 让我们以前所未有的速度，构建出我们自己都无法理解和控制的复杂系统，而这恰恰是极限编程（XP）从诞生之日起就致力于解决的“失控的熵增”问题。

XP 的反向智慧：唯一的出路是“刻意放慢”

面对这种由 AI 加剧的困境，文章提出了一个看似有悖常理的解决方案：拥抱极限编程（XP）的反向智慧，即通过“刻意的摩擦”来“刻意放慢”。

作者对 XP 的核心实践进行了重新解读：

结对编程 (Pair Programming): 它被描述为一种内置的实时代码审查、知识传递和风险对冲机制，其目的不是减慢速度，而是强制建立共享上下文。
测试驱动开发 (TDD): 文章强调，TDD 强迫我们将关注点从“实现”拉回到“意图”，在写任何功能代码前，先定义清楚“我们到底想让系统做什么”。
持续集成 (CI) 与小批量发布: 这些实践被视为创建短而快的反馈循环的关键，使团队能以最小的成本发现错误、验证假设并调整方向。

在作者看来，XP 的所有实践都在为一个终极目标服务：通过极致的沟通、简约的设计和快速的反馈，来对抗软件开发中固有的不确定性。