41 · 并行任务：让几个 Claude 同时开工，而不是排队
📚 系列导航：上一篇 40 Chrome：让它操作浏览器 教你把 Claude 的手伸进浏览器，自动点页面、填表单。这一篇换个维度——不是让一个 Claude 多干一件事，而是让好几个任务同时开工。git worktree 隔离、后台多会话、headless 批量跑，三套手段一次说清，外加最关键的那条：什么时候并行真省事，什么时候纯添乱。
说出来有点丢人，但我自己第一次想「并行干活」时，干的就是这么一件蠢事：开了两个终端，都 cd 到同一个项目目录，一个让 Claude 改前端登录页，另一个让它顺手修一个后端的 bug。
心里还美滋滋地想：「这不双倍效率嘛。」
结果呢——两边都在改 package.json，一边刚写进去的依赖，被另一边的改动直接覆盖回滚了；git status 一看，工作区乱成一锅粥，谁改的哪行根本分不清。我那天花了比「老老实实一件件干」多得多的时间，才把两边的改动手动捋开，越捋越火大。就是那回我才明白：并行不是「多开几个窗口」这么简单，核心是「别让它们踩到同一块地」。
其实 Claude Code 早就备好了正经的并行工具——--worktree 给每个会话一份隔离的代码副本，--bg 把任务甩到后台批量跑，claude agents 给你一块总控台盯着它们。这一篇，咱们把上面那个坑连根填平，再带你把这几套手段亲手跑一遍。
看完这一篇，你会拿到：
- 一句话讲清「为什么要并行」，以及并行的两个前提：任务互相独立、不抢同一份文件
- 官方四种并行方式（子代理 / 代理视图 / 代理团队 / 动态工作流）一张表分清，知道该挑哪个
- 用
--worktree给每个会话一份隔离副本，再不互相覆盖——附.worktreeinclude、清理这些坑点 - 用
claude agents和--bg把任务甩到后台、一块屏幕盯进度，只在需要时介入 - 用
claude -p（无头模式，headless）把任务写进脚本批量跑，配--bare启动更快 - 那条最重要的判断线：什么时候值得并行、什么时候反而把自己绕进去
01 先想清楚：并行到底解决什么问题，前提是什么
先给结论：并行解决的是「几件互不相干的活，不想排队一件件等」；但它能成立，全靠一个前提——这几件活别抢同一份文件。
回想前面四十篇，咱们基本都在「一个会话」里折腾——开一个 Claude，给指令，它一步步干。这模式九成的活儿够用。但有两种时候你会嫌它慢。
一是任务天然就能拆开、互不依赖。 比如「改前端样式」「修后端一个 bug」「补一批单元测试」，三件事八竿子打不着，却只能排队：改完前端才轮到后端。明明能同时干，却被逼着串行。
二是任务大到一个会话扛不动。 比如「把整个代码库里某个旧 API 全换成新的」，涉及几十上百个文件，一个会话从头改到尾，上下文（context，可理解成它的「工作记忆」，详见第 19 篇）早塞满了，越往后越「忘事」。
类比：超市结账。 一条收银通道，十个人拎着购物车排长龙，第十个人得干等前面九个全结完——这就是串行。聪明的超市会多开几个收银口，十个人分到三四条队里同时结，总时间立刻砍下来。并行干活就是「多开收银口」：几件独立的活，分给几个 Claude 同时结账，而不是挤在一条队里。
但收银口能多开有个隐含前提：每条队是独立的，互不干扰。要是三个收银员共用同一个钱箱、同时往里塞钱找零，立刻乱套——这正是开头那个坑。所以并行的铁律就一条：
任务接触相同的文件吗？使用 worktrees 隔离工作。
落到你会遇到的真实场景，能并行的活儿长这样：
- 「这三个互不相干的模块，各修各的 bug」——分三个会话同时修，互不打扰
- 「把
utils/整个目录里没人用的死代码扫出来」——派个子代理去翻，主对话不被一堆文件灌满（详见第 23 篇） - 「同一份脚本，对 30 个文件各跑一遍同样的改动」——写成 headless 批量任务，机器自己跑完
💡 一句话总结：并行是为了让互相独立的活儿不用排队（像超市多开收银口），但它成立的铁律只有一条——别让它们抢同一份文件，否则越并行越乱。
02 官方四种并行方式：先认门，别一上来就挑花眼
Claude Code 的并行不止一招。官方专门有一页《并行运行代理》把它们摆在一起比，核心区别就一个问题：谁来协调这些活儿？ 是 Claude 在一个对话里派活收活，是你甩出去回头再看，还是 Claude 当工头统筹一队。
先把四种方式一张表认清，这一节是地图，下面几节才是逐个深挖：
| 方式 | 它是什么 | 谁协调 | 什么时候用 |
|---|---|---|---|
| 子代理（Subagent） | 一个会话内派出去的工作者，在自己上下文里干完返回摘要 | Claude 在对话里派活收活 | 辅助任务会用一堆搜索结果 / 日志把主对话灌满，而你不会再翻这些过程 |
| 代理视图（Agent view） | 一块屏幕，调度并监控多个后台会话，claude agents 打开（研究预览） | 你甩出任务、回头检查 | 你有几个独立任务，想交出去、一眼扫状态、只在需要时介入 |
| 代理团队（Agent teams） | 多个会话协调干活，共享任务列表、互发消息，有个 leader 统筹（实验性，默认关） | Claude 当工头统筹一队 | 你想让 Claude 把项目拆成几块、分派、还让工人们保持同步（详见第 29 篇） |
| 动态工作流（Workflows） | 一段脚本，跑一大批子代理并交叉验证结果（研究预览） | 脚本而非 Claude 逐轮判断 | 活儿大到几个子代理协调不过来，或要结果互相验证：全库审计、500 个文件迁移 |
⚠️ 实验性标注：上表里代理视图（agent view）和动态工作流（workflows）是研究预览版、代理团队（agent teams）是实验性默认关闭——界面、快捷键、行为后续都可能变。照做前先
claude --version对一下版本。子代理则是稳定功能。
这表你不用背，记住一句就行：「谁协调」是分水岭——Claude 在对话里顺手派 → 子代理；你撒手甩后台 → 代理视图；Claude 当工头带队 → 代理团队；脚本死板地批量跑 → 动态工作流。
还有两个东西它们本身不是「并行方式」，而是给并行打配合的工具，这一篇重点讲前一个：
- Worktrees：给每个会话一份单独的 git 副本，让并行会话永远不会改到同一份文件。这是开头那个坑的正解，第 03 节专讲。
/batch：一个 skill，让 Claude 把一个大改动拆成 5 到 30 个 worktree 隔离的子代理，每个开一个 PR。它是「子代理 + worktree」的打包用法，不是单独一种协调风格。
子代理（第 23 篇）和代理团队（第 29 篇）前面都专门讲透了，这一篇不重复——本篇聚焦那块还没碰过的：worktree 隔离、后台多会话、headless 批量。
💡 一句话总结：并行有四种正经方式，「谁协调」是区分关键；worktree 和
/batch是给并行打配合的工具，不算单独方式；本篇专攻前面没讲过的 worktree、后台会话、headless 三块。
03 用 worktree 隔离：给每个会话一份「自己的副本」
这一节是开头那个坑的正解，也是整篇最该吃透的一块。
先说那个坑到底坑在哪：两个会话 cd 进同一个目录，等于俩人在同一张图纸上同时涂改，后写的盖住先写的，天经地义会乱。git worktree（工作树，git 的一项原生能力）就是来根治这个的。
类比：把同一张图纸复印几份，几个人各改各的副本。 设计图只有一张原稿，三个人要同时在上面标注，挤在一张纸上必然涂乱。正确做法是复印三份——每人拿一份副本随便改，改完再合并。git worktree 干的就是这事：它从同一个仓库历史里，给你拉出几个独立的工作目录，各有各的文件和分支，但共享同一套提交历史和远程。一个会话在它的副本里怎么改，都碰不到另一个会话的副本。
官方把这个值钱的点讲得很清楚：
在自己的 worktree 中运行每个 Claude Code 会话意味着一个会话中的编辑永远不会触及另一个会话中的文件，因此您可以让 Claude 在一个终端中构建功能，同时在第二个终端中修复错误。
一行命令开一个隔离会话
最省事的用法：启动时加 --worktree（或简写 -w），后面跟个名字。Claude 会自动创建一个隔离的 worktree 并在里头开工。默认这个 worktree 放在你仓库根目录下的 .claude/worktrees/<名字>/，分支名叫 worktree-<名字>：
bash
claude --worktree feature-auth想再开第二个独立会话？另一个终端、换个名字，跑同样的命令：
bash
claude --worktree bugfix-123这下两个会话各在自己的副本里，一个搭功能、一个修 bug，谁也碰不到谁的文件——开头那个「互相覆盖」的惨剧从根上没了。名字懒得起？省略它，Claude 自动生成一个像 bright-running-fox 这样的：
bash
claude --worktree会话里也能临时让它进 worktree——直接说一句「在 worktree 中工作」，它会用 EnterWorktree 工具给你建一个。
第一次在某个目录用
--worktree之前，得先在该目录里跑一次普通的claude，接受那个工作区信任对话框。没接受过信任，--worktree会直接报错让你先去跑一次claude——连-p模式也一样。
三个新手必踩的坑点
坑点一：.claude/worktrees/ 要进 .gitignore。 不然这些 worktree 的内容会在你主目录里显示成一堆「未跟踪文件」，看着碜得慌。官方专门提醒了这条。
坑点二：worktree 是干净的新副本，你的 .env 不在里面。 worktree 是个全新检出，主仓库里那些没被 git 跟踪的文件（像 .env、.env.local）默认不会跟过去——结果新会话一跑就缺环境变量。解法是在项目根放一个 .worktreeinclude 文件，列出要自动复制进每个 worktree 的本地文件，语法和 .gitignore 一样：
text
.env
.env.local
config/secrets.json这个坑我亲自栽过：兴冲冲 -w 开了个会话准备改后端，结果 Claude 跑起来一直报连不上数据库，我对着报错排查了半天，甚至怀疑是数据库挂了——最后才反应过来，.env 压根没复制进 worktree，连接串它根本读不到。后来在每个项目根都顺手放上 .worktreeinclude，就再没犯过这毛病。
坑点三：退出时记得「保留还是删除」。 官方的清理规则很实在：
- 没改任何东西（无未提交改动、无未跟踪文件、无新提交）：worktree 和它的分支会自动删除；但如果会话事先命了名（
--name），Claude 会弹提示让你决定保留还是删除。 - 改了东西：Claude 会问你「保留还是删除」——保留就留着目录和分支，以后能回来接着干；删除就连同未提交的改动一起丢掉。
- 非交互（
-p）跑出来的 worktree 不自动清理，因为没有退出提示，得自己git worktree remove删。
不想让 Claude 自动建，也能手动来
要完全掌控 worktree 放哪、用哪个分支，直接用 git 自己建也行（git 工作流第 43 篇会专门讲）：
bash
# 在新分支上建一个 worktree
git worktree add ../project-feature-a -b feature-a
# 进去启动 Claude
cd ../project-feature-a && claude
# 列出所有 worktree
git worktree list
# 干完删掉
git worktree remove ../project-feature-a官方提醒一句很容易忘的：每个新 worktree 都是独立检出，记得在里头重新装依赖、配虚拟环境——别指望它继承主目录装好的 node_modules。
💡 一句话总结：worktree 给每个会话一份独立的代码副本（像复印图纸各改各的），
claude --worktree <名字>一行开一个隔离会话；记牢三坑——.claude/worktrees/进.gitignore、.env靠.worktreeinclude复制、退出时选「保留 / 删除」。
04 多会话并行：后台甩任务 + 一块总控台盯着
worktree 解决了「文件不打架」，但还有个问题：开了三五个会话，难道得开三五个终端来回切、一个个盯？ 太累了。这就轮到「代理视图（agent view）」上场。
类比：机场塔台的航班动态板。 塔台不会派一个人盯一架飞机——一块大屏上，所有航班的状态一目了然：哪架在滑行、哪架等指令、哪架已落地。调度员平时扫一眼总览，只在某架要他拍板时才接管对讲。claude agents 给你的就是这么块塔台屏：所有后台会话排成行，状态一眼扫清，谁需要你才介入。
⚠️ 研究预览：agent view 是官方标注的研究预览功能，需要较新版本的 Claude Code，界面和快捷键后续可能变。先
claude --version对一下版本。
把任务甩到后台
后台会话的精髓是：它不绑在你的终端上——你关掉这块屏、关掉 shell、甚至另开一个交互会话，它照样在跑。有几种甩法。
第一种，从 shell 直接甩，加 --bg：
bash
claude --bg "调查一下 SettingsChangeDetector 这个不稳定的测试为啥老挂"甩出去后，Claude 会打印这个会话的短 ID 和管理它的命令，大概长这样：
text
backgrounded · 7c5dcf5d
claude agents list sessions
claude attach 7c5dcf5d open in this terminal
claude logs 7c5dcf5d show recent output
claude stop 7c5dcf5d stop this session第二种，从正在聊的会话里甩：敲 /bg（/background 的简写），把当前对话挪到后台。
用 claude agents 这块塔台屏管它们
打开总控台：
bash
claude agents它会占满整个终端，把所有后台会话按状态分组列出来——「需要输入」「正在工作」「已完成」各归一拨。每行开头一个图标，颜色和动画告诉你这个会话啥状态：
| 状态 | 图标 | 含义 |
|---|---|---|
| 工作中 | 动画闪动 | 正在跑工具或生成回复 |
| 需要输入 | 黄色 | 在等你回答或批权限 |
| 已完成 | 绿色 | 任务成功干完 |
| 失败 | 红色 | 出错结束了 |
塔台屏的核心操作就三个，新手记住这仨足够：
Space（窥视）：选中一行按空格，弹出小面板看它最近的输出、或它正卡在哪个问题上——多数时候不用进完整对话，瞄一眼就够。- 回复：在窥视面板里直接打字回它，按
Enter发出去，不用离开总控台。 Enter/→（附加）：想钻进某个会话好好聊，按回车「附加」进去，它就变成一个完整的交互会话；在空输入框按←又退回总控台。
这里有个藏得很深但极关键的细节，正好把上一节的 worktree 串起来：每个后台会话在改文件前，Claude 会自动把它挪进 .claude/worktrees/ 下的隔离 worktree。也就是说——你用代理视图并行甩任务，文件隔离是自动帮你做好的，不用像第 03 节那样手动 -w。官方文档确认：代理视图在分派每个会话时，会自动为它创建独立的 worktree。
举个常见的并行组合：同时甩出三个后台会话——一个修 flaky 测试、一个审一个 PR、一个补文档。你该干嘛干嘛，每隔一阵 claude agents 扫一眼——谁变绿了去验收，谁标黄了去拍板。比开三个终端来回切省心太多了。
⚠️ 一个会消耗你额度的事实：后台会话和交互会话一样吃你的订阅用量。并行跑十个，额度消耗速度大约是跑一个的十倍。别看后台跑得欢就无脑开一堆。
💡 一句话总结：
--bg把任务甩到后台、/bg把当前会话甩后台，claude agents给你一块塔台屏（像机场航班板）——Space窥视、直接回复、Enter附加；后台会话的文件隔离是自动用 worktree 做好的，但并行越多越费额度。
05 Headless 批量：写进脚本里，让它无人值守地跑
前面两套是「你坐在终端前盯着」。但有一类活儿你压根不想盯——同一个套路，对一批东西各跑一遍；或者把 Claude 塞进 CI、塞进脚本，让它像个命令行工具一样被自动调用。这就是无头模式（headless，即不开交互界面、跑完就退出的运行方式）。
类比：把指令写成纸条投进自助机，跑完吐结果。 你不会守着自动售货机看它出货——投币、按键、东西掉出来，全程不用你盯。headless 就是这种「无人值守」：你把提示和参数一次性写清，塞给 claude -p，它跑完把结果吐出来，你拿去用就行。
核心就一个标志：-p（或 --print）。加上它，claude 就非交互地跑一次然后退出：
bash
claude -p "找出 auth.py 里的 bug 并修掉" --allowedTools "Read,Edit,Bash"这里 --allowedTools 是预先批准它能用哪些工具——因为没人在旁边点「同意」，你得提前告诉它「这几样工具随便用，别停下来问」（权限模式详见第 20、35 篇）。
三个让它真正好用的配套
配套一：管道喂数据。 headless 会读标准输入（stdin），所以你能像用任何命令行工具一样，把数据用管道喂进去。比如把构建报错丢给它解释，结果写进文件：
bash
cat build-error.txt | claude -p "简明扼要说清这个构建错误的根因" > output.txt排查构建挂掉时，就这么一行甩过去——比复制报错粘进会话快多了。
配套二：--bare 让启动更快。 默认 claude -p 会加载和交互会话一样的全套上下文（hooks、skills、plugins、MCP、CLAUDE.md 全读一遍），脚本里跑就嫌慢、还可能被队友 ~/.claude 里的配置干扰。加 --bare 跳过这些自动发现，启动快、结果还在每台机器上一致：
bash
claude --bare -p "总结这个文件" --allowedTools "Read"官方明确说了：
--bare是脚本和 SDK 调用的推荐模式，将在未来版本中成为-p的默认值。
配套三：--output-format json 拿结构化结果。 脚本要解析 Claude 的输出，纯文本不好处理。加 --output-format json，它会返回带元数据的结构化 JSON（结果、会话 ID，还有 total_cost_usd 这次花了多少钱），配 jq 一提取就能用：
bash
claude -p "总结这个项目" --output-format json | jq -r '.result'把 headless 拼成「批量」
单条 -p 还不算批量。真正的批量是拿 shell 循环把它套起来——对一批文件各跑一遍同样的活。比如给某个目录下每个 .py 文件都生成一句话说明：
bash
for f in src/*.py; do
claude --bare -p "用一句话说明 $f 是干什么的" --allowedTools "Read"
done这就是「无人值守批量」的雏形：循环、-p、--bare，三件套。当然，如果这批活儿大到几十上百个文件、还想互相验证结果，那就该上第 02 节提的动态工作流或 /batch 了——它们本质就是把这种批量正经工程化。
⚠️ 一个要留意的计费变化：官方文档注明，从 2026 年 6 月 15 日起，订阅套餐下的 Agent SDK 和
claude -p用量会从一份独立的月度 Agent SDK 额度里扣，跟你的交互用量分开算。脚本批量跑之前，心里有个数（计费细节见第 06 篇）。
💡 一句话总结：headless 用
claude -p非交互跑一次就退出（像投自助机不用盯），配--allowedTools预批工具、--bare加速、--output-format json拿结构化结果；拿 shellfor循环套起来就是「批量」雏形。
06 最关键的一节：什么时候别并行
讲了三套并行手段，但这一节比前面都重要——因为太多人一学会并行就上头，啥都想拆，结果越并行越乱、越并行越贵。
先把判断线立起来。值得并行，得同时满足两条：任务互相独立（A 不依赖 B 的结果）、不抢同一份文件（或者用 worktree 隔开了）。少一条，并行就是给自己挖坑。
并排看一眼，什么该并行、什么老实串行：
| 场景 | 该不该并行 | 为什么 |
|---|---|---|
| 三个互不相干的模块各修各的 bug | ✅ 并行 | 独立、不抢文件，典型该并行 |
| 同一套改动批量跑 30 个文件 | ✅ 并行（headless / /batch） | 互不依赖，机器代跑最省事 |
| 「先重构 A，再基于新 A 改 B」 | ❌ 串行 | B 依赖 A 的结果，并行只会拿到旧 A |
两个会话都要改 package.json | ❌ 串行（或务必 worktree 隔离） | 抢同一份文件，正是开头那个坑 |
| 一个小改动，五分钟能干完 | ❌ 串行 | 拆开的协调成本比省下的时间还多 |
| 任务之间要频繁互通中间结果 | ⚠️ 看情况 | 沟通成本高，不如一个会话顺着干 |
下面三条土规矩，是踩出来的经验，送给你。
第一，有先后依赖的活儿，死活别并行。 「重构完核心模块，再让其他模块适配新接口」这种，后一步就得等前一步——硬并行，后面那个会照着旧版本改，跑完发现全得返工。这么干一次，就白白浪费两个会话的额度。
第二，小活儿别拆。 五分钟能改完的东西，你光是「想清楚怎么拆、开几个会话、回头怎么合并」就不止五分钟。拆活儿本身有成本，小活儿拆了纯亏。
第三，并行越多越烧额度。 第 04 节那条得再强调一遍：并行十个会话，额度大约按十倍速度烧。一个稳妥的习惯是——手动并行控制在三五个以内，真要大批量（几十上百）就交给 /batch 或动态工作流去工程化，而不是手动开一屏会话。
说白了，并行是把双刃剑：对的场景上它，效率翻几倍；错的场景上它，比串行还慢还贵还乱。判断「该不该并行」，永远比「怎么并行」更值钱。
💡 一句话总结：值得并行的铁律是**「独立 + 不抢文件」**，少一条就别拆；有先后依赖的活儿、五分钟的小活儿别并行；并行越多越烧额度，控制在三五个以内，大批量交给
/batch。
07 动手：亲手跑一遍 worktree 隔离 + 后台甩任务
光看不练假把式。下面这套全程基于一个 git 仓库，没仓库的先随便建一个练手。命令真实可跑，每步都给了预期输出，你照着走一遍，这几套手段就有肌肉记忆了。
用到 git 仓库；后台会话部分需要较新版本的 Claude Code（agent view 是研究预览），先
claude --version看一眼。下面命令不依赖魔法上网。
第一步：进一个 git 项目，先接受信任对话框
bash
cd 你的某个git项目
claude进去后随便问一句（比如「这个项目是干嘛的」）再退出。这一步是为了接受工作区信任——没接受过，下一步 --worktree 会直接报错。
第二步：用 --worktree 开一个隔离会话
bash
claude --worktree test-parallel预期：Claude 在 .claude/worktrees/test-parallel/ 下建好一个隔离 worktree 并在里头启动。你在这个会话里改任何文件，都只动这份副本，主目录纹丝不动。退出时如果改过东西，它会问你「保留还是删除」——练手就选删除。
第三步：确认 worktree 真建出来了（另开一个终端，回到主项目目录）
bash
git worktree list预期：列表里除了主检出，多出一行指向 .../.claude/worktrees/test-parallel，带自己的分支。看到这行 = 隔离副本确实建好了。
第四步：把一个任务甩到后台
bash
claude --bg "列出这个项目所有 markdown 文件的标题"预期：终端打印一行 backgrounded · <短ID>，后面跟着 claude attach / claude logs / claude stop 几条管理命令。看到这串 = 任务已甩进后台在跑，你的终端立刻就能干别的。
第五步：打开塔台屏盯它
bash
claude agents预期：整个终端被代理视图占满，刚甩的那个会话作为一行出现，旁边标着状态（工作中 / 已完成）。选中它按 Space 窥视输出，按 Esc 关面板，再按 Esc 退出代理视图。看到这块分组列表 = 你已经能用一块屏管多个后台会话了。
第六步：清理
bash
# 停掉刚才那个后台会话（短ID 换成第四步打印的）
claude stop <短ID>
# 删掉练手的 worktree（在主项目目录）
git worktree remove .claude/worktrees/test-parallel预期：claude stop 打印停止确认；git worktree remove 之后再跑一次 git worktree list，那行 test-parallel 已经没了。清干净 = 一条完整链路走通。
跑通这六步，你就把「开隔离会话 → 确认副本 → 甩后台 → 塔台盯 → 清理」这条并行主链亲手走了一遍。以后真要并行干活，本质都是这套，无非换任务、加几个会话。
💡 一句话总结：动手链路就六步——
claude（接受信任）→--worktree开隔离会话 →git worktree list确认 →--bg甩后台 →claude agents盯 →stop+git worktree remove清理；走通一遍比记十条命令都管用。
08 小结
这一篇把「让几个 Claude 同时开工」这件事，从「为什么并行」一路讲到「什么时候别并行」，中间塞了三套能上手的手段。
把核心要点串起来回顾：
| 你想干的事 | 用什么 | 关键点 |
|---|---|---|
| 搞清并行解决啥 | 「独立 + 不抢文件」两前提 | 像超市多开收银口，但每条队得独立 |
| 认清并行有哪几种 | 四种方式一张表 | 「谁协调」是分水岭；agent view / workflows 是研究预览，teams 实验性 |
| 让会话不互相覆盖文件 | --worktree / git worktree | 给每个会话一份独立副本，记牢 .gitignore、.worktreeinclude、清理三坑 |
| 后台甩任务、一屏盯进度 | --bg + claude agents | 后台会话不绑终端，文件隔离自动用 worktree；Space 窥视、Enter 附加 |
| 把任务写进脚本批量跑 | claude -p（headless） | 配 --allowedTools 预批、--bare 加速、--output-format json 拿结构化结果 |
| 判断该不该并行 | 「独立 + 不抢文件」铁律 | 有依赖、小活儿别拆；并行越多越烧额度，控制在三五个内 |
你现在应该能： 看明白并行到底解决什么、铁律是「独立且不抢文件」；分清官方四种并行方式该挑哪个；用 --worktree 给会话开隔离副本，再不重蹈开头那个「互相覆盖」的覆辙；用 --bg 和 claude agents 把任务甩后台、一屏盯着；用 claude -p 把活儿写进脚本批量跑；最重要的是——拿到一个任务，先冷静判断「这玩意儿值不值得并行」，而不是一上头就拆。
回头看开头那个「俩终端同改一个目录」的蠢事，根子就是不懂隔离、也没想清依赖。现在你手里有 worktree 这把隔离的钥匙、也有那条判断线，能比一头扎进去的人少走一大圈弯路。
下一篇 42「环境变量」——这一篇里你已经撞见好几个环境变量了：--bare 背后那个 CLAUDE_CODE_SIMPLE、关掉后台任务的 CLAUDE_CODE_DISABLE_BACKGROUND_TASKS、改配置目录的 CLAUDE_CONFIG_DIR……它们像一排藏在背后的「拨动开关」，不显眼，却能悄悄改掉 Claude Code 的行为。下一篇就把这排开关一个个翻出来，告诉你哪个管什么、哪个值得你动。想想看：同样一条命令，在你机器上和在 CI 里跑出来的行为可能不一样——差别往往就藏在这几个环境变量里。