企业官网建设流程全解析

导读：开发新功能写到一半，突然来个 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（简写-w）：

claude --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 审自己刚写的代码，效果是打折的。换个模型有三个实打实的理由：

1. 没有锚定。模型在同一会话里审自己的代码时，之前的对话还躺在上下文里，它会不自觉地把判断锚向"我刚才是对的"。换一个全新的、不知道这代码哪来的评审，就没有这个包袱。（有研究支撑这个方向：收益来自"隔离"，不是多审一次。）

2. 没有自我偏袒。经过 RLHF 训练的模型有附和倾向，对"自己生成的文本"评分也偏高。让一个"根本没写过这段代码"的模型来看，这种偏袒几乎消失。

3. 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 codex@openai-codex /reload-plugins /codex:setup

装好之后，"Claude 写、Codex 挑错"能在同一个会话里闭环，不用切窗口——对个人开发者是最顺手的互审回路。

方式四：PR 机器人。在 GitHub PR 上评论@codex review，Codex 会贴一份聚焦严重问题的评审。适合已经走 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 的能力。这部分讲清边界就好，帮你判断哪些该用、哪些是杀鸡用牛刀。官方有三个层级的范式：

• Subagent（日常主力）：隔离上下文做调查，主会话只收摘要、省 token，个人项目天天能用。

• Agent Teams（实验功能，一般用不上）：官方明确实验性、默认关闭，要设环境变量才开。（早期教程里的TeamCreate/TeamDelete工具自 v2.1.178 起已移除，看到别照抄。）

• Dynamic Workflows（重型武器，基本不用）：Claude 自己写 JavaScript 脚本编排大批 subagent、后台运行、会话还能继续响应，为超大规模扇出而生。

那"超大规模"长什么样？最有名的是Bun 从 Zig 移植到 Rust：Anthropic 官方博客——用 dynamic workflows，11 天从第一个 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"的单机效率，基本就压榨到位了。