夜雨聆风
写代码变快这件事，所有人都兴奋，除了一个人——James Shore。
他是 2001 年敏捷宣言的十个签署人之十，做了 23 年咨询，专接那种"做了五六年突然推不动了"的创业公司。这种人见多了就会有一种直觉：快的东西不一定是好事。
他写了一篇文章，给 AI 编码工具算了一笔没人愿意算的账：维护成本。
结论很冷。你的 AI 让编码速度翻倍，那它必须把维护成本砍到一半。做不到，五个月后你不如从前。就算 AI 写的代码维护成本跟人手写的一样，十九个月后收益归零，四十个月净负。
不是"可能"。是算术。
代码是负债，不是资产
每一行写出来的代码，从那一天起就是一个负债。
它需要修 bug，要跟着依赖升级，要在新环境里跑通，要在新人来的时候让人看得懂。这些东西不产生新功能，但你不做它们就全停。
有人问过大约五十个开发者，让他们估算维护成本。汇总下来：你每花一个月写新代码，第一年要花十天维护它，之后每年花五天。十年之后，你只剩 12.5% 的时间在做有价值的事，剩下的全在还债。
我自己有体感。这个博客项目里有一个模块，五年前写的时候觉得"先跑起来再说"，代码里到处都是 TODO: refactor later。后来呢？later 从来没来。现在它每年吃掉我大概两个月的时间。不是因为它重要，恰恰是因为它不重要但又不能坏。每次改它我都得像拆炸弹一样，不知道哪根线碰了就整个炸了。
这种代码就像一栋老房子。你不修它它就漏雨，你修它花的钱够买半栋新的。但你还不能拆了重建，因为重建的期间你没地方住。
写代码的时候人有一种错觉：我写出来的每一行都是"创造"。但如果你把时间轴拉长到三年以上，创造会变成负债，而且是带利息的那种。
为什么 AI 代码更贵
上面的账还算的是"正常"代码。AI 生成的代码，维护成本通常更高。
原因很直接：你不是写它的人。
自己写的代码，哪怕当时写得烂，你知道为什么那样写。那个奇怪的 if 条件是因为周三下午发现的一个 edge case，那个看起来多余的变量是为了兼容某个老版本。你知道这些，所以改的时候不会踩雷。
AI 写的代码没有这个"知道"。它看起来没问题，跑起来也没问题，但当你需要改它的时候，你面对的是一个黑盒，你不知道它为什么这样写，不知道哪些假设是隐含的，不知道改一个地方会不会牵连三个看不见的地方。
HN 上有个讨论叫"just build it with Claude 悖论"。第一天惊艳，第一周还行，第一个月开始骂人。不是因为 AI 写的代码本身差，而是你不理解它。不理解就是维护成本的源头。
James Shore 的模型里有一个很狠的判断：如果 AI 让编码翻倍的同时让维护成本也翻倍，那五个月后你之前抢回来的时间全还回去了。
AI 让贷款翻了一倍
现在来了一个东西，让你写代码的速度翻倍。
好消息是，你一个月能干两个月的活了。坏消息是，两个月的负债，也是两个月。
更狠的是，就算 AI 写的代码质量跟人手写的一样好（维护成本不变），你也好不了多少。十九个月后归零，四十个月后净负。因为"一样好"不等于"更好"，而你需要的是更好，好到能把维护成本压下来，才能抵消你多写出来的那些代码。
这个逻辑链条只有一种解法：AI 必须让代码比人手写的更好维护。不是更快，不是更多，是更好维护。而且好的程度要刚好抵消你多写的量。写两倍，就要好到维护成本是原来的一半。写三倍，三分之一。
差一点都不行。
行业在往反方向跑
现实呢？
Sonar 这家公司每天分析 7500 亿行代码。他们的报告说，42% 的代码已经是 AI 生成或辅助完成的，但 96% 的开发者无法完全信任 AI 生成的代码。AI 写出来的东西，绝大部分人不敢直接拍板上生产环境。
更夸张的是，35% 的开发者会绕过公司的安全管控，自己偷偷用 AI 工具，所谓"影子 AI"。他们知道公司不批准，但他们也知道不用就拼不过那些在用的人。结果就是：更快的速度，更多的代码，更少的审查，更高的维护成本。
Uber 四个月烧光了 2026 年全年的 AI 预算，主要花在 Claude Code 上。430 多条 HN 评论在吵一件事：这到底证明了 AI 生产力爆表，还是证明企业在失控烧钱？
两边都有道理。但 James Shore 的模型给了我们一个更底层的判断标准：烧掉的钱买来了速度，但速度买来的代码，维护成本是多少？如果维护成本涨得比速度还快，那烧钱不是在买生产力，是在买负债。
退出也是一个陷阱
有人会说：那我就停掉 AI 呗，回到手写。
问题是你停不掉。AI 已经写进去的那部分代码还在那里，带着它更高的维护成本在那里。你关掉工具不等于关掉代码。只要那些代码还活着，你就带着比不用 AI 时更低的 productivity 在跑。
James Shore 用了一个比喻：Hotel California。You can check out any time you like, but you can never leave.
这不是 AI 特有的问题。任何"先快起来再说"的技术决策都面临同样的局面。但 AI 把这个局放大了十倍，因为 AI 写代码的速度是人手的几倍，所以它制造的负债也是几倍。
那怎么办
James Shore 不是反 AI。他自己说得很清楚：这不是一个 anti-AI rant。他建议所有人去抄他的 spreadsheet，把自己的真实数据代进去算。
算完你会发现一件事：问题的关键不在于用不用 AI，而在于你用 AI 做了什么。
如果 AI 只用来写新代码，你必死。因为新代码等于新负债，越多越快等于负债越多越快。这个方向上速度是你的敌人。
如果 AI 用来降低维护成本，自动修 bug、自动重构、自动升级依赖、自动生成测试，那你才活得了。因为你在减少已有的负债，而不是制造新的。
我现在的用法偏向后者。遇到一个老模块，先让 AI 帮我读它、理解它、画出依赖图。这个动作本身不产生新代码，但降低了未来的维护成本。修 bug 的时候让 AI 写测试，测试不产生功能，但防止 bug 回来。这些用法不会让 commit 数量翻倍，但会让明年的自己少骂今天的自己几句。
别误会，新代码还是要写的。但每写一行之前，先问一个问题：这行代码明年的维护成本，AI 帮不帮我还？如果不帮，这行代码就值得再想想是不是真有必要写。
这才是 James Shore 这篇文章真正想说的：别盯着编码速度了。那是一笔贷款。真正决定你三年后是死是活的，是你每个月在还多少债。
一个老派人的直觉
我不是科班出身。写代码这件事是边做边学的。但正因为不是科班，我对"整洁"这件事有一种近乎偏执的执念，因为我见过太多不整洁的代码是怎么把一个团队拖死的。没有老师教过我"设计模式"，所以我反而不太迷恋它们，我看代码只问一个问题：半年后的人改得动它吗？
James Shore 也经历过同样的事。他在 2009 年写过一篇「敏捷的衰落」，说很多团队只学了 Scrum 的短迭代和每日站会，不学 XP 的工程实践，结对编程、测试驱动、持续重构。结果就是三五年后技术债堆到天花板，整个团队动不了。他当时下了一个判断：如果这种情况继续下去，敏捷会变成一阵风，因为失败的项目太多，人们会归咎于方法本身，而不是执行的人。
他说对了。敏捷确实变成了风。然后风停了，留下一地没做完的 sprint backlog。
十七年过去了，剧本换了个皮肤重新上演。只是这次不是 Scrum，是 AI。不是不写测试，是不读 AI 生成的代码就 approve。不是技术债，是"AI 债"，更隐蔽，更难清理，因为写它的人你可能都没法问。
北大有个团队去年发了篇 ICSE 杰出论文，讲的就是这个现象：代码模型在 benchmark 上跑分很高，放进真实工程环境表现大幅下滑。因为他们发现，真实软件工程不是解一道题，是一个长时程、反复验证、不断修正的过程。模型会写代码，但不会理解上下文，而维护成本恰恰来自上下文。
但底层逻辑一点没变：快不是目的。活下来才是。
你团队用的 AI 编码工具，有算过维护成本这笔账吗？还是只看 commit 数量？
原文参考
James Shore. You Need AI That Reduces Your Maintenance Costs. jamesshore.com.https://www.jamesshore.com/v2/blog/2026/you-need-ai-that-reduces-your-maintenance-costs
