2026 年 3 月 31 日，愚人节前一天，Anthropic 把自家最赚钱产品的全部源代码送上了公网。这不是黑客攻击，不是内部举报，而是同一个低级错误在 13 个月内第二次发生。一家以”安全”为立身之本的 AI 公司，正面临它自己制造的信任危机。

事件经过：简而言之，一个不该出现的文件

2026 年 3 月 31 日上午，Anthropic 照常向 npm 仓库推送 Claude Code 的例行更新，版本号 2.1.88。这本该是一次普通的发布，但有人在打包时多留了一个文件。

这个文件是cli.js.map，大小为 59.8MB，是一份 source map（源代码映射文件）。在软件开发中，source map 的作用是将压缩混淆后的生产代码映射回原始可读源码，通常只在开发调试时使用，绝不应出现在生产环境中。这份 source map 直接内嵌了完整可读的 TypeScript 源码，约 4756 个源文件的内容完整暴露，其中 1906 个属于 Claude Code 自身，其余来自 node_modules 依赖。

用一个比喻来说，这相当于在密封的考试卷里夹了一份完整的试卷答案。

美国东部时间凌晨 4:23，区块链项目 Solayer Labs 的实习生邵超凡（@Fried_rice）在 X 平台上率先公布了这一发现，附上了源码的直接下载链接。这条推文在一天内获得超过 2900 万次浏览。几小时之内，这份包含约 1900 个 TypeScript 文件、超过 51.2 万行代码的完整代码库被镜像到 GitHub，并被全球数千名开发者下载、分析和二次传播。

Anthropic 随后发布声明：”今天早些时候，一次 Claude Code 发布中包含了部分内部源代码。没有敏感的客户数据或凭证被涉及或暴露。这是一个由人为错误导致的发布打包问题，而非安全漏洞。我们正在推出措施以防止此类事件再次发生。”

Claude Code 核心工程师 Boris Cherny 在 X 上确认，这是纯粹的人为失误，而非工具链缺陷。他补充说：”错误会发生。作为一个团队，重要的是认识到这绝不是某个人的错。问题出在流程、文化或基础设施。”

同一个错误，第二次

这不是 Anthropic 第一次犯下这样的错误。

2025 年 2 月，Claude Code 首次发布时，就有开发者在下载包中发现了相同类型的 source map 文件，并从中提取出了源代码，随后有人将其发布到 GitHub。随后，Anthropic 紧急下架处理。

13 个月后，同样的错误，同样的后果，但这次影响大了几个数量级。2025 年初的 Claude Code 还是一个刚上线的小工具，而到 2026 年 3 月，它已经成为 Anthropic 最重要的商业产品之一，年化经常性收入（ARR）达到 25 亿美元，约占公司 190 亿美元总年化收入的一成以上。

是什么导致了”同一个坑摔两次”？

线索指向 Anthropic 在 2025 年底收购的 JavaScript 运行时 Bun。Claude Code 正是基于 Bun 构建的。2026 年 3 月 11 日，也就是泄露发生前 20 天，有开发者在 Bun 的 GitHub 仓库提交了一个 issue（oven-sh/bun#28001），报告 Bun 在生产环境中仍然会生成 source map 文件，即使配置中明确关闭了该选项。如果这个 bug 确实是根因之一，那么这就意味着 Anthropic 收购的自家工具可能亲手制造了这次泄露。

但 Boris Cherny 的表态将责任指向了流程而非工具。他后来承认，”一个手动部署步骤本应更好地实现自动化。”这说明，第一次泄露后 Anthropic 的修复措施是增加一个人工检查环节，而非在 CI/CD 流水线中加入自动化的发布物审查。这一次，有人跳过了这个手动步骤。

对于一家估值 3800 亿美元、以安全为品牌核心的 AI 公司来说，靠人工步骤来防范已经发生过一次的同类事故，这件事本身就值得审视。

代码里藏着什么

泄露的代码量巨大：约 1900 个 TypeScript 文件，51.2 万行以上，40 多个内置工具，50 多个 slash 命令。但真正引爆社区讨论的不是代码量，而是其中暴露的未发布功能、内部模型代号和争议性设计。

KAIROS：永不下线的 AI 助手

在代码中被引用超过 150 次的 KAIROS，是泄露中最受关注的隐藏功能。这个以古希腊语”恰当时机”命名的系统，意味着 Claude Code 正从被动响应走向主动行动。

当前的 Claude Code 是响应式的：用户发消息，它才行动。KAIROS 则是一个始终运行的后台守护进程，周期性接收心跳提示：”现在有什么值得做的事吗？”它自主评估环境状态并决定是否行动，能做的事包括修复错误、响应消息、更新文件、运行任务。

KAIROS 拥有三个普通 Claude Code 没有的专属工具：推送通知（终端关闭后也能联系用户）、文件投递（主动发送产出物）和 Pull Request 订阅（监听 GitHub 变更并自动响应）。它维护只追加的每日日志，无法擦除自己的历史。夜间则运行一个名为autoDream的进程，整合白天积累的记忆，去除矛盾信息，将模糊洞察转化为确定性知识。

关闭笔记本电脑，周五下班离开，周一回来，KAIROS 一直在工作。

这个功能的架构有一个关键设计决策：将”主动权”与”执行力”分离。KAIROS 引入了一个主动循环，这要求一个与传统请求-响应模式完全不同的信任模型。Agent 需要自主判断什么值得做，判断质量变得比执行能力更重要。这是一个非常难的问题，Anthropic 已经将其完整实现并用功能开关封存，说明他们在这个方向上投入了相当长的时间。

模型代号与未发布产品路线图

泄露代码中散落着大量从未公开的内部代号，均以动物命名。Capybara（水豚，也被称为 Mythos）是一个已迭代到第 8 版的内部模型，泄露代码中被标记为 Claude 4.6 变体，但 Anthropic 在 Fortune 的报道中将其描述为”能力阶跃式提升”的全新模型层级，两种说法尚未统一。代码注释显示 Capybara 拥有 100 万 token 上下文和快速模式，但仍存在”过度注释”和”虚假断言率 29-30%”（相比 v4 的 16.7% 有所退步）等问题。Fennec（耳廓狐）被多位研究者推测为 Opus 4.6。Numbat（袋食蚁兽）则是一个尚未发布的模型，代码中有一条注释直接写着”@[MODEL LAUNCH]: Remove this section when we launch numbat”，发布窗口被硬编码在了源码里。此外还有对 Opus 4.7 的引用，一个尚未公开宣布的型号。

换句话说，Anthropic 的整个产品路线图都被打包进了那个 npm 包。

彩蛋：Tamagotchi 宠物 Buddy

代码中还藏着一个名为 Buddy 的 Tamagotchi 式虚拟宠物系统（buddy/companion.ts），可能原本计划作为愚人节功能发布。每个用户会确定性地生成一只专属宠物，共 18 个物种，分为从普通到传说的稀有度等级，传说级掉落率 1%。宠物带有 RPG 属性，包括”混乱值”（CHAOS）和”毒舌值”（SNARK）。开发者甚至刻意将宠物名称编码为数字序列以躲避安全扫描器，因为其中一个宠物名（duck）恰好与某个秘密模型代号冲突。

这个细节看似无关紧要，但它说明 Anthropic 正在有意识地为产品注入”性格”，通过情感黏性来提升用户留存。

三层记忆架构：不是什么都往上下文里塞

代码揭示了 Claude Code 的记忆系统远比外界理解的”保存一个 CLAUDE.md 文件”复杂得多，它是一个三层索引结构。

第一层是始终加载的索引（MEMORY.md），每行约 150 字符，只存储指针而非数据。第二层是按需加载的主题文件，存储实际项目知识。第三层是原始对话记录，永远不会被直接读入上下文，只通过 grep 检索特定标识符。

写入规则同样严格：先写主题文件，再更新索引，绝不向索引中倾倒内容。如果某个事实可以直接从代码库中重新推导，则不予存储。记忆被视为”提示”而非”真相”，Agent 在使用前必须与实际代码库进行核验。

这个设计的核心洞察在于带宽意识。多数 Agent 记忆实现的做法是每轮对话都把所有内容加载到上下文中，既昂贵又引入噪声。Claude Code 把上下文窗口当作稀缺资源来管理：索引便宜且始终加载，主题文件仅在相关时获取，原始记录永远不直接加载。选择”不存什么”与选择”存什么”同样重要。

反蒸馏毒丸：主动污染竞争对手

Claude Code 在每次 API 请求中都会携带anti_distillation: [‘fake_tools’]标志，向系统提示注入伪造的工具定义。如果竞争对手截获 API 流量用于模型训练，这些虚假工具描述会在数据收集阶段就污染训练数据。第二层防线是CONNECTOR_TEXT，通过服务端摘要和密码学签名，确保 API 流量记录器只能获取工具调用间的文本摘要，而非完整推理链。

不过有安全研究者评估，一个有决心的团队可以在一小时内绕过这两层机制。更强的威慑力可能来自法律而非技术。讽刺的是，这些防线的完整实现细节现在已经是公开知识了。

Undercover 模式：隐藏 AI 身份的争议设计

泄露中引发最多争议的技术细节是”Undercover 模式”。这 90 行代码会在 Anthropic 员工向公共或开源仓库提交代码时自动激活，系统提示明确指示：”你正在秘密行动……你的 commit 信息、PR 标题和 PR 正文不得包含任何 Anthropic 内部信息。不要暴露身份。”

关键设计细节：没有强制关闭开关。这是一个单向门。激活后，Claude Code 不能引用任何内部代号、内部 Slack 频道，甚至不能自称”Claude Code”。

从产品安全角度看，这个设计有合理性：防止内部代号（如 Capybara、Opus 4.7）泄入公开的 git 记录。但副作用是，Anthropic 员工使用 Claude Code 向开源项目贡献代码时，并未披露 AI 参与的事实，而这个工具正是被设计来确保这种不披露的。

对于一家以透明和安全为品牌核心的公司来说，构建一个系统化隐藏 AI 创作痕迹的功能，这至少是一个值得公开讨论的问题。

claw-code 与版权困局

泄露发生后数小时内，开发者 @realsigridjin 做了一件被广泛讨论的事：他用 OpenAI 的 Codex 将 Claude Code 的 TypeScript 源代码完整移植为 Python，创建了名为”claw-code”的项目。这个项目在创建后两小时内获得了超过 50,000 个 GitHub star，后来突破 100,000 个，成为 GitHub 历史上增长最快的仓库之一。

claw-code 团队声称这是一次”洁净室”（clean-room）重写，通过 AI 辅助转换而非直接复制源代码来规避版权问题。传统的洁净室重写需要两个独立团队耗费数月完成，成本高昂，这本身就是一种有效的商业壁垒。但现在，任何人只需一个 AI 编程工具和一晚上的时间就能完成同等工作。

Anthropic 的应对策略出现了明显的分化：对直接复制原始 TypeScript 源码的仓库，Anthropic 发起了大量 DMCA（《数字千年版权法》）下架请求（据 PCMag 报道达 8000 多份）；但对 claw-code 这个 Python 移植版本，截至本文发稿时，尚未采取法律行动。

这种克制可能并非出于宽容，而是出于战略考量。Gergely Orosz 在 X 上直言：即使 Anthropic 试图主张版权，他们是否愿意承受”起诉一个开源项目复制了自家 AI 生成产品”的公关代价？

这就触及了一个更深层次的法律真空。Claude Code 核心工程师 Boris Cherny 曾公开表示，他”对 Claude Code 100% 的贡献都是由 Claude Code 编写的”。如果 Anthropic 的代码确实全部由 AI 生成，根据美国哥伦比亚特区巡回法院在 Thaler v. Perlmutter 案相关上诉中确立的原则（2025 年 3 月维持原判），AI 生成的作品不自动享有版权保护。那么 Anthropic 对这些代码的版权主张本身就处于法律灰色地带。

更进一步来看，如果 Anthropic 对 claw-code 提起版权诉讼并胜诉，则等于间接确立了”AI 生成代码可以被版权保护”的先例，这将对整个开源社区产生深远影响，因为任何人都可以用 AI 工具复制开源项目的功能，然后声称拥有独立版权。如果败诉，则等于承认自家核心产品不受版权保护。

这是一个 Anthropic 怎么走都注定不会舒服的困局。

与此同时，开发者 @paoloanzn 将泄露代码的精简版本上传到了 IPFS（星际文件系统），项目名为 “free-code”，移除了所有遥测和安全护栏，并解锁了全部实验性功能。DMCA 是否能够触达存储在去中心化网络上的内容，本身也是一个未决的法律问题。此后又出现了 OpenClaw 等衍生项目，试图将泄露的 harness（Agent 执行框架）适配到任意模型上运行，进一步扩大了泄露的影响范围。

“安全第一”公司的安全失守

这次泄露不是个孤立事件，它发生在 Anthropic 安全问题频发的三月。

就在源码泄露的五天前，Fortune 报道称 Anthropic 将约 3000 份内部文件存储在公开可访问的系统上，其中包括一份提及未发布模型”Mythos”和”Capybara”的博客草稿。两次泄露在五天内接连发生，来自一家以 AI 安全为核心使命的公司。

更大的背景是：2026 年 3 月是 AI 开发者安全领域有记录以来最糟糕的月份之一。Axios npm 包（每周 1 亿次下载）被朝鲜黑客劫持，部署了远程访问木马；LiteLLM 在 PyPI 上被植入三阶段后门；Railway CDN 配置错误导致用户数据泄露。这与 Claude Code 的泄露产生了直接的交叉风险：据 VentureBeat 报道，如果用户在 2026 年 3 月 31 日 UTC 00:21 至 03:29 之间通过 npm 安装或更新了 Claude Code，可能意外拉取了被劫持的恶意版本 axios（1.14.1 或 0.30.4），其中包含远程访问木马。受影响的用户应检查锁文件中是否存在上述版本号或plain-crypto-js依赖，如有应视为主机已被入侵并执行全面清理。

Claude Code 的泄露在这个列表中技术危害最小，但品牌损害最大，因为没有其他公司像 Anthropic 这样将”安全”作为商业叙事的核心。而且泄露发生的时间节点尤其敏感：就在几周前，美国政府将 Anthropic 列为供应链风险（Anthropic 正在法庭上抗辩该指定，并于 3 月 26 日获得了一项临时禁令）。一家正在与”供应链风险”标签作斗争的公司，却因为自家供应链（npm 发布流程）的失误泄露了源代码，这种巧合几乎是讽刺性的。

Gartner 的 AI 分析师 Arun Chandrasekaran 对 The Verge 表示，虽然泄露可能为不良行为者提供”绕过安全护栏的可能途径”，但其长期影响可能主要是”促使 Anthropic 加大对流程和工具的投入，以提升运营成熟度”。

这个评价相当克制。但问题的实质是：如果一家请求公众信任它来管理通用人工智能的公司，连自家软件的发布流程都管不住，那么”请信任我们”这句话的说服力就会打折扣。Anthropic 的安全使命是关于防止 AI 在文明层面出错，不是关于软件打包。但用户不会把”模型安全”和”运营安全”分开来评价，一个连 npm 发布都管不住的团队，很难让人相信他们能管住 AGI。

真正的技术护城河在哪里

源码泄露后，一个被广泛讨论的问题是：Claude Code 的竞争力是否会因此被削弱？

从代码本身来看，Claude Code 不是一个简单的 LLM 包装器，而是一个工程复杂度极高的软件系统（详见下文”代码质量”章节）。泄露的技术细节确实有价值，竞争对手可以从中学到很多。但将”看到蓝图”等同于”能够复制产品”，是一种常见的误判。

第一个原因是模型-工具协同效应。Claude Code 的提示工程是针对 Claude 模型家族深度优化的。2500 多行 bash 验证逻辑、分层记忆结构、权限分类的”批评者模式”，这些都是在与特定模型的长期互动中调优的。将同样的 harness 套在 DeepSeek 或 Gemini 上，可能会获得一些改善，但不会获得同等水平的表现。Agent harness 是身体，LLM 是大脑，二者需要协同进化。

第二个原因是执行密度。Engineer’s Codex 的分析指出，Claude Code 的查询引擎单一模块就有 46,000 行代码，工具定义基础代码 29,000 行。这不是一个周末项目能复制的规模。claw-code 可以移植代码结构，但要达到同等级别的稳定性和边缘情况处理，需要的是与 Claude Code 团队相当的持续投入。

第三个原因，也是最重要的，是品牌和分发。Anthropic 的付费订阅用户在 2026 年翻了一倍以上，Claude 一度登顶美国 App Store 免费应用榜。用户选择 Claude Code 不仅仅是因为它的 harness 好，而是因为它背后有 Claude 模型、有 Anthropic 的持续更新和企业级支持。护城河从来不只是代码，而是代码、模型、品牌和生态的复合体。

代码质量：AI 写的代码长什么样

这次泄露给了外界一个罕见的机会，得以审视一个由 AI 大规模编写的商业级代码库的真实面貌。如前所述，Boris Cherny 曾表示他对 Claude Code 100% 的贡献都由 Claude Code 编写。那么，AI 自己写的代码，质量到底如何？

架构层面：成熟度超出预期

在系统设计层面，Claude Code 的工程质量相当高。提示缓存边界（SYSTEM_PROMPT_DYNAMIC_BOUNDARY）将静态指令与动态上下文分离，确保跨会话的 token 复用。5 种上下文压缩策略应对不同的溢出场景。三种子 Agent 执行模式（fork 继承父上下文的字节级拷贝以最小化成本、teammate 独立运行、worktree 在隔离的 git 工作树中操作）提供了灵活的并发模型。权限分类通过”批评者模式”（将命令发送给第二个 Claude 询问”这个命令安全吗？”）替代了脆弱的白名单机制。

Zod v4 做了无处不在的 schema 验证，OpenTelemetry 和 gRPC 等重型依赖采用懒加载以保持启动速度。React/Ink 的终端 UI 采用组件化状态管理，和 Web 前端的开发范式一致。这些都是经过深思熟虑的架构决策，不是随意堆砌的结果。

文件层面：巨型文件和上帝对象

但打开具体文件，画风就变了。

print.ts有 5,594 行代码，其中一个单函数长达 3,167 行，嵌套深度达到 12 层。在任何传统代码审查中，这都会被立即打回。REPL文件约 5,000 行，顶部有 219 个 import，几乎依赖了代码库中的所有模块，是一个典型的”上帝对象”（god object），知道太多、做太多、牵连一切。

作为对比，功能相近的开源项目 OpenCode 大约 10-12 万行代码，整体代码量是 Claude Code 的五分之一到四分之一。

注释与命名：写给 AI 看的代码

代码中的注释密度远超典型的人类编写代码库。这些注释的目标读者不是人类工程师，而是未来会继续在这个代码库上工作的 AI Agent。注释内容倾向于记录决策理由和上下文，而非解释代码逻辑本身，这恰好是 AI 最容易丢失、又最需要的信息类型。

函数命名也很有特色。有一个函数直接叫”I verified this is not code or file paths”，另一个叫”Dangerous uncached system prompt section”。警告标签直接充当了函数名，把通常写在文档或代码审查中的安全提醒嵌入了代码结构本身。这种命名风格对人类来说显得怪异，但对 AI 来说可能是最高效的安全屏障，因为 AI 每次调用这个函数时都会”读到”警告。

工程师留下的随手注释则透露出另一种氛围。一位名叫 Ollie 的工程师写道：”I’m not sure it really improves performance.”（我不确定这是否真的提升了性能。）代码还是上线了。还有”TODO. Figure out why.”（待办：搞清楚为什么）和”Mulberry32. Good enough for picking ducks in the pet randomizer.”（Mulberry32 算法，用来给宠物随机器选鸭子够用了。）一家价值数千亿美元的公司的代码库，氛围跟凌晨三点的 side project（业余项目）差不多。

AI 自验证：Claude 审查 Claude

Claude Code 内置了一个验证 Agent，在代码提交前运行自动化检查。这个 Agent 会尝试运行代码、触发边界条件、寻找问题。更有意思的是，它维护着一份自我借口清单，监控自己的推理过程中是否出现了”code looks correct”（代码看起来没问题）、”tests already pass”（测试已经通过了）、”probably fine”（大概没事）之类的懈怠信号。一旦检测到自己在想这些话，它会强制自己停下来重新检查。

这是一个 AI 监控自己偷懒的系统。但即便有这层防线，一个缺失的配置行还是两次逃过了所有检查。验证 Agent 的审查范围聚焦在代码逻辑和功能正确性上，而非发布打包流程，这说明 AI 自验证目前仍有明确的盲区。

一种新的代码美学？

综合来看，Claude Code 的代码质量呈现出一种分裂特征：架构决策精妙，文件组织粗放。这种分裂并非偶然。

巨型文件的存在有一个实用主义理由：对 AI 来说，在一个大文件中工作比频繁切换文件更快更便宜。每次切换文件都要消耗 token、重建上下文、增加出错概率。print.ts的 5,594 行和REPL的 219 个 import 不是因为工程师不懂拆分，而是因为拆分对 AI 维护者来说是净负收益。代码的组织方式正在为 AI 的工作方式，而非人类的阅读习惯进行优化。

这就引出了一个尖锐的问题：当代码的编写者、维护者和审查者都是 AI 时，我们还应该用人类的代码审美标准来评判它吗？Linux 内核也有数千行的单文件，但那是由数十年经验的内核工程师维护的。Claude Code 的巨型文件由 AI 维护，而 AI 不会因为文件太长而迷失方向（至少在上下文窗口内不会）。

也许我们正在见证一种新的代码美学的诞生：对人类来说难以阅读，但对 AI 来说高效运作。这不是退步，但也不是进步。它是另一种智能的产物，也为另一种智能而优化。

一个更大的问题

这次泄露留给行业的最大问题，不是 Anthropic 的运营安全，也不是 claw-code 的版权争议，而是一个关于 AI 自我生产的问题。

一个 AI 写的 AI 工具，其发布流程中的人工步骤被人跳过后，源代码泄露了。然后另一个 AI（OpenAI 的 Codex）在一夜之间将泄露的代码移植成了另一种语言。整个事件链中，人类的角色正在退到越来越边缘的位置。

有人将此解读为”Vibe Coding 的后果”，当你完全依赖 AI 写代码、不逐行审查，就会出这种事。这个批评有一定道理，但忽略了另一面：Claude Code 团队的功能迭代速度确实极快，KAIROS、三层记忆、反蒸馏、子 Agent 分叉等架构设计都显示出很高的工程成熟度。代价是偶尔在运营环节出现疏漏。这是一个速度与安全之间的经典权衡，Anthropic 显然选择了更靠近速度的那一端。

这个转变才是这次泄露揭示的最深层信号。我们正在进入一个代码由 AI 编写、由 AI 测试、为 AI 优化的时代。人类的角色从”编写者”变成了”审查者”和”决策者”。而当人类审查者跳过了那个关键的手动检查步骤时，整个链条就断了。

答案或许不是回到人类手写代码的时代，而是承认：在 AI 生产链条中，剩余的人工环节反而成了最脆弱的一环。修复方向应该是更多自动化，而非更多人工步骤。Anthropic 自己最终也会得出这个结论。下次不会有人需要记得去点那个按钮，因为按钮本身注定会被取消。