为什么不做 API 格式转换
解释为什么我们选择保持原生接口格式，而不是提供统一的 API 转换
为什么不做 API 格式转换
你可能会问：为什么不像其他中转服务那样，把所有模型都转换成 OpenAI 兼容格式？这篇文章将解释我们的设计理念。
核心原因
1. 不同厂商的接口参数差异巨大
每个 AI 厂商的接口都有其独特的参数和功能：
| 厂商 | 特有功能 | 转换后会丢失 |
|---|---|---|
| Claude | System prompt 格式、Tool use 结构 | 部分系统提示词行为 |
| Gemini | Safety settings、Generation config | 安全设置细节 |
| OpenAI | Function calling 格式、Response format | 原生格式优势 |
强行统一格式意味着：
- 被迫丢弃某些参数 — 目标格式不支持的功能会被忽略
- 被迫增加某些参数 — 为了兼容性不得不添加默认值
- 行为不一致 — 同样的请求，转换前后表现可能不同
2. CLI 工具的特殊性
以 Gemini CLI 为例，官方 CLI 接口需要预制提示词（System Prompt）。如果我们将其转换为标准 API：
原生 CLI 请求 → [转换层] → 标准 API 格式
↓
锁定部分系统提示词
↓
模型行为发生改变
结果就是：
- 模型能力表现不完整
- 出现奇怪的、难以解释的行为
- 用户难以定位问题是出在转换层还是模型本身
3. 无法满足高端用户的调教需求
对于深度使用 AI 的开发者来说，精确控制模型参数至关重要：
格式转换会导致： - Temperature、Top-p 等参数映射不精确 - 特定模型的高级参数无法传递 - 流式输出的 chunk 格式可能变化 - Token 计数方式可能不一致
这些细节对于普通用户可能无感，但对于需要精细调教模型的专业用户来说，可能是致命的问题。
社区已有成熟方案
如果你确实需要统一的 API 格式，社区已经有非常成熟的开源方案：
New API
New API 是一个功能强大的 API 管理与转换平台：
- 支持多种模型的格式转换
- 提供完整的转换过程日志
- 可自定义转换规则
- 开源透明，问题可追溯
One API
One API 是另一个流行的选择：
- 统一管理多个 API 渠道
- 支持负载均衡
- 完善的额度管理
使用这些开源项目，你可以： 1. 完全掌控转换逻辑 2. 查看详细的转换日志 3. 根据自己的需求调整参数映射 4. 出现问题时快速定位
我们的设计理念
保证原汁原味的官方体验
我们的目标是让用户获得与官方 API 完全一致的体验：
- ✅ 参数一一对应，不丢失、不篡改
- ✅ 响应格式与官方完全相同
- ✅ 错误信息保持原样，便于排查
- ✅ 新功能第一时间支持，无需等待转换层适配
用户请求 → AI Code With → 官方 API
↓
原样透传，不做修改
↓
官方响应原样返回
总结
| 方案 | 优点 | 缺点 |
|---|---|---|
| 格式转换 | 统一接口，切换模型方便 | 参数丢失、行为不一致、难以调试 |
| 原生透传 | 100% 官方体验、完整功能、便于调试 | 需要适配不同接口格式 |
我们选择原生透传，是因为：
- 专业用户需要精确控制 — 不能因为转换层的限制而降低使用体验
- 问题排查更简单 — 出现问题时，可以确定是模型本身的行为，而非转换层引入
- 社区方案成熟 — 如果你需要格式转换，有更好的专业工具可用
**我们的承诺**：保证你用到的每一个模型，体验都与官方一致。
相关阅读
- CLI 与 API 价格差异说明 — 了解为什么同一模型的 CLI 和 API 价格不同
- 线路选择 — 选择最适合你的访问线路