为什么一天的 AI 成本比一个月的服务器还贵？

背景

这篇文章源自 Hacker News 上的一篇技术反思，作者是一名工程师，其公司首席财务官（CFO）利用 Claude Code 等 AI 辅助编程工具，在两天内快速构建并上线了一个 SaaS 功能。作为负责后端维护的工程师，作者原本以为这又是一次典型的“非技术人员快速搭建，工程师事后填坑”的故事——通常这类故事涉及密钥泄露或缺乏测试。

然而，这次的问题并非代码逻辑错误，而是单纯的“金钱燃烧”。作者发现，在当月的账单中，有整整一天的 LLM（大语言模型）API 使用费用，竟然超过了整个服务器集群一个月的运行成本。这种极端的成本异常引发了作者的深入调查，最终揭示了一个关于 AI 集成、重试机制和部署流程的深刻教训。

核心内容

异常的账单与初步猜测

作者盯着 LLM API 的成本曲线图，发现某一天出现了一个像富士山一样突兀的高峰，而其他日子都贴近地面。那一天的费用占据了整月账单的一半左右。看到这个数字时，作者感到心惊肉跳：仅仅是一天的 AI 对话成本，就超过了运行整个服务器舰队一个月的费用。

作者询问构建该功能的 CFO：“那天你做了什么？” CFO 的回答是：“老实说，我不记得我做了什么。”

这并非为了推卸责任，而是揭示了问题的本质：烧钱的不是人类，而是自动化的重试机制。

深入调查：从“人类重复”到“机器循环”

起初，作者假设是 CFO 在那天反复测试功能，导致对昂贵的 LLM 进行了成千上万次的调用（即“千刀万剐”式的缓慢消耗）。这一假设看似合理，因为当天的提交记录密集，涉及 AI 生成流程的二十多次变更。

然而，当深入查看应用侧日志（任务队列、数据库、请求）后，真相截然不同。并不是人类在反复点击按钮，而是机器在完整地、一遍又一遍地重新运行同一个重型批处理任务。对于单个租户，一个通常只运行一次的任务，竟然被执行了 21 次。

核心故障：“成功后的失败”

这是整个事件最恐怖也最反直觉的部分。

该批处理任务按顺序调用多个 LLM，并将结果保存至数据库。流程大致如下：

1. 向多个 LLM 发送查询（这是花钱的地方）。
2. 将返回的结果写入数据库。

问题出在第 2 步：代码试图写入一个本应存在但尚未创建的列（column）。由于数据库中缺少该列，数据库抛出 column does not exist 错误，导致作业返回 500 内部服务器错误。

关键在于：所有的 LLM 调用都成功了（返回 200 OK）。这意味着每一次调用都被计费，钱花出去了，结果也拿到了。然而，在最后的保存步骤中，程序崩溃并丢弃了成功的结果。

作者用餐厅比喻来解释这一现象：你吃完了整道菜，付了账，但在起身说“谢谢”时摔倒了，失去了记忆。醒来后，你回到座位上，从头开始吃同一道菜。你吃了 21 次，付了 21 次的账。你吃下去的东西（被计费的部分）无法撤销，但每一轮都从零开始。

这被称为“重试风暴”（Retry Storm），但与传统认知中“调用失败、重试、再失败”不同，这里是“成功被丢弃，然后重新发起新的成功调用”。

两大罪魁祸首

任务队列之所以重复执行 21 次，是以下两个陷阱共同作用的结果：

1. 部署顺序错误（Schema 滞后于 Code）： 代码部署到生产环境时，假设新列已经存在，但添加该列的数据库迁移（Migration）尚未在生产环境中应用。代码先于架构上线，导致代码必然去访问一个不存在的列，从而产生确定性失败（Deterministic Failure）。这种失败无论重试多少次都不会自愈。

2. 任务队列的“善意”重试： 托管任务队列在检测到作业以 500 错误死亡时，会自动重新运行该作业，以为这是暂时的网络抖动。然而，这次失败是“列不存在”，无论重试多少次，列都不会自动长出来。队列出于“善意”不断重试，导致一个无法修复的失败被无限循环。

此外，由于该批处理任务不具备幂等性（Idempotent，即重复执行不会产生副作用或重复结果），每次重试都从头开始，携带完整的 LLM 账单。

公式总结：确定性失败 × 自动重试 × 非幂等 = 静默烧钱。

关键要点

作者从这次事故中提炼出四条核心工程教训：

• 重试不是万能药，确定性失败不应重试： 对于模式不匹配、4xx 类“客户端错误”等确定性失败，重试毫无意义。必须设置重试上限（Retry Ceiling），并将此类错误视为立即中止的信号。重试不是通用的保险政策。

• 高副作用操作必须具备幂等性： 任何执行成本高昂工作（如计费 API、LLM 调用）的批处理任务，从第一天起就必须实现“跳过已处理工作”的逻辑。否则，重试不是“重做”，而是“重复计费”。

• 遵循“先 Schema，后 Code”的部署顺序： 先应用数据库变更，再部署使用这些变更的代码。颠倒顺序会在间隙中批量制造确定性错误。

• 成本必须可观测： 如果没有“烟雾探测器”，你只能在账单烧完后才发现问题。作者之所以能发现异常，是因为偶然查看了成本图表。必须为生产和测试环境使用独立的 API Key，并设置预算警报。

• AI 降低了构建门槛，但未降低维护门槛： “Vibe coding”（氛围编程/直觉式编程）确实让非工程师能快速构建生产级功能。但理解“它如何崩溃”和“它如何变贵”仍然是工程师的职责。你可以两天内构建功能，但防止“优雅重试”演变为“丢弃成功并重复计费”的机制，无法在两天内完成。

意义与影响

这篇文章揭示了 AI 辅助编程时代下，软件工程面临的新挑战。虽然 LLM 极大地加速了功能开发的速度，降低了非技术人员参与生产的门槛，但它也引入了新的成本结构和故障模式。

1. 成本结构的不可预测性：传统服务器成本相对线性且可预测，而 LLM API 成本可能因重试风暴、非幂等设计或配置错误呈指数级爆炸。这种“单次调用成本低，但累积效应巨大”的特性，要求团队建立更精细的成本监控体系。
2. 重试机制的复杂性：传统的容错策略（如自动重试）在处理具有副作用（Side Effects）和成本的操作时，可能从“稳定性保障”变为“财务灾难”。工程师必须重新审视重试策略，区分瞬态错误和确定性错误。
3. DevOps 与数据一致性的严谨性：自动化部署和 CI/CD 流程中，数据库迁移与代码发布的顺序管理变得至关重要。任何顺序颠倒都可能导致生产环境的确定性故障，进而触发灾难性的重试循环。
4. 角色分工的演变：随着非工程师（如 CFO、产品经理）能够直接构建生产代码，传统的“开发-测试-运维”边界变得模糊。这要求所有参与生产代码构建的人员，无论其技术背景如何，都必须具备基本的系统可靠性意识和成本意识。

最终，作者强调：“重试并不总是善意。”在 AI 时代，工程师的核心价值之一，正是构建能够优雅处理失败、避免资源浪费的系统韧性，这是单纯的功能构建无法替代的技能。