AiCodeCat Docs

主题

为什么不做 API 格式转换 ​

你可能会问：为什么不像其他中转服务那样，把所有模型都转换成 OpenAI 兼容格式？这篇文章说明我们的设计理念。

核心原因 ​

1. 不同厂商的接口参数差异巨大 ​

每个 AI 厂商的接口都有其独特的参数和功能。强行统一格式意味着：

  • 被迫丢弃某些参数 — 目标格式不支持的功能会被忽略
  • 被迫增加某些参数 — 为了兼容性不得不添加默认值
  • 行为不一致 — 同样的请求，转换前后表现可能不同

这也是为什么本站按协议拆地址，而不是只给一个 URL：

  • Claude：https://aicode.cat（不要 /v1）
  • GPT：https://aicode.cat/v1（要 /v1）
  • Gemini：https://aicode.cat/v1beta（要 /v1beta）

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 一致的体验：

  • 参数一一对应，不丢失、不篡改
  • 响应格式与官方相同
  • 错误信息保持原样，便于排查
  • 新功能第一时间支持，无需等待转换层适配

请求路径是：用户请求 → AiCodeCat → 官方 API。原样透传，不做格式改写，官方响应原样返回。

总结 ​

我们选择原生透传，是因为：

  1. 专业用户需要精确控制 — 不能因为转换层的限制而降低使用体验
  2. 问题排查更简单 — 出现问题时，可以确定是模型本身的行为，而非转换层引入
  3. 社区方案成熟 — 如果你需要格式转换，有更好的专业工具可用

承诺：保证你用到的每一个模型，体验都与官方一致。

相关阅读 ​