说明：本文来自 https://mp.weixin.qq.com/s/NQKL7-cWeAxdQH94TO-1gA

Claude Code 的源码被人扒出来了， 1884 个文件， 33MB。
泄露的原因很可能是因为一个bun的bug导致的。

也有人说是A社大版本更新前的故意为之， 因为此前Claude Code也被泄露过一次， 而且仅逆向也能够出不多东西。
但不管怎么样， Claude Code的源码就这么真真切切的摆在面前了。
除了之前总结的 Claude Code 源码泄漏后， 我们看见了什么？ Claude Code未发布 的新功能和未来的全景图， 本次泄露源码最大的意义可以就是重新认识Claude Code。 因为在这之前， 所有的对于Claude Code的理解或者用法都只是建立在官方只言片语的 说明文档和猜想上。
现在有了源码作为依据， Claude Code的运行机制一览无余， 而我写代码的方式， 有几 个地方确实该改了。

Prompt 的写法

源码里面每一次对话， 内部被拆成了严格的层级：
系统提示、 用户上下文、 工具结果、 历史记录。
源码里有个写给 Anthropic 工程师自己看的注释：
DO NOT ADD MORE STATE HERE - BE JUDICIOUS WITH GLOBAL STATE。
意思是全局状态一旦乱了， 整个对话上下文就会崩。
比如同样是让 Claude 添加一个 formatRelativeTime 函数：
模糊写法*：
“帮我加个时间格式化函数”* 结构化写法：
“为 src/utils/date.ts 添加 formatRelativeTime 函数， 输入 Date， 输出’刚刚’‘3 分钟前’'2小时前’等， 超过7天返回 YYYY-MM-DD 格式， 验证： 1. 跑单元测试 2. 边界 测试0秒和8天”
后者 Claude 一次成， 前者来回改了三轮， 结构越清晰， AI 犯傻幻觉的概率就越低， Claude Code流畅的编码需要坚实的骨架来打底。
另外， 在源码中， 我们可以看清晰的看到Anthropic 把提示词用法。
它在每个工具目录下都有一个专门的 prompt.ts 文件， 这个文件就是写给 LLM 看的使 用手册， 每次 Claude Code 启动， 这些规则都会被注入到系统提示词里。 所以还是那句话， 代码量少了， 你的文档量就应该上来， 为每一个模块、 每一个方法、 每个业务线都写上详细的结构化文档注解。

AI工具本质是状态机

源码里的Agent循环就四步：
用户输入、 调用工具、 结果回填、 继续循环。

这个设计说明整个系统天然是分步推进的逻辑， 不是一键到位， 其实就和之前很多人的 最佳实践不谋而合。

比如Puzzmo游戏公司的工程师 Orta 就是先让 Claude 生成代码全景， 跑通之后再逐 步精雕细琢， 而不是一开始就要求完美输出。

Claude Code 的作者Boris Cherny了印证了源码的实现， 分享过他的日常流程， 先让 Claude 在 Plan Mode 下只读地探索代码库、 生成计划， 再用第二个 Claude 会话审
计这个计划是否合理， 确认后才开始编码。 Claude Code之父分享的技巧有几点实在 不敢苟同！

两个会话， 两个阶段， 分得很清楚， 每一步都要有明确的完成判断， 再推进到下一步。

上下文管理

源码里有整整四套并行的上下文压缩策略：
microcompact、 autocompact、 context collapse、 history snip。
四套上下文的方式并存说明Anthropic 自己也没找到一个放之四海皆准的答案， 几乎是 现在AI模型以及AI编程遇到的最大的一个麻烦。
上下文一旦爆满， AI的幻觉指数就直线上升， 源码里面的4个方案其实各有所长， 但真正 实践下来， 拿到具体的编码当中， 可能我们能做的也就以下几点：
聊得太长就果断开新窗口， 把确认好的架构决策、 技术选型写成 CLAUDE.md， 每次自 动喂给它， 而不是靠它自己记。 最近几天的龙虾饲养心得和写的配套小工具
/clear 命令建议多用， 不要太依赖于自动压缩， 因为它会丢失非常多的细节。

为了节省Token， 我的另一个做法是在 CLAUDE.md 里专门有一栏禁止事项， 比如"不要修改 alembic/versions/ 里的迁移文件"“不要直接操作数据库， 必须通过 service层”。

把约束写死在上下文里， 比每次口头叮嘱省心省Token得多。

4. 优雅降级

Claude Code 的源码里有一个优雅降级函数。

它做的事情是当用户中断操作时， 为所有还没跑完的工具调用生成一个错误结果， 而不 是让整个消息链断掉， 会话得以完整继续， Claude 知道哪里出了问题， 从那里接着干。 这个设计背后有一个明确的原则： 出错了， 保住已有的结构， 不是推倒重来， 而是定位 最小的断点， 只修那一处。

很多人在用 Claude 遇到 bug 时的第一反应是把整段代码扔进去， 让它重写。
Claude 也会照做， 给你一个全新的版本。 表面上干净了， 但你不知道改了哪里， 为什么 改， 原来的结构里哪些判断是有意为之的， 下一个 bug 出现时， 你还是一无所知， 只能 再扔一次。
专业工程师在架构决策、 关键节点审查、 边界情况处理这些地方保留人工判断， 把 Claude 当成一个执行层， 而不是一个决策层， 出了问题， 先定位， 再告诉 Claude 具体修哪里， 修成什么样。

Claude Code 自己的容错机制就是这么设计的， 它在崩溃边缘没有选择重启， 而是选择 找到断点、 保住上下文、 最小化修复。

用Claude Code写代码的方式， 和它处理自身错误的方式， 应该是一样的。

5. 记忆

很多人以为 Claude Code 的记忆就是 CLAUDE.md， 写进去就行了。
实际上源码里的记忆发现逻辑是这样的， Claude Code 启动时， 从你当前的工作目录开 始， 一路向上递归搜索， 直到系统根目录， 沿途收集所有 CLAUDE.md 文件：

/etc/claude-code/CLAUDE.md          # 系统级，管理员配置
~/.claude/CLAUDE.md                 # 用户级，个人全局偏好
~/.claude/rules/*.md                # 用户级规则模块
./CLAUDE.md                         # 项目级，团队共享
./.claude/rules/*.md                # 项目级规则模块
./CLAUDE.local.md                   # 本地私有覆盖，加进 .gitignore

越靠近当前工作目录的文件， 加载越晚， 在 LLM 的上下文窗口里位置越靠后， 而 LLM 对越靠后的内容注意力权重越高。

这是整个记忆系统里最值得理解的一个分工。

CLAUDE.md 是你写给 Claude 的项目架构、 技术栈、 编码规范、 禁止事项。 这些是不变的规则， 需要你主动维护。

Auto Memory 是 Claude 自己写给自己的， 你改了它的输出它记下来， 你反复强调一 个习惯它记下来， 你踩了一个坑它把解决方案记下来， 下次打开新会话， 这些经验自动 加载。

CLAUDE.md 是你写规则， Auto Memory 是 Claude 记经验。

Auto Memory 有一个 200 行限制， 每次会话启动时只加载 MEMORY.md 的前 200 行。

超出的内容被拆到主题文件里， 按需读取。

所以前200 行放最重要的索引和摘要， 详细内容放到语义化的主题文件里。

源码里还有一个叫 KAIROS 的特性标志， 目前还没有正式发布， 但代码已经在那里了。
在 KAIROS 模式下， 长会话中的记忆不是存在结构化文件里， 而是存在按日期的追加式 日志中， 有点类似于龙虾的文本记忆模式： l
ogs/2026/03/2026-03-30.md
我们其实也可以仿照这种模式， 对当天的或者是每周的， 都进行一个阶段性的总结， 把 这些以文本的形式加入到编程的记忆当中。
CLAUDE.md 的前 200 行是黄金区域。 超过这个范围指令遵从度会下降。

把最核心的约束放前面， 细节拆到 .claude/rules/ 的子文件里， CLAUDE.md 只留核心 指令和索引。

用"禁止事项"而不只是"建议"。

正面的建议 Claude 有时会忘， 明确的禁止边界更稳。 "不要直接操作数据库， 必须通过 service 层 “” 不 要 修 改 alembic/versions/ 里 的 迁 移 文 件 " ， 这 类 写 法 比 " 建 议 使 用 service 层"有效得多。

最后， Anthropic 内部有个数字被透露出来： 他们工程师写的 Claude Code 代码， 90% 是由 Claude Code 自己完成的。

但这不是说人变得不重要了。 恰恰相反， 人的角色从写代码变成了思考代码， 从执行者变成了决策者。

Claude Code 是一个需要你提供结构、 边界和上下文的超级执行者， 它不是魔法， 是一 台设计精良的机器， 你的输入质量决定了它的输出质量。

源码已经告诉你它怎么工作了， 接下来就看你怎么用了。