我的 Claude Code 使用沉淀

TL;DR

大多数人把 AI 编程工具当”高级自动补全”用。这是一个局部最优解。

全局最优解是：让每次使用都让下次更高效 —— 即复合工程（Compounding Engineering）。

问题：为什么你的 AI 编程效率没有随时间提升？

一个反直觉的现象：大部分开发者用了半年 AI 编程工具，效率曲线是平的。

第一天：问 AI 写个函数，省了 10 分钟。 第一百天：问 AI 写个函数，还是省 10 分钟。

边际成本恒定。没有复利。

原因很简单 —— 知识留在了人脑里，没有沉淀到系统中。

你踩过的坑、摸索出的 prompt 技巧、对项目上下文的理解，全部存在你的工作记忆里。换个会话窗口，一切归零。这跟一个没有持久化层的应用没有区别 —— 每次重启都是冷启动。

第一性原理：AI 编程是一个系统工程问题

把”如何高效使用 AI 编程工具”建模为一个优化问题。核心变量：

1. 上下文质量 C —— AI 拿到的信息是否完整、准确、高信噪比
2. 任务粒度 G —— 单次任务的范围是否足够聚焦
3. 知识复用率 R —— 历史经验能否自动加载到当前任务

传统用法：C 靠人肉输入、G 随意、R ≈ 0。

结论：效率上限被锁死。

要突破上限，三个变量都得从架构层面解决。

变量一：上下文工程 —— 信息的分层供给

上下文窗口是稀缺资源。往里面塞太多无关信息，等价于给数据库发了一条没有 WHERE 子句的全表扫描 —— 返回结果多但没用，还拖慢响应。

我的方案是分层按需加载：

项目根目录/
├── CLAUDE.md              # 项目记忆（每次自动加载，< 200 行）
├── context/
│   ├── business/          # 业务知识（开始新功能时加载）
│   ├── tech/              # 技术架构（做架构决策时加载）
│   └── experience/        # 经验沉淀（遇到问题时加载）
│       └── index.md       # 经验索引

设计原则：

• CLAUDE.md 是 L1 缓存：高频、体积小、每次必加载。放项目级约束、常见错误、关键配置。严格控制在 200 行以内 —— 超了就是缓存污染。
• context/ 是 L2 缓存：低频、体积大、按需加载。业务知识、架构决策、历史经验各自隔离，避免交叉污染。
• 加载策略明确：开始新功能 → 读 business/；遇到技术问题 → 查 experience/index.md；做架构决策 → 读 tech/。不靠人记，靠规则驱动。

这个设计的本质是：把上下文管理从”人脑 ad-hoc”升级为”系统化供给”。

信噪比上去了，AI 的决策质量自然跟着上去。

变量二：任务粒度 —— 窄范围、强约束

一个被反复验证的经验：给 AI 的任务越窄越聚焦，输出质量越高。

这不是 AI 的问题，是信息论的基本约束。任务范围越大，解空间越大，AI 越容易在解空间里随机游走。缩小范围等价于增加约束条件，约束越多，解越唯一。

实操层面：

• 不要说”帮我实现用户系统”。要说”在 UserService 中添加 validateToken 方法，输入 JWT string，输出 UserClaims，异常抛 AuthException”。
• 一次只改一个关注点。改了逻辑就先不动样式，改了样式就先不动结构。
• 每次修改完跑一次构建验证。不要攒一堆改动再验证 —— 那是在给自己制造 debug 地狱。

配合 Claude Code 的计划模式（Plan Mode），先让 AI 出方案，审批后再执行。这不是多此一举 —— 这是在任务开始前就约束解空间。

变量三：知识复用 —— 从线性到复利

这是最关键的变量，也是大多数人完全忽略的。

复利的前提是：每次执行产生的知识被持久化，并在下次执行时自动复用。

具体实现路径：

第一层：经验沉淀

遇到以下情况，主动记录到 context/experience/：

1. 调试超过 10 分钟才解决的问题
2. 发现文档中未记录的隐藏坑点
3. 找到了更优的实现方式
4. 第三方库的非直觉行为

格式固定，方便检索：

## [问题名称]
- **触发条件**: 什么情况下会遇到
- **解决方案**: 如何解决
- **相关代码**: `文件路径:行号`
- **日期**: 2026-02-13

第二层：流程固化

重复出现的操作模式，封装为 Skill 或自定义命令。

例子：我的提交流程封装为 /commit —— 自动分析改动、生成语义化提交信息、一键提交推送。不再需要每次手动写 commit message。

第三层：工作流编排

复杂任务拆解为多 Agent 协作。主 Agent 负责意图识别和任务分发，子 Agent 各自处理独立子任务，避免单一上下文窗口被撑爆。

三层叠加的效果：

传统模式是 O(n)。复合工程是 O(log n)，趋近 O(1)。

我的具体配置

全局规范：CLAUDE.md

48 行。没有多余的废话。核心内容：

• 语言偏好（中文回答、英文调研）
• 编码原则（类型安全、简洁优先、禁止 print 调试）
• 经验沉淀触发条件和格式
• 上下文目录结构约定
• 提交规范

官方建议 200 行以内。我认为 越短越好 —— 这是每次对话都要加载的内容，每多一行都是对注意力的消耗。

插件策略：10 个以内，按需迭代

一个重要的认知：别人的插件不一定适合你。

开源插件生态有大量可选项，但盲目安装违反最小化原则。我的策略：

1. 根据当前技术栈，选择 10 个以内的插件先用着
2. 使用过程中观察哪些真正被高频调用
3. 淘汰低频插件，保留高价值插件
4. 需要新能力时，先问 AI 出方案，再自己配置

本质是 演进式架构，不是一次性设计。工具链应该从实际需求中生长出来，而不是从别人的最佳实践中抄过来。

工作流程

接手项目时：

1. yolo 启动全权限模式
2. 检查项目 CLAUDE.md，没有则 /init
3. 检查 context/ 目录，没有则用自定义命令生成
4. 结合 AI 快速了解项目全貌

开发中：

1. 计划模式出方案 → 审批 → 执行
2. 每次修改后跑构建验证
3. 持续更新 CLAUDE.md 和 context/
4. 小错误沉淀到项目记忆；大方向问题放到 context 目录

功能完成后：

1. 重新 /init，更新项目记忆文件
2. 检查是否有可封装为 Skill 的重复模式
3. 清理过时的 context 内容

一个元认知

写这篇文章的过程本身就在验证上面的方法论。

我没有从零开始写 2000 字。我把过去半年使用 Claude Code 的经验、踩过的坑、摸索出的模式，结构化地沉淀在了 context 目录和 CLAUDE.md 里。写这篇文章时，这些沉淀直接变成了素材。

如果我没有做这些沉淀，这篇文章的写作成本至少是现在的 3 倍 —— 我需要重新回忆、重新整理、重新验证。

这就是复利。

结论

Claude Code（或任何 AI 编程工具）的正确使用姿势不是”怎么写 prompt”，而是”怎么建系统”。

三条原则：

1. 上下文分层供给，不要把所有信息塞进一个窗口
2. 任务范围收窄，约束越多输出越精准
3. 知识持久化复用，每次使用都让下次更容易

做到这三点，效率曲线从平的变成指数的。

做不到，你就是在用 2026 年的工具做 2024 年的事 —— 工具升级了，方法论没有。

工具是线性的。系统是复利的。选系统。