企业官网建设流程全解析

1. 三个 AI 并行写完代码，merge 那一刻我人傻了

先说结论：Git Worktree 本身没问题，问题出在合并阶段。我用wt-claude、wt-codex、wt-gemini三个目录让三个模型并行改同一个 Todo 页面，各自跑起来都挺好看，结果git merge的时候冲突像爆米花一样往外蹦——公共组件被改了三遍，样式变量被覆盖，连index.html里的按钮结构都对不上。这不是模型不行，是三个 AI 在互不知情的情况下动了同一批文件。

这篇文章只讲一件事：冲突已经爆发了，怎么用 Codex 配合 TaoToken 的稳定通道，把三个 worktree 的改动逐个对照 diff，快速定位到底谁改了哪一行、该保留谁。适合已经在用 Git Worktree 做多模型并行开发、但卡在合并环节的开发者。核心检索词就三个：Git Worktree 冲突排查、Codex 多目录 diff、TaoToken API Base URL 配置。

我试过最笨的办法是手动开三个编辑器窗口肉眼比对，改到第三个目录时已经忘了第一个改了什么。后来换成让 Codex 按目录逐个读 diff，效率完全不一样。下面把完整流程拆开讲，包括 Key 怎么拿、Codex 怎么配、冲突怎么定位、报错怎么排。

2. 先解决通道问题：TaoToken 给 Codex 一个不中断的模型入口

排查冲突这件事，最怕的是 AI 调用到一半断了。你正让 Codex 对比wt-claude和wt-codex的样式差异，结果请求超时，上下文丢了，又得从头描述一遍三个目录的结构。所以第一步不是急着 merge，而是先把 Codex 的模型通道固定下来。

TaoToken 在这里的角色很单纯：给 Codex 提供一个稳定的 API 入口，让排查过程中的模型调用不中断。它不是编辑器，也不碰你的 Git 仓库，只负责把请求稳稳地送到模型那边。你需要做的只有两件事——创建 Key，然后把 Codex 的 API Base URL 指过去。

创建 Key 的入口在官网，注册后进控制台就能生成。地址是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end ，进去之后找 API Keys 页面。Key 生成后复制保存，后面配置 Codex 要用。

这里有个细节要注意：Codex 的 API Base URL 填https://taotoken.net/api，结尾不要带/v1。很多人习惯性加上/v1，结果请求 404，还以为是 Key 的问题。记住这个地址不带版本路径，Codex 自己会拼。

如果你后面要长期跑多模型并行开发、甚至挂 Agent 自动改代码，可以顺带看下 Coding Plan，它更适合高频调用的场景。只是这次排查冲突，用按量计费的 Key 就够了。

3. 可复制配置：把 Codex 接到 TaoToken 并指向三个 worktree

配置分两层：一层是 Codex 本身的模型通道，一层是让 Codex 知道去哪几个目录读 diff。先配通道。

Codex 的配置文件通常在用户目录下的.codex/config.toml（不同版本路径略有差异，以你本地为准）。核心是改base_url和api_key两项：

# ~/.codex/config.toml model = "gpt-5-codex" model_provider = "taotoken" [model_providers.taotoken] name = "TaoToken" base_url = "https://taotoken.net/api" env_key = "TAOTOKEN_API_KEY" wire_api = "chat"

然后在环境变量里放 Key，别把 Key 硬写进配置文件：

# macOS / Linux export TAOTOKEN_API_KEY="sk-你复制的Key" # Windows PowerShell $env:TAOTOKEN_API_KEY="sk-你复制的Key"

配完之后验证一下通道通不通，直接发一个最小请求：

curl https://taotoken.net/api/chat/completions \ -H "Authorization: Bearer $TAOTOKEN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-5-codex", "messages": [{"role": "user", "content": "ping"}] }'

返回里有正常的choices字段，说明通道没问题。这一步别跳过，通道没通就去排查冲突，等于白忙。

通道通了之后，让 Codex 知道三个 worktree 的位置。假设你的目录结构是这样：

project/ ├── todohtml/ # main 分支 ├── todohtml-claude/ # wt-claude ├── todohtml-codex/ # wt-codex └── todohtml-gemini/ # wt-gemini

在todohtml/主目录里启动 Codex，它默认能读到当前仓库，但另外三个 worktree 是平级目录，需要显式告诉它。最稳的方式是让 Codex 直接执行 git 命令去读，而不是让它猜文件路径。

4. 验证请求：让 Codex 逐个目录对照 diff 定位冲突

现在进入正题。冲突爆发后，不要一上来就git merge，先让 Codex 帮你把三个 worktree 的改动摸清楚。核心思路是：以 main 为基准，分别看每个 worktree 改了哪些文件、哪些行。

第一步，在主目录里先看整体状态：

cd todohtml git worktree list

你会看到四个路径和它们绑定的分支。确认todohtml-claude、todohtml-codex、todohtml-gemini都在列表里，没有出现prunable之类的异常标记。

第二步，让 Codex 逐个目录生成 diff 摘要。你可以直接把下面这段提示词发给 Codex：

我在用 Git Worktree 做多模型并行开发，现在要合并时冲突很多。 请帮我分别对比以下三个目录相对 main 分支的改动： - ../todohtml-claude - ../todohtml-codex - ../todohtml-gemini 对每个目录，执行 git diff main --stat 看改了哪些文件， 再对公共组件和样式文件执行 git diff main -- <文件路径> 看具体改动。 最后按文件汇总：哪些文件被多个 worktree 同时改了。

Codex 会依次执行命令并汇总。实测下来，它给出的输出大概长这样：

文件冲突热力汇总（被多个 worktree 修改）： - index.html 被 claude / codex / gemini 同时修改 - styles/main.css 被 claude / gemini 修改 - components/todo.js 被 codex 单独修改

这张表就是你的排障地图。被三个目录同时改的文件，就是 merge 时冲突的重灾区。接下来针对每个重灾区文件，让 Codex 拉出三方 diff：

# 以 index.html 为例，分别看三个 worktree 相对 main 的改动 git diff main -- index.html # 当前目录（main） cd ../todohtml-claude && git diff main -- index.html cd ../todohtml-codex && git diff main -- index.html cd ../todohtml-gemini && git diff main -- index.html

把这几段 diff 一起丢给 Codex，让它判断哪些改动是等价的、哪些是互斥的。比如三个模型都把按钮圆角从 4px 改成 8px，那这就是等价改动，保留任意一个即可；但如果 Claude 把主色调改成蓝色、Gemini 改成绿色，这就是互斥改动，需要你拍板。

这一步的关键是：让 Codex 做「归类」，你做「决策」。归类是机械劳动，交给 AI；决策涉及产品审美和业务逻辑，必须人来定。

5. 本篇常见错排查：Codex 读不到 worktree、diff 为空、Key 报错

排查过程中最容易踩的坑集中在这几个，我按出现频率排一下。

坑一：Codex 说找不到../todohtml-claude目录。原因是 Codex 的工作目录被限制在当前仓库内，平级目录读不到。解决办法是在提示词里给出绝对路径，或者先cd到父目录再启动 Codex。用pwd确认当前路径，再用ls ..看平级目录是否存在。

坑二：git diff main输出为空。大概率是分支名不对。Worktree 绑定的分支可能不叫main，用git branch --show-current在每个目录里确认一下。另外，如果 worktree 里的改动还没 commit，git diff main是看不到未暂存改动的，需要先git add再git diff --cached main，或者直接git diff main --加上工作区参数。

坑三：Codex 请求报 401 或 404。401 是 Key 问题，检查TAOTOKEN_API_KEY环境变量有没有生效，echo $TAOTOKEN_API_KEY看一眼。404 基本是 Base URL 写错了，重点检查是不是多加了/v1。正确写法是https://taotoken.net/api，不带版本号。

坑四：merge 时提示fatal: refusing to merge unrelated histories。这通常发生在 worktree 是从一个孤立分支拉出来的时候。加--allow-unrelated-histories能强行合并，但更推荐先确认三个 worktree 是不是都基于同一个 main 拉出来的。用git merge-base main todohtml-claude看共同祖先是否存在。

坑五：worktree 删不掉，提示contains modified or untracked files。说明那个目录里还有没提交的改动。先cd进去git status看清楚，确认不要了就git worktree remove --force，要保留就先 commit 或 stash。

这几个坑排完，基本就能顺利走到合并那一步了。合并时如果还有零星冲突，直接在冲突文件里用 Codex 辅助解决——把冲突标记<<<<<<<到>>>>>>>之间的内容贴给它，让它给出保留建议。

6. 通道稳了，冲突排查才不中断

回到最开始那个场景：三个 AI 并行开发，merge 时冲突爆发。真正卡住你的不是 Git 命令不会用，而是排查过程中模型调用老断、上下文老丢，导致你没法连续地把三个目录的 diff 对照完。把 Codex 的通道固定到 TaoToken 之后，整个排查流程可以一口气跑下来，不用中途重新描述背景。

如果你现在正卡在某个 worktree 的冲突里，建议先把 Key 配好、通道验证通过，再让 Codex 按第 4 节的提示词逐个目录拉 diff。通道配置和接入细节在接入文档里有更完整的说明，Key 直接在 API Keys 页面生成。需要长期跑多模型并行、甚至让 Agent 自动处理合并的，可以看下 Coding Plan，高频调用下更省心。模型对话入口也留着，排查时想换个模型交叉验证 diff 判断，直接切过去就行。