高效使用 Claude Code 的 10 条核心技巧「Boris Cherny」

01 Feb, 2026

来源：Boris Cherny推文
日期：2026年2月1日

Claude Code 创始人 Boris Cherny 分享的关于高效使用 Claude Code 的 10 条核心技巧摘要：

1. 并行处理更多任务 (Do more in parallel)

核心建议：同时启动 3-5 个 git worktrees，每个运行独立的 Claude 会话。这是提升生产力的最大关键。
具体做法：使用原生支持 worktree 的 Claude Desktop，或者设置 Shell 别名（如 za, zb）快速切换。建议设立一个专门用于查看日志或运行 BigQuery 的“分析用” worktree。

2. 复杂任务先进入“计划模式” (Start in plan mode)

核心建议：在计划阶段投入主要精力，争取让 Claude 一次性完成实现。
具体做法：可以让一个 Claude 制定计划，启动第二个 Claude（作为 Staff Engineer 角色）来审查计划。一旦执行过程不顺，立即切回计划模式重新规划，不要强行推进。

3. 投资你的 CLAUDE.md

核心建议：利用 CLAUDE.md 建立规则库。
具体做法：每次纠正 Claude 后，要求它：“更新 CLAUDE.md，以免下次再犯同样的错误。” 持续迭代直到错误率下降。可以建立专门的笔记目录，并让 CLAUDE.md 指向它。

4. 创建并提交自定义技能 (Skills)

核心建议：将重复性操作转化为技能或命令，并提交到 Git 供全项目复用。
具体做法：
- 构建 /techdebt 命令，每次会话结束时运行以清理重复代码。
- 设置命令同步 Slack、GDrive、Asana 和 GitHub 最近 7 天的上下文。
- 构建类似“分析工程师”的 Agent 来编写 dbt 模型、审查代码并测试变更。

5. 让 Claude 自行修复 Bug

核心建议：不要微观管理，直接给出错误源。
具体做法：
- 启用 Slack MCP，粘贴 Bug 讨论串并直接说“修复它”。
- 直接指令“去修复失败的 CI 测试”。
- 让 Claude 分析 Docker 日志来排查分布式系统问题。

6. 提升提示词技巧 (Level up your prompting)

a. 挑战它：让 Claude 充当审查者（“以此盘问我，直到通过才提交 PR”）或要求它证明代码有效（“对比主分支和特性分支的行为”）。
b. 追求完美：如果修复方案平庸，指令它“利用你现在知道的一切，废弃旧方案，实现优雅的解决方案”。
c. 详细规范：移交工作前编写详细规格文档，减少歧义。

7. 终端与环境设置

工具推荐：使用 Ghostty 终端（渲染同步、真彩色支持好）。
状态栏：使用 /statusline 自定义状态栏，常驻显示上下文使用量和当前 Git 分支。
语音输入：使用语音听写（Mac 上双击 fn），语速快 3 倍且能提供更详细的提示词。

8. 使用子代理 (Subagents)

核心建议：利用子代理分担算力和任务。
具体做法：
- 在请求后附加“use subagents”以投入更多算力。
- 将独立任务分流给子代理，保持主代理上下文整洁。
- 通过 Hook 将权限请求路由给 Opus 4.5 模型，自动扫描并批准安全请求。

9. 利用 Claude 进行数据分析

核心建议：直接在 Claude Code 中运行数据库 CLI。
具体做法：让 Claude 调用 BigQuery CLI (bq) 实时拉取并分析指标，无需手写 SQL。这适用于任何拥有 CLI、MCP 或 API 的数据库。

10. 用 Claude 辅助学习

配置：在 /config 中启用“解释性 (Explanatory)”或“学习 (Learning)”输出风格，让它解释代码背后的原因。
可视化：让 Claude 生成 HTML 演示文稿解释陌生代码，或绘制 ASCII 架构图。
辅助记忆：构建间隔重复学习技能（你解释理解，Claude 追问填补空白）。

原推文翻译

我是 Boris，Claude Code 的作者。想快速分享一些来自 Claude Code 团队的一手使用技巧。团队使用 Claude 的方式跟我不同。记住：使用 Claude Code 没有所谓的“唯一正确姿势”——每个人的设置都不一样。你应该多尝试，找到适合你的方式！

1. 并行处理更多任务 同时启动 3-5 个 git worktree，每个都在并行运行独立的 Claude 会话。这是提升生产力最大的单一解锁方式，也是团队的首选技巧。我个人习惯用多个 git checkout，但大多数 Claude Code 团队成员更喜欢 worktree——这也是 @amorriscode 在 Claude Desktop 应用里为它们构建原生支持的原因！有些人还会给 worktree 命名并设置 shell 别名（za, zb, zc），这样就能一键跳转。还有人会专门搞一个“分析”用的 worktree，只用来读日志和跑 BigQuery。

2. 任何复杂的任务都先从“计划模式（plan mode）”开始 把精力全投入在计划上，这样 Claude 就能一次性搞定实现（1-shot）。有人会让一个 Claude 写计划，然后启动第二个 Claude 扮演 Staff Engineer 来审查它。还有人说，一旦事情开始跑偏，就切回计划模式重新规划。别硬撑。他们还会明确告诉 Claude 进入计划模式来做验证步骤，而不仅仅是为了构建代码。

3. 投资你的 CLAUDE.md 每次纠正后，都在最后加上一句：“更新你的 CLAUDE.md，别再犯同样的错。” Claude 极其擅长给自己写规则。要随着时间推移无情地编辑你的 CLAUDE.md。不断迭代，直到 Claude 的错误率肉眼可见地下降。有位工程师让 Claude 为每个任务/项目维护一个笔记目录，并在每次 PR 后更新。然后他们让 CLAUDE.md 指向这个目录。

4. 创建你自己的技能（skills）并提交到 git 在所有项目中复用。团队的建议：

如果你一天做某件事超过一次，就把它变成技能或命令。
构建一个 /techdebt 斜杠命令，在每次会话结束时运行，用来查找并消灭重复代码。
设置一个斜杠命令，把最近 7 天的 Slack、GDrive、Asana 和 GitHub 内容同步成一个上下文转储。
构建类似分析工程师风格的 agent，用来写 dbt 模型、审查代码并在开发环境中测试变更。

5. Claude 能自己修好大部分 Bug 我们是这么做的：启用 Slack MCP，把 Slack 上的 Bug 讨论串粘贴进 Claude，直接说“修复它（fix）”。零上下文切换。或者，直接说“去把失败的 CI 测试修好”。别微观管理它怎么做。把 Claude 指向 docker 日志来排查分布式系统的问题——它在这方面能力惊人。

6. 提升你的提示词水平（Prompting） a. 挑战 Claude。说“针对这些变更狠狠盘问我，直到我通过你的测试再提 PR。” 让 Claude 做你的审查员。或者说“给我证明这能跑通”，让 Claude 对比主分支和你功能分支的行为差异。 b. 如果修复得很平庸，就说：“利用你现在知道的一切，废掉这个，实现那个优雅的解决方案。” c. 在移交工作前写下详细的规格文档并减少歧义。你越具体，产出越好。

7. 终端与环境设置 团队超爱 Ghostty！好多人喜欢它的同步渲染、24位色彩和完美的 unicode 支持。为了更轻松地玩转 Claude，用 /statusline 自定义你的状态栏，让它常驻显示上下文用量和当前的 git 分支。我们许多人还会对终端标签页进行颜色编码和命名，有时配合 tmux 使用——每个标签页对应一个任务/worktree。使用语音听写。你说话比打字快 3 倍，结果就是你的提示词会变得详细得多。（macOS 上连按两下 fn 键）。

8. 使用子代理（subagents） a. 在任何你想让 Claude 投入更多算力的问题后面加上“使用子代理（use subagents）”。 b. 把独立任务分流给子代理，让你主 agent 的上下文窗口保持干净专注。 c. 通过 hook 把权限请求路由给 Opus 4.5——让它扫描攻击行为并自动批准那些安全的请求。

9. 用 Claude 做数据和分析 让 Claude Code 使用 "bq" CLI 随时拉取和分析指标。我们在代码库里检入了一个 BigQuery 技能，团队里每个人都直接在 Claude Code 里用它做分析查询。就我个人而言，我已经 6 个多月没写过一行 SQL 了。这招适用于任何有 CLI、MCP 或 API 的数据库。

10. 跟 Claude 一起学习 团队里用 Claude Code 学习的几个技巧： a. 在 /config 里启用“解释性（Explanatory）”或“学习（Learning）”输出风格，让 Claude 解释变更背后的原因。 b. 让 Claude 生成可视化的 HTML 演示文稿来解释不熟悉的代码。做出来的幻灯片好得惊人！ c. 让 Claude 画出新协议和代码库的 ASCII 图表，帮你理解它们。 d. 构建一个间隔重复学习技能：你解释你的理解，Claude 追问来填补认知空白，并存储结果。

希望这些技巧对你有帮助！接下来你们想听关于什么的？