समानांतर कार्य (Parallel Tasks): कई Claude को एक साथ काम पर लगाना, न कि कतार में खड़ा करना

📚 सीरीज नेविगेशन: पिछला लेख 40 Chrome：让它操作浏览器 आपको सिखाता है कि कैसे Claude को ब्राउज़र संचालित करने की अनुमति दें, जिससे वह स्वचालित रूप से पृष्ठों पर क्लिक कर सके और फॉर्म भर सके। यह लेख समानांतरता (parallelism) के बारे में बात करता है—एक ही Claude सत्र में अधिक काम करने के बजाय, कई कार्यों को एक साथ शुरू करना। git worktree अलगाव, बैकग्राउंड सत्र प्रबंधन, और headless बैच प्रोसेसिंग, इन तीनों को विस्तार से समझाया गया है, साथ ही सबसे महत्वपूर्ण बात: समानांतरता कब उपयोगी होती है और कब यह जटिलता बढ़ाती है।

यह कहना थोड़ा शर्मनाक है, लेकिन जब मैंने पहली बार "समानांतर काम करने" के बारे में सोचा था, तो मैंने एक बेवकूफी भरा काम किया था: दो टर्मिनल खोले, दोनों में एक ही प्रोजेक्ट निर्देशिका में cd किया, एक में Claude को फ्रंटएंड लॉगिन पृष्ठ को संशोधित करने के लिए कहा, और दूसरे में इसे बैकएंड बग को ठीक करने के लिए कहा।

मैंने खुशी-खुशी सोचा: "यह दक्षता को दोगुना कर देगा।"

परिणामस्वरूप—दोनों सत्र package.json को संशोधित कर रहे थे, और एक तरफ अभी जोड़े गए निर्भरताओं (dependencies) को दूसरी तरफ के संशोधनों द्वारा सीधे ओवरराइड कर दिया गया था; जब मैंने git status की जांच की, तो पूरा वर्कस्पेस अव्यवस्थित हो गया था, and यह पहचानना असंभव था कि किसने किस लाइन को बदला है। मुझे उन संशोधनों को मैन्युअल रूप से सुलझाने में सामान्य रूप से एक-एक करके काम करने की तुलना में बहुत अधिक समय लगा। तभी मुझे समझ आया: समानांतर काम करना केवल "कई विंडो खोलना" नहीं है, बल्कि मुख्य बात यह है कि "उन्हें एक-दूसरे के कार्य को प्रभावित करने से रोकना"。

वास्तव में, Claude Code में पहले से ही समानांतर काम करने के लिए विशिष्ट उपकरण उपलब्ध हैं—--worktree प्रत्येक सत्र के लिए एक अलग कोड कॉपी प्रदान करता है, --bg कार्यों को बैकग्राउंड में चलाता है, और claude agents आपको उन पर नज़र रखने के लिए एक नियंत्रण केंद्र प्रदान करता है। इस लेख में हम इस विषय को विस्तार से समझाएंगे, और इन उपकरणों का व्यावहारिक उपयोग करना सीखेंगे।

इस लेख को पढ़ने के बाद, आपको मिलेगा:

• एक वाक्य में स्पष्टीकरण कि "समानांतरता क्यों आवश्यक है", और इसके दो मुख्य आधार: कार्य स्वतंत्र होने चाहिए और वे एक ही फ़ाइल को प्रभावित नहीं करने चाहिए
• आधिकारिक तौर पर समर्थित चार समानांतर उपयोग के तरीकों (सब-एजेंट / एजेंट व्यू / एजेंट टीम / गतिशील कार्यप्रवाह) की तुलना, ताकि आप सही विकल्प चुन सकें
• --worktree के माध्यम से प्रत्येक सत्र के लिए एक अलग कॉपी का उपयोग करना ताकि वे एक-दूसरे के कार्य को ओवरराइड न करें—साथ ही .worktreeinclude और फ़ाइलों को साफ़ करने की युक्तियों का विवरण
• claude agents और --bg के माध्यम से कार्यों को बैकग्राउंड में चलाना और एक ही स्क्रीन से प्रगति की निगरानी करना, केवल आवश्यकता होने पर हस्तक्षेप करना
• claude -p (headless मोड) के माध्यम से कार्यों को स्क्रिप्ट में शामिल करके बैच में चलाना, और तेज़ स्टार्टअप के लिए --bare का उपयोग करना
• सबसे महत्वपूर्ण निर्णय रेखा: समानांतरता का उपयोग कब करना सार्थक है, और कब यह जटिलता को और बढ़ाता है

---

01 पहले स्पष्ट करें: समानांतरता किस समस्या को हल करती है, और इसके आधार क्या हैं

पहले निष्कर्ष: समानांतरता इस समस्या को हल करती है कि "कई स्वतंत्र कार्य हैं और आप उन्हें कतार में रखकर प्रतीक्षा नहीं करना चाहते"; लेकिन इसके सफल होने के लिए केवल एक आधार है—ये कार्य एक ही फ़ाइल को प्रभावित नहीं करने चाहिए。

回想前面四十篇，咱们基本都在「一个会话」里折腾——开一个 Claude，给指令，它一步步干。这模式九成的活儿够用。但有两种时候你会嫌它慢。

一是任务天然就能拆开、互不依赖。 比如「改前端样式」「修后端一个 bug」「补一批单元测试」，三件事八竿子打不着，却只能排队：改完前端才轮到后端。明明能同时干，却被逼着串行。

二是任务大到一个会话扛不动。 比如「把整个代码库里某个旧 API 全换成新的」，涉及几十上百个文件，一个会话从头改到尾，上下文（context，可理解成它的「工作记忆」，详见第 19 篇）早塞满了，越往后越「忘事」。

एनालॉजी: सुपरमार्केट में बिलिंग। 一条收银通道，十个人拎着购物车排长龙，第十个人得干等前面九个全结完——这就是串行。聪明的超市会多开几个收银口，十个人分到三四条队里同时结，总时间立刻砍下来。并行干活就是「多开收银口」：几件独立的活，分给几个 Claude 同时结账，而不是挤在一条队里。

但收银口能多开有个隐含前提：每条队是独立的，自动互不干扰。要是三个收银员共用同一个钱箱、同时往里塞钱找零，立刻乱套——这正是开头那个坑。所以并行的铁律就一条：

任务接触相同的文件吗？使用 worktrees 隔离工作。

落到你会遇到的真实场景，能并行的活儿长这样：

• "इन तीन स्वतंत्र मॉड्यूल में बग को अलग-अलग ठीक करना" — इसे three स्वतंत्र सत्रों में विभाजित करके ठीक करें, एक-दूसरे को प्रभावित किए बिना
• "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-<名字>：

claude --worktree feature-auth

想再开第二个独立会话？另一个终端、换个名字，跑同样的命令：

claude --worktree bugfix-123

这下两个会话各在自己的副本里，一个搭功能、一个修 bug，谁也碰不到谁的文件——开头那个「互相覆盖」的惨剧从根上没了。名字懒得起？省略它，Claude 自动生成一个像 bright-running-fox 这样的：

claude --worktree

会话里也能临时让它进 worktree——直接说一句「在 worktree 中工作」，它会用 EnterWorktree 工具给你建一个。

第一次在某个目录用 --worktree 之前，得先在该目录里跑一次普通的 claude，接受那个工作区信任对话框。没接受过信任，--worktree 会直接报错让你先去跑一次 claude——连 -p 模式也一样。

三个新手必踩的坑点

समस्या 1: .claude/worktrees/ को .gitignore में जोड़ा जाना चाहिए। 不然这些 worktree 的内容会在你主目录里显示成一堆「未跟踪文件」，看着碜得慌。官方专门提醒了这条。

समस्या 2: worktree एक साफ़ कॉपी है, और आपकी .env फ़ाइल इसमें मौजूद नहीं होगी। worktree 是个全新检出，主仓库里那些没被 git 跟踪的文件（像 .env、.env.local）默认不会跟过去——结果新会话一跑就缺环境变量。解法是在项目根放一个 .worktreeinclude 文件，列出要自动复制进每个 worktree 的本地文件，语法和 .gitignore 一样：

.env
.env.local
config/secrets.json

这个坑我亲自栽过：兴冲冲 -w 开了个会话准备改后端，结果 Claude 跑起来一直报连不上数据库，我对着报错排查了半天，甚至怀疑是数据库挂了——最后才反应过来，.env 压根没复制进 worktree，连接串它根本读不到。后来在每个项目根都顺手放上 .worktreeinclude，就再没犯过这毛病。

समस्या 3: सत्र से बाहर निकलते समय "सहेजें या हटाएं" चुनना याद रखें। 官方的清理规则很实在：

• 没改任何东西（无未提交改动、无未跟踪文件、无新提交）：worktree 和它的分支会自动删除；但如果会话事先命了名（--name），Claude 会弹提示让你决定保留还是删除。
• 改了东西：Claude 会问你「保留还是删除」——保留就留着目录和分支，以后能回来接着干；删除连同未提交的改动一起丢掉。
• 非交互（-p）跑出来的 worktree 不自动清理，因为没有退出提示，得自己 git worktree remove 删。

手动来建 worktree

要完全掌控 worktree 放哪、用哪个分支，直接用 git 自己建也行（git 工作流第 43 篇会专门讲）：

# 在新分支上建一个 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：

claude --bg "调查一下 SettingsChangeDetector 这个不稳定的测试为啥老挂"

甩出去后，Claude 会打印这个会话的短 ID 和管理它的命令，大概长这样：

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 这块塔台屏管它们

打开总控台：

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 就非交互地跑一次然后退出：

claude -p "找出 auth.py 里的 bug 并修掉" --allowedTools "Read,Edit,Bash"

这里 --allowedTools 是预先批准它能用哪些工具——因为没人在旁边点「同意」，你得提前告诉它「这几样工具随便用，别停下来问」（权限模式详见第 20、35 篇）。

三个让它真正好用的配套

配套一：管道喂数据。 headless 会读标准输入（stdin），所以你能像用任何命令行工具一样，把数据用管道喂进去。比如把构建报错丢给它解释，结果写进文件：

cat build-error.txt | claude -p "简明扼要说清这个构建错误的根因" > output.txt

排查构建挂掉时，就这么一行甩过去——比复制报错粘进会话快多了。

配套二：--bare 让启动更快。 默认 claude -p 会加载和交互会话一样的全套上下文（hooks、skills、plugins、MCP、CLAUDE.md 全读一遍），脚本里跑就嫌慢、还可能被队友 ~/.claude 里的配置干扰。加 --bare 跳过这些自动发现，启动快、结果还在每台机器上一致：

claude --bare -p "总结这个文件" --allowedTools "Read"

官方明确说了：

--bare 是脚本和 SDK 调用的推荐模式，将在未来版本中成为 -p 的默认值。

配套三：--output-format json 拿结构化结果。 脚本要解析 Claude 的输出，纯文本不好处理。加 --output-format json，它会返回带元数据的结构化 JSON（结果、会话 ID，还有 total_cost_usd 这次花了多少钱），配 jq 一提取就能用：

claude -p "总结这个项目" --output-format json | jq -r '.result'

把 headless 拼成「批量」

单条 -p 还不算批量。真正的批量是拿 shell 循环把它套起来——对一批文件各跑一遍同样的活。比如给某个目录下每个 .py 文件都生成一句话说明：

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 拿结构化结果；拿 shell for 循环套起来就是「批量」雏形。

---

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 项目，先接受信任对话框

cd 你的某个git项目
claude

进去后随便问一句（比如「这个项目是干嘛的」）再退出。这一步是为了接受工作区信任——没接受过，下一步 --worktree 会直接报错。

第二步：用 --worktree 开一个隔离会话

claude --worktree test-parallel

预期：Claude 在 .claude/worktrees/test-parallel/ 下建好一个隔离 worktree 并在里头启动。你在这个会话里改任何文件，都只动这份副本，主目录纹丝不动。退出时如果改过东西，它会问你「保留还是删除」——练手就选删除。

第三步：确认 worktree 真建出来了（另开一个终端，回到主项目目录）

git worktree list

预期：列表里除了主检出，多出一行指向 .../.claude/worktrees/test-parallel，带自己的分支。看到这行 = 隔离副本确实建好了。

第四步：把一个任务甩到后台

claude --bg "列出这个项目所有 markdown 文件的标题"

预期：终端打印一行 backgrounded · <短ID>，后面跟着 claude attach / claude logs / claude stop 几条管理命令。看到这串 = 任务已甩进后台在跑，你的终端立刻就能干别的。

第五步：打开塔台屏盯它

claude agents

预期：整个终端被代理视图占满，刚甩的那个会话作为一行出现，旁边标着状态（工作中 / 已完成）。选中它按 Space 窥视输出，按 Esc 关面板，再按 Esc 退出代理视图。看到这块分组列表 = 你已经能用一块屏管多个后台会话了。

第六步：清理

# 停掉刚才那个后台会话（短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 सारांश

इस लेख में हमने Hook को "这是什么" से लेकर "怎么配、怎么调" 一路讲到。

समीक्षा के लिए मुख्य बिंदुओं को एक साथ जोड़ें:

वह कार्य जो आप करना चाहते हैं	क्या उपयोग करें	मुख्य बिंदु
समझना कि समानांतरता क्या है	स्वतंत्रता और कोई फ़ाइल टकराव नहीं	Supermarket counter, प्रत्येक स्वतंत्र होना चाहिए
认清并行有哪几种	四种方式一张表	「谁协调」是分水岭；agent view / workflows 是研究预览，teams 实验性
让会话不互相覆盖文件	--worktree / git worktree	給每个会话一份独立副本，记牢 .gitignore、.worktreeinclude、清理三坑
后台甩任务、一屏盯进度	--bg + claude agents	后台会话不绑终端，文件隔离自动用 worktree；Space 窥视、Enter 附加
把任务写进脚本批量跑	claude -p（headless）	配 --allowedTools 预批、--bare 加速、--output-format json 拿结构化结果
局断该不该并行	「独立 + 不抢文件」铁律	有依赖、小活儿别拆；并行越多越烧额度，控制在三五个内

अब आपको यह करने में सक्षम होना चाहिए: claude xxx --yyy की किसी भी कमांड को कमांड और फ़्लैग में विभाजित करके प्रत्येक के कार्य को समझना; पिछली बातचीत जारी रखने के लिए -c या -r का उपयोग करना;脚本 में इसका उपयोग करते समय -p, पाइप और --output-format json का उपयोग करना, और निकास कोड से सफलता की जांच करना; किसी अपरिचित फ़्लैग का सामना होने पर संदर्भ तालिका या आधिकारिक संदर्भ दस्तावेज़ों की जांच करना। यह कमांड लाइन कौशल ही Claude Code को एक सरल चैट विंडो से आपकी विकास प्रक्रिया में एक प्रोग्राम करने योग्य घटक में बदलने वाली विभाजक रेखा है।

शुरुआत में बताई गई केवल claude टाइप करने की आदत को छोड़कर, -p और पाइप का उपयोग सीखने पर, आप उन सभी मैन्युअल कार्यों को स्क्रिप्ट में बदल सकते हैं जिन्हें आप प्रतिदिन चलाते हैं—यह अनुभव Claude को "सह-चालक" से हटाकर सीधे "असेंबली लाइन" पर स्थापित करने जैसा है। यह लेख आपको वही अनुभव प्रदान करना चाहता था।

---

अगला लेख 42 "पर्यावरण चर (Environment Variables)" — इस लेख में हमने कई पर्यावरण चरों को देखा है: --bare के पीछे का CLAUDE_CODE_SIMPLE, बैकग्राउंड कार्यों को अक्षम करने वाला CLAUDE_CODE_DISABLE_BACKGROUND_TASKS, और कॉन्फ़िगरेशन निर्देशिका बदलने वाला CLAUDE_CONFIG_DIR। वे परदे के पीछे के स्विचों के संग्रह की तरह हैं, जो अदृश्य रहते हैं लेकिन Claude Code के व्यवहार को नियंत्रित करते हैं। अगले लेख में हम इन चरों की समीक्षा करेंगे कि वे क्या करते हैं और आप उनका उपयोग कैसे कर सकते हैं। इसके बारे में सोचें: एक ही कमांड आपकी मशीन पर और सीआई (CI) में अलग व्यवहार क्यों प्रदर्शित कर सकती है—अंतर अक्सर इन पर्यावरण चरों में छिपा होता है।

---

अनुशंसित पठन

• कैसे पूछें और निर्देश दें: अपनी बात को Claude के अनुकूल बनाना
• शब्दावली (शुरुआती-अनुकूल): तकनीकी शब्दों का सरल अनुवाद
• GitHub Actions: PR में @ करके Claude को काम पर लगाना