Appearance
20 · 最佳实践五条法则
📚 系列导航：上一篇 19 Capstone 综合实战 带你走了一趟完整工程流。这一篇换个高度——不教新功能，教「怎么用得好」。
一条总约束
上下文窗口是你最金贵的资源。Claude 的上下文窗口填充速度很快，随着填充，性能会下降。所有最佳实践，归根结底都是在帮它省着用这个「工作台」。
法则一：给它一个能自己验收的方式
NOTE
给 Claude 一个它能自己跑的检查——测试、构建、截图比对。这是「你得盯着的会话」和「你能走开的会话」之间的分水岭。
| 场景 | ❌ 没给验收 | ✅ 给了验收 |
|---|---|---|
| 写函数 | 「实现一个验证邮箱的函数」 | 写 validateEmail，测试用例：a@b.com 为真、invalid 为假。实现后跑测试 |
| 改 UI | 「让仪表盘好看点」 | [贴设计稿] 照这个实现，做完截图比对，列出差异再修 |
| 修构建 | 「构建失败了」 | 修好并验证构建成功。解决根因，别把错误压下去 |
TIP
永远让 Claude 显示证据而不是声称成功：测试输出、它运行的命令及其返回的内容。
法则二：先探索，再规划，最后才编程
让 Claude 上来就闷头写代码，很容易写出一坨「解决了错误问题」的东西。
判断标准： 如果你能用一句话描述这次改完长啥样，直接干；卡壳了，说明够复杂，先 Plan Mode。
text
读一下 src/auth 目录，搞清楚我们怎么处理 session 和登录。
先别改任何代码。法则三：把话说具体
| 招式 | ❌ 模糊 | ✅ 具体 |
|---|---|---|
| 限定范围 | 「给 foo.py 加测试」 | 给 foo.py 写测试，覆盖用户已登出的边界情况，别用 mock |
| 指向来源 | 「ExecutionFactory 这 api 咋这么怪？」 | 看 ExecutionFactory 的 git 历史，总结它的 api 怎么演变的 |
| 参照现有模式 | 「加个日历组件」 | 看主页现有组件怎么写的，HotDogWidget.php 是个好例子。照这个模式实现，别引新库 |
| 描述症状 | 「修登录错误」 | 用户反馈 session 超时后登录失败。查 src/auth/，先写个失败测试复现，再修 |
法则四：CLAUDE.md 要写精，不是写多
WARNING
官方原话：保持简洁。对于每一行，问自己：「删除这个会导致 Claude 犯错吗？」如果不会，删除它。膨胀的 CLAUDE.md 文件会导致 Claude 忽略你的实际指令！
| ✅ 该写 | ❌ 不该写 |
|---|---|
| Claude 猜不到的 bash 命令 | 它读代码就能搞清的任何东西 |
| 跟默认不一样的代码风格规则 | 它早就懂的标准语言约定 |
| 测试指令、你偏好的测试运行器 | 详细的 API 文档（改成贴链接） |
| 仓库规矩（分支命名、PR 约定） | 经常变的信息 |
| 项目特有的架构决策 | 长篇解释或教程 |
法则五：一跑偏就立刻拽回来
一发现 Claude 跑偏，立刻纠正，别等它越走越远。
| 你想干啥 | 怎么做 |
|---|---|
| 中途喊停 | 按 Esc，上下文保留 |
| 倒带到之前 | 双击 Esc 或 /rewind |
| 撤销刚才那步 | 直接说「撤销那个改动」 |
| 不相关任务之间重置 | /clear 清空上下文 |
TIP
纠正两次还不对，别在这个会话里耗了，直接 /clear。干净的台子 + 更好的提示，几乎总是赢过在污染的上下文里继续掰扯。
小结
| 法则 | 一句话 |
|---|---|
| 给验收手段 | 给它一个能自己跑的检查 |
| 先探索再编程 | 大改动先 Plan Mode 出方案 |
| 把话说具体 | 点文件、限场景、给参照、说清修好的样子 |
| CLAUDE.md 写精 | 每行拿「删了会犯错吗」过一遍 |
| 一跑偏就拽回来 | Esc 刹车，两次不对就 /clear |
NOTE
下一篇：21 反模式与排障速查：那些「看着合理、实则坑你」的用法，以及常见报错怎么解。