2026-06-29 · llm, claudecode, 幂等性, ai 老故事：我正在运行我们的首席财务官在两天内投入生产的SaaS。一位非工程师高管快速用Claude Code构建了一些东西，而我（工程师）则一件一件地处理后端。每次我查看时，总有东西爬出来。这次不是“秘密存放在哪里”，也不是“没有一次测试”。这次，是金钱燃烧。一天，我盯着LLM API成本图表，发现有一天的支出像富士山一样高。其他每一天的支出都很低，那一天却直指天空。大约半个月的账单都落在那一天。我老实说，我看到那个数字时，心都凉了。因为那一天的人工智能使用成本本身就超过了整整一个月的服务器费用。运行整个服务器群一个月的费用都比允许人工智能使用一天便宜。这是怎么发生的？我去问构建它的人（首席财务官）：“那一天你做了什么？”答案是：“老实说，我不记得我做了什么。”得了吧。但是这不是一个关于责备的故事（好吧，部分是）。我越深入发掘，越意识到：当然他们不记得。烧钱的不是人，而是重试机制。猎杀。一开始我以为他们只是一天到晚不停地在忙。我的第一次理解大致是：“你那天构建了一堆功能，在生产环境中反复测试，并且每次都调用了昂贵的LLM。死于千刀万剐。”这听起来是合理的。那一天的提交历史密密麻麻，从早到晚都有20多个关于AI生成流程的更改。所以“人重复造成的缓慢燃烧”是有脸面的。然后他们实际上挖掘了应用端的日志（任务队列、数据库、请求），画面完全不同。并不是在缓慢燃烧。同样的重批次被机器反复完全地重新执行。对于单个租户，正常只运行一次的工作运行了21次。人不可能在一天内按下同一个按钮21次。按下按钮的并不是人。最可怕的部分是“它成功了，然后就崩溃了”。这是整个事件的核心，所以让我慢慢说。这个批次依次调用了几个LLM，并将结果保存到数据库中。大致流程是：向几个LLM发出一堆查询（这就是钱花去的地方）将返回的结果写入数据库。问题出在第二步：写入引用了一个应该已经添加但实际上还不存在的列。数据库没有这个列，于是抛出了“列不存在”的错误，工作返回了500。当你听到“它失败了”，自然会想象“调用炸掉了，浪费了一次机会。”不。这每次的LLM调用都是成功的。都是200。所以意味着每一次都被计费了，都是正确的。你支付了，得到了结果，然后就分崩离析在最后一步——保存。如果用餐厅的术语来说：你完成了整个套餐，付了账，正准备说“谢谢你的招待”，你绊倒了，跌倒了，失去了记忆。你醒来，回到座位上，再开始吃同样的整个套餐。二十一遍。你吃的东西（=你被计费的）并没有消除，但每一轮都从零开始。有一个术语叫“重试风暴”。通常你会把它想象成“调用失败，失败，再失败”——一连串的失败。但这不是失败。是扔掉成功的暴风。这是反直觉的部分，也是最可怕的。这怎么发生的？有两个罪魁祸首。机器因为两个一起运作的陷阱重复了21次。陷阱1：部署顺序是反的。代码被送去生产时假设一个新列已存在，但增加该列的迁移尚未应用到生产环境。代码优先，架构其次。在那个顺序中，代码寻找一个不存在的列，并且列的位置是确定性的错误。并且“确定性”是关键——这是一种无论你重试多少次都不会自我修复的失败。陷阱2：当它失败时，任务队列会善意地重新运行它。一个托管的任务队列看到任务因为500错误而失败，并自动表示：“哦，那是失败的，让我为你重新运行。”对于一个短暂的网络故障，这是正确的善意。但这个失败是“列不存在”。无论多少次重试都增加不了列。它因善意而无限地重复了一个无法修复的失败。并且因为批处理不是幂等的（它没有跳过已经处理的工作），每次重试都是从头开始的。所以每一轮都产生全额LLM账单。确定性错误×自动重试×非幂等性。当这三者结合时，金钱就悄然燃烧。难怪那个人不记得——他们什么都没做。按下按钮的东西是任务队列。当我把这一切剖析出来的时候，首席财务官皱了皱脸：“嗯？”（对非工程师来说，“它成功了，你被计费了，然后它又丢掉了成功”是一个真正难以接受的事实。）