Claude Code 团队内部的高效工作流：并行、计划与验证

Anthropic 的 Claude Code 团队把日常开发习惯整理成了一份进阶用法清单，核心结论只有一句：让 Claude 能自己验证结果，是提升产出质量最有效的一招。其余做法围绕并行跑多个会话、先写计划再动手、用 CLAUDE.md 沉淀纠错经验展开。

并行开工：同时跑 3 到 5 个会话

• 团队认为最大的效率提升来自同时开 3 到 5 个 Claude 会话，每个会话放在独立的 git worktree 里，Claude Code 原生支持 worktree。
• 命令行用 claude --worktree 启动隔离工作区，加 --tmux 可让它跑在独立 Tmux 会话里；桌面端在 Code 标签页勾选 worktree 即可。
• 非 git 的版本控制（Mercurial、Perforce、SVN）可以在 settings.json 里定义 WorktreeCreate 和 WorktreeRemove 钩子，获得同样的隔离效果。
• 会话多了容易迷路，建议给 worktree 起名、设 shell 别名快速跳转、给终端标签配色并开启通知；不少人专门留一个 worktree 只用来读日志和跑查询。

子代理与批量迁移

• 子代理也能跑在隔离 worktree 里，在 agent 的 frontmatter 加 isolation: worktree 即可，适合大批量改动。
• 示例提示词：把所有同步 IO 改成异步，分批启动 10 个带 worktree 隔离的并行代理，每个代理端到端测试自己的改动后各自提 PR。
• /batch 命令会先就迁移需求访谈你，再把任务分发给任意数量的 worktree 代理，几十上百个都行，每个代理独立测试并单独建 PR。

先计划再动手，模型和推理档位怎么选

• 复杂任务先按 Shift+Tab 进入 plan mode，把精力花在打磨计划上，让 Claude 一次把实现做对；流程是进计划模式、细化计划、切到自动接受修改、执行。
• 团队常用做法：让一个 Claude 写计划，再开第二个 Claude 以资深工程师视角审这份计划；一旦跑偏就退回计划模式重新规划，而不是边跑边纠。
• 团队几乎全程用 Opus 加思考模式，理由是引导更少、工具调用更准，整体反而比小模型更快。
• /effort 可选 low、medium、high、xhigh、max、auto；复杂编码和代理任务用 xhigh，硬调试和架构决策用 max，但 max 消耗额度快，建议按会话临时开启。

提示技巧与边干边学

• 不要接受第一个方案，常用追问包括：先考我这些改动、我通过你的测试才准提 PR；证明它确实能跑，对比主分支和特性分支的行为差异；基于现在掌握的信息推倒重来，给出更优雅的实现。
• Claude 正在干活时，用 /btw 问一个旁支问题，不会打断它；该命令是单轮、不调用工具，但能看到完整对话上下文。
• 在 /config 里开启 Explanatory 或 Learning 输出风格，让 Claude 解释改动背后的原因；也可以让它生成可视化 HTML 讲解陌生代码、画 ASCII 架构图，或做一个间隔重复的 skill 来检验自己的理解。

CLAUDE.md、记忆与验证闭环

• 在仓库根目录放一份纳入 git 的 CLAUDE.md，全团队共同维护；每次 Claude 做错事就补一条规则进去，纠正后加一句「更新你的 CLAUDE.md，别再犯这个错」。
• 用 /install-github-app 装 GitHub Action，在 PR 评论里 @claude 把评审中的经验写进 CLAUDE.md，团队称之为「复利工程」。
• /memory 配置内置记忆系统，auto-memory 会在会话之间自动保存偏好、纠错和模式，存放在 ~/.claude/projects/<项目>/memory/，与手写的用户级和项目级 CLAUDE.md 分开。
• 验证是全文第一建议：给 Claude 一个能自己检查输出的方式，它就会反复迭代到结果正确；不同领域验证手段不同，比如跑 bash 命令、用 Chrome 扩展或桌面端看实际效果，再用 /simplify 收敛改动。

今天就能做

• 今天就给 Claude 配一条可执行的验证路径（测试命令、脚本或浏览器检查），让它能自己判断对错。
• 把仓库根目录的 CLAUDE.md 纳入 git，并在下一次被纠正后让 Claude 自己补写规则。
• 挑一个中等复杂任务，用 plan mode 先出计划再执行，对比一次成型的成功率。