我亲自总结了 Claude Code 的 30 个操作技巧，其创始人 Boris Cherny 表示这些技巧至关重要。这真是一篇传奇文章。
说实话，知道和不知道这些技巧，你的 Claude Code 体验会天差地别。你会意识到，那些重复相同指令或浪费数小时返工的时间，完全是没必要的。
顺便问一下，你在使用 Claude Code 时是否遇到过这些问题？
- 感觉每次都要重复相同的指令，希望它能自己学会。
- 大改动导致不断返工，让你觉得还不如自己动手改更快。
- 功能太多，不知道从何入手。
- 对话变得冗长且不连贯，出现“等等，我不是刚说过吗？”的情况。
当你正确设置上下文、验证、权限、并行设计和自动化时，Claude Code 的体验会发生巨大变化。
本文由 ClaudeCodeStudio 独立研究和撰写，优先采用截至 2026 年 4 月 23 日的一手信息，包括 Boris Cherny 的 X 帖子、Anthropic 官方文档以及官方 GitHub 仓库/操作！
既然 Boris 明确说过“我创造了 Claude Code”，我优先采纳他的操作建议作为一线声音，同时交叉参考 CLI 选项和官方文档中的设置！😆
如果你使用 Claude Code，绝对要读这篇文章！！！
必须收藏！！！！
它真的能让你的生产力提升 10 倍！我们开始吧！👇
■ 首先要掌握的三个原则
让 Claude Code 在实践中变得强大的最大因素归结为三点。
在 Plan 模式中分离“调查”和“实施”。让 Claude 自我验证。以及考虑并行会话。
Boris 反复强调：“几乎总是使用 Plan 模式”，“给 Claude 一种验证其输出的方法”，以及“3–5 个 git worktrees”。
■ “没有唯一正确答案”的理念
阅读 Boris 的帖子，一个反复出现的立场是：使用 Claude Code 没有唯一正确的方法，而应将其视为高度可定制的操作工具。他本人也重复说：“使用 Claude Code 没有唯一正确的方法。”
基于这个前提，这是他建议的最有效工作流程 👇
在 Plan 模式中调查/规划
↓ 实施会话
↓ 通过测试、截图和 CLI 进行自我验证
↓ 创建 PR
↓ 代码审查 / Ultrareview
↓ 将经验反馈到 CLAUDE.md、Hooks 和 Skills
带着这个流程，我们来看 30 个具体技巧。
■ 30 个操作技巧
这些按实际效果排序。来自 Boris X 帖子的技巧侧重于方向，而设置和约束的细节则由官方文档和 GitHub 补充。研究预览功能已明确标注。
■ 技巧 1：先在 Plan 模式中隔离大改动
仅仅将调查、规划和实施分开，就能大幅减少错误实施和返工。这很简单，但这就是 Boris 说“几乎总是使用 Plan 模式”的原因。
示例：“在 Plan 模式中读取 src/auth 和 secrets。在开始实施前，整理 Google OAuth 的受影响文件、数据流和测试视角。”
没有 Plan 模式就贸然进行大改动，常常会导致上下文丢失或中途修正。先让它把握全局，确实能提高实施准确性。
■ 技巧 2：让 Claude 自我验证
Boris 称这是“单一最高杠杆的事情”。让 Claude 运行测试、检查截图、并自行验证 CLI 输出。
“修复后，运行 npm test，只有所有测试通过才算完成。”
仅此一项，就能让 Claude 在人类审查之前发现并修复问题。如果验证命令太重，可以从最小的冒烟测试开始。
■ 技巧 3：并行运行 3–5 个 Git Worktrees
Boris 称并行 worktree 操作为“最重要的生产力提升”。
通过添加多个 worktrees，如 git worktree add ../repo-auth -b feat/auth，并在每个 worktree 中启动 Claude，等待时间降为零，独立任务可以同时推进。
最佳数量取决于你的环境。3–5 是一个指导，但根据审查带宽、CPU 和你自己的上下文切换成本，有些人可能 2 个就合适，而有些人可以处理 6 个。
■ 技巧 4：无情地编辑 CLAUDE.md
CLAUDE.md 是你项目的特定规则手册。如果放任不管，它会过时，Claude 会基于错误的前提行动。
Boris 的策略很简单：“随着时间的推移无情地编辑你的 CLAUDE.md”，并且“当 Claude 第二次犯同样的错误时，就添加进去。”
相反，删除不再需要的规则。如果它变得过于臃肿，会占用上下文，所以定期修剪至关重要。
■ 技巧 5：将日常重复任务转化为 Skills 并提交到 Git
每次在对话中解释重复流程是浪费时间。创建 .claude/skills/deploy/SKILL.md，并通过 /deploy staging 调用它。
Boris 说：“如果你一天做某件事超过一次，就把它变成 skill 或命令”，并补充说“它几乎不花成本，直到你需要它。”
但是，如果 Skill 变得过于臃肿，其触发条件可能变得模糊，所以拆分较长的参考资料。
■ 技巧 6：将团队设置放在 settings.json 中并通过 Git 管理
对项目特定设置进行版本控制，确保整个团队拥有相同的 Claude Code 体验。它加速了入职，并防止设置依赖于单个人。
显然，永远不要提交个人 API 密钥或令牌。别忘了检查你的 .gitignore。
■ 技巧 7：预先批准安全权限，拒绝危险区域
每次都被问“你允许这个操作吗？”是不是很烦？使用 allow/ask/deny 可以消除这种对话框疲劳。
"allow": ["Bash(npm test *)"], "ask": ["Bash(git push *)"], "deny": ["Read(./.env)", "Read(./secrets/**)"]
Boris 说“预先批准常见权限”，官方文档指定“规则按顺序评估：deny… ask… allow”。原则是明确拒绝 .env 或 secrets，以避免过于宽泛的通配符。
■ 技巧 8：使用 --add-dir 跨越多个文件夹/仓库
很多时候你想展示单仓库之外的文档或库。
CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1 claude --add-dir ../docs --add-dir ../shared-libs
这允许在引用外部文档的同时进行编码。注意，必须启用环境变量才能读取添加目录中的 CLAUDE.md。
■ 技巧 9：通过子 Agent 进行角色分工
将调查、审查和调试全部塞进主上下文会使对话混乱。Boris 说：“我定期使用几个子 Agent”，每个子 Agent 在自己的专用上下文窗口中运行。
准备子 Agent，如 code-reviewer、debugger 或 data-scientist，并为它们编写清晰的描述。
■ 技巧 10：使用 PostToolUse Hooks 自动化格式化/检查
每次 Claude 编辑文件时自动运行格式化工具或 linter。
让 Claude：“编写一个 hook，在每次文件编辑后运行 prettier --write。”
它会处理从生成 hook 到将其集成到 .claude/settings.json 的所有事情。这自动化了代码风格一致性，并消除了审查中的风格评论。
■ 技巧 11：通过 PR 评论更新 CLAUDE.md
在 PR 中随着代码一起更改“未来规则”。Boris 说：“在我同事的 PR 上标记 @.claude，以向 CLAUDE.md 添加内容。”
例如，评论：“@claude 将此经验添加到 CLAUDE.md。始终从 Plan 模式开始更改 src/billing。”这减少了未来重复的反馈。
■ 技巧 12：通过状态行始终了解当前状态
屏幕底部显示的信息让你一目了然地看到“你在哪个分支上做什么，使用了多少上下文，以及成本”。
/statusline show model name, git branch, context percentage, cost
从分支、上下文百分比和成本开始，通常足以及早发现上下文耗尽或分支错误。
■ 技巧 13：使用 Chrome 扩展加速前端工作
Boris 推荐：“在前端工作中使用 Chrome 扩展。”由于它可以共享浏览器登录状态，你可以让 Claude 进行截图比较以进行 UI 验证。
Claude 检测到代码中不可见的 UI 损坏是一个巨大的优势。但是，由于截图无法衡量可访问性或感知速度，根据需要结合使用 Lighthouse 或 e2e 测试。
■ 技巧 14：让 Claude 通过 CLI 处理分析任务
让 Claude 使用 SQL 或 CLI 将开发、分析和策略整合到同一个工作区。
“使用 bq CLI 拉取过去 7 天按渠道划分的转化指标，总结异常，并提出假设。”
正如 Boris 所说，“使用 Claude 进行数据分析”，这个技巧不仅对开发者有效，对产品经理也同样有效。
■ 技巧 15：如果规格模糊，让 Claude 采访你
官方文档有一个部分：“让 Claude 采访你。”与其直接开始实施，不如让 Claude 提问以挖掘需求。
在实施前填补规格空白能大幅减少返工，尤其是在“要构建什么”不明确的情况下。
■ 技巧 16：区分 CLAUDE.md 和自动记忆的角色
人类在 CLAUDE.md 中编写规则。Claude 在自动记忆中记住发现的偏好和习惯。保持这种区分可以防止设置变得混乱。
■ 技巧 17：设计时考虑路径特定规则和压缩
在单仓库中，将“全局规则”与“局部规则”分开。将全局约定放在根目录的 CLAUDE.md 中，局部规则放在 src/billing 等目录中。
■ 技巧 18：积极管理上下文
官方文档明确说明：“积极管理上下文。”将重要的操作知识提升到 CLAUDE.md 或 skills 中，并定期使用 /compact 组织上下文窗口。
■ 技巧 19：使用 /rewind 和检查点尝试“可怕的变化”
Claude Code 中的每个操作都是一个检查点。按两次 Esc 或使用 /rewind 通过代码、对话或两者返回到消息检查点。
■ 技巧 20：通过 MCP 服务器连接外部工具
直接从 Claude Code 操作 Slack、Jira、数据库或内部 API，大幅减少工具切换。
■ 技巧 21：使用非交互模式 (claude -p) 集成到脚本/CI 中
非交互模式是 Claude Code 自动化的入口。
claude -p "列出所有 API 端点" --output-format json
■ 技巧 22：使用 claude -p 按文件扇出大型迁移
在一个会话中处理大规模迁移是不可能的。最好水平分布。
■ 技巧 23：直接从问题管理工具实施
让 Claude 读取 GitHub Issues 或 Linear 工单，直接进入实施。
■ 技巧 24：使用 Hooks 强制执行规则
CLAUDE.md 是“建议”，hooks 是“执行”。不要混淆两者。使用 hooks 处理“零例外”情况，以确保操作发生。
■ 技巧 25：使用 /simplify 进行并行代码审查
三个审查 Agent 同时检查冗余、质量和效率，甚至执行修复。
■ 技巧 26：在 GitHub Actions 中使用 @claude 提及
使用官方的 claude-code-action，只需在 PR 或 Issue 中提及 @claude，即可实现代码更改或获得答案。
■ 技巧 27：区分代码审查和 Ultrareview
常规审查和深度审查不同。日常使用 Code Review，在合并前使用 /ultrareview 进行深度审查。
■ 技巧 28：将重复操作转化为 Routines
将每周维护或与 PR 相关的任务移至云端。“当你的笔记本电脑合上时，继续工作。”
■ 技巧 29：将繁重规划卸载到云端的 Ultraplan
无需在终端等待，而是在浏览器中逐章审查计划。
■ 技巧 30：使用远程控制控制云会话
一种从本地机器控制云端 Claude Code 会话的功能。
■ 尚未确定的操作要点
我也诚实地指出一些方向明确但最佳实践尚未建立的领域，例如 Chrome 扩展与 e2e 测试的结合，或使用 Stop hooks 进行长期“连续数天”的操作。
■ 从哪里开始
对于开发者，从技巧 1、2、4、7、9 和 18 开始。对于产品经理，技巧 14、15、23、27 和 28 最有效。
■ 每周检查清单
- 是否指出了同一个错误两次？→ 添加到 CLAUDE.md。
- 是否有任何重复任务适合 skills/hooks？→ 自动化它们。
- 上下文使用是否过高？→ 检查
/compact习惯。 - worktrees 数量是否合适？→ 根据带宽调整。
■ 结论
掌握 Claude Code 的关键是按顺序巩固操作组件：规划 → 验证 → 持久化 → 自动化。你不需要一开始就全部掌握。仅技巧 1、2 和 4 就能从根本上改变你的开发体验。
另外，我已经开启了一个开放聊天！
你可以在这里加入 👇
我会在那里分享有用信息并举办免费研讨会，请加入！😆
𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲 𝗦𝘁𝘂𝗱𝗶𝗼 @ 𝗝𝗮𝗽𝗮𝗻 (@ClaudeCode_love) 由三位 Claude Code 爱好者运营。我们每天发布关于实际 CLI 使用和自动化的内容。关注我们，获取真实产品开发示例和最新全球信息！👀
