我在学习 Coursera 上的课程 Claude Code: Software Engineering with Generative AI Agents 时，想象了一个由多个 squad 维护的产品：Checkout 负责修改订单创建，Payments 更新状态，Accounts 消费事件，Platform 准备 release/homolog 包。每个团队负责一部分，但共享的更改可能导致这些前端相互冲突。
这就像车间里的几个团队：每个团队都需要自己的工位来拆卸一辆车，但它们仍然依赖同一套零件库存和最终检验。这门课程让我意识到，同样的争夺也发生在代理之间：两个会话可能试图在同一个 checkout 上工作并混合更改。Worktrees 为每个会话提供一个隔离的工位；Claude Code Desktop 使这些前端变得可见，并让 branch、diff、PR 和 CI 更加紧密地结合。
Git 创建 worktree；Claude Code harness 的价值在于把这种能力转化为引导式的可视化流程，并将每个会话绑定到其目录、分支和进行中的工作。
Claude Code 已经在 CLI、Desktop 和编排命令中提供了该流程的部分功能。机会在于将这些功能与每个 squad 使用的流程以及协调跨团队更改的契约相连接。
目录
- 1. Squad 的问题不是创建分支
- 2. 组织并行工作的可视化层
- 3. 工作单元将任务、worktree 和 PR 联系起来
- 4. 在 squad 内部和之间采用的五种方式
- 5. Harness 需要引导和传感器
- 6. Worktrees 无法解决问题的场景
- 7. 扩展前的小规模推出
1. Squad 的问题不是创建分支
大型 squad 已经知道如何创建分支。当团队内部的并发工作量增加时，问题就会出现：
- 一个人中断功能来修复一个事件；
- 另一个人需要审查 PR，而不丢失本地状态；
- 一个代理修改依赖，而另一个代理在同一配置上操作；
- 多个更改同时准备好，并遇到相同的 CI 和审查队列；
在 squad 之间，即使没有人编辑同一个文件，冲突也可能发生：
- 一个 squad 修改了 API，而另一个 squad 仍然依赖旧版本；
- 一个基础设施的 PR 必须在消费者的 PR 之前合入；
- 同一项倡议下的两个仓库进展节奏不同；
- 一个共享的包缺乏明确的所有者或兼容性政策；
- 更改在每个 squad 隔离的 CI 中通过，但当组件相遇时会失败。
一个分支分离了历史，但传统的 checkout 仍然占用单个工作目录。切换分支会改变该目录中的文件。对于顺序的人工工作，这通常已经足够。对于编码代理的并行会话，共享目录会成为瓶颈。
工作树增加了物理隔离：
repo/
├── main/ → main
├── exportacao/ → feature/exportacao
├── dashboard/ → feature/dashboard
└── notificacoes/ → feature/notificacoes
每个目录都有自己的文件和自己的分支，而它们共享同一仓库的历史。
这并不能消除合并冲突，也不能协调 squad 之间的合同。它消除的是一种先前的冲突类别：两个任务在仍在执行时同时修改同一个检出。
2. 组织并行工作的可视化层
Git worktree 并不是由 Claude Code 发明的。Claude Code 桌面版 的不同之处在于，它将 Git 的这一原生能力融入到一个界面中，使并行工作变得易于理解和可审查。
截图：Anthropic。侧边栏汇集了项目和会话；worktree 为每个本地会话提供一个隔离的工作目录。
侧边栏变成操作面板
在 Code 选项卡中，每个对话都是一个独立的会话，拥有自己的历史、项目文件夹和更改。在 Git 仓库中，Desktop 会为每个本地会话自动创建一个 worktree。侧边栏显示这些会话，允许并行运行多个会话，并提供按状态、项目和环境的过滤，此外还支持按项目分组。
这创建了一个如下所示的操作映射：
Projeto: checkout
├── Sessão: corrigir autenticação
│ ├── worktree + branch próprios
│ ├── diff em revisão
│ └── PR aguardando CI
├── Sessão: atualizar SDK
│ ├── worktree + branch próprios
│ └── implementação em andamento
└── Sessão: investigar regressão
├── worktree + branch próprios
└── aguardando decisão humana
这不是对仓库所有分支及其关系的可视化，就像专门用于 Git 历史的工具那样。它展示的是由 Claude Code 进行的工作前线。对一个团队来说，这已经解决了一个重要痛点：不再有一堆没有明确标识的终端，而是出现了一份隔离任务的列表，每个任务都有自己的状态和上下文。
此层提供的功能
| 可视化功能 | 提供的功能 | 对团队的价值 |
|---|---|---|
| 侧边栏会话 | 列出独立的工作并允许在它们之间切换 | 让执行中的内容及其状态可见 |
| 按会话自动 Worktree | 无需手动配置即可为每个任务分离目录和更改 | 降低同一检出下的本地冲突和分支切换 |
| 过滤和分组 | 按状态、项目或环境过滤，并按项目分组 | 帮助跟踪多个前线，避免混淆仓库和上下文 |
| 并排显示两个会话 | 同时显示两个工作 | 方便将更改与其依赖进行比较，或跟踪生产者和消费者 |
| 可配置的分支前缀 | 标准化 worktrees 中创建的分支名称 | 方便识别来源、任务或团队约定 |
| 聊天、计划、任务和子代理面板 | 在会话内组织推理、执行和委派 | 保持任务上下文与正在修改的代码相关联 |
| 可视化 diff 和行注释 | 允许审查文件并向 Claude 提供反馈 | 将审查放在提交或 PR 之前 |
| 集成的终端和编辑器 | 在同一会话的目录中运行 | 避免在错误的 worktree 中执行命令或编辑文件 |
| PR 和 CI 条 | 跟踪检查，并在配置时尝试修复失败 | 将本地执行连接到团队的主要集成传感器 |
| 会话归档 | 手动删除 worktree，或在 PR 关闭或合并后删除 | 有助于控制临时本地环境的积累 |
当更改涉及多个仓库时，远程会话也可以接收多个仓库，每个仓库都有自己的分支选择器。这在一个小队修改了合约而其他小队需要更新其消费者时很有用。不过，该界面仅负责整理这些工作线，而不会决定兼容性、合并顺序或部署序列。
隔离会话也可在 CLI 中使用
官方文档展示了在独立工作树中启动一个会话的过程：
claude --worktree feature-auth
您可以打开另一个会话，使用不同的名称来执行两个任务，而不会导致本地更改冲突。仓库需要至少有一个提交，以便 Git 能够解析基础。该流程在 常见工作流程 中有描述。
大规模更改与 /batch
对于跨越仓库的更改，/batch 描述了另一个层次：Claude Code 会搜索代码，提出分解方案，并在获得批准后，在独立的 worktree 中执行这些单元。每个单元可以实现、测试并打开自己的 PR。
此流程适用于真正可分离的更改，例如更新多个遵循同一契约的模块。如果所有单元都依赖于同一架构决策或修改同一核心，则需要在并行之前完成分解。
PR 周期
Claude Code 还能创建 PR、审查 diff 并跟踪检查。在可用时，/autofix-pr 会启动一个远程会话以观察 CI 失败和审查评论。Claude Code GitHub 动作 将代理带到仓库事件中，以便自动化与 PR 相关的任务。
截图：Anthropic。Claude Code Desktop 在会话中显示 PR 检查的状态。
这些选项将 PR 转变为代理工作与 squad 控制之间的集成点。它们不会让自动合并成为默认的好决定。
3. 工作单元将任务、worktree 和 PR 联系起来
传统流程通常表示如下：
Pessoa → branch → commit → pull request
如果使用代理，我会使用更明确的单位：
Tarefa + responsável humano
↓
Contrato de escopo e aceite
↓
Sessão do Claude Code
↓
Worktree + branch
↓
Implementação + testes locais
↓
Pull request
↓
CI + revisão inferencial + revisão humana
↓
Integração
人类负责人仍然出现在开始阶段。代理可以产生变化，但有人需要对分解、写作限制以及集成决策负责。
在打开会话之前，任务可以加载一个小合同：
task: adicionar exportação CSV
owner: squad-relatorios
owns:
- src/export/**
must_not_change:
- migrations/**
acceptance:
- preserva os filtros atuais
- neutraliza fórmulas em células exportadas
- passa nos testes de exportação
integration:
base_branch: main
human_review: required
Worktree 将文件隔离。该合同指导工作。测试和审查验证更改是否符合约定。
当项目跨团队进行时，合同还需承担交付之间的依赖：
initiative: evoluir contrato de notificacoes
contract_owner: squad-plataforma
producers:
- service-events
consumers:
- app-web
- app-mobile
compatibility: backward-compatible
merge_order:
- contrato e produtor
- consumidores
- remoção da versão anterior
sensors:
- contract tests
- CI por repositório
- revisão dos owners
每个任务仍可拥有自己的 worktree 与 PR。各 squad 之间的纽带是共享的契约、明确的顺序以及兼容性传感器。
4. 在 squad 内部及之间采用的五种方式
我不建议一开始就把所有资源全部关联。至少有五种可行的切割方式。
| 选项 | 工作方式 | 适用场景 | 主要风险 |
|---|---|---|---|
| 1. 辅助 worktree | 每个人通过 claude --worktree <tarefa> 打开一个会话
|
功能、错误以及本地中断 | 随意创建多分支，缺乏清理纪律 |
| 2. 桌面上的可视化看板 | 侧边栏组织会话和 worktree；面板将任务、diff、PR 与 CI 联系起来 | 需要查看状态和上下文的多前线 squad | 把可见性当作协调，并行化依赖任务 |
| 3. squad 之间的契约 | 每个 squad 在自己的 worktree/PR 中工作，通过契约、负责人以及集成顺序相连接 | API、共享包或多仓库项目 | 孤立执行，忽略兼容性与发布 |
4. 使用 /batch 进行编排 |
Claude 提出独立单元并将其分配到各个 worktree | 在独立模块上的迁移或重复变更 | 分解不好会导致 PR 增多和返工 |
| 5. PR 与 CI 的循环 | GitHub Actions、审查以及 /autofix-pr 对 PR 作出反应 |
拥有可靠测试和明确标准的仓库 | 代理仅修复症状或无限制扩大范围 |
我的建议是先在一个 squad 内从选项 1 开始。这几乎不改变当前流程，却能让隔离变得可观察。随后，在两个 squad 之间挑选一个小变更来测试选项 3：兼容的契约、关联的 PR、明确的所有者以及显式的集成顺序。
/batch 最后登场。它能提升吞吐量，但同时也会增加成本、PR 数量以及集成负担。这是一种用于可拆分工作的编排工具，而非万能的生产力按钮。
5. harness 需要指南与传感器
编码代理是模型 + harness。在这种情况下，Claude Code 的 harness 提供会话、工具、权限、子代理以及与 Git 的集成。团队仍需构建仓库的 user harness：上下文、限制、测试、CI 和审查规则。
| 关注点 | 生成前的指南 | 类型 | 生成后的传感器 | 类型 | 轴 |
|---|---|---|---|---|---|
| 任务范围 | 带有 owns 和 must_not_change 的合同
|
推断的 | 路径脚本 + 人工审查 | 计算的 + 推断的 | 行为 |
| 仓库约定 |
CLAUDE.md 和按路径的规则 |
推断的 | linter、格式化工具和审查 | 计算的 + 推断的 | 可维护性 |
| 架构限制 | 允许的模块和依赖关系图 | 推断的 | 架构测试 + 架构审查 | 计算的 + 推断的 | 架构适应度 |
| 期望行为 | 验收标准和示例 | 推断的 | 单元测试、集成测试和 E2E | 计算的 | 行为 |
| 集成 | 基础分支、顺序和负责人 | 推断的 | 强制 CI 和分支保护 | 计算的 | 行为 |
| 团队间合同 | 所有者、版本、兼容性和推出顺序 | 推断的 | 合同测试 + 所有者审查 | 计算的 + 推断的 | 架构适应度 / 行为 |
| 安全 | 最小权限和禁止的文件 | 计算的 + 推断的 | 扫描器、差异审查和人工批准 | 计算的 + 推断的 | 行为 |
工作区是隔离的计算基础设施。它不会替换这些传感器中的任何一个。
界面仅仅因为显示状态而不会成为传感器。分支前缀、所选基础和任务合同在更改之前充当指南。带注释的 diff 作为推断传感器；测试和分支保护作为计算传感器。CI 条仅将这些传感器的结果带到会话进行的同一表面。
如果 CLAUDE.md 说“不要破坏兼容性”，但 CI 没有合同测试，团队仍会依赖推断指令来保护目标行为。当可重复的规则变成计算传感器时，harness 会变得更强。
6. Worktrees 无法解决的问题
在不了解工具局限的情况下推广它，只是把一个瓶颈换成另一个。
Worktrees 无法解决：
- 两个任务同时修改同一个合约、迁移文件或 lockfile；
- 所有权不明确以及不同 squad 的 API 之间不兼容；
- 在独立仓库中，生产者与消费者之间的部署顺序；
- 审查队列跟不上 PR 数量的增长；
- 本地环境争夺同一端口、数据库或外部资源；
- 测试缓慢、不稳定或无法检测回归；
- 长期分支积累与主线的偏差；
- 多个并发会话消耗的成本和上下文；
- 对谁负责批准和集成每个更改的责任不明确。
视觉层也不知道流程 develop → release/homolog → pacote de produção。它只显示会话和关联的分支，但不能阻止任务从错误的基础开始、进入错误的包或以错误的顺序被提升。分支政策只是一个指南；分支保护、测试和 CI 是需要阻止这些偏差的计算传感器。
一些被忽略的文件可能需要在每个 worktree 中存在。Claude Code 提供 .worktreeinclude，但我会把它当作所需本地工件的白名单。凭证和密钥不应在目录之间自动复制。
我也会避免在第一阶段自动合并。在此之前，团队需要检查测试、审查和分支保护是否真的能够拦截重要的错误。
7. 在扩大之前的小规模推出
我建议进行两个可逆的实验。
首先，在一个 squad 内：
- 选择两个独立且具有可靠测试的任务。
- 明确负责人、允许的文件以及验收标准。
- 为每个任务打开一个 Claude Code 的会话/worktree。
- 要求独立的 PR、绿色 CI 和人工审查。
- 记录冲突、CI 重跑、返工和审查时间。
- 与未使用并行会话的类似任务进行对比。
然后，在两个 squad 之间：
- 选择一个小的合约更改或共享库更改。
- 明确合约的所有者和消费方的所有者。
- 定义兼容性、依赖的 PR 以及合并/部署顺序。
- 在各自的会话和 worktree 中执行每一部分。
- 要求合约测试、每个仓库的 CI 以及交叉审查。
- 测量 squad 之间的等待时间、集成失败和返工。
如果这套流程跑得通，下一步就是把任务契约固化成模板，并把确定性规则移交给 CI。只有在这之后，才值得尝试 /batch、例行任务或自动修复 PR。
成功的标志不是“我们开了更多 PR”。对小队内部而言，它意味着在不增加回归的前提下减少等待和上下文切换；对小队之间而言，则意味着在不破坏兼容性、不把返工转嫁给其他团队的前提下减少集成阻塞。
这正是这门课程改变我看 Git 视角的地方。在一个大团队里，分支依然是变更线，PR 依然是评审单元。worktree 补充了一处隔离的工位，让个人或智能体可以在不打乱他人环境的前提下工作。而在小队之间，契约、负责人和传感器负责协调这些工位，让它们交付同一项举措中彼此兼容的部分。
Claude Code Desktop 则为 Git 的这种能力赋予了可视化形态：侧边栏把并行会话整理得井井有条，各个面板让上下文、改动、PR 和 CI 触手可及。harness 的功劳在于把这些部件串成一条开发者既能跟进、又能随时接续的流程。至于小队之间的协调，依然依托远程分支、契约、PR 和 CI。真正打动我的，正是这套组合。
你眼下最大的瓶颈在哪里：是小队内部的并行，还是小队之间的依赖？你又打算从哪里入手——每个任务一个 worktree、共享契约，还是 PR 周期的自动化？
——
