AI编程的甜蜜陷阱：技术债务加速累积

自今年春节后，AI编程步入可用阶段，众多团队纷纷深度应用。起初的三个月，代码产出实现了数倍增长，众人仿佛发现了“银弹”。然而，如今我发现许多人可能也察觉到了新的隐忧：

代码生成的速度并未减缓，但产出创新性功能的比例似乎在不断萎缩。

人力投入未减，AI也并未变笨，反而在不断进化。问题或许在于，对这些AI产出的成果进行维护的负担正在不断堆积。

海外博主James Shore近期发表了一篇文章，通过一道数学题，剖析了AI编程背后的账本。

这道算术题基于一个常识：每一行代码都需要维护——修复Bug、更新依赖、清理重构，无论是开发新功能还是确保系统运行，都需要投入资源。

假设编写一个月的代码，接下来一年需要花费10天维护，之后每年5天。无论这个数字是否精确，只要代码存在，这笔成本就需持续支付。

这不是“编写烂代码”特有的问题，高质量的代码同样会产生维护成本：依赖项会过期，运行环境会变化，当初合适的设计会被新需求挤压变形。

在AI的辅助下，每欣喜地创造一个新代码，就背上一笔新债。这好比物业费：名下多一套房，下个月起就要持续缴费。

这笔债务与今天是否写代码无关，只要代码存在，债务就在。仓库里的代码交接给他人，还债的责任就转移给了下一个接手者。

Shore利用50位开发者的“集体智慧”估算制作了一张表格。根据表格的年化费率，一个新项目在第30个月（两年半）时，团队超过一半的时间不再用于开发新功能，而是用于维护前29个月积累的代码。

10年后，维护工作将消耗殆尽，团队将无暇开发任何新功能。

上述模型并未关注是否有AI。它描述的是任何持续产出代码的团队都会经历的流程。但AI改变了一个变量：债务积累的速度。

假设AI使团队月产出翻倍，且这些代码的维护成本与人工代码相当，那么每月新增的维护负担也会翻倍。

但问题不止于此。AI生成的代码更难维护——并非质量低劣，其通过的测试不比人工代码少。问题在于变量命名在逻辑上正确但缺乏直觉，抽象层级的选择看似正确但跳跃过大，错误处理像是平均了所有见过的代码。审查者扫一眼觉得没问题，合并后，下一个接手者要花更多时间理解那段缺乏作者意图的代码。

Shore做了一个保守假设：AI使维护成本也翻倍。产出2倍，单位成本2倍，每月新增负担4倍。原来两年半达到50%维护占比，现在5个月就达成了。此后生产率跌回起点，几个月后甚至低于未使用AI时——人工代码的维护成本并未消失，AI加速积累的债务正在产生更大的债务。

自然的反应是停止使用AI。产出速度立刻回到原水平，但AI时代积累的代码仍在仓库中。维护是每行代码自身的事，与当初如何编写无关。

Shore称此为“加州旅馆陷阱”：你可以随时结账，但永远无法离开。代码一旦入库，维护的债务就永远挂在你身上。

陷阱最阴险的地方在于延迟性：贷款消费的快感在前半年，账单在一年后一页页翻不过来。等你发现无法开发功能时，问题已埋在几十万行代码中。

有人会说：不使用AI生成代码，而是用AI理解代码、辅助重构、加速审查，这不就是在降低维护成本吗？方向可能正确，但根据Shore的算式，降幅有硬性指标。

产出翻倍，维护成本减半——每月新增总负担 = 2 × 0.5 = 1倍。持平。这是及格线。产出三倍，维护成本必须降至三分之一；产出四倍，降至四分之一。

达不到倒数关系，账就是亏的。产出翻倍但维护成本降至八成，总负担仍是1.6倍——虽慢，但仍往坑里滑。

目前几乎所有AI编程工具的主战场都在生成端——编写速度、SWE-bench排名。维护成本端，仅有零星讨论，缺乏系统性测量，更无产品将其纳入路线图。

讽刺的是，软件工程行业深知维护成本决定长期产出。

Ward Cunningham于1992年提出“技术债务”，指为短期速度牺牲可维护性，利息在未来吃掉更多时间。Martin Fowler随后用“设计耐力假说”量化——好的设计不会让你现在更快，但能让你持续更快。

AI编程工具的兴起撞上了行业最古老的问题。区别在于，过去人写烂代码，至少知道在偷懒。AI写的代码，你不一定知道它“烂”——通过所有测试，逻辑自洽，但读起来不对。这种“不对”很难在代码审查中量化拦截，但会在未来每次修改时变成额外的认知成本。

Shore并非AI悲观主义者，他在文章结尾补充：模型中还有其他杠杆，即使AI没有让代码更易维护，如果利用AI真正提升维护效率，这条路仍可行。

现在需要有人从维护端设计产品，而非继续在生成端卷benchmark。

希望一切还来得及，在更多人被技术债务压垮之前。

参考原文链接

https://www.jamesshore.com/v2/blog/2026/you-need-ai-that-reduces-your-maintenance-costs

https://martinfowler.com/bliki/DesignStaminaHypothesis.html

https://wiki.c2.com/?TechnicalDebt