CC之父曝内部团队使用Claude Code的10条技巧！同时启动3-5个工作树，重度投入CLAUDE.md文件；网友：工作流很管用，但钱包有点痛

公众号名称：51CTO技术栈

作者名称：听雨

发布时间：2026-02-02 11:27

编辑 | 听雨

CC之父又出来总结了10条Claude Code技巧！

不过这次，内容直接来自Claude Code内部团队。

Boris Cherny强调，团队成员使用 Claude 的方式与他本人有所不同，并且不存在唯一正确的使用方法——每个人的设置都各不相同。

你应该亲自试验，找到最适合自己的工作流。

以下是小编整理的Boris分享的十大 Claude Code 使用技巧：

Claude Code团队的十大技巧

1、 并行做更多事情
同时启动 3–5 个 git worktree，每个 worktree 里各自运行一个 Claude 会话。这是提升生产力最大的一个杠杆，也是团队给出的头号建议。
Boris 透露，他个人用的是多个 git checkout，但 Claude Code 团队里的大多数人更偏爱 worktree —— 这也是为什么Anthony Morris（CC团队的一名成员）会在 Claude Desktop 应用里为它们做原生支持。
有些人会给 worktree 命名，并设置 shell 别名（比如 za、zb、zc），这样就能一键在不同 worktree 之间切换。还有人会专门留一个“analysis”用的 worktree，只用来读日志、跑 BigQuery。

2、用“计划模式”启动所有复杂任务
把精力都投入到“计划”阶段，这样 Claude 才有可能一次性（1-shot）完成实现。

团队中有一个人的工作流是：先让一个 Claude 写计划，然后再启动第二个 Claude，站在 staff engineer 的视角来做评审。

另一位成员则表示，只要事情一开始跑偏，就立刻切回 plan mode，重新规划，不要硬推。他们还会明确要求 Claude 在验证步骤中进入 plan mode，而不仅仅是在构建阶段。

3、重度投入到你的 CLAUDE.md
每次纠错之后，都以这句话结尾：“更新你的 CLAUDE.md，这样你下次就不会再犯这个错误。”
Claude 在给自己写规则这件事上，表现得异常好。

要对 CLAUDE.md 进行毫不留情的编辑和精炼。不断迭代，直到你能可量化地看到 Claude 的错误率明显下降。

有位工程师会让 Claude 为每个任务 / 项目维护一个 notes 目录，每次 PR 之后都会更新，然后在 CLAUDE.md 里指向这个目录。

4、创建自己的“技能”并提交到 Git

来自团队的一些建议：

如果一件事你每天要做不止一次，就把它做成一个 skill 或命令
构建一个 /techdebt 的斜杠命令，在每次会话结束时运行，用来找出并清理重复代码
设置一个斜杠命令，把最近 7 天 的 Slack、GDrive、Asana、GitHub 同步成一个统一的上下文 dump
构建“分析工程师风格”的 agent：自动写 dbt model、做代码审查、并在 dev 环境里测试改动

5、让Claude 自行修复大多数 bug

团队是这样用的：

启用 Slack MCP，然后把 Slack 里的 bug 讨论串直接粘给 Claude，只说一句 “fix” 就行了，完全不需要在不同工具之间来回切换。

或者，直接告诉它：“去把失败的 CI 测试修好。” 不要事无巨细地教它怎么做。

把 docker 日志 指给 Claude，让它排查分布式系统的问题——在这方面它的能力出乎意料地强。

6、提升你的提示词水平

a. 主动挑战 Claude。
比如对它说：“就这些改动狠狠拷问我，在我通过你的测试之前不要提 PR。” 把 Claude 当成你的 reviewer。
或者说：“向我证明这东西是可行的。” 让 Claude 对比 main 和你的 feature branch 的行为差异。

b. 对一个平庸的修复方案，可以这样说：
“在你已经知道所有这些信息的前提下，把这个方案推倒重来，实现一个更优雅的解法。”

c. 在交付工作前，先写清晰、详细的规格说明，尽量消除歧义。
你给得越具体，产出的质量就越高。

7、终端与环境配置

团队里很多人都很喜欢 Ghostty，不少人特别看重它的同步渲染、24 位真彩色以及完善的 Unicode 支持。

为了更方便地同时“调度”多个 Claude，可以用 /statusline 自定义状态栏，让它始终显示上下文使用情况和当前 git 分支。团队中还有不少人会给终端标签页做颜色区分、命名，有时会配合 tmux 使用——一个任务 / 一个 worktree 一个标签页。

多用语音输入。你说话的速度大约是打字的 3 倍，而且因此写出来的 prompt 往往更详细（macOS 上按两次 fn 即可）。