本文翻译自 What's Missing With AI-Generated Code? Refactoring，主要是在讨论随着 AI 编程助手的普及，代码重构减少而重复代码增加，不要忽略了软件长期维护的重要性。
上个月，GitClear 在其 AI Copilot代码质量报告 中发布了对 2.11 亿行代码的分析结果。其中一个关键发现是：重构的代码数量正在降低，而重复的代码数量持续攀升。事实上，2024年首次出现了新增重复代码量超过重构工作量的情况。
这种趋势被归因于 AI 编程助手的兴起。如果持续发展，我们可能正走向一场软件危机。
AI 提升生产力
如果您从事软件开发，一定听过 "AI 不会取代开发者，但使用 AI 的开发者将取代不使用 AI 的同行" 的说法。这传递了一个明确信号：要么拥抱 AI，要么面临职业转型。更积极的解读认为，AI 能帮助我们摆脱低价值的重复性工作。
Stack Overflow 最新 开发者现状调查 显示，超过 60% 的开发者已在工作中使用 AI，更多人计划跟进。提升生产力是采用AI 的主要动机。但正如GitClear报告揭示的，盲目追求效率提升就像拆掉自行车链条来加快蹬踏速度------终将适得其反。
在软件开发领域，我们正在加速代码库的变更频率。预计到 2025 年，代码变更速率将达到 AI 普及前（2021年）的近两倍。
代码变更速率图表：包括 2025 年预测总量。图片来源：Octopus Deploy。数据来源：GitClear
这种生产力飞跃被许多利益相关方（尤其是AI供应商）视为重大利好。但我们不应忘记先辈的智慧：生产力指标难以准确衡量知识工作。正如彼得·德鲁克在 1963 年所言："世界上最没有效率的事情，就是以最高的效率去做一件根本不值得做的事情。"
重构正在锐减
在我们开始痴迷于生产力之前，切勿将软件行业沉淀下基础实践置之脑后，而重构就是其中之一。通过持续优化代码结构，保持组件低耦合、概念单一化，才能构建可靠系统。我们需要将相同变更原因的部分集中管理，将不同变更驱动的模块分离处理。
笔者的书架上摆满了 Kent Beck、Emily Bache、Martin Fowler、Robert C. Martin、Michael Feathers、Rebecca Parsons、Steve McConnell 等人的软件设计著作。这些经典书籍蕴含着构建可持续软件的永恒智慧 ------ AI 助手也不能颠覆这些软件开发的基本法则。
加速代码变更必须与优化系统内部结构保持同步。换言之，要实现长期成功，重构速度必须与代码变更速度相匹配。但现实情况恰恰相反。
GitClear 通过 "移动代码"（即保持核心逻辑但优化设计的变更）这一指标来追踪重构行为，包括 "提取方法"、"重命名变量" 等经典模式。自 2021 年以来，重构在代码变更中的占比从 24% 骤降至不足 10%，而复制/粘贴的重复代码比例则从 10% 攀升至近 15%。
代码变更趋势：重构锐减与重复激增。图片来源：Octopus Deploy。数据来源：GitClear
预测显示，2025 年重构占比将跌至 3%。软件系统或许还能勉强运行，但技术债务的雪崩终将来临。
迟来的教训
笔者曾亲历某组织通过实施持续交付改造混乱的系统。通过测试自动化、部署自动化和完善的监控告警体系，不仅显著提升了可靠性，更重建了开发团队与业务方之间的信任。
离职后，该团队认为测试数据管理过于繁琐，删除了用于重置测试环境的数据库脚本。在数月间，集成测试依然运转正常 ------ 只要没人手动修改测试数据。
当测试数据最终被污染后，团队面临艰难抉择：是重建测试数据管理脚本，还是删除报错的测试用例？在交付压力下，他们选择了后者。
删除测试不会立竿见影地引发问题，功能仍能运行一段时间。但错误终将悄然滋生，最终演变成反复发作的顽疾。这就是追求短期效率牺牲长期可持续性的代价 ------ 当问题显现时，往往已积重难返。
勿要因此失彼
AI 代码助手创造了完美的抛物线式开发速度假象。就像零重力飞机通过抛物线飞行制造失重感，这些工具让我们误以为在翱翔天际，实则正在自由落体。
要让 AI 真正持续提升生产力，就不能放任其主导代码质量。我们必须在加速开发的同时，以同等力度维护系统健康。否则，当下的效率狂欢，终将沦为明日的技术灾难。软件开发的真谛，从来不是比谁写代码更快，而是比谁构建的系统更经得起时间考验。