- 原文
- 简短而清晰,很多技巧都非常有用,强烈推荐看看:
同时开 3-5 个 git worktree,每个跑一个独立的 Claude 会话。这是团队公认的最大生产力提升点。
Boris 自己用多个 git checkout,但团队大多数 人更喜欢 worktree。这也是为什么 Claude 桌面应用专门加了原生支持。
有人给 worktree 起名字,设置 shell 别名(za、zb、zc),一个按键就能切换。还有人专门准备一个"分析"worktree,只用来读日志和跑 BigQuery。
每个复杂任务都从计划模式开始。把精力投入到计划里,Claude 就能一次性完成实现。
有人让一个 Claude 写计划,然后启动第二个 Claude 以幕僚工程师的身份审查。另一个人说,一旦事情跑偏,立刻切回计划模式重新规划,不要硬推。
他们还会明确要求 Claude 在验证步骤进入计划模式,不只是构建步骤。
每次纠正错误后,都以这句话结尾:更新你的 CLAUDE.md,确保不再犯同样的错误。
Claude 非常擅长为自己写规则。随着时间推移,毫不留情地编辑你的 CLAUDE.md,不断迭代直到 Claude 的错误率明显下降。
有个工程师让 Claude 为每个任务/项目维护笔记目录,每次 PR 后更新,然后把 CLAUDE.md 指向那个目录。
创建自己的技能并提交到 git,在每个项目中复用。
团队的建议:
▸ 如果你每天做某件 事超过一次,就把它变成技能或命令
▸ 做个 /techdebt 命令,每次会话结束时运行,找出并消除重复代码
▸ 设置一个命令,把 7 天的 Slack、Google Drive、Asana 和 GitHub 同步到一个上下文转储
▸ 构建分析工程师风格的智能体,写 dbt 模型、审查代码、在开发环境测试变更
大部分 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 Code 用 "bq" CLI 即时提取和分析指标。
团队在代码库里集成了 BigQuery 技能,每个人都直接在 Claude Code 里用它做分析查询。Boris 说他已经 6 个多月没写过一行 SQL 了。
这适用于任何有 CLI、MCP 或 API 的数据库。
在 /config 里启用"解释型"或"学习型"输出风格,让 Claude 解释它改动背后的"原因"。
让 Claude 生成可视化的 HTML 演示文稿来解释不熟悉的代码。它做幻灯片的水平出奇地好。
让 Claude 画新协 议和代码库的 ASCII 图表,帮你理解它们。