我意外在 Claude 上花费了 150 万日元：防止 AI 账单灾难的必备设置

为了防止类似事故再次发生。

如果大家都能读到这篇文章，那我们的 150 万日元也算花得有点意义了！！！🥺

现在就该做的事

• 设置 Claude Team 组织的月度用量限制（显然）
• 为 Claude Code Review 设置每项服务的限制
• 将 Claude Code Review 的触发条件从"每次推送"改为"一次"
• 如果你能把信用卡交易记录流式传输到某个频道，就时不时瞄一眼（这次我就是这么发现的）
• 彻底实施护栏和安全措施

Claude Team 组织月度用量限制设置

来自 https://claude.ai/admin-settings/usage

在 Enterprise 版本中，你可以设置比月度更细粒度的限制，所以值得利用起来。

Claude Code Review 每项服务限制

来自 https://claude.ai/admin-settings/usage

将 Claude Code Review 触发条件从"每次推送"改为"一次"

来自 https://claude.ai/admin-settings/usage

发生了什么

在一个平静的周六晚上，一股不安感席卷了整个组织。

150 万日元正在被 Claude Code Review 吞噬。😇

为什么会发生

直接说结论，情况是这样的：

Claude Code Review 运行

↓

添加审查评论

↓

AI Agent（Codex/Claude 等）判断是否需要修复

↓

AI Agent 修复并在需要时提交/推送

↓

推送触发 Claude Code Review 再次运行

↓

Rebase/force push 传播到后续的 Stacked PR

↓

Claude Code Review 也在后续 PR 上运行

↓

无限循环 ♾️

在我们开发的仓库中，我们引入了 Claude Code Review，它会自动审查 GitHub PR 的代码。此外，这次我们使用 AI Agent 来处理相对大规模的变更，将这些变更拆分成多个 PR，并从上游到下游线性堆叠。（这样一系列 PR 称为 Stacked PR）。另外，Claude Code Review 是一种按 token 使用量付费的服务。

Stacked PR

feat/branch-1（PR 1）

↓

feat/branch-2（PR 2）

↓

feat/branch-3（PR 3）

↓

…

↓

feat/branch-N（PR N）

回想起来，这些审查的平均成本是每次 $25.81 😱

即使在 Anthropic 官方博客上，也解释说 Code Review 旨在进行深度审查，会比 Claude Code GitHub Action 等轻量级选项更贵，但我从没想过会这么贵……

这次，为了进行大规模变更，我们在本地同时使用多个 AI Agent 创建了多个 Stacked PR。Claude Code Review 在这些 PR 创建时执行。通常，人类会检查审查内容并决定是否处理，但这次，假设人类会做最终检查，我们将主要响应——包括是否处理审查的判断——都委托给了 AI Agent。

深入分析问题

1. 使用多个 Stacked PR 推进复杂功能

这个任务涉及相对较大的变更。我们将其拆分成多个 PR，因为把所有内容放在一个 PR 里会使审查变得困难，而且还要考虑发布顺序。拆分 PR 本身没有错。问题在于它们是线性的 Stacked PR。

在 Stacked PR 中，如果你修复了上游 PR，下游 PR 必须合并这些变更。换句话说，推送到上游会导致 rebase/push 传播到下游。

这种结构与每次推送都触发审查的 Claude Code Review 设置不兼容。

2. 将审查响应完全交给 AI

由于每次推送都会触发审查，审查评论不断增加，我们给 AI Agent 分配了以下任务：

• 检查未解决的审查评论
• 决定是处理还是跳过
• 如果处理，修复并通过本地测试
• 提交/推送
• 回复审查评论并解决
• 推送后监控一段时间，看是否有额外审查

最初的目标是，在我进行操作检查和审查时，AI 对建议的响应已经完成。

如果我们确保由人类对审查评论的响应策略做出最终决定，很可能可以避免这种情况。

3. 下班后它还在继续运行

我在下班后也运行并监控上述过程，但至少应该在完成工作时停止它。这完全是一个需要反思的点。

由于我是按订阅方式使用本地 AI Agent，所以对 API 成本正在实时增加的感觉很弱。另一方面，在 GitHub 端运行的 Claude Code Review 正在消耗 Anthropic 组织的用量。在 Anthropic Console 上，目标仓库的平均成本显示为 $25.81/次审查。低估这种成本感知也是反思点之一。

我创造了一种情况：按使用量付费的 AI 长时间运行，而感知到的本地成本与实际计费成本之间存在差距。

出了什么问题

1. 对昂贵审查的"每次推送触发"设置过于轻视

这次，Anthropic Console 的设置是每次推送都运行审查。虽然每次推送都审查的功能很方便，但每次变更都可能产生建议，所以应该仔细考虑触发条件。

2. 误判了 Stacked PR 与自动审查的兼容性

Stacked PR 是将 PR 拆分成可审查单元的有效方法。然而，修复上游 PR 需要对下游 PR 进行 rebase。而推送到下游 PR 也会在那里触发审查。原本一个 PR 一次审查，在 Stacked PR 中会传播到 N 个 PR，审查次数也随之增加。

3. 将判断、修复和推送都委托给 AI

使用 AI 来整理审查评论或进行本地修复非常方便。但这次我们给了它太多权限。看到审查评论、处理、推送、再监控这个循环，本应通过明确的人工确认来操作。

4. 将组织限制作为最后一道防线

结果，它接近了组织限制，我们才在那里发现了异常。有限制本身是好的。然而，$10,000 作为最后一道防线太高了。此外，由于启用了额外用量和计费延迟的影响，月度组织累计成本几乎在一天内就超过了 $10,000。我们需要更早停止的护栏。

总结

我在一天之内用 Claude Code Review 熔掉了 150 万日元。目前正在发送退款请求。原因是 Claude Code Review 设置为每次推送触发，而 AI Agent 的修复/推送与 Stacked PR 的 rebase 链结合，造成了审查和修复的循环。

这次，我们过度利用了 AI 驱动开发的便利性，忽视了安全和成本护栏。到目前为止，还只是让我们随便用 AI 的阶段，各种 Agent 相对便宜地提供，但我认为现在我们已经知道了好处，它们会开始像商业一样从我们这里赚钱。

我们正在重新打造面向 AI 时代的开发组织。https://supateam.com/ 我们一定会利用好这次经验。