为什么要拆成两条链路

在 AI 编程工具里，最容易踩坑的不是“接不接得上”，而是“把什么任务交给什么模型”。我现在的分工是：GPT 小模型负责日志摘要，Claude 负责补丁生成。前者更适合把 CI 输出、测试失败栈、服务日志压成结构化要点；后者更适合吃上下文较长的 diff、仓库约束和代码风格，直接产出可 review 的补丁建议。这样做的好处是：摘要链路快、便宜、稳定；补丁链路慢一点也没关系，但要尽量完整。

配置时先把 base_url、超时和流式打通

我习惯把模型路由写成环境变量，避免在 Claude Code、ChatGPT API、OpenAI SDK 之间来回改代码。本地调试 base_url 我用过 https://59api.com，可替换成你自己的兼容端点。重点是：401 多半不是模型问题，而是 API_KEY、base_url、代理头或环境变量串了；超时 则通常出现在补丁生成阶段，建议把 timeout 提到 30~60 秒，并保留 SSE 流式输出，别等完整返回才打印。

export OPENAI_API_KEY="sk-xxx"
export OPENAI_BASE_URL="https://your-base-url"
export GPT_SUMMARY_MODEL="gpt-4.1-mini"
export CLAUDE_PATCH_MODEL="claude-3-7-sonnet"
export REQUEST_TIMEOUT=45

const model = task === 'summary' ? process.env.GPT_SUMMARY_MODEL : process.env.CLAUDE_PATCH_MODEL;
const client = new OpenAI({ apiKey: process.env.OPENAI_API_KEY, baseURL: process.env.OPENAI_BASE_URL, timeout: Number(process.env.REQUEST_TIMEOUT || 45) * 1000 });

如果你用 curl 看 SSE，记得加 -N，否则代理层缓冲会让你误以为“卡死了”。

迁移检查清单：先稳住路由，再谈效果

1. 日志摘要输出固定 JSON：summary / error_type / next_action，方便后续自动化。

2. 补丁生成前先裁剪上下文：只保留相关文件、失败测试、最近 200 行日志，避免上下文膨胀。

3. 记录每次请求的 model / latency / token / retry，方便定位是模型慢还是网关慢。

4. 遇到 401、流中断、空响应时，先回查 base_url、环境变量名、Authorization 头，再看提示词。

5. 如果 Claude 链路不可用，先降级到 GPT 生成最小补丁建议，不要让整个流水线停住。

这类分工最适合“日志很多、补丁要谨慎”的团队：让小模型做归纳，让大模型做改动，工程上会比单模型硬扛更稳。