James Shore：你需要能降低维护成本的 AI

原文来源：James Shore — You Need AI That Reduces Maintenance Costs — Agile 方法论先驱 James Shore 用数学模型证明：AI 编程工具如果不能帮你降低维护成本，最终反而会拖累你的生产力。

核心论点：一句话说清楚

James Shore 的论点非常直白：你的 AI 编程助手必须能降低你的维护成本，而且降低幅度要和你写的代码速度相匹配。写代码快了两倍？你最好让维护成本也砍半。快了 3 倍？维护成本降到三分之一。否则你就麻烦了——你在拿短期的速度提升换一个永久性的债务。

这篇文章在 Hacker News 上引发热议，因为它用数据模型而不是空谈，把一个很多开发者隐约感觉到但说不清楚的问题讲透了。

为什么维护成本决定了你的真实生产力

每行你写下的代码都需要维护：修 bug、清理设计问题、升级依赖等。不是说新功能或改进——只是"维持运转"这件事。每花一个月写代码，接下来的时间就要花一部分来维护它，而且只要代码还存在，这个成本就永远跟着你。

James Shore 用了一个"群体智慧"实验来估算这个成本。如果你问 50 个开发者"每写一个月代码，第一年要花多少天维护？以后每年要花多少天？"，取平均值大概会得到：

• 第一年：每写一个月代码，要花 10 天维护
• 之后每年：每写一个月代码，要花 5 天维护

这个数字本身可以争论，但重要的是趋势。把这些数据放到一个 10 年的时间跨度上，你会看到一个残酷的现实：

• 项目第一个月：100% 的时间在写新功能——太美妙了
• 到第 2.5 年：超过一半的时间花在维护上
• 到第 10 年：只剩约 12.5% 的时间能干新活

如果把维护成本减半（每写一个月只需 5 天/第一年），你可以多撑 3 年才到 50% 的维护泥潭。但如果维护成本翻倍，不到一年你的生产力就跌破 50%。

这个模型背后的道理很简单：你写了多少代码不重要，留给真正有价值工作的时间才重要。

James Shore 在职业生涯中专门被请去拯救那些 5-9 岁的创业公司，它们的问题完全符合这个曲线——团队不再能"搞定事情"了。

AI 进入后发生了什么？

现在假设你的团队刚刚用上了最新最火的 AI 编程框架（James Shore 调侃地称之为"Rock Lobster"），你的代码产出翻倍了！🎉

但坏消息是：为了让 AI 更快地生成代码，你在代码审查上松了手，代码质量下降，每行 AI 代码的维护成本也翻倍了。

画一下曲线：

• 第 36 个月引入 AI：生产力瞬间飙到 ~85%（因为写代码快了两倍）
• 5 个月后：生产力回到原来水平
• 再往后：比不用 AI 还低，并且永远无法恢复

为什么会这样？因为你用 AI 产出了双倍的代码，而双倍的代码量 × 双倍的每行维护成本 = 4 倍的总维护成本。这些新增的维护债务会像滚雪球一样吞噬你所有的时间。

就算你的 AI 代码质量和人工写的完全一样（维护成本不增加），情况也好不到哪去：

• 第 36 个月引入 AI：生产力飙升到 ~85%
• 19 个月后：生产力回到原来水平
• 40 个月后：净收益为负

仅仅用 AI 快写代码是不够的——快意味着你在相同时间内造了更多的东西，每一件都等着你未来去维护。

最可怕的问题：你退不回去

假设你决定"算了，AI 搞得代码维护不过来，我关掉它自己写"。这才是真正的噩梦。

当你停止使用 AI，所有的生产力提升都消失，但新增的维护成本不会消失。那些 AI 生成的代码还在库里，还得有人维护。所以你的生产力会掉到底，比以前更低。

James Shore 形象地说这就跟"加州旅馆"一样——你可以随时退房，但你永远无法离开。

数学真相

这个逻辑其实就是一个简单的数学关系：

• 编码速度 × 维护成本 = 总维护工作量
• 如果编码速度翻倍（×2），维护成本不变（×1），总维护工作量也翻倍
• 如果编码速度翻倍（×2），维护成本也翻倍（×2），总维护工作量变 4 倍
• 唯一能打破魔咒的方式：如果编码速度翻倍（×2），维护成本减半（×0.5），总维护工作量保持不变

换句话说，AI 的收益必须通过大幅降低维护成本来兑现，否则就不成立。

那么问题来了：能做到吗？

James Shore 坦率地说：目前看来，不能。

他看的各种测评和报道都说，AI 编程工具倾向于增加而不是减少维护成本。虽然有些人说 AI 帮他们理解大型系统，但真正意义上的"大规模降低维护成本"——尤其是需要和编码速度提升成反比的那种——目前还没看到。

这不是一篇反 AI 的文章。James Shore 指出了另外一些可行的杠杆，比如用 AI 来提升维护本身的效率，而不是期待 AI 写的代码天生就更可维护。关键是要双管齐下：

去追求编码速度的提升，但也要花同样多的精力去降低维护成本。

对独立开发者的启示

这篇文章对独立开发者尤其有价值。大公司可以多招人来分担维护负担，但独立开发者只有一个人。如果 AI 帮你一周写出了平时一个月的代码，但接下来三个月你都在修 AI 产生的 bug——那效率提升就是个笑话。

几点实操建议：

1. 不要追求速度，追求"可维护的速度"——AI 写的每一行代码，事后都要你花的额外时间和普通代码一样
2. 建立代码审查标准——不要让 AI 代码绕过审查流程，这是维护成本失控的第一道闸门
3. 定期清理 AI 生成的冗余代码——AI 喜欢生成"看起来对"的代码，但其中很多是冗余的，主动清理能降低长期维护成本
4. 把 AI 用于维护而不是生成——比如用 AI 做代码分析、重构、测试生成，这些直接降低维护成本的方向比生成新代码更有长期价值

James Shore 在文章最后说了一段很清醒的话：

去追求编码速度的提升，但也要花同样多的精力去降低维护成本。否则，你就会被困在加州旅馆——一个用短期的速度提升换永久债务的陷阱。