不会用 ChatGPT，也能搭 AI 中转站：WorkBuddy + Sub2API 零基础教程

想搭一个自己的 AI 中转站，教程却从“SSH 登录服务器”开始。SSH 是什么？命令粘到哪里？API Key 和管理员密码又有什么区别？看到这里，不少人已经关掉页面了。

这篇就从这些地方讲起。你不需要先开通 ChatGPT，可以用腾讯的 WorkBuddy 协助安装和排查。我们用 Sub2API 做网站后台，把已经购买或获得授权的上游 API 接进来，再通过自己的域名使用。

先说清楚成本：这里不是“50 元拥有全部模型”。我推荐的商业主机方案，月租预算约 500 元；模型调用、域名和可能用到的工具费用另算。只想试试软件的人，不必照着这个预算买服务器。

本文按 2026 年 9 月 27 日可查的官方资料编写，Sub2API 界面与部署文件以 v0.2.8 为核对基线。它是一份部署与验收教程，不是已经跑完的 WorkBuddy 一键部署实测。操作过程中，以你的实际返回结果为准。

你搭的是入口，不是在服务器上安装所有大模型

把中转站想成一个由你管理的入口，会更容易理解。

用户访问你的域名，提交请求。Sub2API 检查密钥、分组和额度，再把请求送到你配置的上游。上游生成答案，结果经过你的服务器返回给用户。

所以，买一台 4GB 内存的 VPS，并不等于在里面跑起了 GPT、Claude 和 Gemini。模型仍在上游运行。你承担的是接口转发、用户管理、用量记录和服务维护。

Sub2API 当前提供 OpenAI、Anthropic、Gemini，以及 Kimi、智谱 GLM、DeepSeek、MiniMax 等平台相关配置入口。但后台有一个平台选项，不代表你已经获得它的模型。能不能调用，取决于上游授权、账户额度、模型名称和协议兼容性。[Sub2API 官方说明]

这篇只走 API Key 接入路线，不把个人订阅拆成号池，也不教你用浏览器 Cookie 冒充商业 API。商业使用前，核对供应商是否允许转售或转发，别把“能连上”当成“有权对外卖”。

准备什么？先把这笔账算明白

域名不用追求花哨。比如你已有 example.com，可以为中转站单独建一个 api.example.com。本文出现的这个地址是示例，不是能直接访问的真实服务。

为什么我推荐月预算约 500 元的搬瓦工方案

如果你打算长期服务别人，我不会把主机月租压到最低当作首要目标。

中转站经常出故障，用户用不了，你还得处理退款、解释和流失。省下几十块主机费，值不值得拿服务信誉去换？这是我选择这个方案的理由。

推荐的是 搬瓦工 ECOMMERCE SLA 洛杉矶方案（pid 166）。当前官方产品页列出的主要配置如下：

价格、库存和配置以付款时的官方产品页为准。主机费不包含模型调用费，也不代表所有模型可以无限使用。

厂家标示的 99.99% SLA 有适用范围和排除条款，涉及网络与宿主机等条件，不是你这套中转站的零故障保证。上游断了、软件配置错了或自己把数据库删了，不能靠这个数字解决。[搬瓦工 SLA]

通过上面的推荐链接购买，我可能获得佣金。我推荐它是基于这个选型思路及公开配置，并没有在本文中声称跑过长期可用性测试。你已有合适的 VPS，可以直接沿用。

第 1 步：安装 WorkBuddy，不用先解决 ChatGPT 账号

打开 WorkBuddy 官网，下载 Windows 桌面版。官方安装指南列出的要求是 Windows 10 或以上的 64 位系统。按界面使用微信扫码、手机号或邮箱登录即可，不需要拿 ChatGPT 账号去登录。[官方 Windows 安装指南]

在电脑里新建一个空文件夹，例如 D:\AI-Gateway。让 WorkBuddy 打开这个文件夹，把安装方案、配置文件和检查记录放在这里。不要直接选整个系统盘或存放私人资料的目录。

任务输入框的模式菜单里，Plan 用来先出方案，Agent 用来执行；Ask 主要用于问答。先用 Plan 看清会改什么，再转 Agent 执行。[官方任务栏说明]

WorkBuddy 执行命令或访问网络时，可能请求批准。看清命令针对本机还是服务器，再同意。没必要为了少点几次按钮，直接打开影响其他任务的全局 Full Access。[权限模式说明]

免费额度能支持多少操作，要看任务长度和返工次数，不能保证一定免费做完。先用当前账户额度尝试，确实不够再考虑工具费用。[WorkBuddy 定价说明]

第 2 步：找到服务器信息，先验证能登录

购买完成后，在厂商客户中心进入对应服务器的管理面板。搬瓦工通常从产品页面进入 KiwiVM。记下服务器 IP、SSH 端口、登录用户名和操作系统。

IP 是服务器地址；SSH 是远程操作服务器的连接方式；端口相当于这条连接的入口编号。端口可能不是 22，照面板里显示的填，不要猜。

新建空服务器可以选择项目支持的 Linux 环境，例如 Ubuntu。已有网站或数据的服务器，不要为了跟教程一致就重装系统。

把 IP、端口、用户名告诉 WorkBuddy，让它先检查本机有没有 SSH 客户端，再给出登录命令。命令大致长这样，其中 IP 和端口要换成你自己的：

ssh -p 你的SSH端口 登录用户名@你的服务器IP

Windows 可以在“终端”或 PowerShell 中运行这条命令。第一次连接会显示主机指纹，先和厂商提供的指纹核对；来源无法确认时，不要随手输入 yes。密码由你自己在终端输入，输入时不显示字符是正常的。

别把 root 密码、私钥或完整 API Key 粘进文章评论和普通聊天。若你已配置本机 SSH 密钥连接，可以让 WorkBuddy 使用这条连接，但不要把私钥文件内容发给它。另一个程序不会自动继承你刚才登录的终端会话。

只有密码登录、WorkBuddy 又无法完成安全交互时，让它生成分阶段的 Linux 命令和脚本。你在已经 SSH 登录成功的 Linux 提示符里运行，不是在本机 Windows PowerShell 里运行；遇到 sudo 密码提示，由你自己输入。每一段成功后再继续，不要一次粘贴一大串不认识的命令。

这一阶段的通过标准很简单：连接到了正确服务器，能读到操作系统与剩余资源信息。连这里都没通过，先处理端口、密码或网络，不要继续安装。

第 3 步：让域名指向服务器

到域名的 DNS 管理页面，添加一条记录：

如果用根域名，很多面板的主机记录填写 @。各家的叫法略有不同，找“域名解析”或“DNS 记录”即可。

没有给这台服务器配置 IPv6，就不要留下一个指向别处的 AAAA 记录。它可能让部分访问跑到错误地址。使用 Cloudflare 的读者，首次排查可以先用 DNS only；其他 DNS 服务不需要为了这篇教程迁移过去。[DNS 记录示例]

让 WorkBuddy 查询这个域名，确认解析结果是服务器 IP。解析变更可能需要等待缓存更新，此时网站还打不开，并不说明 Sub2API 安装失败。

第 4 步：让 WorkBuddy 部署，但给它一份有边界的任务

不要只说“帮我搭个中转站”。这句话太宽了：它可能替你改端口、重装系统，或者拿一份旧脚本一直试。

下面这份任务卡可以复制给 WorkBuddy。先把里面的 IP、端口、用户名和域名改成自己的，不能把尖括号里的示例原样留下。密码和私钥不填进去。

::ILANG::v5.0
[TYPE:task][PROJECT:private_ai_gateway][VERSION:1.0][LANG:zh]

::MODULE{TARGET}
  server_ip: <服务器IP>
  ssh_port: <实际SSH端口>
  ssh_user: <实际登录用户名>
  domain: <你的完整域名>
  workspace: 当前打开的专用项目文件夹
  release: 0.2.8

::MODULE{PLAN}
  [DO] 先只读检查本机SSH及服务器操作系统 资源 已有服务 端口和域名解析
  [DO] 阅读Wei-Shaw/sub2api的v0.2.8官方部署文件 说明文件来源和将修改的范围
  [MUST] 先给出安装方案和恢复步骤 等我确认方案后再执行

::MODULE{BOUNDARY}
  [MUST] 保留现有SSH 密码 公钥 用户及厂商救援入口 不重装系统 不删除已有数据
  [MUST] 不索取或回显密码 私钥 上游密钥 JWT_SECRET和TOTP_ENCRYPTION_KEY
  [MUST] 安装依赖只用官方来源 失败先读日志 不用反复重装替代排查
  [MUST] 如需网络或防火墙改动 先列出现有管理入口和拟新增80及443入口 由我逐项批准

::MODULE{DEPLOY}
  [DO] 在单独目录部署Sub2API PostgreSQL Redis 使用持久化数据目录
  [DO] 核实并固定weishaw/sub2api:0.2.8镜像及实际digest 不自行替换为latest
  [DO] 生成独立随机数据库密码和固定应用加密密钥 在受限配置文件中保存
  [DO] 同机反向代理时将应用8080仅绑定127.0.0.1 数据库和Redis不发布到公网
  [DO] 使用官方Caddy或Nginx配置域名HTTPS 保留证书数据 支持流式响应
  [MUST] 管理员密码由我安全输入 不使用公开默认密码 不把完整日志发到聊天

::MODULE{ACCEPT}
  [DO] 检查容器状态 本机health请求 域名HTTPS及管理员登录
  [DO] 重启应用后确认用户和配置仍存在 不执行删除数据卷命令
  [DO] 保存版本 digest 文件路径 配置备份 数据库备份方法及恢复步骤
  [MUST] 每个阶段给出实际返回结果 未验证的项目写未验证 不宣称已上线营业
::ILANG::COMPLETE::

这份卡使用 I-Lang 组织任务，你不需要学语法。它的作用是把目标、权限和验收标准说清楚。

你应该看到 WorkBuddy 准备这些内容：Docker 与 Compose、Sub2API 应用、PostgreSQL 数据库、Redis，以及域名的 HTTPS 反向代理。官方本地部署方案将数据保存在 data/、postgres_data/ 和 redis_data/ 等目录里。不要让安装变成“容器删了，账单也没了”。[官方 Compose 文件]

本教程固定应用镜像 weishaw/sub2api:0.2.8，方便问题复现。后面升级时，要先读变更、做备份，再验证新版本，不要让生产服务自动追着 latest 跑。

8080 是应用端口，不需要直接暴露给用户。同一台服务器上的反向代理可以访问 127.0.0.1:8080，用户只访问 HTTPS 域名。数据库和 Redis 也不用开放到公网。

自动签发 HTTPS 证书需要域名解析正确，证书校验入口能访问。常见部署会用到 80、443 端口，已有管理端口必须保留。WorkBuddy 若建议“关掉 SSH 更安全”，不要照做。[Docker 安装文档、Caddy HTTPS 文档]

怎么知道这一步真的完成了？

浏览器输入你自己的 https://api.example.com，应该打开 Sub2API 登录或初始化页面，浏览器不应出现证书错误。完成管理员设置后，可以进入后台。

让 WorkBuddy 再检查应用的 /health、数据库与 Redis 各自的容器健康状态和代理日志，只给出脱敏结果。/health 在这个版本只是应用 HTTP 服务的存活信号，不会替你测试数据库和上游模型。如果域名打不开，按 DNS、端口、反向代理、应用四处查，不要直接清空目录重装。

现在只是网站后台装好了。你还没接模型，也没有完成对外调用测试。

第 5 步：拿到上游信息，分清两把 Key

上游就是卖给你模型调用能力的供应商。可以是你有资格使用的模型厂商官方 API，也可以是你经过评估、获得使用授权的第三方供应商。

别只拿到一个密钥就往下走。至少确认下面四项：

上游给你的 API Key，是你的服务器向供应商买服务时使用的。接好以后，你会在自己的站点生成另一把 API Key，那才是给自己或用户调用的下游密钥。

把上游密钥直接发给用户，他们还需要你的站点做什么？你也很难再控制每个人的额度。

Base URL 不是供应商首页，也不是价格表页面，更不是随手复制的 /chat/completions 完整请求地址。v0.2.8 对根地址和 /v1 有处理逻辑；供应商若用了类似 /openai/v1 的专用前缀，不要擅自删掉。[Base URL 处理源码]

供应商声称“全是官方模型”，只能当作待核查的宣传。返回内容像某个模型，并不能独立证明它的来源。挑供应商时，还要看稳定性、异常退款处理和数据使用规则。

第 6 步：创建分组，再添加上游账号

下面以 OpenAI 兼容 API 为例。其他平台要按实际协议选择，不要为了省事全部选 OpenAI。

分组：决定这批用户可以用什么

进入管理员后台的“分组管理”，创建一个用于测试的分组，例如 OpenAI-测试。平台选择 OpenAI，描述写清用途，费率倍数先保持 1，方便核对计费。其他限制按页面提示设置，不确定的字段先查说明。

分组不只是名字。它会参与权限和计费配置。后面账号、价格渠道与用户密钥都要对应到这组，不能各建各的。

账号：配置供应商的连接信息

进入“账号管理”，添加账号。v0.2.8 界面的关键字段可按下面对应填写：

保存后，在账号的测试入口选一个确实支持的模型，发送一句简短问题。不要照抄别人截图里的模型名，也不用选择最贵模型来证明部署成功。

OpenAI API Key 账号还有 Responses 模式选项，包括自动、强制 Responses 和强制 Chat Completions。先按上游实际能力配置；报接口不支持时，核对供应商文档，不要随机切来切去。[账号配置源码]

出现正常回答，只能说明这次后台到上游的测试通过。它还没有证明普通用户能通过你的域名使用。

第 7 步：配置价格，别让 AI 看错单位

管理员进入渠道管理的定价页面，创建对应平台的渠道，将测试分组关联到渠道，再为实际开放的模型填写价格。

不要直接把供应商整张价目表丢给 AI，说一句“照官方价格填”。你买入的价格、模型厂商公开价和你卖给用户的价格，是三件事。

v0.2.8 定价界面的 Token 价格使用美元 / 百万 Token。输入、输出及适用的缓存价格要分别核对。供应商若用“人民币 / 千 Token”或“积分”报价，必须先转换和确认规则，不能把数字原样粘进去。[价格字段与单位源码]

举个纯算术示例：假设输入价是每百万 Token 2 美元，输出价是 8 美元。一笔请求有 1000 个输入 Token、500 个输出 Token，没有缓存，倍率都是 1，那么理论基础费用是：

输入：1000 ÷ 1000000 × 2 = 0.002 美元
输出： 500 ÷ 1000000 × 8 = 0.004 美元
合计：0.006 美元

这不是任何模型的现价。实际账单还可能受到分组倍率、缓存、取整及供应商规则影响。

让 WorkBuddy 先整理一张“上游报价单位、换算结果、站内价格、倍率”的对照表，你核对后再录入。定价填错一次，后面的请求可能次次按错价算。

第 8 步：用普通用户的密钥，走一遍真实请求

先建一个独立普通测试用户，用它登录用户界面，不要只在管理员的账号管理页里测试。普通计费组要给测试用户设置少量可用余额；订阅组则需要有效订阅，按你所选模式处理。

进入用户界面的 API 密钥页面（路径 /keys），创建一把新 Key，关联测试分组。看不到这个组时，回管理员的用户或分组设置，授权该测试用户使用，再重新检查。

测试 Key 设置明确的小额限额和有效期。这个版本的 Key 限额填 0 或留空，表示无限额，不是“禁止使用”；Key 限额也不等于给账户充值。[用户密钥页面源码]

把这把下游 Key 保存在自己的密码管理工具或本机受限文件里。以后每个用户单独发 Key，泄露时可以单独撤销，不必连上游一起更换。

让 WorkBuddy 生成一个只在本机运行的测试文件。填入你的 HTTPS 域名、下游密钥和刚才确认过的模型 ID。让它在本机以隐藏输入方式读取密钥，不把密钥写进命令行历史或聊天，再发送一句“请只回复测试成功”。

如果上游和当前配置支持 Chat Completions，这个测试可以使用 /v1/chat/completions。仅支持 Responses 的服务，要使用对应接口，不能拿错协议后说中转站坏了。

测试完成，检查自己的用量记录，以及上游同一时段的账单。记录模型、请求时间、输入输出用量、缓存情况、站内扣费和上游扣费。双方计费口径不同可能造成差异，先定位，不要求所有数字机械地相等。

普通问答通过后，再测你准备让用户使用的客户端。要卖给 Agent 或编程工具使用，就额外测试流式输出和工具调用；有图片需求再测图像能力。文本回答成功，不会自动证明这些功能都支持。

遇到报错，先看这张表

这些是排查入口，不是看到一个状态码就能确定原因。把脱敏报错、发生时间和当前阶段交给 WorkBuddy，让它对照日志解释，再决定改哪一处。

能用以后，还差一件事：下次坏了怎么恢复

先把名称、头像之类的外观放一放。改个头像很快，数据库丢了就不是这个工作量了。

至少保存部署版本、Compose 文件、环境配置、应用数据、数据库备份和证书数据。PostgreSQL 优先用 pg_dump 等数据库备份方式，不要在数据库仍运行时，直接把数据目录压缩一下就当作可靠备份。环境文件里的 JWT_SECRET 与 TOTP_ENCRYPTION_KEY 也要按秘密备份，恢复时不能随便重新生成。备份里可能包含用户与账单数据，要限制访问。

让 WorkBuddy 写出备份和恢复步骤，并在隔离环境检查备份能否还原。只看到一个压缩包，不能说已经具备恢复能力。重启一次应用，确认账号、分组和用量还在；不需要用删除数据库来证明。

监控也别只看首页。至少留意服务健康、磁盘、上游余额和失败请求。主机再稳定，上游余额用完一样会停。收费站还要把服务范围、数据处理、退款和故障联系办法写清楚，按所在地及业务范围核对要求。

在这些检查完成前，可以先供自己小规模使用，暂时关闭公开注册或不开放充值。先跑通一个模型、一个用户、一笔账单，再增加平台和用户。

几个新手经常问的问题

我没有 ChatGPT Plus，能搭吗？

可以用 WorkBuddy 作为部署助手，不需要先购买 ChatGPT。它自己的额度，以及域名、服务器和模型调用成本，仍要分别计算。

每个月约 500 元，包含模型费吗？

不包含。这里指推荐主机的月预算，实际美元月付为 69.99。上游按调用或其套餐规则另行收费，域名续费也另外算。

能同时接国内外模型吗？

软件有相关平台配置入口。每个平台仍需要真实可用的上游授权，确认协议、模型、分组和价格后分别测试，不是一键获得所有模型。

照这篇做，能直接开始卖吗？

网站部署完成和经营准备完成不是一回事。对外提供服务，还要核对转售权限、实际承载、计费、备份恢复及用户规则。别拿第一个成功回答代替这些检查。

我的建议

不会写代码，不必成为你动手的障碍。WorkBuddy 可以帮你读文档、准备文件和执行命令，但你至少要知道：钱付给谁，密钥放在哪，失败时找什么证据。

我更看重稳定，不是因为服务器越贵越好。你开始给别人提供服务以后，主机月租只是成本的一部分。出了故障能否恢复，出了错账能否解释，才会影响别人愿不愿意继续用。

别急着挂满几十个模型。先用自己的域名收到第一条正常回答，再确认它花了多少钱。把这件事做明白，你才真的开始拥有一个自己能管理的中转站。

如果你还没想清楚这门生意的收入与风险，可以接着看加密狗的AI API 中转站指南；想了解推广项目与佣金的关系，可以看联盟营销入门。