你需要能够降低维护成本的 AI

# 你需要能降低维护成本的 AI 来源：https://www.jamesshore.com/v2/blog/2026/you-need-ai-that-reduces-your-maintenance-costs 我直奔主题：你用来编写代码的 AI 编码代理（agent），必须降低你的维护成本。而且不能只是降低一点点。如果你现在写代码的速度快了两倍？那你最好希望维护成本也减半。效率高了三倍？维护成本就得降到三分之一。否则，你就完了。你正在用暂时的速度提升，换取永久的奴役。 哦，你想知道*为什么*？当然可以。让我们开车兜风。在一条昏暗的沙漠公路上…… ### 生产力由维护成本决定 你写的每一行代码都需要维护：修复 bug、清理代码、升级依赖项等等。我不是指新功能或增强功能，仅指维护。对于你花费每一个月编写代码的时间，在随后的一年里，你将花费一定时间维护这些代码，在此后的每一年也是如此，只要这些代码存在，这种情况将永远持续。 假设你询问了一群，比如说，50 名开发者，这些维护成本是多少。使用一种称为“群体智慧”（Wisdom of the Crowd）的技术，你可以得到一个相当准确的答复。^1 ^1 欢迎你自己进行群体智慧调查！但事实证明，具体数字对于我在这里阐述的整体观点并不重要。 你的这群人可能会告诉你，对于你花费每一个月编写代码的时间，你将花费…… - 第一年的 10 天用于维护；*以及* - 此后的每年 5 天用于维护。 如果你是一个特别执着的人，你可以花几个小时制作一个电子表格，模拟这些估算如何随时间影响生产力。就像这样的电子表格 (https://docs.google.com/spreadsheets/d/109XUgvOMClSoknyGr9MtjWvNSfdf6XYiD5fnSvGYTTU/edit)。  *图表显示维护成本随时间对项目的影晌。横轴表示月份，从 0 到 120；纵轴表示用于增值工作的时间百分比，从 0 到 100。图表中有一条粗蓝线，标记为“正常”，从 100% 开始，在前 12 个月内迅速降至约 65%，然后在剩余的 11 年内逐渐降至约 12.5%。另外两条线遵循类似的轨迹：一条虚黄线，标记为“维护减半”，最终降至约 35%；一条虚红线，标记为“维护翻倍”，最终降至约 5%。每条线在穿过 50% 的点都被标记为“生产力低于 50% 的时间”。对于“正常”线，这发生在第 31 个月；对于“维护减半”，发生在第 68 个月；对于“维护翻倍”，发生在第 10 个月。* 一个新项目的第一个月是辉煌的。你把所有时间都花在构建花哨的新功能上。 第二个月稍微不那么辉煌。你的一小部分时间——不多，但有一点——花在了修复 bug 和清理第一个月的设计错误上。第三个月，多一点。第四个月，第五个月，第六个月…… 最终，这根本不*辉煌*。根据我们这群人的维护估算，在 2 年半之后，你将花费超过一半的时间进行维护。十年之后，你几乎无法做其他任何事情。 将群体的维护估算减半，意味着你在达到 50% 标记之前能多出三年。如果将其翻倍，你在不到一年的时间内就会低于 50%。 教训很明确。如果你想要一个高效的团队，你就必须关注他们的维护成本。 ### 所有模型都是错误的 这些数字让你觉得真实吗？对我而言确实如此。在我的职业生涯中，我专注于后期初创公司，它们都出现了上面图表所示的完全相同的问题。大约在 5 到 9 年之后，他们会注意到他们的团队不再能搞定事情，然后就会联系我。 他们的团队并没有*完全*像图表显示的那么糟糕。也许他们的维护成本较低。或者……这在我看来更有可能……他们的维护成本*确实*那么糟糕，但他们只是掩盖了这个问题。也许他们： - 决定不修复每个 bug，或不升级每个依赖项 - 当团队变慢时增加人手……然后继续增加更多的人，因为人手永远不够 - 放弃一切，通过重写从头开始 关于精确的维护数字，有争论的空间，但总体而言，模型感觉是正确的。如果你经验丰富，你*知道*这张图表是真实的。你见过生产力是如何随时间流逝而消融的。你身上带着伤痕。 ### 这与 AI 有什么关系？ 事关重大。 假设你的团队刚刚开始使用 Rock Lobster (https://www.youtube.com/watch?v=n4QSYx4wVQg)，这是最新最棒的代理编码框架，它让你的代码产出*翻倍*！哇！不过，代码稍微难以理解一些，你的团队淹没在拉取请求（pull requests）中，而且你可能根本就在按下“批准”按钮之前没有真正阅读代码。真的，完全没有。我是说，你有时在无聊的会议中略读了代码，这应该足够好了，对吧？LGTM（看起来不错），让我们搞定这该死的事吧！ 所以，你现在一个月产出了两个月的工作量，假设你使每个“月”产出的维护成本翻倍。下个月的维护成本将*翻四倍*。  *与之前相同的图表，但只显示粗蓝线“正常”。叠加在该线上的是标记为“AI 使生产力和维护成本翻倍”的细红线。在第 36 个月时，它迅速上升至约 85% 的生产力，峰值标记为“AI 提供巨大的短期效益”。随后它迅速降至低于 AI 使用前的生产力水平，标记为“5 个月后收益抹平”。在接下来的 12 个月里，它降至比蓝线“正常”低约 10% 的位置并保持不变。标记为“永久性长期惩罚”。* 噢。 在你开始使用 Rock Lobster 大约五个月后，你的生产力回落到起点，几个月后，它甚至*低于*你从未接触过 Rock Lobster 时的水平。 我并不是说你的 AI 会翻倍维护成本。或者生产力。这是一个极端的例子。但即使你的 AI 生成的代码*和你人类编写的代码一样易于维护*，生产力提升也不会持久。  *前一个图表的新版本，具有相同的粗蓝线“正常”。这次，细红线标记为“AI 使生产力翻倍，维护成本正常”。在第 36 个月时，它像以前一样迅速上升至约 85%，但这次下降得更慢。它在第 55 个月降至低于 AI 使用前的生产力水平，标记为“19 个月后收益抹平”。它继续比蓝线稍微快一点下降，在第 86 个月交叉，标记为“40 个月后净负面影响”。它最终低于蓝线几个百分点。* ### 你随时可以结账离开^2 ^2 但你永远无法离开。 代理（Agents）很昂贵，而且只会越来越贵。一旦你的代理的“果汁”不值得挤了，你可能会决定省点钱，回到老式的编码方式。像穴居人一样。用你的*手指*。 哈！你被耍了！当你停止使用代理时，所有的生产力效益都消失了……但增加的维护成本却没有！只要这些代码还存在，你就不得不承受比从未接触过代理更低的生产力。  *重复了显示 AI 使生产力和维护成本翻倍的图表。前一个图表中的细红线，标记为“AI 使生产力和维护成本翻倍”，现在是虚红线。一条新的黄线标记为“AI 使生产力和维护成本翻倍，已移除”。粗蓝线仍然存在并标记为“正常”。黄线遵循红线的轨迹，36 个月时的生产力跳跃标记为“引入 AI”。和以前一样，该线在接下来的六个月内迅速下降。但在第 60 个月，黄线与红线分道扬镳。它下降得更快，比红线多损失约 10%。这一点标记为“移除 AI”。黄线略有恢复，然后比红线和蓝线更慢地失去阵地，最终比红线好 5%，比蓝线差 5%。* ### 返回之路 只有当 LLM *降低*你的维护成本，并且降低的幅度恰好等于它增加代码的速率的倒数时，数学才能成立。如果你使产出翻倍，并且使这些产出的维护成本翻倍，二乘以二意味着你的维护成本翻四倍。如果你使产出翻倍并保持维护成本不变，二乘以一意味着你的维护成本*仍然*翻倍。 相反，你必须逆转你的生产力。如果你产出的代码多了一倍，你需要维护成本减半的代码。代码多出三倍，维护成本就要降到三分之一。 *这*才是成功的秘诀。拥有所有的好处，没有锁定效应。  *这张图表显示与其他图表相同的粗蓝线“正常”。但这次，细红线没有降至蓝线以下。红线标记为“AI 使生产力翻倍，维护成本减半，已移除”。在第 36 个月时，它像其他图表一样跳跃至约 85% 的生产力，在标记为“引入 AI”的点。然后它保持在蓝线之上，沿着相似但略陡的曲线下降。在第 84 个月时，它回落至正好追踪蓝线，在标记为“移除 AI”的点。* ### 我们能杀死这只野兽吗？ 我不知道。我阅读*最优质的新闻来源* (https://news.ycombinator.com/) 的所有内容都表明，编码代理*增加*了维护成本。有些人确实表示它们帮助他们更好地理解大型系统。但像我们需要看到的那样大幅降低成本？没有。恰恰相反。 这是一个问题。模型不是现实的完美代表，但总体信息是正确的。你需要能降低维护成本的 AI，并且降低的比例要与你从新代码中获得的速度提升成比例。没有它，你就完了。你正在用暂时的速度提升，换取永久的奴役。 所以，是的，去追求编码速度的改进吧。但也要花同样多的时间去追求维护成本的改进。否则，你也将被困在“加州旅馆”（Hotel California）中。 如此美妙的地方。 如此美丽的面孔。 尽管看起来可能如此，但这并不意味着是一篇反 AI 的 rant（发泄文）。还有其他可以拉的杠杆，例如即使它不能让*代码*更易维护，也能使维护本身更具生产力的 AI。我鼓励你*复制这个电子表格* (https://docs.google.com/spreadsheets/d/109XUgvOMClSoknyGr9MtjWvNSfdf6XYiD5fnSvGYTTU/edit) 并玩转模型中的所有杠杆。看看当你改变假设以匹配你的现实世界情况时会发生什么。