AI API 中转站

先定性质，因为它决定你要不要资质、要不要风控、要不要备案：

1. 自用中转：自己在多个设备 / 应用里用同一个入口。合规压力最小
2. 小范围分享：给朋友或小团队用，需要 key 分发与额度控制
3. 对外售卖：把 API 包装成商品。这条线最重：涉及经营资质、发票、退款、投诉，个人做之前先想清楚

技术之外必须想清楚的三件事：

• 上游服务条款允不允许转发（多数厂商不允许公开转售）
• 成本谁承担、超支谁兜底（务必设硬上限）
• 用户出了问题你负什么责（写清免责）

本站建议：个人先做前两种，把「可控、可计量、能止损」跑通，再考虑商业化。别一上来就收钱——收款之后的责任比技术难十倍。

成本先算：单价 × 预估调用量，加上服务器与流量。多数人高估了收入、低估了刷量。

方案 A：自己写最小转发（约 60 行，可控性最高）

import express from 'express';
const app = express();
app.use(express.json({ limit: '1mb' }));
app.post('/v1/chat/completions', async (req, res) => {
  const upstream = await fetch(UPSTREAM + '/v1/chat/completions', {
    method: 'POST',
    headers: { 'Authorization': `Bearer ${UPSTREAM_KEY}`, 'Content-Type': 'application/json' },
    body: JSON.stringify(req.body)
  });
  // 流式：直接 pipe；非流式：转发 json
  upstream.body ? upstream.body.pipe(res) : res.json(await upstream.json());
});

方案 B：开源中控（推荐先试）
One API / New API 这类项目自带：多渠道管理、key 分发、额度与限流、用量统计、Web 管理界面。装好即用，省掉你造轮子。

必须做的四件事：

• 密钥只存服务端环境变量，绝不进前端、绝不进 Git
• 请求体大小与 max_tokens 限制，防止单请求打爆额度
• 按 key 限流（每分钟请求数 + 每日总量）
• 超时与上游错误统一转成友好提示，别把上游报错原文甩给用户

别做的：为了让别人「免费无限用」而开放无鉴权端点，几天就会被扫到刷爆。

每个使用者一个 key，这是底线。共享一个 key 出事了查不出是谁。

最小表结构（SQLite 或 JSON 文件都行）：

keys:  key_hash | name | quota_total | quota_used | rpm_limit | enabled | created_at
usage: ts | key_hash | model | in_tokens | out_tokens | status | latency_ms

四个必须实现的接口/能力：

• POST /admin/keys 生成 key（只返回一次明文，库里存 hash）
• 每次调用后累加 quota_used，超配额返回 429
• /admin/usage 看每个 key 的用量（按天 / 按模型）
• enabled=false 一键停用某个 key（出事时你的止损按钮）

计量口径写死：按上游返回的 usage.prompt_tokens / completion_tokens 记，不要自己估算 token——模型换了分词就全错。

告警：当日总量超过预算 80% 时给自己发一条通知（钉钉 / 邮件，见「服务器监控面板」场景）。等账单出来才发现就晚了。

访问控制：

• 所有 /v1/* 端点强制校验 key，缺失或失效返回 401
• 按 key 限速：每分钟请求数 + 并发数双限
• 管理接口放内网或独立端口，不要暴露在 80/443，且加二次口令

日志要记什么（决定是否够用）：
时间 | key | 模型 | 状态码 | 延迟 | 输入/输出 token | 错误信息

日志绝不能记什么：

• 完整请求正文（含用户隐私内容）——只记长度与脱敏后的首尾片段
• 上游密钥、用户 key 明文
• 任何可用于还原个人身份的信息

留存与合规：日志保留 7–30 天够排查即可，定期清理；页面与接口文档里写明「记录哪些数据、保留多久」。

异常处置：发现某个 key 异常放量 → 先 enabled=false 止血 → 再看日志 → 最后才决定要不要恢复。顺序不能反。

上线：

• 域名 + HTTPS（宝塔 Let's Encrypt 一键）+ Nginx 反代到本机服务
• Nginx 设请求体大小限制、超时（AI 请求可能很长，读超时设 120s 以上）
• 配健康检查端点 /healthz，接 UptimeRobot 做可用性告警

观测三张表（决定你能不能长期跑）：

1. 用量表：按天 / 按 key / 按模型的 token 与请求数
2. 成本表：用量 × 单价 = 成本，与实际账单对账（误差 >10% 说明计量有问题）
3. 质量表：错误率、平均延迟、超时占比

埋点事件（写进 data/conversion.json）：api_call、api_error、quota_hit（触发限流）。quota_hit 上升说明有人滥用或你的配额给低了。

月度复盘 20 分钟：成本 vs 预算、错误率趋势、TOP3 使用方。连续两个月成本高于预期且没有对应价值，就缩规模——中转站最危险的形态是「有人白嫖，你在买单」。

合规收尾：接口文档写清用途限制与免责声明，发现滥用立即停用。