Claude Code 最佳实践指南
你的 Claude Code 完整操作手册 - 从入门到精通
📌 文档说明
文档定位:Claude Code 完整使用指南,涵盖从基础配置到高级工作流的全流程
适合人群:
- AI Agent 开发者想要提升编程效率
- 对 AI 辅助编程感兴趣的工程师
- 希望掌握 Claude Code 的团队
核心价值:
- ✅ 系统化的学习路径(从入门到精通)
- ✅ 实战验证的最佳实践
- ✅ 企业级的工作流模式
- ✅ 完整的命令速查表
阅读时间:约 60-90 分钟(建议分段学习)
📖 目录
快速入门
安装与启动
1 | # 安装 Claude Code |
基本操作
1 | # 打印模式 - 执行后退出 |
核心配置
1. CLAUDE.md - 最重要的文件
CLAUDE.md 是你代码库的”宪法”,Claude 会自动读取此文件作为上下文。
创建位置
- 仓库根目录:
CLAUDE.md(团队共享,提交到 git) - 本地版本:
CLAUDE.local.md(个人使用,加入 .gitignore) - home 目录:
~/.claude/CLAUDE.md(全局配置) - 父目录或子目录:支持 monorepo 场景
内容建议
1 | # 项目名称 |
编写技巧和反模式
✅ 应该做的:
从防护栏开始,不是手册:根据 Claude 出错的地方来编写文档,而不是一开始就写全面的手册
提供替代方案:不要只说”绝不使用 X”,要说”不要使用 X,优先使用 Y”
引导阅读其他文档:不要 @-引用整个文件(会膨胀上下文),而是说明何时阅读
1
对于复杂的 API 使用或遇到 AuthenticationError,参见 docs/api-guide.md
作为简化工具的驱动力:如果 CLI 命令复杂冗长,不要写长篇文档解释,而是写一个简单的 bash 包装器
使用 # 快捷键:在 Claude Code 中按
#键,让 Claude 自动将内容合并到相关的 CLAUDE.md 中
❌ 不应该做的:
- ❌ 不要在 CLAUDE.md 中 @-引用其他文档文件(会完整嵌入,浪费 token)
- ❌ 不要只写否定约束(”绝不使用…”),总是提供替代方案
- ❌ 不要让文件过于冗长,保持简洁(建议 13-25KB)
维护策略
- 迭代优化:使用 prompt improver 优化指令
- 强调重点:用 “IMPORTANT” 或 “YOU MUST” 强调关键指令
- 团队同步:维护一份
AGENTS.md与其他 AI IDE 保持兼容
2. settings.json 配置
位置:.claude/settings.json 或 ~/.claude.json
1 | { |
关键配置项:
- HTTPS_PROXY/HTTP_PROXY:用于调试,检查原始流量和提示
- MCP_TOOL_TIMEOUT/BASH_MAX_TIMEOUT_MS:提高超时时间,适合运行长时间命令
- ANTHROPIC_API_KEY:使用企业 API key,按使用量计费而非按座位
- permissions:定期审计自动允许的命令列表
3. 工具权限管理
有四种方式管理允许的工具:
1 | # 方式 1: 在会话中被提示时选择 "Always allow" |
推荐白名单:
1 | # 安全的文件操作 |
4. 安装 gh CLI(GitHub 用户)
1 | # 安装 GitHub CLI |
Claude 会自动使用 gh CLI 与 GitHub 交互(创建 issue、开启 PR、读取评论等)。
基础命令
会话管理命令
1 | /help # 显示帮助和可用命令 |
模型选择
1 | # 切换模型 |
目录管理
1 | # 添加额外的工作目录 |
输出格式
1 | # 不同的输出格式 |
键盘快捷键
1 | Ctrl+C 取消当前操作 |
工作流模式
1. 探索 → 规划 → 编码 → 提交(推荐)
这是最通用且有效的工作流:
1 | # 第 1 步:探索代码库 |
关键点:
- 步骤 1-2 至关重要,防止 Claude 直接跳到编码
- 使用 “think” 关键词触发扩展思考模式
- 考虑使用子智能体来保留主上下文的可用性
2. 测试驱动开发(TDD)- Anthropic 内部最爱
1 | # 第 1 步:编写测试 |
优势:
- Claude 有明确的迭代目标(通过测试)
- 可以持续改进直到成功
- 防止过度设计
3. 视觉迭代工作流(UI 开发)
1 | # 第 1 步:设置截图能力 |
技巧:
- 经过 2-3 次迭代,结果通常会好得多
- 明确告诉 Claude 结果要”视觉上美观”
4. 代码库问答(入职利器)
1 | # 直接提问,无需特殊提示 |
应用场景:
- 新人入职,快速了解代码库
- 理解复杂的代码逻辑
- 查找代码的历史原因
5. Git 工作流(90%的 Git 交互)
1 | # 搜索 git 历史 |
6. GitHub 工作流
1 | # 创建 PR |
7. 安全的 YOLO 模式
1 | # 跳过所有权限检查(危险!) |
8. 清单和草稿板工作流(大型任务)
1 | # 处理大量 lint 错误 |
9. Jupyter Notebook 工作流
1 | # 数据分析 |
高级功能
1. 上下文管理(Compact vs Clear)
查看上下文使用情况
1 | /context # 查看 200k token 上下文窗口的使用情况 |
在大型代码库(如 monorepo)中,新会话基线成本约 20k tokens(10%),剩余 180k 用于修改。
三种上下文管理策略
策略 1:/compact(避免使用)
1 | /compact "保留重要部分" |
❌ 不推荐原因:
- 自动压缩不透明、容易出错、优化不佳
- 可能丢失关键上下文
策略 2:/clear + /catchup(简单重启)
1 | /clear # 清除状态 |
✅ 推荐用于: 简单任务、快速重启
策略 3:Document & Clear(复杂重启)
1 | # 步骤 1:记录进度 |
✅ 推荐用于: 大型任务、长时间工作
2. 自定义斜杠命令
位置:.claude/commands/ 或 ~/.claude/commands
示例 1:catchup 命令
.claude/commands/catchup.md:
1 | Read all changed files in my current git branch and summarize the changes. |
使用:/catchup
示例 2:修复 GitHub issue
.claude/commands/fix-github-issue.md:
1 | Please analyze and fix the GitHub issue: $ARGUMENTS. |
使用:/project:fix-github-issue 1234
示例 3:PR 命令
.claude/commands/pr.md:
1 | Clean up my code, stage it, and prepare a pull request with a descriptive title and description. |
使用:/pr
⚠️ 注意:
- 不要创建过多复杂的自定义命令(反模式)
- 斜杠命令应该是简单的个人快捷方式,不是新的”魔法命令”系统
3. 子智能体(Subagents)
内置方式:Task(…)(推荐)
1 | # 让主 Agent 决定何时委托 |
✅ 优势:
- 主 Agent 保留所有上下文(CLAUDE.md)
- 动态委托,由 Agent 自己决定如何分工
- “Master-Clone” 架构,灵活性高
自定义子智能体(不推荐)
1 | # 创建专门的子智能体 |
❌ 问题:
- 隔离上下文:主 Agent 失去测试相关的上下文,无法整体推理
- 强制工作流:将人类定义的工作流强加给 Agent
- 降低灵活性:Agent 无法根据实际情况调整策略
结论: 使用 Task(…) 让主 Agent 自己管理委托,而不是预定义专门的子智能体。
4. MCP(Model Context Protocol)
MCP 的正确使用方式
不要做: ❌ 创建臃肿的 API 镜像
1 | # 糟糕的 MCP 设计: |
应该做: ✅ 提供高级数据网关
1 | # 好的 MCP 设计: |
配置 MCP
1 | # 配置 MCP 服务器 |
三种配置方式
- 项目配置:在项目目录中可用
- 全局配置:在所有项目中可用
- 检入的 .mcp.json:对团队所有人可用
示例 .mcp.json:
1 | { |
推荐的 MCP 使用场景
✅ 适合使用 MCP:
- 复杂的、有状态的环境(如 Playwright、iOS Simulator)
- 需要认证和安全边界的操作
- 跨网络的数据访问
❌ 不适合使用 MCP:
- 无状态的工具(用简单的 CLI 代替)
- 纯数据查询(提供原始数据下载 API,让 Agent 用脚本处理)
5. Skills(技能)- 比 MCP 更重要
什么是 Skills
Skills 是 “Scripting Agent” 模型的形式化产品化:
Agent 自主性的三个阶段:
- Single Prompt:在一个提示中给出所有上下文(不可扩展)
- Tool Calling:手工制作工具,抽象现实(经典 Agent 模型,但创建新的抽象瓶颈)
- Scripting:给 Agent 访问原始环境(二进制、脚本、文档),它动态编写代码交互(最灵活)
Skills = Scripting 的形式化
Skills vs MCP
- MCP:安全网关,管理认证、网络、安全边界
- Skills:可发现的、文档化的 CLI/脚本,Agent 可以动态调用
如何使用 Skills
1 | # Skills 本质上是文档化的 CLI 工具 |
技巧:
- 如果你已经在使用 CLI 而非 MCP,你已经在使用 Skills 的理念
- SKILL.md 只是让这些 CLI 更有组织、可共享、可发现
6. Hooks(钩子)- 企业级关键功能
什么是 Hooks
Hooks 是确定性的”必须做”规则,补充 CLAUDE.md 中的”应该做”建议。
两种 Hook 策略
策略 1:Block-at-Submit Hooks(推荐)
1 | // .claude/hooks/pre-commit.js |
工作流:
- Claude 编写代码
- 尝试提交
- Hook 检查
/tmp/agent-pre-commit-pass文件 - 如果测试未通过,阻止提交,Claude 进入”测试-修复”循环
- 测试通过后,允许提交
✅ 优势:
- 在最终结果处验证
- 让 Agent 完成完整的计划
- 不会中途”挫败” Agent
策略 2:Hint Hooks(提示型)
1 | // 简单的、非阻塞的提示 |
✅ 适用于: 提供优化建议,但不强制
❌ 避免:Block-at-Write Hooks
不要在 Edit 或 Write 时阻塞:
- 中途阻塞会让 Agent 困惑或”挫败”
- 破坏 Agent 的完整计划
7. 规划模式(Planning Mode)
1 | # 启动规划模式 |
最佳实践:
- 对于任何”大型”功能变更都使用规划模式
- 定义”检查点”,让 Claude 在关键处停下来
- 使用规划建立对所需最小上下文的直觉
企业级:自定义规划工具
基于 Claude Code SDK 构建,强制执行内部最佳实践:
- 技术设计格式
- 代码结构规范
- 数据隐私和安全要求
8. 会话历史与恢复
1 | # 恢复会话 |
高级用法:挖掘历史数据
1 | # 会话历史位置 |
性能优化
1. 上下文管理技巧
1 | # 频繁使用 /clear |
2. 指令具体化
❌ 糟糕的提示:
1 | 修复这个 bug |
✅ 好的提示:
1 | 修复 src/auth.py 中的认证 bug。问题是在用户登录后 |
关键原则:
- Claude 可以推断意图,但不会读心术
- 具体性 = 更好的首次成功率 = 更少的迭代 = 更快的结果
3. 提供视觉和数据
视觉输入
1 | # 方式 1:粘贴截图 |
数据输入
1 | # 方式 1:直接粘贴(最常见) |
4. 提及文件和 URL
1 | # 使用 Tab 补全快速引用文件 |
5. 路线修正技巧
四种修正工具
工具 1:提前规划
1 | > 制定一个详细计划来实现 X。在我确认计划可行之前,不要编写任何代码 |
工具 2:中断(Escape)
1 | 按 Escape:中断当前操作(思考、工具调用、文件编辑) |
工具 3:回退历史(Escape x2)
1 | 双击 Escape:跳回历史记录 |
工具 4:撤销修改
1 | > 撤销你刚才对 auth.py 的修改 |
原则:
- Claude 偶尔能一次成功,但修正通常能更快得到更好的结果
- 成为积极的合作者,而不是被动的观察者
6. 自动接受模式
1 | # 切换自动接受模式 |
自动化与集成
1. 无头模式(Headless Mode)
用于 CI、pre-commit hooks、构建脚本和自动化。
1 | # 基本无头模式 |
2. Issue 分类自动化
1 | # GitHub Actions 示例 |
3. 主观代码审查
1 | # 在 CI 中运行 Claude |
4. 多 Claude 并行工作流
模式 1:一个写代码,一个审查
1 | # 终端 1 |
模式 2:多个 Git Checkouts
1 | # 创建 3-4 个 git checkout |
模式 3:Git Worktrees(推荐)
1 | # 创建 worktrees |
优势:
- 共享 Git 历史,节省空间
- 独立的工作目录
- 适合并行的独立任务
5. 无头模式的两种模式
模式 A:扇出(Fan-out)- 大规模处理
1 |
|
适用场景:
- 代码迁移(数千个文件)
- 日志分析(数百个日志文件)
- 批量数据处理
模式 B:管道化(Pipeline)- 集成到数据流
1 | # 集成到现有管道 |
6. Claude Code GitHub Action(GHA)
这是最强大的操作化 Claude Code 的方式。
1 | # .github/workflows/claude-pr.yml |
应用场景:
- 从 Slack 触发 PR
- 从 Jira 自动修复 bug
- 从 CloudWatch 告警自动修复问题
数据驱动的改进循环:
1 | # 查询 GHA 日志,找到常见错误 |
优势:
- 完全可定制的容器和环境
- 强大的沙箱和审计控制
- 支持所有高级功能(Hooks、MCP)
- 比 Cursor 后台 Agent 或 Codex Web UI 更可控
7. Claude Code SDK
Claude Code 不仅是 CLI,也是一个强大的 SDK。
三种使用方式
用途 1:大规模并行脚本
1 |
|
用途 2:内部聊天工具
1 | # 为非技术用户构建简单的聊天界面 |
用途 3:快速 Agent 原型
1 | # 快速原型新的 Agent 想法 |
推荐:
- 作为默认 Agent 框架(替代 LangChain/CrewAI)
- 用于编码和非编码任务
- 快速测试想法,再决定是否构建完整系统
最佳实践总结
核心原则
1. CLAUDE.md 是关键
- ✅ 从防护栏开始,基于 Claude 的错误迭代
- ✅ 提供替代方案,不只说”不要”
- ✅ 引导阅读其他文档,不要 @-引用完整文件
- ✅ 保持简洁,作为简化工具的驱动力
- ❌ 不要试图写一本完整的手册
2. 上下文管理至关重要
- ✅ 频繁使用
/clear在任务之间清除上下文 - ✅ 使用
/context监控 token 使用 - ✅ 对大型任务使用 “Document & Clear” 模式
- ❌ 避免依赖
/compact(不可靠)
3. 具体化你的指令
- ✅ 提供详细的、多步骤的指令
- ✅ 使用 “think” / “think hard” / “think harder” 触发扩展思考
- ✅ 明确告诉 Claude 何时不要编码(探索阶段)
- ❌ 不要期望 Claude 读心术
4. 让 Claude 看到结果
- ✅ 提供截图、设计稿、数据可视化
- ✅ 使用测试作为迭代目标
- ✅ 让 Claude 截图并比对设计
- ✅ 明确要求视觉上美观
5. 积极合作,主动修正
- ✅ 在编码前要求制定计划
- ✅ 使用 Escape 中断并重定向
- ✅ 使用 Escape x2 编辑历史提示
- ✅ 让 Claude 撤销并重试
- ❌ 不要完全”放手”,保持参与
6. 使用正确的架构
- ✅ 使用 Task(…) 让主 Agent 动态委托
- ✅ MCP 应该是简单的数据网关,不是 API 镜像
- ✅ 优先使用 CLI + Skills,而非复杂的 MCP
- ❌ 避免自定义子智能体(会隔离上下文)
7. 测试和验证
- ✅ 使用 TDD 工作流(写测试 -> 实现)
- ✅ 使用 Hooks 在 commit 时验证(不是 write 时)
- ✅ 让独立的 Claude 审查代码
- ✅ 使用子智能体验证是否过拟合