导读:从 Claude Code 源码中学到的设计哲学

导读：从 Claude Code 源码中学到的设计哲学

写给产品经理的产品架构课

为什么产品经理应该研究一个 CLI 工具的源码？

你可能会觉得，我是做产品功能的、做增长策略的、做用户调研的，为什么要去看 50 万行代码？

因为 Claude Code 的设计决策，本质上就是产品决策的技术表达。每一个架构选择背后，都有一群工程师在权衡利弊、争论方案、做出取舍。这些取舍，就是你能学到东西的核心。

举个例子：Claude Code 的安全系统设计。它没有选择”简单直接”的全询问模式，也没有选择”完全信任”的全放行模式，而是设计了 5 种权限模式，让用户根据自己的信任程度逐步放开。这个技术选择背后的产品洞察是：信任不是一次建立的，而是通过重复的安全体验逐步积累的。

这种洞察，不是来自用户访谈，不是来自数据分析，而是来自你对技术实现的深入理解。

Claude Code 的五条核心设计原则

通过深入分析 10 个子系统，我提炼出贯穿始终的 5 条设计原则。它们不仅适用于这个 CLI 工具，也可以应用到任何产品设计中。

1. 深度防御：不信任是默认状态

Claude Code 的每一个子系统都有多层防护。安全系统有 3 道安检门（AST 扫描 → 正则匹配 → ML 分类器），压缩系统有 5 层策略（Micro → Snip → Collapse → Session Memory → Auto Compact），API 调用有 10 次重试 + 模型降级。

产品启示：好的系统不是相信一切会顺利运行，而是假设一切都会出问题，然后为每种故障准备好降级路径。这在产品设计中对应的是：你的关键流程有多少 Plan B？用户在你产品中犯错后的恢复路径是否清晰？

2. 渐进式增强：从不一步到位

Claude Code 的压缩系统从最轻量级的 Micro Compact（每次删除几百 token 的旧工具结果）开始，只有不够用时才升级到 Snip Compact（切除中间段落），再不够用时才触发 Auto Compact（调用 LLM 全文摘要）。这种”先用低成本方案，不够再升级”的策略，贯穿了整个系统的每个角落。

产品启示：渐进式增强不只是技术策略，更是产品策略。你的产品功能是否也有从轻量到重量的分级？用户是否可以在不付出高成本的情况下获得基础价值？

3. 统一抽象：减少认知税负

Claude Code 把 50+ 个内置命令、用户自定义 skill、第三方插件、MCP 服务器暴露的能力，全部统一为一个 Command 接口。不管来源是哪里，调用方式、权限检查、生命周期通知都是一样的。这意味着用户不需要”内置命令怎么触发”和”插件命令怎么触发”两套心智模型。

产品启示：统一抽象降低了用户的认知负荷。你的产品中，不同来源的功能（原生功能 vs 第三方扩展 vs 用户自定义）是否有一致的交互路径？

4. 传输无关：为变化预留接口

Claude Code 的通信桥接系统同时维护了 v1（WebSocket + HTTP POST）和 v2（SSE + CCRClient）两套传输协议，但上层代码完全不需要关心底层用哪一套。这是因为它们定义了统一的 Transport 接口。当需要升级时，只需替换底层实现，不动上层逻辑。

产品启示：传输无关是一种面向未来的设计。你的产品中，核心功能是否依赖某个特定渠道或平台？如果明天要切换到新渠道，改造成本有多大？

5. 成本意识：每一分钱都计算

Claude Code 的 FileReadTool 有智能去重功能——如果同一个文件同样的范围之前读过且没被修改过，就只返回一个 “file_unchanged” 的标记，不重新发送内容。这个优化节省了 18% 的 API 缓存写入。Session Memory Compact 更极端——它直接用之前提取好的记忆文件做压缩，完全不调用 API，成本为零。

产品启示：成本意识不只是为了省钱，是为了在资源有限的情况下做更多的事。你的产品是否也在为”每一点资源的使用效率”负责？

10 个子系统的关系图

┌─────────────────────────────────────────────────────────────┐│                     用户输入 / 远程触发                       │└────────────────────────┬────────────────────────────────────┘                         │┌────────────────────────▼────────────────────────────────────┐│                  第 05 章：命令系统                          ││            统一接口，7 源聚合，动态发现                       │└────────────────────────┬────────────────────────────────────┘                         │┌────────────────────────▼────────────────────────────────────┐│              第 01 章：查询引擎与 Agent 循环                 ││                    queryLoop while(true)                     ││   上下文压缩 → 系统提示 → API调用 → 工具执行 → 附件注入 → 恢复  │└─────┬────────┬─────────────┬───────────────┬───────────────┘      │        │             │               │      ▼        ▼             ▼               ▼┌──────────┐ ┌──────────┐ ┌─────────────┐ ┌──────────────┐│ 第 02 章 │ │ 第 03 章  │ │  第 04 章   │ │  第 07 章    ││ 安全权限 │ │ 多Agent  │ │ 内存压缩    │ │ 通信桥接     ││ 信任边界 │ │ 协调分工 │ │ 遗忘智慧    │ │ 远程连接     │└──────────┘ └──────────┘ └─────────────┘ └──────────────┘      ▲        ▲             ▲               ▲      │        │             │               │┌─────┴────────┴─────────────┴───────────────┴──────────────┐│              第 09 章：服务层架构（底层基础设施）            ││           四端适配、重试机制、错误分类、MCP 集成             │└───────────────────────────────────────────────────────────┘支撑层：┌──────────────┐  ┌──────────────┐  ┌────────────────┐│ 第 06 章     │  │ 第 08 章     │  │ 通用技术模式    ││ 插件与技能   │  │ 状态管理     │  │ (代计数器、      ││ 可扩展性     │  │ 数据流       │  │  Forked Agent、  ││              │  │              │  │  FlushGate)     │└──────────────┘  └──────────────┘  └────────────────┘