用好 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. 1. 探索阶段（开启 Plan Mode）：让 Claude 读代码、梳理现状，不做任何修改

2. 2. 规划阶段：让 Claude 列出具体的实施计划——哪些文件要改、流程是什么

3. 3. 实施阶段：切回正常模式，按计划执行，边写边验证

4. 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