Logo独立开发者全球聚集地
返回博客

claude code的13个使用技巧

claude cn

Claude Code 使用技巧

Boris Cherny 是 Claude Code 的创始工程师，最近他在 X 上公开了自己使用 Claude Code 的 13 个核心方法。这些不是理论，而是他每天实际在用的工作流程。

让我们一条一条拆解，看看真正的高手是怎么用 AI 工具的。

方法 1：终端同时跑 5 个 Claude 实例

具体做法：

Boris 在终端里同时开启 5 个 Claude 窗口。他把标签页编号为 1 到 5，每个窗口处理不同的任务。比如：

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

关键技巧：

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

为什么这么做：

Claude 订阅费是每月 200 美元。如果你只开一个窗口，让 AI 干完一件事再干下一件，就好比你花钱请了 5 个助手，但让他们排队一个个来工作。同时开 5 个窗口，就是让这 5 个助手并行干活，效率提升 5 倍。

很多人会说：我同时开这么多窗口，切换不过来怎么办？Boris 的答案是：大部分时候你不需要切换，你只需要在某个 Claude 卡住或需要确认时，收到通知过去处理一下就行。其他时间，它们在后台自动工作。

方法 2：网页版再开 5 到 10 个 Claude 任务

具体做法：

Boris 不满足于终端里的 5 个窗口，他还会在浏览器里打开 claude.ai/code，再启动 5 到 10 个 Claude 会话。

他会用两种方式在终端和网页版之间切换：

  • 用 & 符号把终端任务交给网页版继续
  • 手动在 Chrome 里启动新会话
  • 用 --teleport 命令在两者间来回切换

更夸张的是，他早上起床和白天随时会用手机（Claude iOS 应用）再启动几个任务，然后过一会儿再去看结果。

为什么这么做：

加上终端的 5 个，Boris 经常同时运行 15 个左右的 Claude 实例。这听起来疯狂，但仔细想想，如果你有 15 件事要做，为什么不让 15 个 AI 同时帮你做？

关键是要区分哪些任务需要你实时跟进，哪些可以扔给 AI 自己跑。比如生成测试数据、整理文档、做初步的代码审查，这些都可以扔给网页版或手机版，让它们在后台慢慢跑，你只需要最后看结果就行。

方法 3：永远用 Opus 4.5 + 思考模式

具体做法：

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

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

Boris 的理由：

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

具体来说：

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

而且 Opus 在使用工具（比如读写文件、运行命令、调用 API）时更准确，更少出错，这意味着你不需要频繁修正它的错误。

什么时候这个选择特别重要：

当你的任务比较复杂，需要多步骤操作时，Opus 的优势最明显。比如你要让 AI 重构一个模块，涉及到读多个文件、理解代码逻辑、做改动、跑测试。这种情况下，Sonnet 可能会在某个步骤卡住或做错，你得重来。Opus 往往能一次走通全流程。

方法 4：团队共享 CLAUDE.md 文件

具体做法：

Boris 的团队维护一个 CLAUDE.md 文件，这个文件被提交到 Git 仓库里，所有人都能看到和修改。

这个文件专门记录两类信息：

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

比如文件里可能会写：

禁止在生产代码中使用 console.log，请使用我们的 logger 工具。

提交信息必须遵循 Conventional Commits 格式。

所有 API 错误必须返回统一的错误格式 {code, message, details}。

工作流程：

每当团队成员发现 Claude 做错了什么，他们就会在 CLAUDE.md 里加一条规则。整个团队每周会向这个文件贡献多次。

久而久之，这个文件变成了团队的"AI 培训手册"。每个新启动的 Claude 会话都会读取这个文件，自动了解这个团队的工作方式。

为什么这么做：

传统的团队知识管理很难：你写文档，但很少有人去看；你开会培训，但新人过两天就忘了。

但 CLAUDE.md 不一样，因为 Claude 每次都会读它。你写进去的规则，Claude 100% 会遵守。这相当于你把团队规范直接内置到了 AI 助手里。

而且因为这个文件是持续更新的，它会随着团队的成长而成长。六个月后，它可能包含了几百条经验，这时候新人加入，Claude 就能按照团队老手的标准来工作了。

方法 5：代码审查时用 @claude 更新规范

具体做法：

Boris 的团队用 Claude Code Github action。在做代码审查时，如果有人发现某个问题值得记录下来，就在 PR 评论里 @claude，让它自动把这条规则加到 CLAUDE.md 里。

比如审查时发现：

这个 API 调用没有加 timeout，如果服务端卡住，我们的应用会一直等待。

你就可以评论：

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

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

为什么这么做：

这个机制解决了一个老问题：代码审查中的宝贵经验往往散落在各个 PR 的评论里，过几个月就找不到了。

现在这些经验被自动沉淀到 CLAUDE.md 里，变成了可执行的规则。下次 Claude 写类似代码时，它会自动记得加 timeout。

这就像把代码审查变成了一个持续的"AI 训练过程"。每次审查都在让 AI 变得更懂你们团队的要求。

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

具体做法：

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

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

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

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

为什么这么做：

很多人用 AI 的方式是：

请帮我实现用户登录功能。

然后 Claude 就开始写代码了。写了半天，你一看，发现它用的技术方案跟你想的不一样，或者它理解的需求有偏差。这时候要么让它全部重写，要么你自己改，都很浪费时间。

Boris 的方式是：

我想实现用户登录功能，支持邮箱和手机号两种方式。

Claude 回复：

好的，我计划这样做：
1. 在后端添加 /api/login 接口
2. 支持 email 和 phone 两个字段
3. 验证格式后查数据库
4. 返回 JWT token
5. 前端用 localStorage 存储 token

请问这个方案可以吗？

你看了说：

手机号需要先发验证码验证，不是直接查数据库。另外 token 建议用 httpOnly cookie 而不是 localStorage，更安全。

Claude 调整计划：

明白了，新方案：
1. 添加 /api/send-code 接口发送验证码
2. 手机号登录时先验证验证码
3. 用 httpOnly cookie 存储 token
...

这样可以吗？

你确认后，Claude 才开始写代码。这时候它知道了所有细节，往往能一次做对。

Boris 强调：一个好的计划真的很重要。花 3 分钟确认计划，能省下 30 分钟的返工时间。

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

具体做法：

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

他举的例子是 /commit-push-pr 命令。这个命令的功能是：

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

他每天要用这个命令几十次。

命令是怎么写的：

斜杠命令本质上是一个包含了 bash 脚本和提示词的文件。比如：

#!/bin/bash

# 获取 git 状态
git_status=$(git status --short)
git_diff=$(git diff --cached)

# 调用 Claude
echo "请根据以下改动生成 commit message，然后提交代码并创建 PR：

Git 状态：
$git_status

代码变更：
$git_diff

要求：
1. commit message 遵循 Conventional Commits
2. PR 标题简洁明了
3. PR 描述包含改动原因和测试方法
"

为什么这么做：

想象你每天要做同样的操作 20 次，每次都要重新输入提示词，很容易遗漏细节，也很浪费时间。

斜杠命令把这个流程固化下来，你只需要输入 /commit-push-pr，剩下的全自动。而且因为命令被提交到 Git，整个团队都能用，新人也能立刻上手。

Boris 还提到，他会在命令里用 bash 预计算一些信息（比如 git 状态），这样 Claude 不需要反复调用工具查询，执行速度更快。

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

具体做法：

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

比如：

  • code-simplifier：在 Claude 完成代码后，专门负责简化和优化代码
  • verify-app：包含详细的测试指令，负责端到端测试应用
  • 其他专门处理文档、性能分析等任务的子代理

子代理和斜杠命令的区别：

斜杠命令适合固定步骤的操作，比如提交代码、运行测试。

子代理适合需要判断和决策的任务，比如：

  • 看到一段代码，判断哪里可以简化
  • 测试一个应用，发现哪些功能有问题
  • 审查文档，找出不清楚的地方

为什么需要子代理：

当任务比较复杂时，把所有指令都塞进一个会话里，Claude 容易分心或遗漏细节。

用子代理相当于把大任务拆分成专门的小任务。每个子代理只需要专注做好一件事，指令可以写得非常详细和精确。

比如 verify-app 子代理的指令可能包含：

请按以下步骤测试应用：
1. 打开浏览器访问 localhost:3000
2. 测试用户注册流程，确认能收到验证邮件
3. 测试登录功能，包括错误密码的情况
4. 测试主要功能的每个按钮
5. 查看控制台，确认没有错误
6. 总结发现的所有问题，按严重程度排序

这种详细的指令，如果写在主会话里会显得很乱，但做成子代理就很清晰。

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

具体做法：

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

比如：

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

为什么这么做：

Claude 生成的代码通常逻辑正确，但格式可能不完全符合团队规范（缩进、空格、换行等）。

如果不处理，这些格式问题会在 CI（持续集成）环节报错，你还得回来修。

用钩子自动格式化，就相当于在 Claude 工作时给它配了一个"助理"，专门负责收尾工作。Claude 专注写逻辑，格式化由钩子搞定。

这个思路可以推广：

钩子机制可以用来自动化很多"善后工作"：

  • 代码写完后自动跑 linter 检查
  • 文件修改后自动更新相关的文档
  • 测试文件创建后自动添加到测试套件

只要是"每次都要做的固定操作"，都可以用钩子自动化。

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

具体做法：

Claude Code 默认会在执行敏感操作时询问你的许可。比如：

  • 要删除文件
  • 要运行 shell 命令
  • 要访问网络

Boris 不用 --dangerously-skip-permissions（跳过所有权限检查），因为那太危险。

他的做法是用 /permissions 命令预先允许一些已知安全的常用命令。

比如他会预先允许：

git status
git diff
npm test
docker ps
ls
cat

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

为什么这么做：

如果每个 git status 都要你确认一次，很烦人，也打断工作流程。

但如果完全跳过权限检查，Claude 可能会不小心运行危险命令（比如 rm -rf）。

预设权限是一个平衡：常用的安全命令自动放行，危险的或不常见的命令还是要确认。

怎么判断哪些命令可以预设：

Boris 的原则是：

  • 只读操作（查看状态、读文件）→ 预设允许
  • 可逆操作（git commit 可以 revert）→ 预设允许
  • 不可逆操作（删除、覆盖）→ 每次确认
  • 涉及外部系统（发邮件、调 API）→ 每次确认

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

具体做法：

Boris 给 Claude 配置了大量 MCP 服务器（Model Context Protocol，让 AI 能调用外部服务的协议）。

Claude 现在可以：

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

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

实际使用场景：

比如 Boris 会说：

我们的用户反馈说昨天晚上有个功能出错了，帮我查一下。

Claude 会自动：

  1. 去 Sentry 查看昨晚的错误日志
  2. 分析是哪个接口报错
  3. 查看相关代码找到可能的原因
  4. 在 Slack 搜索看有没有其他人也遇到
  5. 给出诊断结果和修复建议

整个过程你不需要手动切换工具，Claude 自己搞定。

为什么这么做：

程序员的工作不只是写代码，还要查日志、看数据、和团队沟通。如果这些都要手动做，很浪费时间。

让 Claude 能调用所有工具，相当于给了它"手"和"眼睛"，它可以自己去获取信息，而不是等你喂给它。

配置的关键：

Boris 强调，把常用的 MCP 配置写进 .mcp.json 并提交到 Git，这样整个团队都能用，新人也不需要自己配置。

这又是一个"团队知识积累"的例子：第一个人配好了，后面所有人都能享受。

方法 12：长任务用后台代理或插件

具体做法：

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

策略 A：让 Claude 用后台代理验证

在任务快完成时，提示 Claude：

任务完成后，请启动一个后台代理验证你的工作，确保所有测试都通过，功能正常。

策略 B：用代理停止钩子自动验证

设置一个钩子，在 Claude 任务结束时自动触发验证流程。这比策略 A 更可靠，因为不需要你记得提醒 Claude。

策略 C：用 ralph-wiggum 插件

这是一个专门的插件，可以让 Claude 在完成任务后自动运行一系列检查，并把结果报告给你。

配合无权限提示模式：

在沙箱环境里，Boris 会用 --permission-mode=dontAsk 或 --dangerously-skip-permissions，这样 Claude 可以不受阻碍地完成整个长任务，不会因为某个权限确认卡住。

为什么需要这个：

想象你让 Claude 做一个需要 1 小时的大任务，比如重构整个模块。你不可能盯着屏幕 1 小时，随时准备点"允许"。

用后台代理或插件，相当于你去忙别的事，等回来时 Claude 已经干完了，而且自己检查过没问题了。

安全性考虑：

Boris 强调，只在沙箱环境（不影响生产代码的隔离环境）里跳过权限检查。在正式项目里还是要谨慎。

方法 13：给 Claude 验证工作的途径

具体做法：

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

他举的例子是：Claude 每次给 claude.ai/code 网站提交代码后，都会：

  1. 用 Claude Chrome 扩展打开浏览器
  2. 测试 UI 的各个功能
  3. 检查用户体验是否流畅
  4. 如果发现问题，自己修改代码再测试
  5. 直到所有功能正常才算完成

不同领域的验证方式：

Boris 说，验证方法因任务而异：

  • 后端代码：运行测试套件
  • 前端页面：在浏览器里测试
  • 移动应用：在模拟器里测试
  • 数据分析：检查数字是否合理
  • 文档：检查链接是否有效、格式是否正确

为什么这条最重要：

没有反馈循环的 AI 就像闭着眼睛干活的人，它不知道自己做得对不对，只能等你告诉它。

有了反馈循环，AI 可以自己检查、自己纠错、自己迭代，最终结果的质量能提升 2 到 3 倍。

你需要做的投资：

Boris 强调：确保验证过程"坚如磐石"。

这意味着：

  • 测试环境要稳定，不能时好时坏
  • 测试脚本要可靠，不能误报
  • 验证标准要明确，不能模糊

这些是一次性投资，做好了之后，每次 Claude 都能用它来自我验证。

总结：这 13 条方法的共同逻辑

看完这 13 条，你会发现它们围绕着几个核心思想：

  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）

这些方法不是随便想出来的，是 Boris 和他的团队在实际工作中不断试错总结出来的。

你不需要一次全部用上，可以先从最适合你的几条开始，慢慢建立自己的 AI 工作流。

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

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