别人怎么用（抽象成模式）
模式 1：一任务一 worktree（最常见）
- 把任务拆成可独立合并的小块（最好改不同模块）。
- 每块任务开一个分支 + worktree；AI 只在该目录工作。
- 产出：1–N 个 commits 或一个 PR；人工只做审阅与合并。
模式 2：对同一问题跑多个方案（A/B/C）
- 开多个 worktree：
ai/agent-1、ai/agent-2… - 给同一任务不同约束/策略（例如“最小改动”“性能优先”“可读性优先”）。
- 对比 diff + 测试结果，选一个合并，其余删除。
模式 3：保留一个“干净主工作区”
- 主工作区只做审阅、合并、发布；尽量不直接写代码。
- 所有改动来自 worktree（人或 AI 都一样）。
- 好处：不会被临时实验弄脏，心智负担更小。
模式 4：把验收写死（防止“能跑但不对”）
- 每个任务固定 3 件事：目标、边界、必须通过的命令。
- AI 的输出必须包括：改动摘要、执行过的命令、失败/跳过的原因。
最小可用流水线（本地）
# 0) 准备 worktrees 目录（建议加入 .gitignore）
mkdir -p .worktrees
# 1) 为 Agent/任务创建 worktree
git worktree add -b ai/alice/task-1 .worktrees/ai-alice-task-1 origin/main
# 2) 在该目录运行 AI 工具（示意）
# - 约束：只改指定文件/目录
# - 验收：必须跑通 tests
# 3) 审阅与合并（在主工作区）
git diff main..ai/alice/task-1
# 通过后 merge/squash
# 4) 清理
git worktree remove .worktrees/ai-alice-task-1
# 可选：git worktree prune给 AI 的“任务单”模板
目标（Definition of Done）：
- ...
边界（Do NOT）：
- 不要改动 ...
- 不要引入新依赖
必须通过的命令：
- ...（例如 npm test）
输出格式：
- 你改了什么（列表）
- 你跑了哪些命令 + 输出摘要
- 如果没跑，请说明原因
- 给出最终 diff 或建议的 commit message冲突与合并（经验法则）
- 并行前先拆任务：尽量让不同 worktree 修改不同文件集合。
- 如果必须碰同一文件：指定“文件所有者”（一个 worktree 写、其他只提建议），减少三方冲突。
- 合并前统一基线：必要时让每个 Agent 先
git rebase main再提交最终版本。