从产品经理视角看ClaudeCode源码

Claude Code 51万行源码泄露后，技术圈都在拆架构、看代码。但对产品经理来说，这份源码里藏着的不是技术细节——是一整套"如何让用户信任 AI 去做真实工作"的产品方法论。

一、Prompt 不是文案，是产品规则引擎

大多数 PM 理解的 prompt = "写一段好的提示词"。Claude Code 的做法完全不同：

• 7 层动态拼装：静态宪法（行为准则）+ 动态政策（环境/记忆/会话状态）
• 每个工具配独立使用手册（prompt.ts），不是一段通用说明
• 缓存边界精确划分：静态部分走缓存省钱，动态部分按需注入

PM 启发：如果你在做 AI 产品，prompt 管理应该当做配置系统来设计，而不是放在一个文本框里。需要版本管理、A/B 测试、分层架构。Anthropic 内部版（ant 分支）和外部版有不同指令集——这就是 prompt 的灰度发布。

二、信任体系设计 > 功能堆叠

Claude Code 最大的工程量不在 AI 调用，而在信任体系：

• 51 万行代码，真正调 LLM API 的不到 5%
• 一个 Bash 命令要过9 层审查（AST 解析、ML 分类器、权限决策、Hook 前后置...）
• 工具默认fail-closed：忘了声明安全属性 → 系统假设最坏情况

PM 启发：AI 产品的核心竞争力不是"模型多聪明"，而是**"用户敢不敢把真实工作交给它"**。Claude Code 让你直接在自己电脑上跑，Cursor 要你每步确认，Copilot Agent 给你一台虚拟机隔离。三种安全哲学，对应三种用户信任程度。

做 AI 产品的第一个问题不是"能做什么"，而是**"用户在什么条件下愿意让它做"**。

三、角色分离：做事的人和验收的人必须分开

Claude Code 有 6 个内建 Agent，最值钱的设计是Verification Agent：

• 它的方向不是"确认没问题"，而是try to break it
• 强制要求跑 build、测试、linter，做 adversarial probes
• 和实现者没有利益关联——写代码的 Agent 天然觉得自己写得对

PM 启发：如果你的产品里有"AI 生成 → AI 检查"的环节，千万不要让同一个 Agent 自己生成自己检查。这在传统软件工程里是常识（开发不能自测），但大部分 AI 产品还没做到。

即使用同一个模型，把职责拆开（不同 system prompt、不同工具权限）也会有显著改善。

四、"不要信任模型的自觉性"——行为规范要写成制度

Claude Code 的 getSimpleDoingTasksSection() 列了极其具体的行为规范：

不要加用户没要求的功能。不要过度抽象。不要瞎重构。先读代码再改代码。不能假装自己测试过了。

PM 启发：你希望 AI 有什么行为，就必须明确写出来。不要指望模型"应该知道"。这和管理团队一样——OKR 写得越具体，执行偏差越小。

常见的 AI 产品问题：

• 你让它改一个 bug，它顺手重构了半个文件 → 没写"不要加用户没要求的功能"
• 你让它测一下，它说"测试通过了"但根本没跑 → 没写"不能假装自己测试过了"

这些问题的根源不是模型笨，是产品规则没有覆盖到。

五、上下文是预算，不是免费空间

Claude Code 围绕"上下文经济学"做了大量设计：

• 三层压缩：微压缩（清旧工具结果）→ 自动压缩（87%阈值）→ 完全压缩（AI摘要替换历史）
• 按需注入：Skill 不是一开始全塞进去，MCP 指令只在连接时注入
• 缓存复用：子 Agent fork 时保持字节级前缀一致，复用主线程缓存

PM 启发：做 AI 产品时，每一条注入给模型的信息都有成本——占上下文空间、影响缓存命中率、增加 token 费用。

产品设计中需要回答：

• 哪些信息必须常驻？哪些按需加载？
• 对话太长怎么办？哪些可以压缩、哪些必须保留？
• 能不能让缓存多命中 10%？（对应直接的运营成本下降）

做 Demo 可以不管这些，做产品必须管。

六、生态的关键不是"有插件"，而是"模型知道有插件"

Claude Code 有 Skill、Plugin、MCP 三套扩展机制，共同点是：

它们不只是"挂载到系统上"，而是通过 skills 列表、agent 列表、MCP instructions 等通道，让模型感知到自己当前有哪些扩展能力、什么时候该用、怎么用。

PM 启发：很多平台也有插件市场，但模型不知道这些东西存在。这就像给员工发了工具箱但没告诉他箱子里有什么。

如果你在做 AI 平台产品，扩展机制的最后一步必须是：让模型看到自己的能力清单。否则插件装了 10 个，模型一个都不会主动调用。

七、KAIROS：从被动响应到主动服务的产品范式转变

源码中最科幻的发现是 KAIROS 守护进程模式：

• Always-on 后台运行：不等用户提问，主动监控和执行
• autoDream 记忆整理：用户不活跃时自动整合记忆、消除矛盾、提炼洞察
• GitHub webhook 订阅：监听外部事件，主动触发行动

PM 启发：当前 AI 产品 99% 是"用户问 → AI 答"的被动模式。KAIROS 代表的方向是：AI 作为一个持续运行的助手，像人类同事一样主动跟进工作。

这不是一个技术问题，是一个产品定义问题：你的 AI 产品是一个"工具"（用完即走），还是一个"同事"（持续在线）？这两种定位对应完全不同的产品架构、计费模式和用户预期管理。

总结

Claude Code 的秘密不在 prompt 里，在于它用工程系统解决了"如何让用户信任 AI 去做真实工作"这个产品问题。

做 AI 产品，模型能力是地基，但地基之上的信任体系、行为治理、角色分工、上下文经济学、生态感知——这些才是决定产品"手感"的东西。

八、一些产品面试题设想

以下问题围绕 Claude Code 源码揭示的产品设计理念展开，适用于 AI 产品经理/AI 产品策略岗位的面试准备。