- 原文
- 简短而清晰，很多技巧都非常有用，强烈推荐看看：
并行工作是头号生产力秘诀
同时开 3-5 个 git worktree， 每个跑一个独立的 Claude 会话。这是团队公认的最大生产力提升点。
Boris 自己用多个 git checkout，但团队大多数人更喜欢 worktree。这也是为什么 Claude 桌面应用专门加了原生支持。
有人给 worktree 起名字，设置 shell 别名（za、zb、zc），一个按键就能切换。还有人专门准备一个"分析"worktree，只用来读日志和跑 BigQuery。
复杂任务先做计划
每个复杂任务都从计划模式开始。把精力投入到计划里，Claude 就能一次性完成实现。
有人让一个 Claude 写计划，然后启动第二个 Claude 以幕僚工程师的身份审查。另一个人说，一旦事情跑偏，立刻切回计划模式重新规划，不要硬推。
他们还会明确要求 Claude 在验证步骤进入计划模式，不只是构建步骤。
维护 CLAUDE.md 是长期投资
每次纠正错误后，都以这句话结尾：更新你的 CLAUDE.md，确保不再犯同样的错误。
Claude 非常擅长为自己写规则。随着时间推移，毫不留情地编辑你的 CLAUDE.md，不断迭代直到 Claude 的错误率明显下降。
有个工程师让 Claude 为每个任务/项目维护笔记目录，每次 PR 后更新，然后把 CLAUDE.md 指向那个目录。
把重复操作做成技能
创建自己的技能并提交到 git，在每个项目中复用。
团队的建议：
▸ 如果你每天做某件事超过一次，就把它变成技能或命令 ▸ 做个 /techdebt 命令，每次会话结束时运行，找出并消除重复代码 ▸ 设置一个命令，把 7 天的 Slack、Google Drive、Asana 和 GitHub 同步到一个上下文转储 ▸ 构建分析工程师风格的智能体，写 dbt 模型、审查代码、在开发环境测试变更
让 Claude 自动修复 bug
大部分 bug Claude 都能自己修。
启用 Slack MCP，把 Slack 里的 bug 讨论帖粘贴给 Claude，只说一句"修复它"。不需要切换上下文。
或者直接说"去修复失败的 CI 测试"，不要微观管理怎么做。
让 Claude 看 Docker 日志来排查分布式系统故障，它在这方面能力出奇地强。
提升提示词水平
挑战 Claude。说"针对这些改动严厉审查我，在我通过测试之前不要创建 PR"。让 Claude 当你的审查员。
或者说"向我证明这行得通"，让 Claude 对比 main 分支和功能分支的行为差异。
在平庸的修复后，说："基于你现在掌握的所有信息，废弃这个方案，实现那个更优雅的解决方案。"
交付任务前，写详细的规格 说明，减少歧义。你描述得越具体，输出越好。
终端和环境设置
团队很喜欢 Ghostty。很多人看中它的同步渲染、24 位色彩和完善的 Unicode 支持。
用 /statusline 自定义状态栏，让它始终显示上下文使用情况和当前 git 分支。
很多人给终端标签页做颜色编码和命名，有时配合 tmux，每个任务或 worktree 一个标签页。
用语音听写。你说话比打字快 3 倍，提示词会变得详细得多。macOS 上连按两次 fn 键就能开启。
使用子代理
在任何希望 Claude 投入更多算力的请求中，加上"use subagents"。
把单个任务分给子代理，保持主代理的上下文窗口整洁专注。
通过钩子把权限请求路由到 Opus 4.5，让它扫描潜在攻击并自动批准安全请求。
用 Claude 做数据分析
让 Claude Code 用 "bq" CLI 即时提取和分析指标。
团队在代码库里集成了 BigQuery 技能，每个人都直接在 Claude Code 里用它做分析查询。Boris 说他已经 6 个多月没写过一行 SQL 了。
这适用于任何有 CLI、MCP 或 API 的数据库。
用 Claude 学习
在 /config 里启用"解释型"或"学习型"输出风格，让 Claude 解释它改动背后的"原因"。
让 Claude 生成可视化的 HTML 演示文稿来解释不熟悉的代码。它做幻灯片的水平出奇地好。
让 Claude 画新协议和代码库的 ASCII 图表，帮你理解它们。