导读开发新功能写到一半突然来个 bug 要修——你是不是还在git stash里来回倒腾这篇给你两件个人开发者天天能用的事① 用 git worktree 在一个仓库里开多条互不干扰的并行工作线② 写完别只问 Claude 对吗把 diff 丢给另一个模型让它证明你错了。命令和提问句式都可照抄。那天我正用 Claude Code 在项目里开发一个新功能代码写到一半——线上冒出来一个 bug得马上修。这个场景你八成不陌生手头的功能还没写完另一件急事插进来两件事却挤在同一个工作目录、同一个分支上。放以前我只有一条路git stash把手头没写完的活塞起来、切到修 bug 的分支、改完、切回来、再git stash pop捞回去。来回切几次stash 串味、改丢东西是常事脑子还得在两件事之间反复横跳。这次我没 stash。我开了第二个worktree——同一个仓库多一个独立的工作目录、独立的分支。两个终端、两个 Claude 会话一个继续写新功能、一个专心修 bug俩谁也不碰谁的文件。修完 bug 那个直接提交合并新功能这边一行没断。上一篇第 7 篇我们把单条工作线配顺了——MCP、Subagent、Hook、Skill 各就各位。这一篇把视角再拉开怎么同时铺开多条工作线worktree 并行以及怎么让另一个模型来挑你这条线的错双模型互审。一句话别让单个工作区、单个模型成为你的瓶颈和盲区。说明worktree 命令依据 git 官方文档Claude Code / Codex / Gemini 用法依据各自官方文档2026-06 核对示例用通用小项目不涉及任何业务代码。第一部分git worktree——一个仓库多条并行工作线先一句话git worktree 是什么它是Git 自 2.5 版本2015 年 7 月就内置的官方功能——不是插件、不用装任何东西git自带。作用只有一句让同一个仓库同时拥有多个工作目录每个目录一个 worktree可以各自停在不同分支上、独立改动、互不干扰。打个比方过去一个仓库只能开一扇门一个工作目录你一次只能进一间屋子干活worktree 让你在同一栋房子同一份.git历史上多开几扇门每扇门后是一间独立的房间——你可以同时在好几间屋里各干各的互不打扰。一句话原理共享历史各自工作区平时我们一个仓库对一个工作目录同一时刻只能待在一个分支上。git worktree 打破的就是这条一个 git 仓库可以同时签出多个工作目录每个目录是一个 worktree各自待在一个分支上。共享的提交历史、objects、远端——整个仓库只有一份.git。独立的每个 worktree 有自己的工作区文件、自己的暂存区index、自己签出的分支。所以在 A 目录里改文件、git add绝不会动到 B 目录。两个 Claude 各自在一个 worktree 里折腾文件层面物理隔离但提交进的是同一部历史。worktree 让同一个仓库、两个隔离工作区、两个并行 Claude成为可能——不用再靠 stash 在一个目录里腾挪。可照抄的命令速查# 在【已有分支】上开一个 worktree git worktree add ../app-feature feature-a # 在【新建分支】上开一个 worktree默认从当前 HEAD 切出 git worktree add ../app-feature -b feature-a # 列出所有 worktree主工作区排第一其余是 linked worktree git worktree list # 用完移除必须是干净的见下方坑 git worktree remove ../app-feature git worktree remove --force ../app-feature # 有未提交改动时强制移除 # 手动删了目录后清理 .git 里残留的登记信息 git worktree prune并行 Claude 的标准动作两个终端、两个分支、一个仓库# 终端 1开发新功能 git worktree add ../app-feature -b feature-x cd ../app-feature claude # 终端 2同时修 bug git worktree add ../app-bugfix -b bugfix-123 cd ../app-bugfix claude这正是 Claude Code 官方推荐的范式在各自的 worktree 里跑 Claude Code一个会话里的编辑永远不会碰到另一个会话的文件所以你可以在一个终端里让 Claude 开发功能同时在第二个终端里修 bug。嫌敲命令麻烦Claude Code 自带一键 worktree如果你不想手动敲那串 git 命令Claude Code 内置了--worktree简写-wclaude --worktree feature-auth它会在.claude/worktrees/feature-auth/下自动创建一个隔离 worktree、分支名为worktree-feature-auth并直接在里面启动 Claude。想并行就换个名字、在第二个终端再跑一次。官方还提醒一句把.claude/worktrees/加进.gitignore。先掌握手动git worktree机制通用、放之四海皆准再把--worktree当省事的语法糖——两个都会按口味选。讲透三个坑坑一同一个分支不能在两个 worktree 同时签出。你想在第二个 worktree 里再签出main会被直接拒绝除非--force。同一分支两处签出、两边乱改HEAD 会打架。一个 worktree 占一个分支所以前面修 bug 才要新建bugfix-123而不是复用 main。坑二移除 worktree 要干净。只有干净的 worktree没有未跟踪文件、没有已跟踪文件的改动才能被remove。有没提交的改动时直接remove会失败——先提交或 stash实在要丢就--force。能用remove就别手动rm -rf删目录否则得再git worktree prune去清残留登记。坑三新 worktree 是全新签出环境要重建。这是最常撞的为什么新 worktree 里跑不起来。worktree 只复制 git 跟踪的文件那些没被跟踪的——.env、node_modules、Python 虚拟环境——不会带过去。进新 worktree 后该npm install、该建 venv 的照样得做一遍。worktree 的护城河不在那行add而在这三条约束一分支一 worktree、移除要干净、新签出要重建环境——知道它们并行才不翻车。第二部分双模型互审——让另一个模型当反方工作线能并行了再说质量。代码写完你大概率会顺手问一句这段对吧——但问的还是刚写它的那个 Claude。这一节讲一个更狠也更有效的习惯把改动丢给另一个模型让它来证明你错了。核心思路diff 就是一段文本道理简单到一句话**git diff的输出就是一段纯文本任何能读 stdin 或接收提示词的 CLI 都能审它。** 所以让 OpenAI 的 Codex、或 Google 的 Gemini 来审 Claude 写的代码技术上毫无障碍——把 diff 喂过去就行。为什么换个模型才真有用同一个会话里让 Claude 审自己刚写的代码效果是打折的。换个模型有三个实打实的理由没有锚定。模型在同一会话里审自己的代码时之前的对话还躺在上下文里它会不自觉地把判断锚向我刚才是对的。换一个全新的、不知道这代码哪来的评审就没有这个包袱。有研究支撑这个方向收益来自隔离不是多审一次。没有自我偏袒。经过 RLHF 训练的模型有附和倾向对自己生成的文本评分也偏高。让一个根本没写过这段代码的模型来看这种偏袒几乎消失。bug 盲区不同。Claude 和 Codex 训练思路不同犯错和漏看的类型也不同Claude 漏的Codex 可能一眼揪出反之亦然。这是强实践共识换模型能多抓 3-5 倍 bug是博客口径、不是同行评审数据当方向看就行。换个模型给你的是没有锚定的新上下文 没有护短的动机 不一样的盲区——这三样同会话自审给不了。怎么把 diff 喂给另一个模型可照抄方式一管道喂给另一个模型的 CLI最通用# 让 Codex 审 Claude 的改动 git diff main..HEAD | codex exec 你是一位极度挑剔的评审。找出这段 diff 里的正确性 bug、边界情况和安全问题。 # 用 Gemini CLI 的非交互模式 git diff --staged | gemini -p 评审这段 diff只报告高/中严重级别的问题并标注严重级别。codex exec是 Codex CLI 的非交互模式、接受管道输入gemini -p 提示词是 Gemini CLI 的 headless 模式。注意 Gemini CLI 目前还没有原生的/review命令所以对它来说管道喂 diff就是正路。方式二Codex 自带的评审器。交互式/review命令有菜单审未提交改动、对某个基准分支审、审某个具体 commit、或自定义指令它给出按优先级排序的发现、不改你的代码。也能存档codex review --uncommitted codex-review.txt。方式三在 Claude Code 里直接调 Codex个人开发者最省事。OpenAI 出了一个给 Claude Code 用的官方插件codex-plugin-cc/plugin marketplace add openai/codex-plugin-cc /plugin install codexopenai-codex /reload-plugins /codex:setup装好之后Claude 写、Codex 挑错能在同一个会话里闭环不用切窗口——对个人开发者是最顺手的互审回路。方式四PR 机器人。在 GitHub PR 上评论codex reviewCodex 会贴一份聚焦严重问题的评审。适合已经走 PR 流程的项目。可照抄的挑错句式裸喂一句 review this diff 产出往往又长又水。真正管用的提问有两个万能开关① 要求标注严重级别高/中/低② 要求没发现严重问题就明说、别凑数。这一句能挡掉大半噪声。下面几条可以直接贴在 diff 后面通用对抗式有罪推定你是一位极度挑剔的资深评审。下面的 diff 由另一个 AI 编写可能存在隐蔽错误。在被证明正确之前默认它是有问题的。请找出正确性 bug、被遗漏的边界情况和安全问题。每条给出严重级别高/中/低、具体行号、为什么错、一个可落地的修复。忽略代码风格。如果确实没发现严重问题请明确说明——不要为了凑数而编造问题。两轮法压误报最有效的一招请分两轮评审这段 diff。第一轮善意理解简要说明这段代码想做什么、以及它大概率没问题的理由。第二轮攻击现在努力推翻你第一轮的结论找出它实际会失败的情形。只有当一个问题能扛过你自己第二轮的审视才标为高严重级别。安全红队碰认证/加密/用户输入时用你是一名安全评审正在对这段 diff 做红队审计。重点排查注入SQL/命令/路径、缺失的认证/授权、硬编码或写入日志的密钥、不安全的反序列化、SSRF、未经校验就流向危险操作的用户输入。按可利用性排序每条给出具体攻击场景和修复。只报告真实可被利用的问题。那个两轮法——先逼模型说这代码为什么大概率没问题再逼它推翻自己——是单条里压低误报最有效的杠杆。诚实边界什么时候值得审什么时候是过度设计互审不是免费的它最大的失败模式是误报。各家口径差异很大——好的专用工具误报率约 5%–15%泛用 AI 评审可能高达 60%–90% 噪声。误报多了会引发告警疲劳当大半提示都是吹毛求疵你会开始无视全部反而漏掉那真正要命的 10%。再加上多一个模型 多一份 API 账单 每次 diff 多一轮往返。还有一点两个模型都同意 ≠ 正确它们可能共享同一个盲区。所以要挑场合值得审安全敏感代码认证、加密、碰钱碰用户数据、涉并发或边界、难以靠跑一下验证的、大改动或你自己脑子装不下整段 diff 的——以及合并到 main 前 / 发布前这个关卡。过度设计琐碎改动、原型、一次性脚本、有良好测试覆盖的格式化重构对每个commit 都跑互审一个人却去搭6 模型投票 综合的流水线——那是企业级表演。个人开发者的正确姿势一个第二模型、对抗式提问、放在合并/发布关卡跑、开严重级别过滤——不是模型投票团也不是每个 commit 都审。第三部分再往上是多智能体编排——但你大概率用不上worktree 是你手动开几条并行线。再往上Claude Code 还有让 AI 自己编排一群 agent 的能力。这部分讲清边界就好帮你判断哪些该用、哪些是杀鸡用牛刀。官方有三个层级的范式维度SubagentAgent TeamsDynamic Workflows谁决定下一步Claude 逐轮决定Lead agent 逐轮脚本决定上下文各自独立、结果回汇主线各自完全独立各 agent 独立规模每轮少量委派一小撮长时运行的同伴每次数十到数百 agenttoken 成本低摘要回汇高每个队友独立实例取决于扇出规模Subagent日常主力隔离上下文做调查主会话只收摘要、省 token个人项目天天能用。Agent Teams实验功能一般用不上官方明确实验性、默认关闭要设环境变量才开。早期教程里的TeamCreate/TeamDelete工具自 v2.1.178 起已移除看到别照抄。Dynamic Workflows重型武器基本不用Claude 自己写 JavaScript 脚本编排大批 subagent、后台运行、会话还能继续响应为超大规模扇出而生。那超大规模长什么样最有名的是Bun 从 Zig 移植到 RustAnthropic 官方博客——用 dynamic workflows11 天从第一个 commit 到合并、约75 万行 Rust、现有测试套件99.8% 通过、上百个 agent 并行每个文件配两个评审。网上不少转载写成96 万行 / 6 天以官方 75 万行 / 11 天为准。另外一个常见误传dynamic workflows 不是单次上限 1000 个 agent官方口径是最多 16 个并发、单次运行累计最多 1000 个。对个人开发者worktree Subagent 是天天能用的主力Agent Teams 知道它存在即可Dynamic Workflows 是为 75 万行级移植准备的你的项目用上它基本就是过度设计。能力越大越要分清自己在不在那个量级。结尾别让单点成为瓶颈和盲区这一篇的两件事表面是两个技巧骨子里是同一个判断。worktree 是把工作线铺开——别让单个工作目录把你卡在一次只能干一件事双模型互审是把判断铺开——别让单个模型既当运动员又当裁判。一个治串行的瓶颈一个治自审的盲区方向不同针对的都是单点依赖。放在这一季的脉络里第 6 篇教你给上下文减负第 7 篇教你把能力配齐这一篇教你把工作线和判断都铺开。到这里一个人 Claude Code的单机效率基本就压榨到位了。你想解决的问题这一篇给你的工具同时干多件互不干扰的活git worktree/claude --worktree不想被自己模型的盲区坑管道喂 diff 给 Codex/Gemini对抗式提问不知道什么时候该互审合并/发布关卡跑别每个 commit 都审想玩多 agent 编排Subagent 够用Teams/Workflows 知道边界即可