🍃作者介绍：AI 应用工程师 / 产品架构师，阿里云专家博主。Java 后端出身，现专注 LLM 应用开发、Agent 系统设计、具身智能与工业 AI 落地。日常在大模型训练、Coding Agent 工具链、AI 产品商业化等方向持续输出实战内容。
🦅个人主页：@逐梦苍穹
🐼GitHub主页：https://github.com/XZL-CODE
✈ 您的一键三连，是我创作的最大动力🌹

2026年3月31日，Anthropic 的 Claude Code CLI 完整源码因 npm 包中遗留的 source map 文件被公开。1906 个 TypeScript 文件、51.2 万行代码，就这样被一个打包失误"开源"了。本文将从事件经过、源码深度拆解、安全评估、工程启发四个维度，以一个 AI 应用工程师的视角，全面解构这份"意外的礼物"。

---

1、前言

作为一个日常深度使用 Claude Code 的 AI 应用工程师，当我看到 @Fried_rice 在 X 上发出那条推文的时候，第一反应是：终于有机会看看这个每天陪我写代码的工具，到底是怎么构建的了。

Claude Code 是目前 Coding Agent 赛道最强的产品之一，它的工具调用系统、权限管理、多 Agent 编排等能力，一直是我在做 AI 应用架构设计时的参考对象。这次源码泄漏，相当于直接拿到了 Anthropic 一线工程团队的设计蓝图。

本文不是简单的新闻搬运，而是我花了大量时间阅读源码后的深度技术分析——每一个结论都有对应的代码路径和文件引用。

---

2、事件概览

2.1 谁发现的？

安全研究员 Chaofan Shou（X/Twitter: @Fried_rice，Fuzzland 联合创始人）于 2026年3月31日发推披露：

“Claude code source code has been leaked via a map file in their npm registry!”

该推文浏览量迅速超过 79.4万次。Chaofan Shou 此前曾发现 Twitter XSS+CSRF 漏洞、多个 DeFi 协议攻击等，在安全圈有较高知名度。

中文社区的 @Gorden_Sun 也第一时间确认：

“我让 Claude Code 分析了，基本确定是 Claude Code 源码，而且是比较新的版本，因为支持 claude-opus-4-6。”

2.2 Source Map 是什么？为什么能泄漏源码？

Source map 是前端开发中常见的调试辅助文件，它建立了编译产物与原始源码之间的映射关系。当 TypeScript 被编译为 JavaScript、或代码被压缩混淆后，source map 可以让开发者在浏览器 DevTools 中看到原始源码。

关键点在于：source map 文件中包含了完整的原始源码文本。它绝不应出现在生产发布包中。

2.3 泄漏时间线

时间节点	版本	包大小	事件
2025年2月	v0.2.8	-	首次泄漏，Anthropic 紧急删除
2026年3月29日	v2.1.87	~17MB	正常发布
2026年3月30日	v2.1.88	~31MB	Source map 再次被打包，包大小翻倍
2026年3月31日	-	-	@Fried_rice 发现并公开
2026年3月31日	v2.1.89	~17MB	Anthropic 紧急修复

source map 以 inline-source-map 形式内嵌于 cli.mjs 文件中，长达 1836万字符。任何人用标准的 source-map npm 库即可还原出完整 TypeScript 源码——1,906 个文件，约 51.2 万行代码。

这不是第一次犯同样的错误，2025年2月的 v0.2.8 版本就发生过完全相同的 source map 泄漏。说明 Anthropic 的 CI/CD 流程中缺乏有效的包内容审查机制。

2.4 Anthropic 的应对

Anthropic 没有发表任何公开声明，仅以静默方式处理：

• 紧急发布 v2.1.89 移除 source map
• 从 npm 仓库删除 v2.1.88
• 尝试清除 npm 缓存

但代码早已被社区缓存并广泛传播。开发者 Dave Schumaker 甚至撰文记录了一个戏剧性的细节：Anthropic 删除旧版本后，他因为 Sublime Text 编辑器还开着，通过 Cmd+Z（撤销）找回了尚未关闭的 cli.mjs 文件内容——这大概是 Sublime Text 最意想不到的使用场景了。

2.5 社区反应

2.5.1 GitHub 上的"考古"项目

泄漏后社区迅速行动，出现了多个分析项目：

项目	说明	Stars
ghuntley/claude-code-source-code-deobfuscation	用 LLM 辅助进行 cleanroom 反混淆重建	~884
Piebald-AI/claude-code-system-prompts	从源码提取的 110+ 个系统提示词片段	7,200+
leeyeel/claude-code-sourcemap	直接从 source map 提取的完整源码	~33

Geoffrey Huntley 还撰文 “Yes, Claude Code can decompile itself”，描述了用 Claude 自身来反混淆 Claude Code 源码的过程，并感叹"LLM 在反混淆、转译和结构转换方面出乎意料地强大"。

2.5.2 Hacker News 的三派观点

在 Hacker News 讨论帖中，开发者们各抒己见：

技术赞赏派：

• 对 React + Ink 构建终端 UI 的架构表示认可
• 对启动优化（并行预取 MDM/Keychain）的细节印象深刻
• 对多层权限系统的安全设计给予肯定

代码批评派（如 HN 用户 q3k）：

• useCanUseTool.tsx 等文件存在极深的嵌套条件逻辑（“if statement soup”）
• 多处临时实现了相同的哈希函数和伪随机数生成器
• 环境变量访问分散各处，缺乏结构性文档

安全关注派：

• 安全研究员 Adam Chester（@xpnsec）在早期版本中发现了提示注入漏洞（CVE-2025-64755）：通过 sed 命令写入 .zshenv 实现代码执行
• 源码中发现了反调试保护机制和安全检查上报功能

2.5.3 中文社区热度

• Odaily 星球日报：题为"Claude Code 完整源码暴露"，详述技术细节
• BlockBeats（律动财经）：重点报道蚂蚁工程师逆向分析 Auto Mode 决策流水线的发现
• @karminski3：转发并评论"重磅新闻，claude code 反编译版本来了！"

---

3、源码深度分析

以下所有分析均基于实际代码阅读，每个结论都有对应的源码文件路径。我会从一个 AI 应用工程师的视角，重点拆解那些对我们做 AI 产品设计和 Agent 系统开发最有参考价值的架构决策。

3.1 整体架构一览

3.1.1 技术栈全景

类别	技术选型	选型分析
运行时	Bun	启动速度远优于 Node.js，适合 CLI 场景
语言	TypeScript（strict）	类型安全 + 大型项目可维护性
终端 UI	React + Ink	组件化思维管理复杂终端 UI
CLI 解析	Commander.js（extra-typings）	成熟方案 + TypeScript 类型推断
Schema 校验	Zod v4	运行时类型校验，与 TS 类型系统深度集成
代码搜索	ripgrep	性能远超原生 grep
协议	MCP SDK, LSP	标准化工具/语言服务协议
遥测	OpenTelemetry + gRPC	行业标准可观测方案
Feature Flags	GrowthBook	渐进式功能发布
认证	OAuth 2.0, JWT, macOS Keychain	多层认证体系

3.1.2 项目规模

src/
├── 1,884 个 TypeScript 文件
├── 18 个 JavaScript 文件
├── ~51.2 万行代码
└── 编译产物约 17MB（不含 source map）

我的点评：React + Ink 构建 CLI 是一个很大胆的选择。传统 CLI 工具用 readline/ncurses 风格的方案，但 Claude Code 的 UI 复杂度（权限弹窗、进度条、多面板、语法高亮）确实到了需要组件化框架的程度。这个选型对于做复杂 CLI 工具的团队很有参考价值。

3.2 启动优化：对毫秒的执念

src/main.tsx 的开头是一段精心编排的并行预取，这段代码让我印象深刻：

// main.tsx — 这些副作用必须在所有其他 import 之前运行：
// 1. profileCheckpoint 在重度模块求值开始前标记入口
// 2. startMdmRawRead 启动 MDM 子进程（plutil/reg query），
//    使其与后续 ~135ms 的 import 并行运行
// 3. startKeychainPrefetch 并行启动两个 macOS keychain 读取
//    （OAuth + legacy API key），否则 isRemoteManagedSettingsEligible()
//    会通过同步 spawn 串行读取它们（macOS 每次启动多花 ~65ms）

profileCheckpoint('main_tsx_entry');
startMdmRawRead();
startKeychainPrefetch();

注意这段代码的位置——在 import 语句之间穿插副作用调用。这在常规开发中是反模式，但 Anthropic 团队有意为之：利用 JavaScript 模块求值的顺序性，在后续模块导入的 ~135ms 窗口期内，让 MDM 和 Keychain 的 I/O 操作并行完成。

我的点评：做 AI 应用开发的同学要注意，CLI 工具的启动体验至关重要。用户每次输入一条指令就要等一次冷启动，65ms 的差距累积起来会严重影响使用意愿。这种对毫秒的"斤斤计较"是专业级 CLI 工具和玩具 Demo 之间的差距。

3.3 Feature Flag 驱动的内外版本分离

源码大量使用 Bun 的 bun:bundle feature flag 做编译时死代码消除：

import { feature } from 'bun:bundle'

// 编译时根据 feature flag 决定是否包含代码
// 如果 flag 为 false，整个 require 和相关代码会被 tree-shaking 剥除
const coordinatorModeModule = feature('COORDINATOR_MODE')
  ? require('./coordinator/coordinatorMode.js')
  : null

const assistantModule = feature('KAIROS')
  ? require('./assistant/index.js')
  : null

3.3.1 已发现的 Feature Flag 清单

Flag	含义	状态推测
PROACTIVE	主动模式基础功能	内测中
KAIROS	全功能主动/助手模式	未发布
VOICE_MODE	语音输入	部分开放
BRIDGE_MODE	IDE 桥接模式	已发布
COORDINATOR_MODE	多 Agent 编排	已发布
DAEMON	守护进程模式	未发布
TRANSCRIPT_CLASSIFIER	AFK Mode 权限自动分类器	已发布（auto 模式）
FORK_SUBAGENT	隐式 Fork 子 Agent	未发布
CCR_MIRROR	未知内部功能	未发布

关键洞察：这意味着 npm 上的公开版本和 Anthropic 内部版本功能差异可能非常大。公开版本在编译时就把未发布功能的代码彻底剥除了——你在 node_modules 里反编译也找不到那些代码，因为它们根本不存在于编译产物中。

我的点评：这个方案比我之前见过的大多数 feature flag 实现都要优雅。常见做法是运行时 if/else 判断，代码仍然存在于产物中；而 Bun 的编译时消除是真正的零开销——不仅没有运行时分支判断，连代码体积都不会增加。对于做 SaaS 产品的团队，这是一个很好的"内部版 vs 公开版"分离范式。

3.4 Auto Mode 四层安全决策流水线

这是源码中最值得深入研究的设计。作为 AI 应用工程师，我在做 Agent 系统时经常面对同一个问题：如何在"自动化"和"安全性"之间找到平衡？ Claude Code 的答案是四层递进式决策。

3.4.1 第一层：权限规则匹配

检查用户预设的权限规则（来自 8 个来源：userSettings、projectSettings、localSettings、flagSettings、policySettings、cliArg、command、session），如果有匹配规则，直接批准或拒绝。

3.4.2 第二层：模式模拟

模拟 acceptEdits 模式——如果在该模式下操作会被允许，说明是低风险操作（如文件编辑），直接放行。

3.4.3 第三层：只读工具白名单

Read、Grep、Glob、LSP、WebSearch 等只读工具无条件放行——读操作不会造成破坏性变更。

3.4.4 第四层：AI 分类器

前三层都无法判断时，调用 Claude Sonnet（温度=0，确定性输出） 进行安全审查。分类器会拦截 22+ 类危险操作，包括：

• git push --force / git reset --hard
• 生产环境部署命令
• 凭证文件的读写
• 数据库删除操作
• 系统文件修改
• ……

3.4.5 熔断机制

连续 3 次或累计 20 次被 AI 分类器拒绝后，自动切换到手动确认模式。这防止了恶意提示注入通过反复尝试来"碰运气"。

我的点评：这个四层设计的精妙之处在于渐进式成本控制——大部分请求在前三层（纯逻辑判断，零成本）就能决策，只有真正需要语义理解的操作才会调用 AI 分类器（需要消耗 token）。这比"所有操作都过 AI 审查"高效得多。我在设计自己的 Agent 权限系统时，会直接参考这个分层架构。

3.5 工具系统设计

Claude Code 的工具系统是其核心能力的载体。从 src/tools/ 目录可以看到约 40 个工具的完整实现：

3.5.1 工具注册与 Schema

每个工具都是一个独立模块，通过 buildTool() 函数构建，定义了：

// src/tools/BashTool/BashTool.tsx 结构示意
const tool = buildTool({
  name: 'Bash',
  description: '...',
  inputSchema: z.object({
    command: z.string(),
    timeout: z.number().optional(),
    // ...
  }),
  // 权限模型
  isReadOnly: () => false,
  // 执行逻辑
  call: async (input, context) => { /* ... */ },
  // UI 渲染
  renderToolUse: (props) => <BashToolUI {...props} />,
})

这是一个非常清晰的关注点分离：Schema 定义、权限声明、执行逻辑、UI 渲染四个维度正交独立。

3.5.2 BashTool 的安全纵深

BashTool 是功能最强大也最危险的工具，它的实现体现了"安全纵深"理念：

防护层	实现	文件
命令 AST 解析	对 shell 命令进行语法树解析，识别危险模式	utils/bash/ast.ts
sed 编辑检测	专门解析 sed 命令，防止通过 sed 写入文件	tools/BashTool/sedEditParser.ts
只读约束检查	在只读模式下阻止写操作	tools/BashTool/readOnlyValidation.ts
沙箱隔离	通过 @anthropic-ai/sandbox-runtime 限制文件/网络访问	utils/sandbox/sandbox-adapter.ts
Git 操作追踪	自动追踪 git 命令的影响范围	tools/shared/gitOperationTracking.ts

我的点评：做过 AI Agent 的同学都知道，Bash 工具是"万能钥匙"——它能做任何事，所以也能搞任何破坏。Claude Code 对 BashTool 的五层防护设计，是我见过的 AI 工具安全实现中最完善的。特别是 sed 命令的专门解析器，直接堵住了 CVE-2025-64755 这类提示注入的攻击面。

3.6 多 Agent 编排系统（Coordinator）

src/coordinator/coordinatorMode.ts 实现了一个完整的多 Worker 编排框架，这对于理解 Claude Code 的 Agent Teams 功能非常关键：

3.6.1 编排模式

• SIMPLE 模式：Worker 只能使用 Bash/Read/Edit，适合简单并行任务
• FULL 模式：Worker 可以使用完整工具集（排除部分内部工具），适合复杂任务

3.6.2 工作流设计

系统强制执行一个严格的工作流：

Research（并行）→ Synthesis（综合）→ Implementation（串行）→ Verification（验证）

编排 prompt 中有一条明确的反模式禁令：

“Based on your findings, fix the bug” — 这种把综合推理推给 Worker 的做法是被禁止的。Coordinator 必须先理解 Worker 的研究结果，再发出具体的实施指令。

3.6.3 跨 Worker 知识共享

提供 Scratchpad 机制——一个持久化的跨 Worker 知识存储，无需权限提示即可读写。这解决了并行 Agent 之间的信息同步问题。

我的点评：这套编排系统的设计理念和我在做 Agent 系统时的思考高度一致：Agent 不是越多越好，关键在于编排策略。Research 并行、Implementation 串行的工作流，Scratchpad 的跨 Agent 知识共享，"综合后再委派"的强制约束——这些都是经过大量实践打磨出来的设计。

3.7 Buddy System——被提前泄漏的愚人节彩蛋

src/buddy/ 目录藏着一个完整的电子宠物系统，被 Hacker News 用户确认是 2026 年愚人节（4月1日）计划的一部分。

3.7.1 宠物生成机制

// src/buddy/companion.ts 核心逻辑
// 使用 Mulberry32 PRNG 确定性生成
// salt: 'friend-2026-401'（401 = April Fools）
function mulberry32(seed: number): () => number {
  return () => {
    seed |= 0; seed = seed + 0x6D2B79F5 | 0;
    let t = Math.imul(seed ^ seed >>> 15, 1 | seed);
    t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
    return ((t ^ t >>> 14) >>> 0) / 4294967296;
  }
}

• 18 个物种：鸭子、鹅、水滴(blob)、龙、美西螈(axolotl)、水豚(capybara)、蘑菇……还有一个叫 “chonk” 的特殊物种
• 5 个稀有度：Common → Uncommon → Rare → Epic → Legendary（加权概率）
• 1% 概率出现"闪光"（shiny）变体
• ASCII 艺术动画：5 行高、12 字符宽的逐帧动画
• 属性系统：DEBUGGING, PATIENCE, CHAOS, WISDOM, SNARK

每个宠物通过用户 ID 的 hash 确定性生成，所以你的宠物是唯一且固定的——骨骼（外观）由算法决定，灵魂（名字、性格）由 Claude 生成并持久化。

我的点评：这个彩蛋因为源码泄漏而提前曝光，据说打乱了 Anthropic 的营销计划。但不得不说，用 seeded PRNG 保证确定性生成、骨骼与灵魂分离的设计，是一个非常优雅的工程实现。也侧面说明 Anthropic 的工程文化——即使是愚人节彩蛋，代码质量也不含糊。

3.8 KAIROS——主动模式的内部代号

“Kairos”（希腊语，意为"恰当的时机"）是 Claude Code 主动模式（Proactive Mode）的内部代号。这个功能目前处于 Feature Flag 控制之下，尚未完全对外开放。

3.8.1 设计哲学

在 KAIROS 模式下，Claude 不再等待用户输入，而是持续主动工作。所有与用户的沟通必须通过 SendUserMessage 工具（代码中称为 BriefTool）：

“Text outside it is visible if the user expands the detail view, but most won’t — assume unread. Anything you want them to actually see goes through SendUserMessage… Even for ‘hi’. Even for ‘thanks’.”

3.8.2 功能分支

Feature Flag	功能
KAIROS_BRIEF	简短消息变体
KAIROS_CHANNELS	频道支持
KAIROS_GITHUB_WEBHOOKS	GitHub Webhook 集成

我的点评：KAIROS 的设计方向很明确——从"被动工具"演进为"主动助手"。GitHub Webhooks 的集成暗示未来 Claude Code 可能会在代码推送、PR 创建等事件发生时自动触发响应。这对 AI 应用产品化方向有重要参考意义。

3.9 权限系统架构

权限系统是 Claude Code 安全架构的核心，定义在 src/types/permissions.ts 和 src/utils/permissions/ 中。

3.9.1 权限模式

模式	类型	说明
default	外部	每次危险操作都需用户确认
acceptEdits	外部	自动批准文件编辑，其他操作仍需确认
plan	外部	只允许只读操作，需用户批准实施计划
bypassPermissions	外部	跳过所有权限检查（危险）
dontAsk	外部	被拒绝时静默跳过，不再询问
auto	内部	AI 分类器自动决策（即四层流水线）
bubble	内部	权限提示向上冒泡到父 Agent

3.9.2 权限规则来源（8 层）

权限规则可以来自 8 个不同的来源，按优先级排序：

1. policySettings — 组织策略（最高优先级）
2. cliArg — 命令行参数
3. command — 命令级别
4. session — 会话级别
5. flagSettings — Feature Flag
6. localSettings — 本地项目设置
7. projectSettings — 项目 CLAUDE.md 配置
8. userSettings — 用户全局设置

我的点评：8 层权限来源的设计很巧妙——它允许企业 IT 管理员通过 policySettings 强制覆盖用户的任何本地设置，同时也给个人用户足够的灵活性。这种"组织策略 > 用户偏好"的优先级模型，对做企业级 AI 工具非常有参考价值。

3.10 沙箱系统

src/utils/sandbox/ 实现了基于 @anthropic-ai/sandbox-runtime 的运行时隔离，用于限制 BashTool 的破坏范围：

• 文件系统限制：allowWrite、denyWrite、denyRead、allowRead 四个维度
• 网络隔离：allowedDomains 白名单、allowUnixSockets（仅 macOS）
• 域名管控模式：组织策略可以限制只允许访问 managed 域名
• 违规追踪：SandboxViolationStore 记录所有违规尝试

代码注释中有一个有趣的安全细节：

“com.apple.trustd.agent access in sandbox… reduces security — opens potential data exfiltration vector”

——即使是 macOS 系统服务的访问，团队也在权衡安全风险。

3.11 内部命名彩蛋

代码中散落着有趣的内部命名规范，透露出团队文化：

名称	含义	分析
tengu_	核心内部功能的命名空间前缀	“天狗”——团队中有日本文化爱好者？
tengu_amber_quartz_disabled	语音模式的紧急关闭开关	用宝石名做 kill switch
tengu_hawthorn_window	工具结果预算控制	“山楂窗口”
tengu_scratch	Scratchpad 功能
friend-2026-401	Buddy 系统的随机种子盐值	401 = April Fools
AnalyticsMetadata_I_VERIFIED_THIS_IS_NOT_CODE_OR_FILEPATHS	防止遥测误报文件路径的显式类型名	这个命名风格只有真实内部代码才有
moreright/	内外版本扩展点	名字可能暗示"more rights"（更多权限）

3.12 MoreRight——内外有别的扩展点

src/moreright/useMoreRight.tsx 是一个几乎空白的 React Hook，但它暴露了 Anthropic 的内外分离构建策略：

• 公开版本：返回 no-op（空操作）
• 内部版本：提供 onBeforeQuery（查询前拦截）、onTurnComplete（回合后处理）、render（自定义 UI）

这说明 Anthropic 内部可能在使用一个功能更丰富的 Claude Code 版本，通过这个扩展点挂载额外的内部工具和 UI。

3.13 Vim 模式——工程级的状态机

src/vim/ 不是简单的 vi 键绑定，而是一个完整的 Vim 引擎：

• 完整的状态机：INSERT、NORMAL（含 idle/operator/count/find/replace/indent/g-command 子状态）
• 文本对象：word、WORD、引号、括号、方括号、大括号、尖括号
• 操作符：delete (d)、change ©、yank (y)
• f/F/t/T 字符查找 + count 支持
• Dot-repeat 记忆（保存 RecordedChange 对象）

最有趣的是，类型定义文件中直接用 ASCII 画了完整的状态转换图作为文档——用 TypeScript 类型系统保证所有状态转换都被穷举处理。

---

4、安全影响评估

4.1 泄漏了什么？

• Claude Code CLI 客户端的完整 TypeScript 源码（1,906 文件）
• 系统提示词的完整集合（110+ 个片段，已被单独整理为 7.2k stars 项目）
• 权限系统、沙箱系统的完整实现细节
• 内部 Feature Flag 和未发布功能的代号
• 内部命名规范和团队文化线索

4.2 没有泄漏什么？

• 模型权重或训练数据
• 用户数据或会话记录
• API 密钥或内部服务凭证
• 服务端代码（API 后端、训练基础设施等）

4.3 实际风险评估

风险类型	影响程度	说明
提示注入攻击面扩大	中	了解权限判断逻辑后，攻击者可更精准地构造绕过方案
竞品架构参考	高	其他 AI 编码工具可以直接学习 Claude Code 的设计
未发布功能曝光	低	Buddy System、KAIROS 等提前曝光，但无实质安全影响
普通用户风险	极低	不涉及模型、数据或凭证，无直接安全威胁

---

5、AI 应用工程师的 5 个收获

作为一个每天在 Agent 系统设计、AI 工具链开发上花大量时间的从业者，这份源码给了我几个非常实用的启发：

5.1 编译时裁剪 > 运行时判断

用 bun:bundle feature flag 实现内外版本分离，比运行时 if/else 更彻底：

• 零运行时开销
• 代码体积无增长
• 未发布功能的代码在公开产物中物理不存在

可借鉴场景：做 SaaS 产品的内部版/社区版/企业版分离。

5.2 安全系统要分层，不要一刀切

Auto Mode 的四层决策 + 熔断机制告诉我们：

• 大部分请求用规则就能解决（低成本）
• 只有真正需要语义理解的操作才调用 AI（高成本但高精度）
• 熔断机制防止暴力尝试

可借鉴场景：任何需要"自动化 + 安全"平衡的 Agent 系统。

5.3 CLI 工具的毫秒级优化值得投入

启动阶段的并行预取、lazy loading、重模块延迟 import——这些看似微小的优化，累积起来决定了用户体验的质量。

可借鉴场景：开发者工具、CLI 工具的冷启动优化。

5.4 Agent 编排的核心是"综合后再委派"

Coordinator 系统明确禁止"Based on your findings, fix the bug"这种把思考推给 Worker 的做法。Coordinator 必须先理解、再指导。

可借鉴场景：多 Agent 系统的编排策略设计。

5.5 即使是彩蛋，也要有工程标准

Buddy System 的确定性生成、骨骼/灵魂分离设计，说明好的工程文化不区分"正经功能"和"玩具功能"。

---

6、结语

一个 source map 文件，揭开了当前最强 AI 编码工具的内部面纱。

作为一个 AI 应用工程师，我从这份源码中学到的远比一篇技术博客能承载的更多。Claude Code 的工程实践——从四层安全流水线到编译时 feature flag，从毫秒级启动优化到多 Agent 编排策略——每一个设计决策背后都有实实在在的思考和取舍。

这不是一次简单的"代码泄漏"，而是一份价值连城的 AI 工具工程教材。

当然，我们也看到了讽刺的一面：即使是 Anthropic 这样的顶尖 AI 公司，也会在 CI/CD 流程中犯低级错误。而且，这已经是第二次同样的错误了。

也许 Anthropic 的下一个 Feature Flag 应该叫 tengu_never_ship_sourcemaps_again。

---

本文基于公开传播的泄漏源码及网络公开信息撰写，所有源码版权归 Anthropic 所有。

参考来源：

• Chaofan Shou (@Fried_rice) 原始推文
• Hacker News 讨论帖 #47584540
• Dave Schumaker: Digging into Claude Code Source
• ghuntley: Yes, Claude Code can decompile itself
• Piebald-AI/claude-code-system-prompts (GitHub, 7.2k stars)
• XPN InfoSec: An Evening with Claude Code (CVE-2025-64755)
• BlockBeats: Auto Mode 四层决策流水线分析
• Odaily: Claude Code 完整源码暴露

🚀 持续探索 AI 与前沿技术 分享大模型应用、软件开发实战与行业洞察。 欢迎关注公众号 【龙哥AI】，加入 7000+ 技术同行的交流圈！ 🌟 探索技术边界，让开发更有效率