一、Claude Code（下文简称CC）原理
主要涉及到CC的基本原理以及运作方式，详见：code.claude.com/docs/zh-CN/…
二、Claude Code扩展功能
介绍了我们经常听到的Skills、MCP、Hooks等基本概念以及使用方式，详见：code.claude.com/docs/zh-CN/…
三、Claude Code使用经验总结
1、注意claude code上下文窗口
CC 有一个上下文窗口（约 200K，如下图所示），就像一块白板，每条消息、命令输出、文件读取都会写入这块白板。白板快满时，CC 的性能就会显著下降，需要注意的是性能衰减是从 20-40% 使用率的时候就开始了，这也就是为什么对于复杂任务或者对话轮次比较长时，CC 效果比较差了。
graph LR
A[0%] -->|性能正常| B[20-40%]
B -->|开始衰减| C[50%]
C -->|显著下降| D[70%]
D -->|性能极差| E[100%]
style A fill:#90EE90
style B fill:#FFD700
style C fill:#FFA500
style D fill:#FF6347
style E fill:#FF0000,color:#fff
解决方案：
（1）使用clear命令定期清理一些不相关的历史
（2）使用子代理，因为子代理拥有独立上下文
（3）复杂任务拆解成多个小任务去执行
（4）避免导入或者粘贴不必要的大文件
2、善于使用多会话（即多个session）
例如在开发过程中，我们可以开多个窗口，一个窗口用于设计方案，一个窗口用于代码开发，一个窗口用于代码检视。因为在单个窗口干一件事情，就会导致该窗口的 CC 没法发现自身的问题，而多个窗口不共享上下文的情况下，能起到纠错或者监督的作用。
graph LR
A[Session 1<br/>设计方案<br/>独立上下文 A] -->|设计文档| B[Session 2<br/>代码开发<br/>独立上下文 B]
B -->|代码| C[Session 3<br/>代码检视<br/>独立上下文 C]
C -->|问题反馈| B
style A fill:#E3F2FD
style B fill:#E8F5E9
style C fill:#FFF3E0
3、合理使用CLAUDE.md
关于什么是 CLAUDE.md 的介绍，参考"二、Claude Code扩展功能"章节，至于如何合理使用，从开发的角度来说，我们可以把必要流程或动作添加到 CLAUDE.md 中，同时避免添加某些固定场景才需要用到的东西，这样可以避免使用 CC 过程中引入过长的上下文而导致性能下降
举个例子：在需求开发时，我会将静态代码校验放到 CLAUDE.md 中，这些属于所有代码开发的必要流程，不管是从代码健壮性还是后期维护角度，这样会使得写出来的代码比较干净。然后像性能校验这类，可以放到 Skills 中去，因为只有某些特定的需求才需要考虑性能。
| CLAUDE.md（每次启动加载） | Skills（按需手动调用） |
|---|---|
| 静态代码校验 | 性能校验 |
| 代码规范要求 | 某些场景功能校验 |
| 通用开发流程 | 特定框架/工具链 |
| 特点：全局生效，内容过多会影响性能 | 特点：按需调用，不占用默认上下文 |
4、选择做信息的提供者而不是发号施令者
一般涉及到大型需求（项目）开发时，并不是所有人对整个需求流程以及细节都很清楚，往往是各自负责各自的一亩三分地，而对其他模块以及端到端的流程并不是很熟悉。尽管 CC 可以辅助完成需求，但是这里有个关键点：要如何告诉 CC 去完成？一般情况下大家会直接告诉 CC 要实现 xxx，然后将自己了解的局部信息作为实现细节告知 CC，这时候 CC 实现出来的代码可能会有很多问题，相当于在这个需求背景下，你把 CC 拉低到跟你一样的认知水平上而没法发挥出模型本身的能力。
这时候可以换种方式，直接将结果告诉 CC，然后让它反问你如果要实现这个需求，需要你给它提供哪些信息，这时候它往往会提出一些你的信息盲点。这时候我们再去收集这些信息，在收集的过程中也能加深自己对业务本身的了解，从而高质量地落地这个需求。
graph TB
subgraph bad[发号施令 - 效果差]
U1[用户] -->|局部信息| CC1[CC]
CC1 --> R1[输出质量差]
end
subgraph good[信息提供 - 效果好]
U2[用户] -->|告诉目标| CC2[CC]
CC2 -.->|反问| U2
U2 ==>|完整信息| CC2
CC2 --> R2[高质量输出]
end
style bad fill:#FFEBEE
style good fill:#E8F5E9
5、善于使用命令
个人来看，但凡在开发过程中，使用次数超过三次以上的相同提示词，都应该用命令来表述，例如"执行环境变量，然后执行 build.sh 编译源码"。例如下面是我编码时常用的命令：
/compile # 编译
/run-ut # ut
6、不要给 CC 纠错
当然这里有个前提，在非 Plan Mode 下不要给 CC 纠错，否则你就会收到"您说的对"，然后 CC 疯狂降智，给你输出一堆屎山代码。一般情况下，针对简单需求，如果 CC 错了，直接把避免再次出错的提示词加到原始提示词后面重新来过，如此反复即可。针对复杂需求，你可以使用 Plan Mode，这里你可以跟 CC 极限拉扯，最终敲定一份终极 plan，让其一次性完成，同时需要考虑 context 是否足够，如果不够，拆解需求，分步完成。
graph TB
subgraph simple[简单需求 - 非 Plan Mode]
S1[提出需求] --> S2[CC 执行]
S2 --> S3{出错了?}
S3 -->|否| S4[完成]
S3 -->|是| S5[加上避免出错的提示词]
S5 --> S2
end
subgraph complex[复杂需求 - Plan Mode]
C1[进入 Plan Mode] --> C2[提出需求]
C2 --> C3[讨论方案]
C3 --> C4[方案敲定]
C4 --> C5{context 足够?}
C5 -->|是| C6[一次性完成]
C5 -->|否| C7[拆解分步完成]
end
style simple fill:#E3F2FD
style complex fill:#FFF3E0
