Claude Code 源码泄露事件后续越来越精彩了.-夜雨聆风

Claude Code 源码泄露事件后续越来越精彩了.

这几天，AI 圈最热闹的“吃瓜”事件莫过于 Claude Code 的源码泄露。本以为这只是一次安全事故，但在全球顶级极客们的“显微镜”下，源码里竟然挖出了一个让开发者和企业血压飙升的“惊天漏洞”：你那飞速消耗的 Token 和莫名其妙的限速，可能只是因为一个没写上限的重试机制。

一、疯狂的“自动压缩”：它是如何搬空你账户的？

事情的起因是，有开发者将泄露的 Claude Code 源码丢给 OpenAI 的 Codex（专门分析代码的 AI 模型）进行全量审计。结果发现了一个名为 autoCompact 的机制。

什么是 autoCompact（自动上下文压缩）？

简单来说，当你与 AI 进行超长对话时，为了节省空间并保持记忆，系统会自动尝试压缩之前的对话背景。这本是一个优化性能的好经，但在 Claude Code 的源码里，这本经被念歪了。

审计发现：

在该机制失败后，程序会进入一种“死循环重试”状态。最令人震惊的是，源码注释中竟然记录了一个极端案例：某次会话在压缩失败后，连续重试了高达 3272 次！

每一次重试，都在默默消耗大量的 Token。想象一下，你只是想让 AI 写个简单的脚本，后台却像疯了一样反复冲击接口。难怪很多用户吐槽：“还没用两下，额度就见底了，甚至直接触发了速率限制（Rate Limit）。”

二、价值万金的修复方案：只需三行代码

讽刺的是，这个让无数用户“破产”的 Bug，修复起来竟然简单到离谱。极客们给出了最直接的解决方案：人工干预，强行封顶。

重点来了！

只要在代码逻辑中引入一个计数器：

MAX_CONSECUTIVE_AUTOCOMPACT_FAILURES = 3

修复逻辑很直白：

1.程序尝试自动压缩。

2.如果失败，重试计数器 +1。

3.一旦连续失败达到 3 次，立即停止重试，直接放弃压缩。

三行代码，就给狂奔的“烧钱机器”拉上了手刹。据率先打上补丁的老哥反馈，修复后使用额度瞬间恢复正常，那种“动不动就限速”的噩梦终于消失了。

三、源码泄露后的反思：你的 AI 额度安全吗？

这次事件给所有 AI 开发者和企业敲响了警钟：

1.盲目信任官方工具是危险的：即便是像 Anthropic 这样顶尖的 AI 公司，其开源工具在早期阶段也可能存在极其低级的逻辑错误。

2.Token 审计刻不容缓：开发者在调用 API 时，务必在自己的后端增加“熔断机制”。不要只看 AI 返回的结果，更要监控消耗的异常波动。

3.重试机制必须设限：无论是网络请求还是上下文处理，任何自动化重试都必须有 Max Retries（最大重试次数）和 Exponential Backoff（指数退避策略）。

四、程序员的“三行诗”

有人调侃，这大概是史上最贵的“三行代码”。

目前，相关的修复补丁已经在社区传开。如果你也在使用基于此类源码构建的工具，或者正在开发自己的 AI 应用，请务必检查你的重试逻辑。毕竟，谁也不想因为一个简单的循环，就在一夜之间给供应商送去一套房的首付。

工具虽好，可不要“贪杯”重试。