Claude Code 完全指南：从入门到精通的 13+6 个核心技巧

前言

Claude Code 是 Anthropic 推出的智能编程助手，它不仅仅是一个聊天工具，更是一个能与你的开发环境深度集成的”编程伙伴”。本文整理了 Claude Code 创始工程师 Boris Cherny 每天实际在用的 13 个核心方法，以及高级功能和最佳实践，帮助你真正掌握这个强大的开发工具。

---

第一部分：Boris Cherny 的 13 个核心工作方法

方法 1-2：并行工作，榨干工具价值

终端同时跑 5 个 Claude 实例

Boris 在终端里同时开启 5 个 Claude 窗口，每个窗口处理不同的任务：

• 窗口 1：正在写新功能的代码
• 窗口 2：跑测试找 Bug
• 窗口 3：查 API 文档
• 窗口 4：做代码重构
• 窗口 5：处理用户反馈

关键技巧是开启系统通知功能。当某个 Claude 需要输入时，系统会弹出提醒。这样就不需要盯着某一个窗口傻等，而是可以在不同任务间灵活切换。

网页版再开 5-10 个任务

除了终端的 5 个窗口，Boris 还会在浏览器里打开 claude.ai/code，再启动 5-10 个 Claude 会话。他甚至会在手机（Claude iOS 应用）上启动几个任务，然后过一会儿再去看结果。

核心逻辑：Claude 订阅费每月 200 美元。如果你只开一个窗口，就好比你花钱请了 5 个助手，但让他们排队一个个来工作。同时开多个窗口，就是让多个助手并行干活，效率成倍提升。

方法 3：永远用最强的模型

Boris 在所有任务上都用 Opus 4.5 模型，并且开启思考功能。

很多人可能会问：Opus 比 Sonnet 贵，速度也慢，为什么不用便宜的？

Boris 的理由：

虽然 Opus 单次响应时间更长，但因为它更聪明，你需要的来回次数更少：

• 用 Sonnet：可能要提示 3 次才能得到满意结果，每次等 30 秒，总共 90 秒
• 用 Opus：第一次就能做对，虽然要等 60 秒，但总共只需要 60 秒

而且 Opus 在使用工具（读写文件、运行命令、调用 API）时更准确，更少出错。

方法 4-5：积累团队智慧

团队共享 CLAUDE.md 文件

Boris 的团队维护一个 CLAUDE.md 文件，专门记录两类信息：

1. Claude 做错过的事情，以及正确的做法
2. 团队的特殊规范和偏好

例如：

禁止在生产代码中使用 console.log，请使用我们的 logger 工具。
提交信息必须遵循 Conventional Commits 格式。
所有 API 错误必须返回统一的错误格式 {code, message, details}。

每当团队成员发现 Claude 做错了什么，就会在 CLAUDE.md 里加一条规则。久而久之，这个文件变成了团队的”AI 培训手册”。

代码审查时用 @claude 更新规范

在做代码审查时，如果发现某个问题值得记录，就在 PR 评论里 @claude，让它自动把这条规则加到 CLAUDE.md 里。

例如审查时发现某个 API 调用没有加 timeout，你可以评论：

@claude 请在 CLAUDE.md 中添加：所有外部 API 调用必须设置合理的 timeout。

Claude 会自动把这条规则写进 CLAUDE.md，并作为 PR 的一部分提交。

方法 6：用计划模式启动任务

Boris 的大多数会话都是在计划模式下开始的。

启动计划模式的方法：按两次 Shift+Tab

进入计划模式后，工作流程变成：

1. 你告诉 Claude 想做什么
2. Claude 给出一个计划，列出它打算怎么做
3. 你审查这个计划，提意见，要求调整
4. 来回几轮，直到计划让你满意
5. 切换到自动接受模式，让 Claude 执行

核心原则：花 3 分钟确认计划，能省下 30 分钟的返工时间。

方法 7：为高频工作流创建斜杠命令

Boris 为每个重复执行的工作流创建了斜杠命令，保存在 .claude/commands/ 文件夹里。

例如 /commit-push-pr 命令，功能包括：

• 查看 git 当前状态
• 生成合适的 commit message
• 提交代码
• 推送到远程仓库
• 创建 Pull Request

他每天要用这个命令几十次。斜杠命令把这个流程固化下来，只需要输入 /commit-push-pr，剩下的全自动。

方法 8：用子代理处理专门任务

Boris 创建了多个子代理（sub-agents），每个负责特定类型的任务：

• code-simplifier：在 Claude 完成代码后，专门负责简化和优化代码
• verify-app：包含详细的测试指令，负责端到端测试应用
• security-reviewer：专注于安全问题审查
• performance-reviewer：专注于性能问题分析

子代理适合需要判断和决策的任务，而斜杠命令适合固定步骤的操作。

方法 9：用钩子自动格式化代码

Boris 的团队用了一个 PostToolUse 钩子。每当 Claude 使用工具（比如编辑文件）后，这个钩子会自动运行代码格式化工具：

• Claude 写了 JavaScript 代码 → 钩子自动运行 Prettier 格式化
• Claude 写了 Python 代码 → 钩子自动运行 Black 格式化

这样就不用在 CI 环节因为格式问题报错了。

方法 10：用权限预设避免重复确认

Claude Code 默认会在执行敏感操作时询问许可。Boris 不用 --dangerously-skip-permissions（那太危险），而是用 /permissions 命令预先允许一些已知安全的常用命令：

git status
git diff
npm test
docker ps
ls
cat

这些命令被写进 .claude/settings.json 文件，提交到 Git，团队共享。

判断原则：

• 只读操作 → 预设允许
• 可逆操作 → 预设允许
• 不可逆操作 → 每次确认
• 涉及外部系统 → 每次确认

方法 11：让 Claude 使用所有工具

Boris 给 Claude 配置了大量 MCP 服务器（Model Context Protocol），让 Claude 可以：

• 搜索并发布消息到 Slack
• 运行 BigQuery 查询做数据分析
• 从 Sentry 获取错误日志
• 调用各种命令行工具

这些配置被写在 .mcp.json 文件里，团队共享。

方法 12-13：长任务处理与验证闭环

长任务用后台代理或插件

对于需要运行很长时间的任务，Boris 有三种策略：

1. 策略 A：让 Claude 用后台代理验证
2. 策略 B：用代理停止钩子自动验证
3. 策略 C：用专门的插件在完成任务后自动运行检查

在沙箱环境里，他会用 --permission-mode=dontAsk，让 Claude 可以不受阻碍地完成整个长任务。

给 Claude 验证工作的途径

这是 Boris 认为最重要的一条：确保 Claude 有办法验证自己做的工作。

没有反馈循环的 AI 就像闭着眼睛干活的人，它不知道自己做得对不对。有了反馈循环，AI 可以自己检查、自己纠错、自己迭代，最终结果的质量能提升 2 到 3 倍。

---

第二部分：高级功能详解

4.1 Plan 模式（规划模式）

Plan 模式是一种”先规划、后执行”的工作模式。Anthropic 开发者关系负责人 Ado Kukic 有 90% 的时间都在使用这个模式。

进入 Plan 模式：

• 快捷键：按两次 Shift+Tab
• 命令：/plan

核心价值：在这个模式下，Claude 会阅读代码、分析架构、起草计划，但绝不修改代码。直到你批准计划，它才会动手。你是架构师，它是执行者。

适合场景：

• ✅ 复杂功能开发（多文件、多步骤）
• ✅ 架构重构
• ✅ 性能优化
• ✅ 代码迁移
• ❌ 简单 Bug 修复、单行代码修改

4.2 Sandbox 模式（沙箱模式）

Sandbox 模式通过定义允许的操作范围，拦截危险操作，提高安全性。

配置方式：

{
  "permissions": {
    "allow": {
      "bash": [
        "npm install",
        "npm test",
        "npm run build",
        "git *"
      ],
      "write": [
        "src/**/*",
        "tests/**/*"
      ]
    },
    "deny": {
      "bash": [
        "rm -rf *",
        "format *",
        "shutdown"
      ]
    }
  }
}

4.3 Headless 模式（无头模式）

Headless 模式是非交互式运行方式，可集成到 Shell 脚本或 CI/CD 流程中。

使用场景：

• 🔄 CI/CD 集成（自动化代码审查）
• 📜 脚本自动化（批量处理任务）
• 🔍 快速分析（不需要交互的代码分析）

基本用法：

# 从管道输入
git diff | claude -p "解释这些更改"

# 直接指定
claude -p "检查代码质量" < src/main.js

4.4 Slash Commands（自定义命令）

Slash Commands 是将高频工作流封装成可复用的斜杠命令。

创建方式：
在 .claude/commands/ 目录创建 Markdown 文件：

# .claude/commands/commit-push-pr.md

你是一个发布助手。请执行以下步骤：

1. 检查 Git 状态
   !git status

2. 运行测试套件
   !npm test

3. 如果测试通过：
   - 添加所有更改
   - 生成符合 Conventional Commits 的提交消息
   - 推送到远程
   - 创建 Pull Request

使用：直接输入 /commit-push-pr

4.5 Extended Thinking（扩展思考模式）

当你需要设计复杂的缓存层或重构架构时，在提示词中加上 ultrathink。

ultrathink: 设计一个高可用的 Redis 缓存层，考虑：
- 缓存穿透、缓存击穿、缓存雪崩
- 分布式锁
- 缓存更新策略
- 降级方案

效果：Claude 会分配高达 32k 的 Token 进行内部推理，逻辑准确率大幅提升。

---

第三部分：实用技巧与快捷操作

基础操作技巧

操作	命令/快捷键
项目初始化	/init
快速引用文件	@src/auth.ts
引用整个目录	@src/components/
即时执行 Bash	!git status
回退操作	双击 ESC
反向搜索历史	Ctrl + R
提示词暂存	Ctrl + S

会话管理技巧

# 恢复上一次对话
claude --continue

# 显示历史会话列表
claude --resume

# 给当前会话命名
/rename feature-auth

# 按名称恢复会话
/resume feature-auth

# 在终端和网页间同步上下文
claude --teleport session_id

常用斜杠命令速查

命令	功能	使用频率
/clear	清空对话历史	⭐⭐⭐⭐⭐
/compact	清空对话但保留摘要	⭐⭐⭐⭐⭐
/context	可视化上下文使用	⭐⭐⭐⭐⭐
/model	切换模型	⭐⭐⭐⭐
/cost	显示费用统计	⭐⭐⭐⭐
/export	导出对话	⭐⭐⭐⭐

---

第四部分：最佳实践

模型选择策略

国外模型：

• 快速查询/格式化：Haiku 4.5 - 最快最便宜
• 日常开发/代码编写：Sonnet 4.5 - 性价比平衡
• 架构设计/复杂重构：Opus 4.5 + Thinking - 最高质量（创始人首选）

国内模型：

• 简单查询：DeepSeek-Coder - 极低成本
• 中文项目：GLM-4.7 - 中文理解最强
• 大型重构：Kimi K2 - 超长上下文（2M+）
• Python/JS：Qwen-Coder-Plus - 开源优秀

验证闭环（Feedback Loop）

来自 Boris 的最重要技巧：永远给 Claude 一种验证自己工作的方法。

如果 Claude 能看到自己代码的运行结果（报错信息、测试通过与否），它的代码质量会提升 2-3 倍。

实践方法：

请实现一个用户登录功能，然后：
1. 运行测试验证
!npm test
2. 根据测试结果修复问题
3. 重新验证直到所有测试通过

探索-规划-编码-提交工作流

第 1 步：探索阶段 - 理解项目架构
第 2 步：规划阶段 - 使用 Plan 模式设计实现方案
第 3 步：编码阶段 - 按计划实施
第 4 步：提交阶段 - 使用 commit skill 生成规范的 commit message

---

总结

这 13+6 个方法围绕着几个核心思想：

1. 并行工作，榨干工具价值（方法 1、2）
2. 用最好的模型，追求一次做对（方法 3）
3. 积累团队智慧，让 AI 越用越聪明（方法 4、5、11）
4. 自动化一切重复操作（方法 7、8、9、10）
5. 给 AI 完整的工具和权限（方法 10、11、12）
6. 建立反馈循环，让 AI 自我验证（方法 13）
7. 先计划再执行，方向比速度重要（方法 6、Plan 模式）

这些方法不是随便想出来的，是 Boris 和他的团队在实际工作中不断试错总结出来的。你不需要一次全部用上，可以先从最适合你的几条开始，慢慢建立自己的 AI 工作流。

关键是要有这个意识：AI 工具不是拿来就能用好的，需要你投入时间去配置、训练、优化。但一旦建立起顺手的工作流，回报是巨大的。

就像 Boris 说的：Claude Code 没有唯一正确的用法，团队里每个人都在用不同的方式。重要的是找到适合你的方式，然后不断迭代改进。

---

本文部分内容结合个人实践经验整理而成。