上一篇文章发布后，许多读者纷纷询问：那套代码真的如此强大吗？Anthropic不是手握超过100亿美元融资吗？按理说代码质量应该很高吧？

答案恰恰相反——这个问题本身就暴露了一个常见的认知偏差：融资规模大，并不等同于代码写得好。

事实上，当开发者 Chaofan Shou 将 Claude Code 的源码公开后，另一位工程师 Rohan 也进行了深入审查。他的发现与之前的分析截然不同——并不是精妙的架构设计，而是一堆令人头疼的技术债务。

我把这些发现整理出来，结合自己的理解，和大家聊聊：一个顶级AI产品的代码里，究竟藏着哪些“正常”的混乱。

提前说明：这并非针对 Anthropic。任何快速迭代的产品都会积累类似的问题。Claude Code 能发展到今天这个样子，工程团队已经非常出色了。但正因为它是“全球最重要的AI开发工具之一”，这些问题才更值得我们公开讨论。

第一件事：一个React组件，5005行

打开 screens/REPL.tsx，你会看到一个长达5005行的文件。

这是每天与 Claude Code 交互的主界面。整个用户界面，就被塞进了一个组件里。

单看这一个文件中的 React Hook 调用数量：

• useState：68个
• useEffect：43个
• useRef：54个
• useCallback：44个
• useMemo：18个

总计：227个 Hook 调用，绝大部分集中在同一个组件内。

JSX 嵌套最深的位置在第4604行，缩进达到了22层。整个文件包含超过300个条件分支。光是 import 部分就有244行，引用了235个不同的模块。

我知道你想说什么——“大文件怎么了，能跑就行”。

但问题不在于“大”，而在于这样的代码已经变得不可测试了。

想象一下：43个 useEffect，每一个都可能依赖前面68个 useState 中的某几个。要想给这个组件写单元测试，追踪依赖链到最后，你会发现几乎无从下手。代码中在第4114行也有一条坦诚的注释：

// TODO: fix this
// eslint-disable-next-line react-hooks/exhaustive-deps

团队自己也知道这里有问题，但一直没有修复。

这种“巨型组件”是怎么诞生的？

没有人一开始就计划写5000行。它是这样一步步长大的：一开始只是一个简单的终端输入框，然后加入了流式输出，接着是工具执行、权限弹窗、上下文压缩提示、语音模式、远程会话……每增加一个新功能，就多几十行代码，看起来没什么。等你回过神来，已经5005行了。

正确的做法是什么？使用状态机（比如 XState，或者简单的 reducer）来驱动15-20个职责单一的子组件。REPL 其实有非常清晰的状态边界：初始化中、等待输入、流式输出、执行工具、等待权限、压缩上下文、展示结果。每个状态对应一个子组件，68个 useState 可以变成一个带类型的状态对象。这是 React 处理复杂 UI 的标准做法，不清楚为什么没采用。

可能的原因：这个产品的迭代速度太快了，没时间做重构。

第二件事：89个 Feature Flag，960次引用

Feature flag 是产品开发中的常规手段——你想灰度一个新功能，开启一个开关，先让10%的用户试用，确认没问题再全量发布。

但 Claude Code 里竟然有89个 Feature Flag，在整个代码库中被引用了960次。

把完整列表搬过来，感受一下：

ABLATION_BASELINE, AGENT_MEMORY_SNAPSHOT, AGENT_TRIGGERS, AGENT_TRIGGERS_REMOTE, 
ALLOW_TEST_VERSIONS, ANTI_DISTILLATION_CC, AUTO_THEME, AWAY_SUMMARY, BASH_CLASSIFIER, 
BG_SESSIONS, BREAK_CACHE_COMMAND, BRIDGE_MODE, BUDDY, BUILDING_CLAUDE_APPS,
BUILTIN_EXPLORE_PLAN_AGENTS, BYOC_ENVIRONMENT_RUNNER, CACHED_MICROCOMPACT, 
CCR_AUTO_CONNECT, CCR_MIRROR, CCR_REMOTE_SETUP, CHICAGO_MCP, COMMIT_ATTRIBUTION, 
COMPACTION_REMINDERS, ...（还有60多个）
KAIROS, KAIROS_BRIEF, KAIROS_CHANNELS, KAIROS_DREAM, KAIROS_GITHUB_WEBHOOKS, 
KAIROS_PUSH_NOTIFICATION, ULTRAPLAN, ULTRATHINK, VERIFICATION_AGENT, VOICE_MODE,
WEB_BROWSER_TOOL, WORKFLOW_SCRIPTS

单单“KAIROS”这一个功能就有6个独立的 Flag：KAIROS、KAIROS_BRIEF、KAIROS_CHANNELS、KAIROS_DREAM、KAIROS_GITHUB_WEBHOOKS、KAIROS_PUSH_NOTIFICATION。

这已经不是 Feature Flag 了，这简直是在一个代码仓库里藏了一个平行产品。

还有一些 Flag，光看名字就暗示着身份尴尬：

• EXPERIMENTAL_SKILL_SEARCH：还在实验阶段，但究竟实验了多久？
• NEW_INIT：有新的初始化逻辑，那旧的还保留着吗？
• OVERFLOW_TEST_TOOL：这是测试用的工具，为什么会在生产代码里？
• ABLATION_BASELINE：消融测试基线？这是研究代码混进来了？

除了 Feature Flag，还有472个环境变量，分散在1425个调用点：

ANTHROPIC_API_KEY, ANTHROPIC_AUTH_TOKEN, ANTHROPIC_BASE_URL,
ANTHROPIC_BEDROCK_BASE_URL, ANTHROPIC_BETAS, ANTHROPIC_CUSTOM_HEADERS, 
ANTHROPIC_CUSTOM_MODEL_OPTION, ANTHROPIC_DEFAULT_HAIKU_MODEL, 
ANTHROPIC_DEFAULT_OPUS_MODEL, ANTHROPIC_DEFAULT_SONNET_MODEL, 
ANTHROPIC_FOUNDRY_API_KEY, ANTHROPIC_FOUNDRY_BASE_URL, ANTHROPIC_MODEL,
CLAUDE_CODE_COORDINATOR_MODE, ...// 还有458个

为什么这很重要？

89个 Flag 说明一件事：这个团队并不确定这个产品最终会变成什么样子。Feature Flag 是用来做渐进式发布的，而不是替代产品决策的。当你拥有89个 Flag 的时候，你实际上是在用代码推迟一个艰难的决定：到底要做哪个功能，不做哪个功能。

值得一提的是，这里使用的是 Bun 的编译期 feature() 函数，所以被禁用的 Flag 对应的代码会在构建时被完全删除，运行时不会产生性能损耗。代价纯粹体现在开发体验层面：当960个 feature check 散落在代码库各处时，没有人知道哪些 Flag 还活着、哪些可以安全删除。

第三件事：61个文件在处理循环依赖

在代码中搜索“break import cycle”、“a void circular dependency”、“circular dependency”，会在61个不同的文件中找到结果。

而且团队并没有隐瞒这个问题，注释写得相当坦诚：

// types/permissions.ts
// Pure permission type definitions extracted to break import cycles.

// to a void circular dependencies.
// schemas/hooks.ts
// Hook Zod schemas extracted to break import cycles.

// circular dependency between settings/types.ts and plugins/schemas.ts.

// tasks.ts
// Note: Returns array inline to a void circular dependency issues 
// with top-level const

// utils/bash/ast.ts (line 2218)
// circular import with bashPermissions.ts.

处理循环依赖的方式无非几种：

1. 把类型定义单独提取到一个文件（types/permissions.ts 就是这么来的）
2. 用懒加载 require() 代替 import
3. 把本应 import 的内容直接内联进来

这些都是补丁，不是根本解决方案。

types/permissions.ts 这个文件存在的唯一理由就是打破循环依赖。schemas/hooks.ts 同理。几个文件的存在价值不是承载业务逻辑，而是作为架构债务的创可贴。

根本原因在哪里？

追踪下来，问题的核心是 Tool.ts——一个792行的类型定义文件，它同时引用了权限类型、消息类型、分析模块、MCP类型、Agent类型、进度类型、Hook……当你的核心类型文件引用了所有东西，那么所有东西也会反过来引用它，循环依赖就这样产生了。

61个文件，说明模块边界从来没有被刻意设计过，而是随着功能增长自然长出来的。每一个懒加载 require() 都是 TypeScript 无法在编译期帮你检查的一个漏洞。

第四件事：一个出现1193次的类型名

logEvent('tengu_startup_telemetry', {
    entrypoint: entrypoint as AnalyticsMetadata_I_VERIFIED_THIS_IS_NOT_CODE_OR_FILEPATHS,
    action: 'hint_converted' as AnalyticsMetadata_I_VERIFIED_THIS_IS_NOT_CODE_OR_FILEPATHS,
    variant: idleHintShownRef.current as AnalyticsMetadata_I_VERIFIED_THIS_IS_NOT_CODE_OR_FILEPATHS,
})

AnalyticsMetadata_I_VERIFIED_THIS_IS_NOT_CODE_OR_FILEPATHS。

53个字符。在整个代码库里出现了1193次，其中超过1000次是显式的 as 类型断言。

这个设计的初衷是好的——Claude Code 运行在用户的真实代码库上，绝不能把文件路径、源代码内容或密钥意外发送到数据分析管道中。因此他们设计了这种类型，强制开发者在每次记录事件时手动确认：“我验证了这个字段既不是代码也不是文件路径”。

问题是：当你需要写这1193次的时候，它就不再是一个安全检查了，而变成了一种仪式。

第一周你可能还会认真读它、想一想。到第三周，你已经形成了肌肉记忆，打完字还没进脑子。

更关键的是：这个类型断言什么都没防住。as 是 TypeScript 在说“相信我”，而不是在执行任何运行时验证。你完全可以把一个文件路径 as AnalyticsMetadata_I_VERIFIED_THIS_IS_NOT_CODE_OR_FILEPATHS，编译器不会报任何错误。

正确的做法应该是：

// 不是这样（现在的做法）：
logEvent('name', {
    key: value as AnalyticsMetadata_I_VERIFIED_THIS_IS_NOT_CODE_OR_FILEPATHS,
})

// 应该是这样：
logSafeEvent('name', {
    key: SafeMetadata.from(value) // 运行时检查：如果value看起来像路径就抛错
})

运行时验证才能真正拦截问题。一个53字符的类型名只是在“礼貌地请求”开发者注意，而这种请求在重复1000多次之后，早就被忽略了。

第五件事：用十六进制编码来拼写“鸭子”

这是整个源码里最令人莞尔的一段：

// buddy/types.ts
// One species name collides with a model-codename canary in 
// excluded-strings.txt. The check greps build output (not source), 
// so runtime-constructing the value keeps the literal out of the 
// bundle while the check stays armed for the actual codename.
// All species encoded uniformly.

const c = String.fromCharCode

export const duck = c(0x64,0x75,0x63,0x6b) as 'duck'
export const goose = c(0x67,0x6f,0x6f,0x73,0x65) as 'goose'
export const blob = c(0x62,0x6c,0x6f,0x62) as 'blob'
export const cat = c(0x63,0x61,0x74) as 'cat'
export const dragon = c(0x64,0x72,0x61,0x67,0x6f,0x6e) as 'dragon'
export const octopus = c(0x6f,0x63,0x74,0x6f,0x70,0x75,0x73) as 'octopus'
// ...还有10多种动物，全部十六进制

没错，Claude Code 里藏了一个宠物系统（对应上面提到的 BUDDY Feature Flag）。有稀有度等级（从 common 到 legendary），有不同的物种，有帽子、眼睛样式、属性分布……这是一个藏在终端编程工具里的电子宠物。

但这段代码想说的不是宠物系统（这个留到下篇讲），而是为什么 duck 要写成 c(0x64,0x75,0x63,0x6b)。

原因在注释里：某个物种的名字（大概像 axolotl 或者 capybara 这类奇异物种，我猜的）和 Anthropic 内部某个模型的代号撞了。Anthropic 的 CI 流水线会 grep 构建产物，检查有没有泄露内部模型代号——这是很合理的安全金丝雀机制。

问题是，撞名之后正确的修法是给 CI 脚本加一条排除规则，专门忽略 buddy 模块。但实际的做法是：把所有18个物种的名字全部用十六进制编码，一个不剩。

现在任何一个新来的工程师打开这个文件，看到满屏十六进制，内心独白大概是：？？？

第六件事：4683行的入口文件

main.tsx 是 CLI 的入口文件，它有4683行，塞进去了：

• 所有 CLI 命令定义（claude、init、config、mcp、doctor等）
• 全部参数和 Flag 解析（通过 Commander.js）
• 完整的 OAuth 登录流程
• 会话恢复逻辑
• 远程会话管理
• 性能基准采样
• 插件加载
• MDM（移动设备管理）配置

为什么全塞在一个文件里？注释给出了答案：

// main.tsx — lines 1-8
// These side-effects must run before all other imports:
// 1. profileCheckpoint marks entry before hea vy module evaluation begins
// 2. startMdmRawRead fires MDM subprocesses in parallel with the 
//    remaining ~135ms of imports below
// 3. startKeychainPrefetch fires both macOS keychain reads in parallel
//    (~65ms on every macOS startup)

翻译一下：Bun 对 import 是饥渴式求值的，导入越深，启动越慢。把所有东西塞进一个文件，减少 import 层级，能在启动时节省大约135毫秒。

这不是意外，而是有意的架构决策：用代码可读性换取启动速度。

这个取舍是否合理？取决于你站在哪个角度：

• 站在用户角度：Claude Code 是一个每天要调用几十上百次的工具。少135ms，乘以100次，每天就是13.5秒。长期积累确实有感知。
• 站在工程师角度：一个4683行的入口文件，意味着“添加一个新的 CLI 子命令”这件事会令一个本来就很拥挤的地方更加拥挤。任何修改都可能引发意外的副作用。

其实有折中方案：懒加载命令模块。当有人运行 claude init 时才加载 init 模块，需要 OAuth 时才加载认证模块。这是几乎所有大型 CLI 工具（oclif、yargs 等）的标准做法。Bun 支持动态 import()，理论上可以实现。

但可能 Bun 的模块加载有特殊性，这条路在他们的技术栈里走不通。这方面没有足够把握，先留个问号。

第七件事：require() 混进了 TypeScript 里

这是上面几个问题叠加之后的连锁反应。

在 query.ts 和 REPL.tsx 里，会看到这种写法：

// query.ts — lines 15-22
const reactiveCompact = feature('REACTIVE_COMPACT')
    ? (require('./services/compact/reactiveCompact.js') as typeof import('./services/compact/reactiveCompact.js'))
    : null

const contextCollapse = feature('CONTEXT_COLLAPSE')
    ? (require('./services/contextCollapse/index.js') as typeof import('./services/contextCollapse/index.js'))
    : null

这是 TypeScript 代码在 ES 模块里使用 require()，外面包裹编译期 Feature Flag 检查，然后再用 as typeof import(...) 把类型找回。

REPL.tsx 里有17处这种写法，query.ts 里有6处。

为什么要这么写？因为：

1. import 是声明式的，模块加载时就会被执行，没法条件化
2. feature() 检查需要在编译时阻止整个模块被打包进来
3. 只有 require() 能在函数体内条件性地加载模块
4. 但 require() 会让 TypeScript 丢失类型信息
5. 所以要用 as typeof import(...) 把类型“找回来”

这是一种将四个不同层面（编译期、运行时、模块系统、类型系统）的工具硬拼在一起的写法，每一步都是对下一步问题的补救。

最大的风险在哪里？

as typeof import(...) 是一个类型断言，不是类型验证。如果有人修改了 reactiveCompact.js 的导出结构，这里的类型会悄悄地撒谎，TypeScript 编译器不会报错。只会在运行时才发现问题。

现代 JS 有 dynamic import() 可以做条件性模块加载，而且完全保留类型信息：

const module = await import('./services/compact/reactiveCompact.js')

Bun 支持这个语法。但因为 import() 是异步的，改造需要让调用链变成 async，这是一个波及范围比较广的重构。所以他们选择了 require() 这条“更简单但更危险”的路。

把这些放在一起看

读完这七个问题，你可能会问：这代码到底好不好？

答案是：这很正常，也是真实的代价。

这些问题不是 Anthropic 工程团队水平差。恰恰相反，里面很多决策（比如入口文件启动速度优化）都是有意识的取舍，是真正做过生产系统的人才会做的权衡。

但这些问题也揭示了一件事：Claude Code 在过去一两年里，增长速度超过了其架构所能承受的范围。

这很常见。几乎所有快速成长的产品都会经历这个阶段：功能塞得比重构快，Flag 加得比清理快，依赖加得比梳理快。最后得到的就是5005行的巨型组件，89个 Feature Flag，61处循环依赖。

问题不在于“这些存在”，而在于：当你的产品是一个直接在用户机器上跑命令的 AI 工具时，这些技术债的风险溢价就比普通的 Web 应用高得多。

一个循环依赖，在普通的 Web 应用里可能只是代码丑陋；在一个拥有9层安全审查的工具里，如果恰好影响了权限判断的逻辑，后果就完全不同了。

这是值得认真对待的区别。

你能从这里学到什么

如果你在做 AI Agent 产品：

Claude Code 的这些问题，本质上是“Product Market Fit 之后、工程化之前”的典型症状。找到了用户价值，但还没来得及用工程的方式将其固化下来。

这个阶段有一条很难走的路：在不停止迭代的前提下，逐步偿还技术债。没有捷径，只有优先级选择。

如果你在写任何需要长期维护的代码：

5005行的 React 组件不是一天长成的。每一次“先这样，以后再说”都在往里加砖。

“以后再说”的问题不是它不对，而是“以后”经常不会来。

定期的重构不是奢侈品，而是工程可持续性的最低保障。

如果你觉得 Anthropic 的代码应该完美无缺：

这篇文章是一个很好的提醒：不存在完美的代码库，只有不同的取舍。真正的工程水平，不是写出没有问题的代码，而是清楚地知道做了哪些取舍，为什么做，代价是什么。

从这个角度看，Claude Code 的注释文化其实相当好——61处循环依赖都有注释说明，main.tsx 的架构决策都有注释解释，问题被承认，原因被记录。这是一个团队对自己技术债保持清醒认知的表现。

知道自己欠了多少债，不代表没有债。但总比欠了不知道要好得多。