了解更多：https://treerouter.com
比较 WorkBuddy 和 Codex，不能只看哪个聊天界面更顺手，也不能根据一次演示判断哪个工具更强。
真正需要明确的是：你希望它完成什么工作？
是整理几份业务文件，输出一份报告？修改已有代码并验证结果？还是在不同大模型之间切换，建立可以重复使用的工作流程？
这些需求分别影响客户端、模型和 API 接入方式。选型时把它们混在一起，很容易买到了方便的界面，却发现模型接不进去；或者模型调用成功，但文件操作无法完成。
## 一、先分清客户端、模型和 API 服务
客户端负责组织任务、管理会话、操作文件和调用工具。
大模型负责理解要求、生成内容，并在适用场景下提出工具调用。
API 服务负责提供模型访问，包括接口地址、身份验证、模型名称、协议和计费方式。
三者有关联，但不能互相替代。模型能力更强，不代表客户端就能找到正确的项目目录；聊天能够返回内容，也不代表工具调用已经兼容。
TreeRouter 这类 API 中转站处在模型接入层。合理的选择顺序是先确定工作流程，再确认模型需求，最后验证接入方式。
## 二、用“能够验收的任务”做比较
办公场景可以准备一组不含敏感信息的测试文件，让工具提取会议决定、找出时间冲突，并生成能够对应来源的项目简报。
开发场景可以准备一个自己熟悉的小型仓库，要求工具修改一处明确行为，并说明如何验证。
不要把“做一个厉害的东西”当作测试要求。结果看起来漂亮，并不代表事实正确，也不代表需求已经完成。
开始前就写清验收条件：报告中的数字不能被改写，代码修改不能扩大范围，缺少证据时必须明确说明。
## 三、如何判断 WorkBuddy 是否适合你的工作
可以优先用文件驱动的办公任务测试 WorkBuddy，例如整理会议纪要、处理业务表格和形成报告。
检查重点不是“有没有生成文件”，而是：
- 是否读取了正确的资料。
- 是否区分已确认决定与未通过建议。
- 修改一个段落时，是否影响其他数字。
- 输出是否方便交给同事继续处理。
这些问题能帮助你判断工具是否适合长期使用，也能反推出所需模型能力。涉及图片、表格理解或工具调用的工作，通常不能只验证普通文本对话。
## 四、如何判断 Codex 是否适合你的开发流程
先选择一个能够人工检查的小项目，要求它完成一处具体修改，例如补上空输入处理或修正边界条件。
随后检查实际代码差异：
- 修改是否集中在相关文件。
- 是否遵循项目已有写法。
- 是否引入无关改动。
- 验证方法是否覆盖需要修复的行为。
“建议运行测试”与“已经运行测试”是两回事。即使构建成功，也不等于业务要求全部通过。
对比不同模型时，保持代码版本、任务要求和验收标准一致，结果才有参考价值。
## 五、自定义模型接入，要核对协议
WorkBuddy 提供自定义模型配置入口，但填写 URL、Key 和模型名称只是开始。
还要核对客户端实际使用哪种接口，以及目标模型是否支持需要的能力。例如，普通对话可用，并不能证明图像输入、函数调用或多轮工具结果回传同样可用。
Codex 也应按照当前客户端版本的说明配置。本地 CLI 的设置，不能直接当作云端环境的设置。
模型出现在列表里，说明存在一个可选项；完整任务能够执行，才说明这个配置适合当前工作。
## 六、中转站应该解决什么问题
多模型工作流经常遇到重复维护连接的问题：不同地址、不同 Key、不同模型名称，以及分散的调用记录。
TreeRouter 的接入方案可以作为统一模型访问层进行评估。对于兼容的应用，可以先固定任务逻辑，再按文档切换模型配置。
但统一入口不意味着所有模型的参数和行为完全相同。接口兼容、工具支持、上下文限制和输出格式，仍然需要逐项确认。
中转站的价值应通过实际接入与管理体验判断，而不是依靠“所有功能都一样”的假设。
## 七、连接验证分成三步
第一步，发送一个简单文本请求，确认身份验证、模型权限和响应是否正常。
第二步，测试任务需要的关键能力。Agent 可以测试一个只读工具；文档任务可以验证指定文件是否确实被读取。
第三步，执行一个真实但范围有限的任务，按照验收条件检查结果。
这样可以分清问题发生在哪一层：文本失败检查连接，工具失败检查协议，结果不正确再检查上下文和模型表现。
## 八、比较的是完成任务的总成本
实际成本可能包括客户端订阅、模型调用、重复尝试、工具费用和人工复核。
不能只拿一次请求的价格判断哪个方案更便宜。低价调用可能需要多次重试，高价模型也可能被用在不需要复杂推理的简单任务上。
更有用的口径是：完成一个通过验收的任务，总共花了多少钱，以及多少人工时间。
记录真实结果，不要用宣传价格替代实际使用成本。
## 九、控制对比变量
两个客户端都支持同一模型时，可以尝试使用相同接入路线，减少模型差异的影响。
但这仍然不是严格实验。客户端的系统提示、上下文组织、工具定义和重试行为都可能不同。
因此，不要把几次试用包装成普遍适用的性能榜单。应记录普通任务、困难任务和信息不足任务中的表现，尤其观察纠错和承认不确定性的能力。
## 十、需要两种工具时，把交接材料写清楚
团队完全可以让不同工具承担不同阶段。
例如，前一阶段整理业务资料并形成规格说明，后一阶段根据明确规格修改代码。
交接时应包含目标行为、约束条件、相关文件、验收标准和待确认问题，而不是直接扔出一大段聊天记录。
明确的交接内容既方便模型理解，也方便人工判断最终结果是否符合要求。
## 十一、保留能够恢复的配置
配置跑通后，记录客户端版本、模型 ID、接口类型和验证方法。
更新时一次只改一个关键因素，先重复小测试，再继续大型任务。团队共享配置时，说明凭证由谁管理，但不要把 Key 直接写进共享文档。
## 常见问题
**WorkBuddy 一定比 Codex 更适合办公吗？**
应通过你的具体任务验证，不能根据产品定位推断所有场景的结果。
**同一个中转站能同时连接两种工具吗？**
需要分别确认客户端协议和对应模型路线，不能只测试其中一个。
**中转站能提高模型准确率吗？**
不能直接等同。准确率仍取决于模型、上下文、任务设计和结果验证。
准备测试时，可以进入 [TreeRouter](https://treerouter.ai/)，确认模型及客户端兼容性后注册并创建测试 Key。先完成一个可验收任务，再根据实际调用和人工复核情况决定是否扩大使用。
# Codex 提示无法确定项目根目录，为什么不应该先换 API Key？
看到“unable to determine project root for task”，不少用户首先想到更换模型、重建 Key，或者改用另一个中转站。
但这个操作可能没有触及真正的问题。
项目根目录错误，关注的是任务如何关联到工作环境；API 身份验证错误，关注的是客户端能否访问模型服务。它们可能出现在同一个工具中，却不能用同一种方法处理。
下面按照“工作区定位—配置加载—模型连接—工具执行”的顺序排查。本文不把某个命令包装成所有环境都适用的修复方案。
## 一、先确认你使用的是哪一种 Codex 环境
记录当前使用的是本地 CLI、编辑器插件、桌面环境，还是云端任务界面。
同一个文件夹名称，在不同环境中可能指向完全不同的位置。本机存在的目录，不代表远程容器里也存在；云端连接能够访问仓库，也不代表新任务已经正确关联到该环境。
同时保留完整报错文字。项目根目录错误、工作区要求加载失败、工作区路由发现失败，应分别作为排查线索，不要直接认定它们原因相同。
## 二、找出最先失败的环节
可以把整个过程分成四步：
1. 找到工作区。
2. 读取相关配置。
3. 连接模型。
4. 执行文件和工具操作。
任务还没有关联到项目时，更换模型名称通常不能证明工作区问题已解决。相反，工作区已经加载，随后出现身份验证失败，就应该转向检查模型连接。
一次只调整一个相关设置。否则，即便重新运行成功，也难以知道是哪一步起作用。
## 三、本地环境先做只读检查
在启动客户端的同一个终端执行：
```bash
pwd
git rev-parse --show-toplevel
git status --short
```
分别检查当前目录、Git 仓库根目录和未提交修改。
Git 提示不是仓库时，先判断是不是进入了错误目录，或当前项目本来就没有使用 Git。
不要为了消除提示直接执行 `git init`，更不要删除 `.git`、重置仓库或清空文件。这些操作不是确认目录所必需的，还可能影响原有工作。
## 四、从正确的项目位置启动
本地终端可以先切换到实际项目目录，再启动：
```bash
cd "/absolute/path/to/your/project"
codex
```
这里的路径必须存在于运行 Codex 的机器上。这是本地启动方式，不适用于没有终端入口的云端网页。
单体仓库还需要区分仓库根目录与具体应用目录。任务只修改一个子应用，不代表可以忽略共享配置和公共代码。
在任务里写明范围，通常比让工具从一个包含多个仓库的大目录中猜测更可靠。
## 五、检查配置，但不要一次清空
本地目录近期被移动、重命名，或者配置刚刚调整过，都值得检查。
先备份相关配置，再逐项排除可疑改动。不要直接复制另一台电脑的完整配置，因为里面可能包含不存在的路径、模型服务和权限策略。
也不要为了排查把所有环境变量打印出来，其中可能包含凭证。
官方关于项目根目录发现的说明，可以帮助理解本地配置加载，但不能据此认定所有云端报错都由缺少 `.git` 导致。
## 六、远程环境要从运行进程的角度看路径
编辑器窗口在本机，不代表终端也在本机。它可能运行在 SSH 主机、容器或远程开发环境里。
确认仓库是否挂载到正确位置，以及运行客户端的系统账号是否能读取相关目录。
使用 Git worktree 时，不要因为 `.git` 是文件就断定仓库损坏，应使用 Git 命令验证。
权限问题应修复具体目录或挂载，不要直接放开整个系统的权限。
## 七、云端任务按云端流程排查
检查产品实际提供的仓库、分支和环境选择项，确认连接仍有权限，环境初始化已经完成。
初始化日志成功，只能说明相应步骤完成，不能单独证明新任务与环境的关联一定正确。
在目标项目中创建一个新任务，先要求读取一个已知文件。任务仍然无法提交时，保留时间、环境标识和报错，通过私密支持渠道反馈。
不要编造不存在的“根目录设置”，也不要把本地配置文件的修改当作云端修复方法。
## 八、用小项目做对照
可以准备一个只有 README 的测试仓库，在同一客户端中执行相似任务。
测试仓库正常、原项目异常，说明差异可能位于原仓库、配置或环境关联；两个都异常，则优先检查共享的客户端或服务环境。
这是缩小范围的方法，不是对根因的最终证明。对照过程中尽量保持账号、任务和客户端一致。
## 九、工作区正常后，再验证 API
先发送一个不修改文件的短请求，再要求读取指定文件并总结。
随后比较答案和真实文件，确认模型确实获取了所需上下文。
使用 TreeRouter 时，需要核对对应客户端的模型 ID、接口地址、凭证和协议。普通聊天成功，不代表 Agent 所需的全部能力都已兼容。
中转站接入检查应该放在这一阶段，而不是让它承担本地目录修复的职责。
## 十、识别后续错误
工作区问题修复后，可能出现新的错误：
- 身份验证失败：检查 Key 和地址是否匹配。
- 模型不存在：检查模型 ID 和账号权限。
- 工具请求被拒绝：检查协议及能力支持。
- 限流：检查额度、请求频率或服务状态。
错误发生变化，可能说明任务已经推进到下一层，不要因此否定前面有效的修复。
## 十一、准备能够复现的问题说明
记录客户端类型、可见版本、操作系统、失败时间、完整错误，以及测试项目能否复现。
本地问题可以附上脱敏后的目录检查结果；云端问题通过官方私密支持入口提供环境标识。
不要提交 API Key、完整环境变量、私有代码或未经筛选的终端历史。
“改了什么，结果怎样”比“所有方法都试过了”更有帮助。
## 十二、怎样确认真正恢复
新开一个会话，选择正确项目，读取已知文件并核对答案，再完成一个范围有限的真实任务。
使用自定义模型服务的，还要确认模型请求与工具操作正常。
最后记录有效的修改和可恢复配置。下次客户端更新、仓库移动或模型迁移时，就不必从头猜测。
恢复工作区后，可以参考 [TreeRouter 接入文档](https://treerouter.apifox.cn/)确认模型连接方式，再注册并创建测试 Key。先跑通一个可检查的项目任务，再扩大使用范围。
# 国产大模型 API 怎么选？模型能力和接入方式要分开判断
了解更多：https://treerouter.com
搜索 Chinese LLMs，通常会看到模型名单、参数规模、榜单成绩和发布消息。
这些信息能够帮助发现候选模型，却不能直接回答开发者最关心的问题：哪个模型能通过适合项目的 API，稳定完成自己的业务任务？
DeepSeek、Qwen、GLM 和 Kimi 都可以进入候选范围，但不能把它们当作完全相同的产品，也不能仅凭一次演示决定长期接入方案。
更可靠的过程是：明确任务，选择具体模型路线，建立测试集，再判断是否需要 API 中转站。
## 一、先解释清楚“国产大模型”对应什么需求
它可能指中国机构开发的模型，也可能指中文任务表现，或者某个地区能够使用的模型服务。
这几个条件并不相同。
模型来自哪里，不能直接说明某条托管 API 的处理位置；中文回答流畅，不代表产品术语和数字一定准确；存在可下载权重，也不等于部署许可、硬件和维护成本已经满足要求。
先写清楚你需要解决的是双语客服、字段提取、代码开发，还是企业批准的接入安排。
## 二、选择具体 API 路线，而不只选择模型家族
测试时应记录：
- 完整模型 ID。
- 接口地址与协议。
- 账号和权限要求。
- 使用的参数。
- 核验日期。
DeepSeek、Qwen、GLM 和 Kimi 都有相应 API 接入文档，但这不表示它们的所有能力、参数和计费方式都一致。
不要拿一个模型家族中的轻量版本，与另一个家族中的高预算推理版本比较，然后把结果扩大成整个品牌的结论。
## 三、根据业务设计测试
客服任务检查是否依据政策回答、能否保留例外条件，以及缺少信息时是否承认不知道。
字段提取检查必填值是否准确、缺失项是否被错误补齐，以及结果能否被程序验证。
编程任务检查实际代码修改和测试结果。
多语言内容检查术语、数字、产品名称和原意。表达顺畅不等于业务含义没有变化。
不同任务选出不同模型并不奇怪。只有实际收益明确时，才需要增加按任务分配模型的复杂度。
## 四、建立一个小而稳定的测试集
先准备能够人工核验的样本，包含简单任务、困难任务、信息缺失，以及过去发生过错误的情况。
例如，客服样本可以同时包含普通退货规则和定制商品例外；提取样本可以故意缺少一个字段，并加入容易混淆的数字。
不要只测试最容易成功的输入。应用是否可靠，往往取决于它如何处理不完整和不一致的信息。
比较期间保持测试集稳定，真实使用中出现新问题后再补充样本。
## 五、先完成最小 API 请求
第一步只确认身份验证、模型权限和基本响应。
英文版提供的 Python 示例，使用一段包含例外条件的退货政策，检查模型能否回答“未损坏的定制商品是否可以退货”。
接入时使用控制台实际提供的模型 ID，不要把展示名称当作接口名称。Key 应由对应服务签发，并保存在环境变量或受控的凭证管理位置。
示例使用 TreeRouter 公布的兼容接口地址，但没有进行付费调用实测。正式使用前，仍需确认账号能够访问所选路线。
## 六、把兼容性拆成具体能力
普通文本返回成功，不代表图片输入、结构化输出、工具调用、流式响应和多轮续接都已经可用。
每项能力应单独测试。
JSON 能被解析，只说明语法可读，不能证明字段值正确。
工具调用必须验证完整过程：模型提出请求，程序检查参数，工具实际执行，结果返回后模型正确使用。
流式输出还需要检查结束事件和连接中断行为。不能因为屏幕出现了部分文字，就认定整个请求正常完成。
## 七、什么时候适合直连，什么时候适合中转站
应用长期只依赖一个模型服务商，并且需要其专用能力时，可以评估直接接入。
需要比较或组合多个支持的模型，并希望统一管理连接配置时，可以评估 API 中转站。
TreeRouter 可以放在模型访问层进行测试。把业务逻辑与连接配置分开，有利于在更换模型时保留应用主体。
但统一入口不会消除所有差异。专用工具、参数扩展、上下文处理和响应结构，仍可能需要针对性适配。
## 八、怎样理解 best LLM gateway
对你的项目来说，合适的网关应满足明确的要求，而不只是展示很多模型名称。
要检查：
- 当前账号能否调用需要的具体模型。
- 所需协议和能力能否完整运行。
- 使用记录是否便于理解。
- 错误是否方便定位。
- 更换模型时需要改配置，还是需要修改业务代码。
不能用一次短请求证明所有地区、时段和任务都足够快。应使用相同测试集验证整个流程。
## 九、按“通过验收的结果”计算成本
除了标价，还应计入重复请求、历史上下文、工具相关调用、失败输出和人工修正。
比较时采用同一验收标准。例如字段提取必须满足全部必填字段，客服答案必须获得政策支持。
否则，一个方案显得便宜，可能只是因为你对它接受了更低的质量。
官方直连价格、套餐价格和中转站实际计费，也不能混为一谈。
## 十、比较完整任务耗时
首个字符出现得快，不代表整个任务完成得快。
有些模型开始响应很快，但后续耗时更长；另一些模型可能尝试次数少，或者输出需要的人工修正更少。
记录用户感受到的响应速度，也记录直到结果通过验收的总时间。
真实业务需要工具和长文档时，就用相近任务测试，不要只拿一句问候语比较延迟。
## 十一、模型切换要保留行为验证
共享接口格式可以减少迁移工作，但不保证结果相同。
引入备用模型后，要重新运行测试集，确认其保留业务限制、输出格式和证据要求。
内部记录应能够识别实际使用的模型路线，方便事后定位问题。
对于可能触发业务操作的结构化结果，在执行下游动作前仍应验证，不要因为模型来自同一个入口就直接信任。
## 十二、接入也包含长期维护
真实业务上线前，应明确凭证由谁管理，谁可以修改模型设置，Key 失效或路线不可用时由谁处理。
不要把 Key 放进前端代码，也不要把完整业务数据默认写入调试日志。
小团队可以从简短的配置记录和凭证轮换流程开始，避免某位员工的个人设置变成无人理解的关键依赖。
## 常见问题
**哪个国产大模型最适合编程？**
需要限定具体版本、任务和配置，再比较代码修改与验证结果，不能只根据家族名称判断。
**OpenAI 兼容是不是所有参数都支持？**
不是。必须核对具体路线的能力。
**GLM proxy 就是 GLM 模型吗？**
不是。前者是访问层，后者是模型，两者需要分别确认。
准备接入时，可以在 [TreeRouter](https://treerouter.ai/)确认支持的模型路线，注册并创建测试 Key。用同一组任务比较结果、耗时和真实调用成本，再决定扩大使用。
**GPT-Image-1 vs GPT-Image-2：图像 API 迁移与中转接入教程**
搜索“GPT-Image-1 vs GPT-Image-2”的开发者，往往不只是想看模型参数，而是正在解决一个实际问题：现有图片生成应用应该换用哪个接口，怎样迁移才能继续正常运行？
首先要确认模型状态。
截至 2026 年 10 月 29 日，OpenAI 官方模型页面显示，GPT-Image-1 已于 2026 年 10 月 23 日停用，并推荐 GPT-Image-2.5 Sunburst 用于当前的图像生成与编辑。因此，把 GPT-Image-1 当作仍可正常部署的模型进行比较，已经不足以指导新的接入。具体状态可查看 [GPT-Image-1 官方页面](https://developers.openai.com/api/docs/models/gpt-image-1)。
本文围绕真实迁移过程展开：确认原有请求、选择可用模型、验证 API 中转站通道、检查图片结果，并计算合格图片的实际成本。
**为什么迁移不能只修改模型名称**
一个图像应用依赖的不只是 `model` 参数。
接口地址、请求格式、图片尺寸、返回编码、超时时间和计费方式，都可能影响最终结果。
例如，一个商品背景生成工具可能默认：
- 每次返回一张图片。
- 返回内容采用固定编码。
- 图片始终是指定尺寸。
- 请求在某个时间范围内完成。
- 保存后的文件可以直接上传到商城。
即使新模型生成效果更好，只要返回格式发生变化，应用仍然可能报错。
因此，一次完整迁移应该覆盖五件事：模型可用性、请求兼容性、结果解析、图片验收和成本核对。
API 中转站可以提供统一接入入口，但具体模型支持哪些操作，仍然要逐项确认。
**第一步：整理原来的请求**
先找到项目中真正发起图像请求的代码。
记录模型 ID、接口路径、提示词、尺寸、质量设置、参考图处理方式和输出格式，同时确认生成文件最终保存在哪里。
接下来，把业务任务写具体。
“生成图片”过于宽泛，更有价值的描述包括：
- 为商品生成留有标题空间的背景。
- 为博客生成不含文字的插图。
- 修改背景，同时保持商品主体不变。
- 生成多个方案，供设计人员挑选。
- 生成包含指定文案的方形宣传图。
不同任务的验收标准不同。善于生成插画的模型，不一定适合保持商品细节或准确呈现文字。
保存几张过去已经通过审核的图片。旧模型无法调用后，这些历史作品仍然可以作为视觉参考。
**第二步：把历史比较和当前选型分开**
GPT-Image-1 的历史输出，可以继续用于评估原有工作流的效果，但不能据此认为它的官方 API 仍然可用。
如果应用已经使用 GPT-Image-2，先确认当前服务商是否继续提供所需通道，以及现有质量是否满足业务需求。
如果是新项目，则应该查看当前可用的模型和官方推荐。站内的 [GPT-Image-2.5 API 介绍](https://api.treerouter.ai/en/blog/gpt-image-2-5-api-guide)可以作为了解相关模型系列的入口，实际调用仍以当前接口文档为准。
整个过程中要分别回答：
1. 原来的工作流能够产生什么结果？
2. 替代模型能够完成什么任务？
3. 当前账号实际上能调用哪些模型？
这能避免根据过时的价格对比文章做出部署决定。
**第三步：检查 API 中转站的图像通道**
打开 [TreeRouter 模型列表](https://api.treerouter.ai/en/models)，确认目标图像模型及对应文档。
重点核对完整模型 ID，以及通道支持的是生成、编辑，还是两者都支持。
还要确认它使用 Images 风格接口、Responses 工作流，还是服务商自己的格式。文本聊天调用成功，并不代表图像生成接口已经可用。
如果控制台仍显示旧模型名称，需要核实这个名称实际对应什么服务。中转站保留一个别名，并不能证明原来的上游模型仍在运行。
首次测试建议只生成一张图片，使用短提示词和文档支持的尺寸。先验证基础请求，再加入参考图、编辑操作和其他参数。
**第四步：从最小请求开始**
如果所选通道明确支持 Images generations 格式，可以从下面的请求体模板开始：
```json
{
"model": "替换为控制台支持的图像模型ID",
"prompt": "生成一张适合保温杯广告的简洁方形背景。使用柔和自然光和中性色台面，画面上方三分之一留出空白。不要添加文字、商标或额外商品。",
"size": "1024x1024"
}
```
将占位内容替换成当前账号提供的模型 ID，并发送到该通道文档指定的接口。
这个最小请求用于确认网络、鉴权和基础图片生成功能。它不能代替编辑接口或多轮图像工作流的测试。
也不要把旧代码中的所有参数原样复制过来。例如，OpenAI 当前文档要求 GPT-Image-2 请求省略 `input_fidelity`，因为该模型固定按高保真方式处理图片输入，不能通过这个参数调整。具体规则见 [官方图像生成指南](https://developers.openai.com/api/docs/guides/image-generation)。
基础请求成功后，每次只增加一项功能，更容易定位兼容性问题。
**第五步：检查图片解析与保存**
HTTP 请求成功，不等于应用已经拿到可用图片。
如果通道返回 Base64 数据，需要验证能否正确解码，并使用匹配的文件格式保存。
如果返回图片 URL，则按照该通道的文档处理下载，并留意可能存在的有效期。
同时检查：
- 文件能否正常打开。
- 文件扩展名与实际格式是否一致。
- 图片尺寸是否符合要求。
- 文件大小是否超过上传限制。
- 文件是否保存到正确位置。
接口返回空内容时，应用应该报错，不能继续把它当作成功结果。
跨服务商或跨通道迁移时，返回包装结构可能不同，这类问题尤其值得单独验证。
**第六步：建立图片验收集**
不要只测试一张看起来不错的图片。
商品营销场景可以准备以下测试：
- 纯背景生成。
- 带有明确留白要求的构图。
- 包含指定文字的图片。
- 竖版宣传图。
- 使用已批准参考图的编辑任务。
每个任务都要提前写好通过条件。
例如，商品编辑任务要求标签、形状和颜色保持不变；背景生成任务要求不能出现额外商品或意外文字。
把新模型结果与验收要求、历史合格图片进行比较。如果旧图片来自存档，应明确标注为历史基准，不要描述成刚刚完成的在线对比测试。
**第七步：计算每张合格图片的成本**
单次请求价格低，不一定意味着业务成本低。
假设一种通道生成十张图片，只有三张能用；另一种通道每次调用更贵，但十张中有八张通过审核，后者可能更适合实际业务。
可以使用：
`每张合格图片成本 = 本轮生成与编辑总费用 ÷ 合格图片数量`
实际发生计费的失败尝试、重新生成和追加编辑，都应纳入统计。使用参考图时，还要检查是否包含图片输入费用。
人工审核时间建议单独记录。如果需要计算总业务成本，再明确说明人工成本假设，避免把内部估算误写成模型官方价格。
比较不同通道时，使用相同任务、尺寸、质量要求和验收标准，并查看真实账单。
**第八步：分阶段替换生产流程**
一次请求成功后，不要立即替换所有图片任务。
可以先从博客配图草稿等范围较小的流程开始。将新模型配置独立保存，便于停止调用或切换到已验证的替代通道。
已经停用的旧模型不能作为可靠的回退目标。
根据业务情况，备选方案可以是另一个经过验证的模型、稍后重试的任务队列，或者已审核的静态素材库。
持续记录失败率、完成时间、图片通过率和实际成本，再决定是否扩大使用。
**常见迁移问题**
**提示参数不支持怎么办？**
删除非必要参数，从文档给出的最小请求开始，再逐项加回。
**文本接口正常，图片接口失败怎么办？**
检查图像模型权限和对应接口。文本能力与图像能力需要分别验证。
**图片生成成功，但应用不能使用怎么办？**
检查编码、文件格式、尺寸和存储流程，问题可能出在图片处理代码。
**换了模型后费用更高怎么办？**
先确认比较的是相同尺寸、质量、参考图数量和合格结果数量，再核对重新生成产生的费用。
**第三方平台仍显示 GPT-Image-1，是否说明还能调用原模型？**
不能仅根据名称判断。需要确认该别名实际对应的服务和模型身份。
**用实际结果完成选型**
现在回答“GPT-Image-1 vs GPT-Image-2”，需要同时考虑模型状态、接口兼容和迁移质量。
可以先[注册 TreeRouter](https://treerouter.ai/register)，查看当前账号可用的图像模型，完成少量测试，再根据合格图片成本和业务要求决定正式使用的通道。
