1. 冲突现场长什么样先复现再让 Claude Code 接手多人协作的仓库里冲突不是意外是常态。你改src/service/user.ts的第 42 行同事也改了同一段你删了一个旧函数同事还在调用它。Git 不会替你判断谁对它只会在文件里塞进一堆、、然后停下来等你。我先把冲突场景复现出来你跟着做一遍后面让 Claude Code 接手时才有真实素材。假设主分支叫release/3.1.11你的功能分支叫feature/order-refund。先制造冲突git checkout release/3.1.11 git pull origin release/3.1.11 git checkout feature/order-refund git rebase release/3.1.11如果两边改了同一处终端会输出类似Auto-merging src/service/user.ts CONFLICT (content): Merge conflict in src/service/user.ts error: could not apply 8f3c2a1... feat: adjust refund logic hint: Resolve all conflicts manually, mark them as resolved with hint: git add/rm conflicted_files, then run git rebase --continue.这时候git status会显示interactive rebase in progress; onto 4d9e1b2 You are currently rebasing branch feature/order-refund on 4d9e1b2. Unmerged paths: (use git add file... to mark resolution) both modified: src/service/user.ts打开src/service/user.ts你会看到export function calcRefund(order: Order) { HEAD return order.amount * 0.9; const rate order.vip ? 0.95 : 0.9; return order.amount * rate; 8f3c2a1 (feat: adjust refund logic) }HEAD是目标分支release/3.1.11的版本下面那段是你功能分支的改动。人工判断要花时间尤其是冲突文件多、上下文长的时候。Claude Code 的价值就在这里它能读整个文件、读提交历史、读两边 diff然后给出一个「保留谁、怎么合」的建议而不是只做文本替换。这一步的目标不是让 CC 直接提交而是让它把冲突标记清零、给出可复核的合并结果。你负责审核它负责体力活。2. 把 Claude Code 的 endpoint 接到 TaoToken 统一通道在让 CC 处理冲突之前先把它的请求通道配好。Claude Code 默认走 Anthropic 官方 endpoint如果你希望用统一的 Key 和 API 通道管理可以把它指向 TaoToken。TaoToken 官网是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 入口是 https://taotoken.net/api 。注意 API 地址不带 UTM 参数配置时直接用https://taotoken.net/api。Claude Code 读取环境变量来决定请求地址和鉴权。你可以在 shell 配置文件里写export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_API_KEYsk-你的TaoTokenKey如果你用的是settings.json方式Claude Code 支持项目级或用户级配置可以写成{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的TaoTokenKey } }路径通常在~/.claude/settings.json或项目根目录的.claude/settings.json。改完后重启终端或重新加载配置。如果你同时用 Cline、Codex 这类工具三件套要写全Base URL、Key、Model ID。以 Cline 的 MCP 配置为例{ mcpServers: { claude-code: { command: npx, args: [-y, anthropic-ai/claude-code], env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的TaoTokenKey, ANTHROPIC_MODEL: claude-sonnet-4-20250514 } } } }Model ID 按你实际可用的写不要照抄。Codex 的auth.json同理把 base URL 和 key 填进去model 字段写清楚。配好后先验证通道通不通别等到处理冲突时才发现 401。用一条最小请求curl -s https://taotoken.net/api/v1/messages \ -H x-api-key: sk-你的TaoTokenKey \ -H anthropic-version: 2023-06-01 \ -H content-type: application/json \ -d { model: claude-sonnet-4-20250514, max_tokens: 64, messages: [{role: user, content: reply with ok}] }返回里有content字段且文本是ok说明通道正常。如果返回 401先检查 Key 有没有多余空格如果返回local proxy failed检查ANTHROPIC_BASE_URL是不是写成了带路径的完整 URL 而多了一层/v1。Key 的获取入口在 https://taotoken.net/api-keys 接入文档在 https://taotoken.net/doc 。这两个页面建议先过一遍尤其是文档里的 endpoint 说明避免路径拼错。3. 可复制的 rebase 冲突处理提示词与配置通道通了回到冲突现场。核心操作是把你的分支 rebase 到目标分支然后让 Claude Code 读冲突、给策略、逐文件收尾。先确认你在功能分支上且工作区干净git status git checkout feature/order-refund git rebase release/3.1.11出现冲突后不要急着git add。先让 CC 介入。在 Claude Code 里输入这段提示词可以直接复制我的当前分支是 feature/order-refund正在 rebase 到 release/3.1.11。 现在有冲突文件请执行以下步骤 1. 运行 git status 和 git diff --name-only --diff-filterU 列出所有冲突文件 2. 对每个冲突文件读取完整的冲突标记段落结合 git log 和 git diff 判断两边改动的意图 3. 给出合并策略保留哪边、如何融合说明理由 4. 直接修改文件清除所有 、、 标记 5. 修改完成后运行 git diff 复核并告诉我哪些文件需要我人工确认。 不要执行 git add、git commit、git rebase --continue等我审核。这段提示词的关键是最后一句不让 CC 自动提交。它只负责改文件你负责审核和推进 rebase。如果你希望 CC 在改完后自动跑测试可以追加6. 如果项目有 npm test 或 pnpm test运行它并报告失败用例 7. 如果测试通过输出一份变更摘要包含每个文件的合并决策。CC 处理时你可以观察它的动作。它通常会先跑git diff --name-only --diff-filterU然后逐个cat文件再调用编辑工具改文件。对于上面那个calcRefund的例子它可能给出这样的合并结果export function calcRefund(order: Order) { const rate order.vip ? 0.95 : 0.9; return order.amount * rate; }理由是目标分支的0.9是旧逻辑功能分支引入了 VIP 判断融合后既保留 VIP 逻辑又覆盖了非 VIP 的 0.9。这个判断对不对你要自己看业务。如果冲突文件多CC 会分批处理。你可以让它每处理完一个文件就停下来等你确认提示词改成每处理完一个冲突文件暂停并输出该文件的 diff等我回复「继续」再处理下一个。这样节奏可控不会一次性改乱。配置层面如果你在项目里用.claude/settings.json固定了模型和 endpoint记得把 model 写成你实际要用的{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的TaoTokenKey, ANTHROPIC_MODEL: claude-sonnet-4-20250514 }, permissions: { allow: [Bash(git status), Bash(git diff:*), Read, Edit] } }permissions.allow里放开git status、git diff、Read、EditCC 才能读冲突和改文件。不要放开git push避免误推。4. 验证请求与成功结果冲突标记清零、测试通过、diff 复核CC 改完文件后你不能直接git rebase --continue。先做三层验证。第一层冲突标记清零。全局搜一遍grep -rn \|\| src/ --include*.ts --include*.tsx如果没有输出说明标记清干净了。如果有输出把文件路径贴给 CC让它继续处理。第二层测试通过。跑项目测试npm test # 或 pnpm test如果测试失败把失败输出贴给 CC测试失败输出如下 粘贴失败日志 请分析是合并逻辑问题还是测试本身需要更新给出修复方案并修改文件。注意测试失败不一定是合并错也可能是目标分支的测试还没适配你的新逻辑。让 CC 判断你复核。第三层diff 复核。看 CC 到底改了什么git diff重点看三类地方被删除的代码是不是真的该删、被保留的分支逻辑有没有遗漏、新增的融合逻辑有没有引入未定义变量。我一般会对照git log --oneline release/3.1.11..feature/order-refund看提交意图确认合并结果符合功能预期。三层都过了再推进 rebasegit add src/service/user.ts git rebase --continue如果还有下一个冲突重复第 3 节的提示词流程。全部冲突处理完rebase 会输出Successfully rebased and updated refs/heads/feature/order-refund.这时候再跑一次完整测试确认最终状态npm test git log --oneline -5git log应该看到你的提交被重新应用在release/3.1.11之上。确认无误后推送git push origin feature/order-refund --force-with-lease用--force-with-lease而不是--force避免覆盖别人的推送。如果你想让 CC 帮你做最终复核可以再发一条请运行 git diff release/3.1.11...feature/order-refund检查这次 rebase 引入的变更是否都符合预期列出任何可疑的删除或覆盖。这一步是兜底尤其是冲突文件多的时候人工看 diff 容易漏。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth配通道和处理冲突时几个报错反复出现我按真实日志对照给你。401 Unauthorized。返回体通常是{type:error,error:{type:authentication_error,message:invalid x-api-key}}原因Key 错了、Key 前后有空格、或者用了别的平台的 Key。检查ANTHROPIC_API_KEY的值重新从 https://taotoken.net/api-keys 复制。注意不要把它写进会提交到 Git 的文件里。local proxy failed。终端输出API Error: local proxy failed to connect原因ANTHROPIC_BASE_URL写错或者网络到不了。确认写的是https://taotoken.net/api不要多加/v1也不要用带 UTM 的地址。改完export后要新开终端或source配置文件。reading choices 报错。CC 在解析响应时可能输出Error: reading choices: unexpected end of JSON input原因请求被截断或返回了非 JSON 内容。先确认max_tokens没设太小再确认 endpoint 返回的是标准 JSON。用第 2 节的 curl 命令单独测一次如果 curl 正常而 CC 报错检查 CC 的 model ID 是否写错。OAuth 相关报错。如果你之前登录过 Anthropic 官方账号CC 可能优先走 OAuth 而不是 API Key输出OAuth token expired, please re-authenticate解决在 CC 里执行登出或者显式用 API Key 模式启动。检查~/.claude/下有没有残留的凭据文件必要时清掉再配ANTHROPIC_API_KEY。rebase 中途想放弃。如果 CC 改乱了别硬撑git rebase --abort回到 rebase 前的状态重新来。这比在冲突里越陷越深快。冲突标记没清干净就 continue。git rebase --continue会报error: you must edit all merge conflicts and then mark them as resolved用第 4 节的 grep 命令找残留标记清完再git add。CC 改了不该改的文件。比如它顺手格式化了整个文件导致 diff 巨大。提示词里加一句只修改冲突标记涉及的代码段不要做额外的格式化或重构。如果已经改了用git checkout -- file还原单个文件重新让 CC 处理。6. 把 CC 接进日常合并流程冲突处理完这套流程可以固化下来。我的习惯是rebase 前先git fetch拉最新目标分支rebase 时一旦冲突就交给 CC提示词固定用第 3 节那段改完必跑 grep 和测试diff 复核后再 continue。如果你经常做长期编码或 Agent 类任务可以考虑用 Coding Plan 把额度固定下来入口在 https://taotoken.net/coding-plan 。模型对话调试在 https://taotoken.net/chat 接入文档在 https://taotoken.net/doc Key 管理在 https://taotoken.net/api-keys 。Claude Code 的接入说明在 https://taotoken.net/claude-code 。最后留一个实用技巧把第 3 节的提示词存成项目里的.claude/prompts/rebase-conflict.md每次冲突时直接引用文件路径不用重新打一遍。CC 读文件比读长提示词更稳也方便团队共享同一套合并策略。