用好 Claude Code 的七条核心法则
用好 Claude Code 的七条核心法则
如果你把 Claude Code 当成一个"更聪明的代码补全工具"，你可能只发挥了它不到三成的能力。它更像一个能独立探索、规划、执行的工程助手——但要让它真正高效运作，需要掌握一些反直觉的工作方式。
一、上下文窗口是你最宝贵的资源
在所有技巧之前，先理解一个底层约束：Claude 的上下文窗口是有限的，而且一旦填满，性能会显著下降。
每一次对话、每一个读取的文件、每一行命令输出，都在消耗上下文空间。一个拖了很久的 debug 会话可能轻松吃掉数万 token。上下文越满，Claude 越容易"忘记"前面的指令、犯更多错误。
实践建议：
• 不相关的任务之间，主动运行
/clear重置上下文• 探索陌生代码库时，用 subagents（子代理）来替你读文件——它们在独立的上下文窗口里运行，不会污染你的主对话
• 长对话积累了太多失败尝试时，果断清空重来
二、先给 Claude 一个验证自己的方法
这是单一最高价值的习惯：在交任务之前，告诉 Claude 怎么验证结果是否正确。
没有验证标准，Claude 可能交出一个"看起来能跑"但暗藏边界问题的实现，而你是唯一的反馈回路，每个错误都需要你亲自审查。
反过来，当你提供测试用例、截图对比、或者一条检查命令，Claude 可以自我校验、自我修正，大幅减少你的介入。
示例对比：
弱提示 | 强提示 |
|---|---|
"实现一个邮箱格式校验函数" | "写一个 validateEmail 函数，测试用例：user@example.com[1]返回 true，invalid 返回 false，user@.com 返回 false。实现后运行测试。" |
"修复登录 bug" | "用户在会话超时后登录失败。检查 src/auth/ 里的 token 刷新逻辑，先写一个能复现问题的测试，再修复，别只是屏蔽报错。" |
三、先探索、再规划、再动手
直接让 Claude 写代码，它可能花力气解决了一个错误的问题。更好的流程是：
1.探索阶段（开启 Plan Mode）：让 Claude 读代码、梳理现状，不做任何修改
2.规划阶段：让 Claude 列出具体的实施计划——哪些文件要改、流程是什么
3.实施阶段：切回正常模式，按计划执行，边写边验证
4.提交阶段：让 Claude 写好 commit message 并开 PR
当然，不是所有任务都需要这个流程。改个变量名、加一行日志——直接做。规划最有价值的场合是：你对方案不确定、改动涉及多个文件、或者你不熟悉这段代码。
四、写一份精准的 CLAUDE.md
CLAUDE.md 是每次对话开始时 Claude 都会读取的配置文件。它能让你的工程习惯、项目约定、以及环境特殊性持久化到每次会话。
关键原则：短而精，不要长篇大论。
一个过长的 CLAUDE.md 会让 Claude 把重要规则淹没在噪音里。每一条规则问自己："删掉这条，Claude 会犯错吗？"如果不会，就删。
适合写进去的：
• 项目特有的 Bash 命令
• 与默认值不同的代码风格规则
• 测试偏好、分支命名规范
• 容易踩的坑和非直觉的行为
不适合写的：• Claude 看代码就能自己推断的东西
• 通用语言惯例
• 频繁变化的信息
五、提示词要具体，但不是"越多越好"
明确不等于冗长。提示词要精准定位：告诉 Claude 看哪个文件、遵循哪个现有模式、输出是什么形态。
几个有效技巧：
• 用
@文件名直接引用文件，比描述文件位置更高效• 直接粘贴截图或错误信息，而不是用文字转述
• 指向一个现有的好例子，让 Claude 参考模式来实现新功能
• 模糊提示（比如"这个文件你觉得哪里可以改进？"）有时是有价值的——它能帮你发现你没想到的问题
六、管理好你的会话节奏
Claude 不是无限制的流式问答机器，会话的质量会随时间退化。几个关键习惯：
•尽早纠偏：发现方向不对，立刻按
Esc打断，而不是等它做完•两次纠正不见效，就重来：如果已经纠正两次还是不对，上下文大概率被失败尝试污染了。清空、重写一个更好的初始提示
•用
/rewind回滚：每次 Claude 做出改动前都会自动存档，随时可以回到任意历史状态•不同任务，不同会话：把不相关的工作流分开，避免把一个会话变成"什么都有"的大杂烩
七、水平扩展：并行运行多个 Claude
一旦掌握了单个 Claude 的用法，可以考虑并行化：
•Writer/Reviewer 模式：一个 Claude 实现功能，另一个做代码审查——后者没有参与实现，反而能更客观地发现问题
•批量迁移：生成待处理文件列表，用脚本循环调用
claude -p "..."并行处理每个文件•CI 集成：用
claude -p的非交互模式，把 Claude 嵌入 pre-commit hook 或 CI 流水线，自动做 lint、检查、或生成报告
最后：培养直觉，而不是死守规则
这些法则都是起点，不是终点。有时候让上下文积累是对的（你在深挖一个复杂问题）；有时候跳过规划更好（任务本质上是探索性的）；有时候模糊提示才是你真正需要的。
最好的办法是：当 Claude 给出很好的结果时，回头想想你做对了什么。当它表现不佳时，问自己为什么——是上下文太乱？提示太模糊？任务太大？
反复观察，逐渐你会建立起超越任何文档的直觉。
References
• https://code.claude.com/docs/en/best-practices
• https://code.claude.com/docs/zh-CN/best-practices