前言

AI 编程工具真正改变效率的地方，不只是“帮你写几行代码”，而是把一个复杂需求拆成多个可验证的小任务：一个会话负责分析，一个会话修改代码，另一个会话运行测试，最后再由主会话统一审查。

不过，当多个任务同时修改同一份代码时，文件覆盖、分支混乱和上下文串线也会随之而来。解决这个问题的关键不是开更多终端，而是给每个任务准备一套互相隔离的工作目录。

这正是本文要介绍的组合：

  • Codex + GPT-5.6 Sol：负责理解仓库、修改代码、执行命令和验证结果；
  • WM（Workspace/Worktree Manager）：负责管理并行任务的工作区；
  • Git Worktree：负责在 Git 层面隔离不同分支的文件；
  • 测试与人工审查：作为合并前的质量闸门。

这套方法适合功能开发、Bug 修复、依赖升级、文档整理和多方案原型验证。下面从原理、搭建到日常使用完整走一遍。

一、先理解这套工作流

1. Codex 负责什么

在一个已经初始化的项目中，Codex 可以读取仓库结构，根据任务修改文件，并调用项目现有的构建、测试和格式化命令。相比只在聊天窗口里生成代码，它更像一名可以在真实开发环境中工作的协作者。

但无论模型能力多强，都不应该把“生成完成”直接等同于“可以上线”。最稳妥的闭环始终是：

1
明确需求 → 检查仓库 → 制订计划 → 修改代码 → 运行测试 → 审查差异 → 提交合并

2. WM 解决什么问题

这里将 WM 统称为工作区管理器。它的核心职责，是把不同任务映射到不同目录和 Git 分支。例如：

工作区 分支 任务
project-main main 保持稳定、负责最终合并
project-login feat/login 开发登录功能
project-bugfix fix/cache 修复缓存问题
project-docs docs/guide 更新使用文档

这样做以后，每个 Codex 会话只处理自己的工作区。即使多个任务同时运行，也不会互相覆盖未提交文件。

3. “无限工作流”不等于“无限额度”

任务数量可以按需要扩展，但机器资源、模型额度和人的审查能力都不是无限的。并行度越高，并不一定越快：

  • 任务拆分不清晰，会产生重复修改；
  • 多个分支改到同一区域，会增加冲突；
  • 同时运行大量构建，会占满 CPU 和内存；
  • 缺少最终审查，会让错误更快进入主分支。

因此，本文追求的是可持续扩展，而不是通过批量账号、共享 Token 或代理轮换来绕过服务限制。请使用官方客户端和正常授权方式，并遵守对应服务条款。

二、准备基础环境

开始之前，建议准备以下工具：

  1. Git 2.20 或更高版本；
  2. 项目所需的 Node.js、Python、Go 或其他运行环境；
  3. 已正常登录的 Codex；
  4. 一个干净的 Git 仓库；
  5. 可选的 WM 图形界面或命令行管理工具。

先检查常用工具：

1
2
3
git --version
node --version
npm --version

再进入项目并确认当前状态：

1
2
3
cd ~/Projects/my-project
git status
git branch --show-current

如果工作区里还有未提交修改，建议先提交、暂存或明确保留原因。不要在状态不明的仓库上直接创建一批并行任务。

提示：不同版本的 Codex 或 WM 界面可能略有差异。安装与登录步骤应以你使用版本的官方说明为准，不要从不明来源下载客户端，也不要把访问令牌交给第三方脚本。

三、不依赖 WM，也能先用 Git Worktree 跑通

WM 的底层思想可以直接用 Git Worktree 演示。假设主仓库位于：

1
~/Projects/my-project

1. 创建两个独立工作区

1
2
3
4
5
cd ~/Projects/my-project
git fetch --all --prune

git worktree add -b feat/user-profile ../my-project-profile main
git worktree add -b fix/api-timeout ../my-project-timeout main

此时目录结构大致如下：

1
2
3
4
~/Projects/
├── my-project/           # 主工作区
├── my-project-profile/   # 用户资料功能
└── my-project-timeout/   # API 超时修复

执行下面的命令可以查看关联关系：

1
git worktree list

2. 分别安装依赖

Worktree 共享 Git 对象，但不共享被忽略的依赖目录。因此，Node.js 项目通常要在每个工作区单独安装依赖：

1
2
3
4
5
cd ~/Projects/my-project-profile
npm ci

cd ~/Projects/my-project-timeout
npm ci

不要直接复制一个来源不明的 node_modules。如果项目依赖安装耗时，可以配置包管理器的全局缓存，而不是让多个任务共用同一个可写依赖目录。

3. 每个目录开启一个独立会话

分别从两个工作区启动 Codex，并给出边界清楚的任务。一个好的任务描述至少包含：

  • 要解决的问题；
  • 允许修改的范围；
  • 不希望改变的行为；
  • 验收标准；
  • 必须执行的测试。

例如，功能任务可以这样写：

1
2
3
4
5
6
7
8
请在当前分支实现用户资料编辑功能。

要求：
1. 只修改 profile 页面及相关 API；
2. 沿用现有组件和表单校验方式；
3. 不调整数据库结构；
4. 补充成功、校验失败和接口失败测试；
5. 完成后运行项目的 lint、单元测试与构建命令，并总结改动。

Bug 修复任务则可以这样写：

1
2
请定位 API 请求偶发超时的原因，先复现并说明根因，再做最小修复。
不要通过无限重试掩盖问题；请补充回归测试，并列出测试命令和结果。

相比“帮我优化一下项目”，这类提示能显著减少无关修改。

四、用 WM 管理并行任务

如果使用带界面的 WM，可以把上面的手工命令变成固定流程。不同工具的按钮名称可能不同，但配置逻辑基本一致。

第一步：导入仓库

选择主仓库目录，让 WM 识别远程地址、默认分支和现有 Worktree。导入后先检查：

  • 默认分支是否为 main 或项目实际使用的稳定分支；
  • 新工作区是否创建在主仓库之外；
  • 分支命名是否符合团队规范；
  • 删除任务时是否会同时删除分支。

最后一项尤其要谨慎。推荐默认只移除工作目录，分支由人工确认后再删除。

第二步：建立任务模板

可以按项目类型保存初始化命令。例如 Node.js 项目：

1
2
npm ci
cp -n .env.example .env

Python 项目可以使用：

1
2
3
python -m venv .venv
. .venv/bin/activate
pip install -r requirements.txt

.env 中不要放入生产密钥。并行工作区应使用本地、测试或临时凭据，且这些文件必须被 .gitignore 排除。

第三步：限制并行数量

个人开发建议先从 2～3 个并行任务开始：

  1. 一个主任务负责实现功能；
  2. 一个辅助任务负责测试、文档或调查；
  3. 主工作区负责审查和合并。

等任务边界和机器负载都稳定后，再逐步增加。盲目打开十几个会话，往往只会得到十几份等待审查的修改。

第四步：为每个任务设置完成条件

建议在 WM 的任务备注中固定记录以下内容：

1
2
3
4
5
6
7
- [ ] 需求已实现
- [ ] 没有越界修改
- [ ] 格式化与静态检查通过
- [ ] 单元/集成测试通过
- [ ] 已检查 git diff
- [ ] 已提交到独立分支
- [ ] 合并后删除临时工作区

任务只有在这些条件全部满足后才算完成，而不是看到 Codex 回复“已完成”就结束。

五、一套可复用的实战流程

下面以“给博客增加站内搜索”为例，演示如何拆分工作。

任务 A：调查与方案设计

让第一个会话只阅读项目，不修改代码：

1
2
分析当前博客的构建方式、主题结构和可用扩展点，给出两种站内搜索方案。
比较构建体积、中文搜索效果、部署依赖和维护成本。不要修改文件。

只读调查可以避免在方向未确定时产生大批无效代码。

任务 B：功能实现

方案确认后，从稳定分支创建 feat/search 工作区：

1
2
根据已确认的本地索引方案实现站内搜索。复用现有主题样式，支持中文关键词，
不得引入外部搜索服务。完成后运行构建并检查生成的索引文件。

任务 C：测试与文档

不要让任务 C 同时修改任务 B 尚未提交的文件。更稳妥的做法是：任务 B 提交后，将其分支同步到一个新的检查工作区，再让 Codex 执行：

1
2
审查本分支的站内搜索实现。重点检查空关键词、特殊字符、无结果状态、
移动端布局和构建体积。发现问题时先列出证据，再进行最小修改，并补充使用文档。

主工作区：最终审查

回到主工作区，先查看提交和差异：

1
2
3
git log --oneline main..feat/search
git diff --stat main...feat/search
git diff main...feat/search

然后在本地合并并运行完整验证：

1
2
3
4
git switch main
git merge --no-ff feat/search
npm test
npm run build

如果项目没有 npm test，就运行仓库实际提供的检查命令。不要为了让流程“看起来完整”而编造不存在的测试。

六、让 GPT-5.6 Sol 更稳定的提示词方法

1. 先让模型读规则

仓库经常包含 AGENTS.md、CONTRIBUTING.md、README.md 或代码风格配置。任务开头可以明确要求：

1
2
开始修改前，请先阅读仓库内的开发说明和与目标文件相关的规则，
再检查 git status。不要覆盖现有未提交修改。

2. 要求“先证据，后结论”

遇到 Bug 时，先要求模型找到复现方式、错误日志或失败测试，再修改代码：

1
2
请先复现问题，并指出根因对应的文件与代码路径。
在没有证据前不要大规模重构。修复后用同一复现步骤验证。

3. 限制修改半径

上下文越多不代表结果越好。可以限定目录、文件类型或禁止事项：

1
2
只修改 src/auth 和对应测试；不要升级依赖，不要调整公共 API，
不要格式化无关文件。如确实需要越界修改，请先说明原因。

4. 把验证写进任务，而不是留到最后

推荐让模型在每个阶段执行最接近改动的检查：

1
2
完成一个小步骤后先运行相关测试；所有修改完成后再运行完整 lint 和 build。
如果命令失败，请区分代码问题与环境限制，不要隐瞒失败结果。

5. 要求输出交接清单

每个会话结束时，至少应交代：

  • 修改了哪些文件；
  • 为什么这样实现；
  • 执行了哪些命令；
  • 哪些测试通过或失败；
  • 是否存在风险和后续工作；
  • 提交哈希或待提交状态。

这份清单能让主工作区快速判断某个分支是否适合合并。

七、常见问题与排查

1. 为什么不能在两个 Worktree 使用同一分支

Git 默认不允许同一个分支同时被多个 Worktree 检出，这是为了避免两个目录同时推进同一个分支而造成状态混乱。正确做法是每个任务使用独立分支，最后通过合并或变基整合。

2. 删除目录后，Worktree 记录还在怎么办

先查看状态，再清理失效记录：

1
2
git worktree list
git worktree prune

正常移除工作区时，优先使用：

1
git worktree remove ../my-project-profile

确认分支已经合并后，再删除分支：

1
git branch -d feat/user-profile

不要随手使用大写 -D 强制删除尚未合并的工作。

3. 多个任务产生冲突怎么办

冲突通常说明任务边界重叠。处理时应：

  1. 暂停继续生成代码；
  2. 确定哪个分支先合并；
  3. 在另一个分支同步最新主分支；
  4. 人工理解冲突两侧意图；
  5. 解决后重新运行相关测试。

不要把冲突文件整份交给模型盲选一边，否则很容易丢失另一项功能。

4. 环境变量和端口互相抢占

并行启动多个服务时，为每个工作区分配不同端口和独立测试数据库。例如：

1
2
3
4
5
# 工作区 A
PORT=3101 DATABASE_URL=postgres://localhost/app_a npm run dev

# 工作区 B
PORT=3102 DATABASE_URL=postgres://localhost/app_b npm run dev

数据库迁移、云资源和消息队列尤其需要隔离。否则代码目录虽然分开，外部状态仍可能互相污染。

5. Codex 修改得太多怎么办

先用 git diff --stat 判断范围，再用 git diff 逐段审查。如果大部分改动与目标无关，最好的方式通常不是继续打补丁，而是保留必要片段、回退分支，然后用更清晰的约束重新执行。

八、安全与成本边界

高效工作流必须建立在可控的权限上：

  • 不在提示词、日志或提交中粘贴 API Key、Cookie 和访问令牌；
  • 给开发环境使用最小权限账号；
  • 涉及删除数据、发布、付款和生产部署时保留人工确认；
  • 不执行来源不明的一键脚本；
  • 不通过共享账号、批量注册或轮换凭据绕过额度；
  • 定期检查 Worktree、后台进程、临时数据库和云资源，避免持续计费。

对于包含生产数据、隐私信息或商业机密的仓库，还要先确认团队的数据处理规范，再决定哪些内容可以交给 AI 工具处理。

九、推荐的日常使用节奏

最后给出一套简单、可长期坚持的节奏：

开始任务前

1
2
3
git status
git fetch --all --prune
git worktree list

确认主分支干净，再为任务建立独立分支和工作区。

任务进行中

  • 一次只给一个会话一个明确目标；
  • 小步修改、小步测试；
  • 每个阶段检查 git diff；
  • 发现任务重叠时及时停止并重新划分边界。

合并之前

1
2
git diff --check
git diff main...your-branch

随后运行项目的格式化、静态检查、测试和构建命令，并进行人工代码审查。

合并之后

1
2
3
git worktree remove ../your-task-worktree
git worktree prune
git branch -d your-task-branch

同时关闭不再使用的开发服务，清理临时数据库和任务备注。

总结

Codex GPT-5.6 Sol 与 WM 的价值，不是让一个人无节制地开启更多 AI 会话，而是把软件开发变成一条边界清晰、结果可验证的流水线。

真正可靠的组合可以概括为四点：

  1. 用 Worktree 隔离文件和分支；
  2. 用清晰提示词隔离任务上下文；
  3. 用测试与差异审查约束生成结果；
  4. 用人工决策守住合并、发布和权限边界。

从两个并行工作区开始，先把任务拆分、验证和清理流程跑顺，再逐步扩展。这样得到的才不是一次性的“AI 炫技”，而是一套真正能够融入日常开发的高效工作方式。