CC 使用技巧

1. 并行处理更多任务

同时启动 3–5 个 Git worktree，每个 worktree 运行自己的 Claude 会话。这是最大的生产力提升，也是团队的首要建议。我个人使用多个 Git checkout，但 Claude Code 团队大多数人更喜欢 worktree——这也是 @amorriscode 在 Claude Desktop 应用中内置对 worktree 支持的原因！

有些人会为 worktree 命名，并设置 shell 别名（如 za、zb、zc），这样可以一键切换。还有人有一个专用的“分析”worktree，只用于阅读日志和运行 BigQuery。

2. 每个复杂任务从规划模式开始

将精力投入到规划中，这样 Claude 可以一次性完成实现。

有人让一个 Claude 编写计划，然后启动第二个 Claude 以资深工程师的身份审查它。

另一个人说，一旦事情偏离轨道，就切换回规划模式并重新规划。不要继续推进。他们还明确告诉 Claude 在验证步骤中进入规划模式，而不仅仅是构建。

3. 重视claude.md

每次更正后，以“更新你的文档，这样你不会再犯同样的错误”结束。Claude 在为自己编写规则方面异常出色。

随着时间推移，无情地编辑你的文档。不断迭代，直到 Claude 的错误率明显下降。

一位工程师告诉 Claude 为每个任务/项目维护一个笔记目录，并在每个 PR 后更新。然后将它指向文档。

4. 创建自己的技能并提交到 Git

在每个项目中重复使用。

团队的提示： - 如果你一天做某事超过一次，就把它变成一个技能或命令。 - 构建一个 /techdebt 斜杠命令，并在每个会话结束时运行它，以查找和删除重复代码。 - 设置一个斜杠命令，将 7 天的 Slack、GDrive、Asana 和 GitHub 同步到一个上下文转储中。 - 构建像分析工程师那样的代理：编写 dbt 模型、审查代码，并在开发环境中测试更改。

5. Claude 可以自己修复大多数 bug

方法： 启用 Slack MCP，然后将 Slack bug 线程粘贴到 Claude 中，只说“修复”。无需上下文切换。

或者，只说“去修复失败的 CI 测试”。不要微观管理如何做。

将 Claude 指向 Docker 日志来排查分布式系统问题——它在这方面出奇地强大。

6. 提升你的提示技巧

a. 挑战 Claude。说“审视这些更改，在我通过你的测试前不要创建 PR。”让 Claude 成为你的审查者。或者，说“向我证明这有效”，让 Claude 比较 main 分支和你的功能分支之间的行为差异。

b. 在一个平庸的修复后，说：“知道你现在知道的一切，废弃这个，实现优雅的解决方案。”

c. 在移交工作前编写详细规范并减少歧义。你越具体，输出越好。

7. 终端和环境设置

团队喜欢 Ghostty！多人喜欢它的同步渲染、24 位颜色和正确的 Unicode 支持。

为了更容易管理 Claude，使用 /statusline 自定义状态栏，始终显示上下文使用情况和当前 Git 分支。我们很多人还为终端标签着色和命名，有时使用 tmux——每个任务/worktree 一个标签。

使用语音听写。你说话的速度是打字的 3 倍，你的提示因此会更详细。（在 macOS 上，按 fn 两次）

更多提示：

8. 使用子代理

a. 在任何你想让 Claude 投入更多计算的请求中，附加“使用子代理”。

b. 将单个任务分配给子代理，以保持主代理的上下文窗口干净和专注。

c. 通过钩子将权限请求路由到 Opus 4.5——让它扫描攻击并自动批准安全的请求

9. 使用 Claude 进行数据和分析

让 Claude Code 使用“bq”CLI 即时拉取和分析指标。我们有一个 BigQuery 技能检查到代码库中，团队中的每个人都直接在 Claude Code 中使用它进行分析查询。我个人已经 6 个月多没写一行 SQL 了。

这适用于任何有 CLI、MCP 或 API 的数据库。

10. 与 Claude 一起学习

团队的一些使用 Claude Code 学习的提示：

a. 在 /config 中启用“解释性”或“学习”输出风格，让 Claude 解释其更改背后的为什么。

b. 让 Claude 生成一个视觉 HTML 演示文稿来解释不熟悉的代码。它能做出惊人好的幻灯片！

c. 让 Claude 绘制新协议和代码库的 ASCII 图表，以帮助你理解它们。

d. 构建一个间隔重复学习技能：你解释你的理解，Claude 问后续问题来填补空白，并存储结果。