cj2api：用 Cloudflare Worker 把 ChatJimmy 变成 OpenAI 兼容 API，零成本接入现有工具链

2026-03-18 8 views cj2api

很多团队在做聊天能力集成时，最头疼的不是“能不能调用”，而是“怎么不改代码地切换模型/供应商”。
你可能已经在后端写死了 OpenAI 的 /v1/chat/completions，前端也依赖现成的 OpenAI SDK；一旦换成另一个服务（比如 ChatJimmy），就要改鉴权、改请求体、改流式解析，甚至连日志与网关策略都要重配。

cj2api 解决的就是这个迁移成本：它把 ChatJimmy 的能力包装成 OpenAI 兼容 API，并且直接跑在 Cloudflare Worker 上。
你得到的是一个“协议转换层 + 边缘部署”的组合，部署近乎零成本，还带一个可直接打开验证的测试页。

cj2api 在做什么：协议对齐与流式转发

从工程视角看，cj2api 是一个典型的“API 适配器（Adapter）”。
它对外暴露 OpenAI 风格接口（例如 POST /v1/chat/completions），对内把请求映射到 ChatJimmy，并把返回再转成 OpenAI 的响应结构。

关键点通常有两个：

  • 请求结构对齐：把 model/messages/temperature/stream 等字段翻译为 ChatJimmy 所需格式，并处理缺省值与边界情况。
  • 响应与流式协议对齐：对非流式请求返回 OpenAI 结构化 JSON；对流式请求使用 SSE（Server-Sent Events）持续推送 delta 片段，直到 [DONE] 结束。

流式转发是最容易“踩坑”的部分：很多服务的流分片粒度、字段名、结束标记并不一致。
cj2api 的价值在于把这些差异隐藏在 Worker 内部，让你继续用原先的 OpenAI 流式消费逻辑（如前端逐 token 渲染、后端边收边写日志等）。

架构特点：Cloudflare Worker 的边缘网关模型

cj2api 选择 Cloudflare Worker 有很现实的工程收益：

  • 部署简单：不需要服务器、不需要容器常驻，适合个人或小团队快速上线验证。
  • 边缘就近：Worker 在边缘节点执行，跨区域访问延迟更平滑，适合面向多地用户的聊天应用。
  • 天然做网关：请求入口统一，后续要加鉴权、限流、日志采集、AB 测试，都可以围绕这一层迭代。

你可以把它理解成“把 OpenAI API 这一层挪到边缘”，应用侧完全不感知底层调用的是 ChatJimmy。
对于已经有 OpenAI 生态工具链（SDK、Agent 框架、代理层）的团队，这种兼容层能显著降低改造成本。

与同类工具的差异：为什么是 OpenAI 兼容而不是自建 SDK

很多“转发/代理”项目会走两条路：要么逼你用它提供的 SDK，要么仅做简单反代。
cj2api 的思路更偏向工程可维护性：把 API 形状做成 OpenAI 兼容，从而复用大量现成生态。

与“纯反向代理”相比，cj2api 通常会做更深的协议适配：

  • 不只转发路径，还会改写请求体字段与响应字段
  • 兼容 OpenAI 的流式 SSE 格式，减少前端/中间层改动
  • 自带测试页，方便你在没有接入业务代码前先验证连通性与流式表现

这种“兼容层”更像是一个可插拔的网关组件，而不是一次性脚本。

快速使用：用 OpenAI SDK 直接打到你的 Worker

部署到 Cloudflare Worker 后，你会得到一个类似 https://<your-worker>.<domain>/v1/chat/completions 的入口。
应用侧基本只需要改 baseURL（或 api_base），其余逻辑保持不变。

下面以 curl 为例演示一次流式请求（路径和字段保持 OpenAI 风格）：

curl -N https://<your-worker-domain>/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <YOUR_TOKEN>" \
  -d '{
    "model": "chatjimmy",
    "stream": true,
    "messages": [
      {"role":"system","content":"You are a helpful assistant."},
      {"role":"user","content":"用三句话解释什么是 Cloudflare Worker。"}
    ]
  }'

关键点是 -N：它会关闭 curl 的缓冲，便于你看到 SSE 实时输出。
如果你在浏览器或 Node 端已经按 OpenAI 的流式协议解析过 data: {...}\n\n，通常无需改动。

自带测试页：先验证再接入

cj2api 提到“自带测试页”，这对排障很有帮助。
在正式把它塞进业务网关或 SDK 之前，先通过测试页确认三件事：

  • 鉴权是否正确（请求能否到达并返回）
  • 流式是否稳定（是否存在中途断流/乱序）
  • 响应结构是否符合现有解析逻辑（尤其是 choices[].delta / choices[].message）

这样可以把问题收敛在“适配层”而不是业务层，定位速度会快很多。

适合什么场景：低成本迁移与多后端切换

cj2api 更适合那些“已经围绕 OpenAI API 写了大量代码”的项目：

  • 你想把后端从 OpenAI 切到 ChatJimmy，但不想全链路重构
  • 你需要一个边缘入口，统一做鉴权、观测与流式转发
  • 你想在零成本部署的前提下，快速给内部工具或原型提供兼容接口

当你的应用希望“接口不变、底层可换”，cj2api 这种 OpenAI 兼容 API 的 Worker 网关，就能把迁移成本压到接近只改一行配置。

Back to Blog