用了半年 Claude Code，踩了不少坑，也摸索出一套比较稳定的使用方法。今天把这些经验整理出来，从 Plan Mode 到 CLAUDE.md，从上下文管理到提示词技巧，都是实战中验证过的东西。
先想清楚，再动手
大多数人打开 Claude Code 的第一反应是开始打字。这恰恰是最大的错误。
用 Plan Mode 的产出质量，10 次里有 10 次都比直接开聊要好，差距非常明显。
很多人觉得 AI 编程就是把需求丢进去等结果，但实际上你给的输入越模糊，输出就越离谱。"帮我搞个登录系统"和"用现有的 User Model 做邮箱密码登录，session 存 Redis，24 小时过期，给 /api/protected 下的路由加中间件"——这两句话得到的结果天差地别。
Plan Mode 的操作很简单：按两次 Shift+Tab 就进去了。花 5 分钟想清楚架构，能省后面几个小时的 debug 时间。
哪怕是一个很小的功能，也值得先在脑子里过一遍：这个东西应该放在哪一层？跟现有代码怎么衔接？有没有边界情况要处理？想清楚这些再动手，效率完全不一样。
CLAUDE.md 是你最大的杠杆
CLAUDE.md 这个文件，很多人要么完全忽略，要么往里面塞一堆没用的东西。
它的本质是什么？每次你开一个 Claude Code 会话，Claude 做的第一件事就是读这个文件。里面的每一条指令都会影响它后续的所有行为。相当于你给 Claude 的"入职培训材料"。
几个关键原则：
保持精简。Claude 一次能可靠执行的指令大概在 150-200 条，而 Claude Code 的系统提示词已经占了大约 50 条。你加的每一条指令都在跟其他指令抢注意力。如果你的 CLAUDE.md 写成了一本小说，Claude 就会随机忽略一些内容，而你根本不知道它忽略了哪些。
写项目特有的东西。不要解释什么是 components 文件夹——Claude 知道。告诉它那些"奇怪的"东西，比如你项目里特殊的 bash 命令、非标准的目录结构、团队约定的命名规范。
告诉它为什么，而不只是告诉它做什么。"用 TypeScript 严格模式"还行，"用 TypeScript 严格模式，因为我们之前因为隐式 any 类型出过生产事故"更好。给了原因之后，Claude 在遇到你没预料到的情况时，也能做出更合理的判断。
持续更新。工作的时候按 # 键，Claude 会自动往 CLAUDE.md 里加指令。每次你发现自己在纠正 Claude 同一个问题两次，那就是一个信号——这条规则应该写进文件里。
差的 CLAUDE.md 像是给新员工写的入职文档，好的 CLAUDE.md 像是你知道自己明天会失忆时给自己留的笔记。
上下文窗口没你想的那么大
Opus 4.5 有 20 万 token 的上下文窗口，但真相是：远在你用满之前，模型质量就已经开始下降了。
实际体验下来，大概在 20-40% 的上下文使用量时，输出质量就开始打折扣了。如果你用过 Claude Code 的 /compact 功能，然后发现压缩完输出还是很差——原因就在这里。模型在压缩之前就已经退化了，压缩并不能神奇地恢复质量。
这个认知很重要，因为它直接影响你的工作方式：
一个对话只做一件事。不要在同一个对话里又搞认证系统又重构数据库。上下文会互相污染，Claude 会越来越糊涂。
用外部记忆。做复杂项目的时候，让 Claude 把计划和进度写到实际文件里（比如 SCRATCHPAD.md 或 plan.md）。这些文件跨会话持久存在。第二天回来的时候，Claude 读一下文件就能接上，不用从零开始。
复制粘贴大法。当上下文膨胀的时候，把终端里重要的内容复制出来，跑一下 /compact 拿到摘要，然后 /clear 清空整个上下文，再把关键信息粘贴回去。全新的上下文加上保留的关键信息，比让 Claude 在退化的上下文里挣扎好太多了。
基本上一个功能一个对话，做完就清。宁可多开几个对话，也不要让一个对话变成垃圾场。
提示词就是一切
很多人花几周时间学框架、学工具，但花在"怎么跟 AI 说话"上的时间是零。
这其实是最值得投入的技能。提示词不是什么玄学，它就是沟通。跟人说话一样，说得越清楚，对方理解得越准确。
几个实用的原则：
具体。"搞个认证系统"不如"用现有的 User Model 做邮箱密码认证，session 存 Redis，给 /api/protected 下的路由加中间件"。
告诉它不要做什么。Claude 有一些倾向性，特别是 Claude 4.5 喜欢过度工程化——多余的文件、不必要的抽象、你没要求的灵活性。如果你想要简单的东西，直接说"保持简单，不要加我没要求的抽象，能一个文件搞定就一个文件"。
给上下文。"这个需要快，因为每个请求都会跑一遍"和"这是个原型，用完就扔"——这两句话会让 Claude 做出完全不同的权衡。你脑子里的约束条件，不说出来 Claude 是猜不到的。
输出烂？先看看你的输入
如果你用 Opus 4.5 这种级别的模型还是得到很差的结果，问题大概率不在模型，在你。
模型质量在今天已经是基本盘了，瓶颈几乎总是在人这边：你怎么组织提示词、怎么提供上下文、怎么清晰地表达你到底想要什么。
不过模型之间确实有差异：
Sonnet 更快更便宜，适合路径清晰的执行类任务——写样板代码、按计划重构、实现你已经想好架构的功能。
Opus 更慢更贵，但在复杂推理、规划、需要深度权衡的任务上更强。
一个好用的工作流：用 Opus 做规划和架构决策，然后切到 Sonnet（在 Claude Code 里按 Shift+Tab）做实现。CLAUDE.md 确保两个模型在同样的约束下工作，所以切换是无缝的。
MCP、Hooks 和各种配置
Claude Code 的功能生态已经很丰富了：MCP 服务器、Hooks、自定义斜杠命令、Skills、插件……
不需要全部用上，但应该去试。不试的话，你可能在浪费时间或者金钱。
MCP（Model Context Protocol）让 Claude 连接外部服务——Slack、GitHub、数据库、各种 API。如果你发现自己经常从某个地方复制信息粘贴到 Claude 里，大概率有一个 MCP 服务器能自动化这个过程。
Hooks 让你在 Claude 修改代码前后自动运行脚本。想让 Prettier 在 Claude 每次改文件后自动跑一遍？Hook。想在每次编辑后做类型检查？Hook。这能在问题堆积之前就抓住它们。
自定义斜杠命令就是你经常用的提示词打包成命令。在 .claude/commands 文件夹里加 markdown 文件，然后就能用 /commandname 来调用。如果你经常做同一类任务——调试、代码审查、部署——做成命令就对了。
Claude 卡住了怎么办
有时候 Claude 会陷入循环：试同一个方案，失败，再试，再失败。或者它信心满满地实现了一个完全错误的东西，你花 20 分钟解释为什么不对。
这时候大多数人的本能是继续推——更多指令、更多纠正、更多上下文。但更好的做法是直接换个思路。
清空对话。累积的上下文可能在干扰它。/clear 给你一个全新的开始。
简化任务。如果 Claude 搞不定一个复杂任务，拆成小块。不过说实话，如果 Claude 搞不定复杂任务，大概率是 Plan Mode 不够充分。
展示而不是描述。如果 Claude 一直误解你的意思，自己写一个最小的例子。"输出应该长这样，现在把这个模式应用到其他地方。"Claude 非常擅长理解成功的样例。
换个角度。有时候你描述问题的方式跟 Claude 的思维方式不匹配。换个说法——"把这个实现成状态机"和"处理这些状态转换"——可能就通了。
核心的元技能是：尽早识别你是不是在循环。如果你解释了三遍 Claude 还是不理解，继续解释不会有帮助。换个方向。
把 Claude 变成系统的一部分
从 Claude Code 获得最大价值的人，不是把它当一次性工具用的，而是把它变成系统的一个组件。
Claude Code 有一个 -p 参数可以进入 headless 模式——跑你的提示词然后输出结果，不进入交互界面。这意味着你可以把它脚本化，把输出管道到其他工具，跟 bash 命令串联，集成到自动化工作流里。
已经有团队在用这个做自动 PR 审查、自动客服工单回复、自动日志和文档更新。全部有日志、可审计，而且随着时间推移基于效果不断改进。
飞轮效应：Claude 犯了错，你审查日志，改进 CLAUDE.md 或工具配置，下次 Claude 就做得更好。甚至可以让 Claude 自己改进自己的 CLAUDE.md 文件。经过几个月的迭代，这样构建的系统比刚上线时好了很多——同样的模型，只是配置更好了。
如果你只是交互式地用 Claude，你在浪费它的潜力。想想你的工作流里，哪些环节 Claude 可以在你不盯着的时候自己跑。
总结
- 先想后写，Plan Mode 不是摆设
- CLAUDE.md 是你最大的杠杆，写给失忆的自己而不是新员工
- 上下文在 20-40% 就开始退化，一个对话只做一件事
- 提示词是最值得投入的技能，具体、有约束、给上下文
- 输出不好先反思输入，Opus 做规划 Sonnet 做执行
- 用 MCP、Hooks、自定义命令扩展能力边界
- Claude 卡住了就换方向，不要死磕
- 把 Claude 变成系统组件，让飞轮转起来
参考链接
- Claude Code 官方文档：docs.anthropic.com/en/docs/cla…
- Anthropic MCP 协议：modelcontextprotocol.io
