在 Claude Code 的官方文档中，隐藏着一份由 Anthropic 内部团队积累的最佳实践指南。与此同时，社区也不甘示弱，一个 GitHub 仓库整理出了多达 84 条实用技巧——本文从中精选了几条真正高效的实践，并结合实际使用经验进行了梳理与解读。
一、为 Claude 提供明确的验证方式
这确实是一个非常关键的要点。官方反复强调，这可能是提升效果最为显著的建议之一。
当 Claude 能够自主验证其工作成果时，它的表现会大幅提升：例如运行测试、进行截图对比、检查输出结果等。如果缺乏明确的验证标准，Claude 很容易写出看起来没问题但实际上无法运行的代码。
不同验证策略的效果对比
策略 |
欠佳的指令 |
优质的指令 |
|---|---|---|
提供测试用例 |
"实现邮箱验证函数" |
"编写 validateEmail 函数，测试用例：user@example.com 返回 true，invalid 返回 false，user@.com 返回 false。实现后运行测试验证" |
视觉验证 UI |
"让仪表盘看起来更好看" |
"[贴截图] 请按照这个设计实现。完成后进行截图对比，列出所有差异并逐一修复" |
解决根本原因 |
"构建失败了" |
"构建失败，错误信息如下：[贴错误]。请修复并确保构建通过。要解决根本原因，不要仅仅压制错误" |
处理 Bug：只说"修复"，别越级指挥
这是社区中一条最反直觉的经验。
遇到 Bug 时，直接将错误信息粘贴给 Claude，只给它一个指令：修复。不要指导它如何修复，不要猜测原因，更不要指定解决方案。Claude 的调试能力远超大多数人的想象——你越是微操，越容易把它带偏。直接让它处理，成功率能达到 80%。
如果两次尝试仍未成功，停下来。使用 /clear 重置上下文，换一个角度重新尝试。
你：这个报错是因为数据库连接超时，可能是连接池配置问题，你查一下连接池设置...
你：[粘贴错误信息]修复。
二、遵循探索 → 规划 → 编码的流程
将研究与规划阶段与具体实现分开，能有效避免解决错误的问题。
Plan Mode 工作流
进入 Plan Mode：按 Shift Tab 两次。在此模式下，Claude 只会读取文件、回答问题，不会进行任何修改。
推荐的工作流程：
- 探索（Plan Mode）—— claude (Plan Mode) 读取 /src/auth，理解 session 处理逻辑。
- 规划（Plan Mode）—— claude (Plan Mode) 我想添加 Google OAuth。需要修改哪些文件？请制定一个计划。
- 实现（Normal Mode）—— claude (Normal Mode) 按照计划实现 OAuth 流程。为回调处理器编写测试。
- 提交—— claude (Normal Mode) 使用描述性信息提交，并打开 PR。
什么时候可以跳过规划？
场景 |
是否需要规划 |
|---|---|
修改错别字、添加日志、重命名 |
跳过 |
不确定解决方案 |
需要规划 |
改动涉及多个文件 |
需要规划 |
不熟悉需要修改的代码 |
需要规划 |
能够用一句话描述出 diff，就可以跳过计划。
三、CLAUDE.md 保持在 60 行以内
这是新手最容易踩的坑。
刚开始使用 Claude Code 时，我曾将 CLAUDE.md 写到了将近 500 行——项目描述、编码规范、API 文档全部塞了进去。结果如何呢？Claude 会选择性忽略部分规则，尤其是那些放在文件末尾的内容。
经验数据表明：理想的行数在 60 行以内，硬性上限是 300 行。Boris Cherny（Claude Code 的创建者）解释道：当前前沿 LLM 能够可靠执行的指令大约在 150-200 条之间，而系统提示已经占了约 50 条。留给用户自定义指令的空间确实有限。
具体做法：CLAUDE.md 只存放 Claude 可能会忽略的信息——例如构建命令、测试命令、分支命名规范、以及项目特定的架构决策。Claude 能从代码中直接推断出来的内容，就不必写进去。如果规则太多，可以拆分到 .claude/rules/ 目录下实现按需加载。关键规则建议用
四、让 Claude 先"面试"你
给 Claude 一个简单的需求描述，然后让它使用 AskUserQuestion 工具来"面试"你，澄清所有细节。面试结束后，再开启一个新会话执行具体任务。
我曾经做过一个 API，Claude 问了"并发请求如何处理"、"超时策略是什么"等问题——这些细节我起初根本没有考虑到。它的提问能够帮你发现平时容易忽略的边界情况。
关键点：面试完成后一定要开新会话。面试过程中的长对话会污染上下文。
示例：
你：我需要做一个用户认证系统。
Claude 开始面试：1. 认证方式：JWT 还是 Session？2. 密码存储：使用什么哈希算法？3. 登录失败限制：几次后锁定？4. Token 过期时间：多久？5. 多设备登录：允许还是互踢？
你回答完所有问题。
你：/clear（开启新会话）你：请按照刚才讨论的需求实现用户认证系统。
五、提供具体的上下文
指令越精确，后续需要纠正的次数就越少。
不同上下文策略的效果对比
策略 |
欠佳的指令 |
优质的指令 |
|---|---|---|
划定范围 |
"给 foo.py 编写测试" |
"给 foo.py 编写测试，覆盖用户未登录的边界情况。不要使用 mock" |
指向来源 |
"这个 API 为什么设计得这么奇怪？" |
"查询 ExecutionFactory 的 git 历史，总结一下 API 是如何演变成现在这样的" |
引用模式 |
"添加一个日历组件" |
"参考主页现有组件的实现方式。HotDogWidget.php 是一个很好的参考例子。请按照这个模式来实现" |
描述症状 |
"修复登录 Bug" |
"用户报告登录后仍显示未登录状态。问题可能出在 AuthContext.tsx。请先检查 auth 流程" |
上下文来源清单
代码语言：ja vascript src/auth/login.ts
六、要求重写平庸的方案
当 Claude 给出的方案虽然能用但不够优雅时，不要一点点打补丁。直接这样说：
knowing everything you know now, scrap this and implement the elegant solution
Claude 会基于对问题的完整理解重新设计。我试过几次，重写后的版本总能比打补丁的方案好得多。
类似地，也可以说 prove to me this works，让 Claude 将当前分支与 main 分支做 diff，验证改动是否正确。
Claude：[实现了一个能用但很丑陋的方案]你：这个方案能用，但不够优雅。knowing everything you know now, scrap this and implement the elegant solution.Claude：[基于完整理解重新设计，新的方案更加简洁]
七、在提示词中加入"用子 Agent"
在提示词里加上一句 use subagents，Claude 就会将任务拆分成多个子 Agent 并行处理。
这种方法特别适合代码审查和大规模重构。有人曾使用 9 个并行的子 Agent 进行代码审查，每个子 Agent 专注于一个质量维度。
你：请审查这个 PR，检查安全性、性能、代码风格。use subagentsClaude 启动 3 个子 Agent：子 Agent 1：安全审查；子 Agent 2：性能审查；子 Agent 3：风格审查。主会话只收到汇总报告。
技巧：创建子 Agent 时，尽量让它的功能更具体（例如"前端组件 Agent"），而不是过于笼统（如"QA Agent"）。功能越具体，最终效果越好。
八、Skills 使用文件夹结构，并添加 Gotchas 区
很多人只写一个 SKILL.md 文件就完事了。但实际上，Skills 应该是一个完整的文件夹结构：
.claude/skills/my-skill/├── SKILL.md # 核心规则和索引├── references/ # 详细文档├── scripts/ # 可执行脚本└── examples/ # 示例文件
这种渐进式披露的方式非常关键——Claude 只在需要时才会读取子目录中的内容，而不会一次性将所有信息塞进上下文。
另一个实用技巧：在每个 Skill 里建立一个 Gotchas（陷阱记录）区，每次 Claude 犯错时都记录下失败的模式。时间一长，这部分内容会成为信噪比最高的宝贵资料。
## Gotchas（陷阱记录）- ❌ "值得注意的是" → 太啰嗦，直接说重点- ❌ "在...的背景下" → 翻译腔，改成"在...情况下"- ❌ 连续三个四字短语 → AI 腔，换表达
九、上下文使用率达到 50% 时手动压缩
这是最重要的工作流级实践之一。
Claude Code 存在一个"Agent 呆滞区"——当上下文使用率超过 60-70% 时，性能会明显下降，Claude 开始忽略指令，犯一些低级的编码错误。
仓库建议：在上下文使用率达到 50% 时就手动执行 /compact，不要等到自动压缩，那时通常已经晚了。
你：/contextClaude：当前上下文 90K/200K，使用率 45%你：[继续读取文件...]你：/contextClaude：当前上下文 105K/200K，使用率 52%你：/compactClaude：已压缩对话历史，当前上下文 35K/200K
可以使用 /statusline 实时监控上下文用量。
十、跑偏时按 Esc Esc 回滚
当 Claude 跑偏了该怎么办？大多数人的本能反应是在当前会话里纠正它。
建议的做法是：直接按两次 Esc（或使用 /rewind）回滚到上一个检查点。在同一个上下文里纠正跑偏，往往会越改越乱——因为错误的推理过程仍然保留在上下文中，Claude 会被自己的错误逻辑带偏。
一个实用的习惯是：跑偏一次 → Esc Esc 回滚；同一问题跑偏两次 → /clear 重新开始。
Claude：[开始重构整个架构，但你原本只是想改一个函数]你：Esc Esc（回滚到重构前的状态）你：我只想修改 validateToken 这个函数，不要动其他文件。
十一、早纠正，频纠正
Claude 并不怕被纠正。它真正怕的是你保持沉默。
何时进行纠正
• 方向错了：立即打断，说明正确的方向• 方法对了但细节有误：让它继续，完成后统一调整• 完成度达到 50% 时：快速检查一下，确认方向正确
不同纠正方式的效果对比
"不对，重来"
"方向没问题，但不要使用 mock，改用真实的数据库。当前的测试在 CI 中会失败，因为 mock 的响应格式与真实 API 不一致。"
十二、小任务别用复杂工作流
原生 Claude Code 处理小任务的速度比任何复杂工作流都要快。修改一个变量名也要走完整的 Plan → Execute → Review 流程，实际上只需一句话就能搞定。
那些复杂的工作流（如 Superpowers、Spec Kit 等）是为涉及多文件、多步骤的大任务设计的。对于三五分钟就能完成的小事，使用原生方式效率最高。
判断标准：能用一句话描述改动的 → 直接说；涉及 3 个以上文件的 → 使用工作流；需要多轮验证的 → 使用工作流；改动逻辑复杂的 → 先使用 Plan Mode。
十三、实现自动化与扩展
非交互模式
适用于 CI/CD、脚本、后台任务：claude --print "analyze the test failures in src/tests/"
并行会话
使用 Git Worktree 运行多个 Claude 实例：git worktree add ../feature-a feature-branch; cd ../feature-a; claude "implement feature A" &
Auto Mode
让 Claude 完全自主运行：claude --auto
十四、常见失败模式
模式一：缺少验证标准
症状：Claude 写出了看起来正确但实际上无法运行的代码。解决方案：提供测试用例、截图、预期输出。
模式二：一次性输入过多信息
症状：Claude 被大量信息淹没，开始丢失关键点。解决方案：分阶段处理，使用子 Agent 隔离任务，在上下文使用率达到 50% 时进行压缩。
模式三：指令描述模糊
症状：Claude 不得不猜测你的意图，导致需要反复纠正。解决方案：指明具体文件、约束条件、以及参考示例。
模式四：忽视上下文管理
症状：等到上下文快被用满时才发现问题，Claude 开始出现"失忆"现象。解决方案：定期使用 /context 检查，使用率超过 70% 时立即执行 /compact。
模式五：不及时进行纠正
症状：Claude 走偏了很久才被发现，导致需要进行大范围修改。解决方案：在任务完成度达到 50% 时就进行阶段性检查。
总结
核心实践速查表：
实践 |
关键点 |
|---|---|
验证方式 |
提供测试、截图、预期输出 |
Bug 只说修复 |
不要微操，成功率可达 80% |
Plan Mode |
复杂任务先进行规划 |
CLAUDE.md 60 行 |
只存放 Claude 可能忽略的信息 |
面试技巧 |
需求不清晰时让 Claude 提问来厘清 |
具体上下文 |
指明文件、约束条件、参考示例 |
重写平庸方案 |
不要打补丁，直接要求重写 |
提示加 subagents |
实现并行处理，隔离上下文 |
Skills 文件夹 |
主文件 + references + Gotchas |
50% 就压缩 |
不要等到自动压缩 |
Esc Esc 回滚 |
跑偏时回滚，不要在原有上下文中纠正 |
小任务直接说 |
不要为小事启动复杂工作流 |
参考
• Claude Code 最佳实践文档 — https://code.claude.com/docs/en/best-practices• Claude Code 最佳实践仓库 — https://github.com/shanraisshan/claude-code-best-practice• Claude Code 常见工作流 — https://code.claude.com/docs/en/common-workflows• Claude Code 扩展机制 — https://code.claude.com/docs/en/features-overview
