Featured image of post Meta工程师告诉你:Claude Code 用一个分支,你就输在起跑线上了

Meta工程师告诉你:Claude Code 用一个分支,你就输在起跑线上了

从 Meta Staff Engineer 的实战经验出发,讲解为什么多分支策略是 Claude Code 的正确用法,包括 git worktree 并行工作流、上下文管理技巧和团队协作规范。

你是不是也这样用 Claude Code?打开终端,在 main 上直接跑,遇到问题再撤销……

Meta Staff Engineer John Kim 看到这里,可能会摇摇头说:“你走了一条最难的路。”


先说一个真实场景

假设你正在用 Claude Code 修复一个 Bug。

AI 开始分析代码,修了几个文件,突然发现需要重构一个底层函数——它就去重构了。重构过程中发现另一个问题,又顺手改了……

20 分钟后,你的 main 分支上有 37 个文件被修改,你完全不知道哪些是 AI 改的、哪些是你该保留的,想回滚又怕丢失真正有用的修改。

这就是"一个分支跑 Claude Code"的典型灾难现场。


第一部分:为什么单分支是个陷阱?

问题 1:上下文污染,越改越乱

Claude Code 在同一个分支上工作时,每次对话都会累积历史修改。你问它修 Bug A,它可能连带改了 B 和 C。等你发现问题时,git diff 已经是一堵墙。

1
2
3
4
5
6
7
# 你以为你会看到这样的 diff
$ git diff main
# 修改了 1 个文件,5 行

# 实际上看到的是
$ git diff main
# 修改了 23 个文件,342 行增加,180 行删除

问题 2:无法并行,效率减半

大多数人用 Claude Code 是串行工作的:等这个任务完成,再开始下一个。但大厂工程师早就发现,Claude Code 最适合并行运行

一个分支意味着一次只能做一件事,你白白浪费了 AI 的并发能力。

问题 3:主分支受污染,团队协作变噩梦

如果你在一个团队里,在 main 上直接让 AI 乱改,你的同事拉代码时会懵:这些改动是谁做的?为什么改?能回滚吗?


第二部分:多分支工作流——大厂工程师的正确姿势

核心原则:一个任务,一个分支

Leon van Zyl 在他的视频"Stop Using Claude Code on One Branch"里演示了这个工作流:

1
2
3
4
5
6
7
8
# 不要在 main 上直接跑
# ❌ 错误做法
git checkout main
claude  # 直接开干

# ✅ 正确做法:为每个任务创建独立分支
git checkout -b claude/fix-login-bug
claude  # 在隔离环境中工作

命名约定建议(来自社区最佳实践):

1
2
3
4
claude/feature-用户认证
claude/fix-登录bug
claude/refactor-数据库层
claude/experiment-新缓存方案

claude/ 前缀,一眼就知道这是 AI 工作分支,不需要人工深度审查就能判断是否合并。

进阶技巧:用 Git Worktree 真正并行

这是 John Kim 工作流里的核心武器。git worktree 允许你在同一个仓库里同时检出多个分支,每个在独立目录中工作。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# 创建多个工作目录
git worktree add ../project-feature-a claude/feature-a
git worktree add ../project-feature-b claude/feature-b
git worktree add ../project-fix-c claude/fix-c

# 现在你的目录结构是
~/projects/
├── my-project/          # 主目录(main 分支)
├── project-feature-a/   # Claude 在这里做 feature-a
├── project-feature-b/   # Claude 在这里做 feature-b
└── project-fix-c/       # Claude 在这里修 bug-c

然后打开 3 个终端,每个进入不同目录,运行 Claude Code:

1
2
3
4
5
6
7
8
# 终端 1
cd ~/projects/project-feature-a && claude

# 终端 2
cd ~/projects/project-feature-b && claude

# 终端 3
cd ~/projects/project-fix-c && claude

三个 Claude Code 实例同时工作,互不干扰。你在任务之间切换检查进度,就像管理一个小型 AI 团队。


第三部分:上下文管理——给 Claude Code “刚刚好"的信息

多分支解决了隔离问题,但每个 Claude 实例的"智商"取决于你给它的上下文质量。

技巧 1:CLAUDE.md 要"瘦身”

很多人把 CLAUDE.md 写成百科全书,结果 Claude 记不住重点。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# ❌ 太臃肿的 CLAUDE.md
这个项目是一个 SaaS 平台,创建于 2023 年,使用了 Next.js、
TypeScript、PostgreSQL、Redis、Stripe... (后面还有 3000 字)

# ✅ 精炼有效的 CLAUDE.md
## 当前任务约束
- 只修改 src/auth/ 目录下的文件
- 不要动 database/migrations/
- 新功能必须有对应测试

## 架构关键点
- 认证走 JWT(不是 Session)
- 数据库操作必须通过 src/services/ 层
- 禁止直接调用 prisma client

原则:CLAUDE.md 是"任务说明书",不是"项目百科"。每个分支可以有专属的上下文。

技巧 2:用 /compact 控制对话长度

当一次对话拖太长,Claude 的"记忆"会开始模糊。John Kim 的习惯是:

  • 每完成一个子任务,运行 /compact 压缩上下文
  • 感觉 Claude 开始"绕圈子"时,用 /clear 重置
  • 重置后重新提供当前任务的最小上下文
1
2
3
# 在 Claude Code 交互中
/compact   # 压缩历史,保留关键信息
/clear     # 完全清除,重新开始

技巧 3:用 --resume 恢复中断的任务

1
2
3
4
5
# 第二天继续昨天的任务
claude --resume

# Claude 会恢复上次对话的上下文
# 配合 git 分支,无缝继续工作

第四部分:Meta 工程师的真实工作流拆解

John Kim 分享的工作流可以拆解为 5 个步骤:

Step 1:任务规划前先建分支

1
2
3
# 看到 Jira ticket,第一件事不是写代码
# 而是建分支
git checkout -b claude/JIRA-1234-user-profile-api

Step 2:写清楚任务说明,让 Claude 先规划

不是直接说"帮我实现用户 Profile API",而是:

1
2
3
4
5
6
7
我需要实现用户 Profile API,要求:
1. GET /api/user/profile - 返回当前用户信息
2. PUT /api/user/profile - 更新用户信息(姓名、头像 URL)
3. 必须有请求校验和错误处理
4. 参考现有的 /api/user/settings 实现风格

请先给我一个实现计划,我确认后再执行。

这触发 Claude Code 的 Plan Mode,AI 会先列出步骤,你确认没问题再开始改代码。

Step 3:并行跑,自己做 Code Review

Claude 在工作期间,John Kim 会切到另一个终端处理别的事。等 Claude 完成,他回来做 Code Review:

1
2
3
4
5
6
7
# 查看 AI 做了什么
git diff main

# 重点检查
# - 有没有改它不该改的文件?
# - 逻辑是否正确?
# - 有没有引入安全隐患?

Step 4:测试通过才合并

1
2
3
4
5
6
# 在 AI 分支上跑测试
npm test

# 只有测试全绿,才考虑合并
git checkout main
git merge claude/JIRA-1234-user-profile-api

Step 5:清理工作树

1
2
3
# 任务完成后,清理 worktree
git worktree remove ../project-feature-a
git branch -d claude/JIRA-1234-user-profile-api

第五部分:团队协作中的 Claude Code

如果你在团队里推广 Claude Code,多分支工作流还有额外收益。

统一命名约定,一眼识别 AI 工作

在团队 CLAUDE.md 或 README 中约定:

1
2
3
4
5
## AI 分支命名规范
- claude/feat-xxx   # 新功能
- claude/fix-xxx    # Bug 修复
- claude/refactor-xxx  # 重构
- claude/exp-xxx    # 实验性(随时可丢弃)

这样 PR 列表里,所有人都知道哪些 PR 是 AI 生成的,需要更仔细的 Review。

给 AI 分支设置 PR 模板

1
2
3
4
5
6
7
8
9
<!-- .github/PULL_REQUEST_TEMPLATE/claude.md -->
## AI 生成说明
- [ ] 我已 Review 所有修改的文件
- [ ] 测试已通过
- [ ] 没有引入安全问题
- [ ] 逻辑符合业务需求

## Claude 使用的提示词
(粘贴你给 Claude 的原始需求)

共享 CLAUDE.md,降低团队上手成本

1
2
3
4
# 在仓库根目录维护团队共用的 CLAUDE.md
# 每个人不用重新给 AI 解释项目架构
git add CLAUDE.md
git commit -m "chore: 更新 Claude Code 团队工作指南"

总结:三个记住就够

  1. 一个任务 = 一个分支git checkout -b claude/任务名 是你每次使用 Claude Code 的第一步

  2. git worktree 实现真并行:不要让 AI 串行排队,让它们同时工作,你来统筹

  3. 你是 CEO,AI 是执行团队:Claude 做完之后,你来 Review、测试、决定是否合并


最后说一句

用一个分支跑 Claude Code,就像让一个实习生在生产数据库上直接操作——不是不行,但你需要承担所有风险。

多分支工作流的本质,是把"人类的判断力"和"AI 的执行力"分离开来。你负责方向,AI 负责实现,最后你来验收。

这才是大厂工程师真正的用法。


参考来源

RSS Feed 使用 Hugo 构建
主题 StackJimmy 设计