终端里的半日分支：让多个智能体只交付一个小补丁

先把缓存修复缩成一个可合并的任务

智能体写代码很快，团队消化改动却不会同步提速。一个分支同时塞进缓存修复、接口重命名和依赖升级，最后通常不是省时间，而是让审查者重新理解半个项目。我更愿意把分支限制为一个行为变化，争取半天内送审；半天是提醒拆任务的信号，不是绕过检查的截止时间。

这次演练只修一个问题：相同请求使用不同模型时，缓存键必须不同。假设仓库使用 npm，已经提交锁文件，测试框架是 Vitest，并有 lint、test、build 三个脚本；实现和测试分别位于 src/cache-key.ts 与 tests/cache-key.test.ts。下面命令在同一个终端会话运行，需要 Git、Node.js，以及已登录的 GitHub CLI。

从干净的主分支创建独立工作树

先确认当前工作区没有未提交改动，再同步主分支。第一条检查失败时，先提交或妥善保存自己的工作，不要接着执行。

test -z "$(git status --porcelain)" && git switch main && git pull --ff-only

ROOT=$(pwd) — git worktree add -b fix/cache-model-key ../fluxo-cache-key origin/main

cd ../fluxo-cache-key && npm ci — 工作树隔离的是文件和索引，不是整个运行环境。如果另一个智能体需要启动服务，还要分配不同端口；不要让两个实例共用可写数据库。另一个任务也应该拥有自己的分支，而不是在这个目录里抢着修改文件。

给写代码的智能体两条文件边界

在编辑器里交给智能体的任务可以直接写成：“只修改 src/cache-key.ts 和 tests/cache-key.test.ts；先增加回归测试，证明相同请求在不同模型下生成不同缓存键，再做最小修复。不要升级依赖，不要重构无关函数；如果必须修改第三个文件，先停下来说明原因。”

第二个智能体只负责只读审查：检查键是否存在拼接歧义、原有缓存行为是否被意外改变，不直接写文件。一个写入者配一个审查者，比两个智能体同时编辑同一实现更容易收敛。

如果团队通过 Fluxo 调用模型，可以让 Claude Sonnet 5.5 处理补丁，让 GPT-6.1 Sol 提出反例。Fluxo 用一个密钥和同一个基础地址 https://api.fluxorelay.com 接入多家模型，可配合 Claude Code、Codex、Gemini CLI，以及使用 OpenAI SDK 的工具。密钥交给本地环境或密钥管理器，不要放进任务说明、补丁或提交记录。

先看测试失败，再看最小修复通过

让智能体只添加回归测试，暂时不改实现，然后执行： — npm test -- --run tests/cache-key.test.ts

这里应该看到目标断言失败，而不是模块找不到、依赖缺失或测试根本没有运行。确认测试确实抓住缓存碰撞后，再允许修改实现。修复完成后，运行完整检查，而不只运行刚新增的用例：

git diff --check && npm run lint && npm test -- --run && npm run build

接着执行 git diff -- src/cache-key.ts tests/cache-key.test.ts，逐段阅读。测试通过只能证明覆盖到的行为成立，不能替你发现顺手改掉的公共接口。

只提交两个文件，再同步一次主分支

不要习惯性执行 git add .。明确暂存目标文件，可以挡住智能体留下的临时输出和无关格式化。 — git add -- src/cache-key.ts tests/cache-key.test.ts

git diff --cached --stat — git diff --cached

git commit -m "修复不同模型之间的缓存键碰撞"

git fetch origin && git rebase origin/main

如果发生冲突，先处理冲突并执行 git rebase --continue；拿不准就用 git rebase --abort，不要让智能体盲目选择某一侧。变基成功后，再运行前面的完整检查链。这里暂不推送，避免为正常同步主分支而强推远端。

把拉取请求写成一个行为说明

git push -u origin fix/cache-model-key — gh pr create --base main --title "修复不同模型之间的缓存键碰撞" --body "范围：缓存键纳入模型标识。验证：新增跨模型回归测试，并通过检查、测试和构建。不包含：依赖升级与无关重构。"

gh pr checks --watch — 等待必需检查完成，并让真人确认关键差异。若团队配置了合并队列，就按队列流程处理；否则，在满足仓库审查要求后执行：

gh pr merge --squash — 确认已经合并，才清理工作树与本地分支。下面用状态检查保护删除操作；压缩合并后，本地提交未必是主分支祖先，因此这里明确使用 -D。

test "$(gh pr view --json state --jq .state)" = MERGED && cd "$ROOT" && git pull --ff-only && git worktree remove ../fluxo-cache-key && git branch -D fix/cache-model-key

让试错成本跟着小分支一起缩小

小分支减少的不是生成次数，而是每次需要验证的范围。Fluxo 按实际令牌计费，包含缓存读取和写入，没有月费；排查成本时，把这些用量一起看，不要只数提示词长度。如果你想把这套流程接进自己的终端，可以创建一个 Fluxo 账号试试。邀请用户付费后，邀请人也会获得分成；需要帮助时，登录后在联系页面留言即可。

最终标准很简单：一个分支解释一个行为，一个补丁能被完整读懂，一个失败能被单独撤回。智能体可以并行思考，但交付边界必须清楚。