API Key 泄漏之后我才补上的课 - 给小程序直连 AI 加一层安全代理
带团队做 AI 功能这两年，我最怕的不是模型效果差，而是打开后台日志的那一刻——某个部署在小程序端三个月的 API Key,调用量在凌晨飙到了平时的四十倍。那次事故之后我复盘了很久，结论是：小程序直连 AI 服务这件事，从第一天就不该让密钥离开服务器。 这篇文章把我们的整改方案完整写出来，给同样在带小团队的读者一个可以直接抄的作业。
一、先想清楚：风险出在哪个环节
很多独立开发者的第一版架构是这样：小程序前端直接请求模型服务的 API,Key 硬编码在前端代码里。这个做法在 demo 阶段没问题，但一旦上线，有三个绕不开的风险：
- Key 即现金。 任何拿到小程序包的人，反编译后都能看到你的 Key。它等价于一张没有限额的信用卡。
- 无预算闸门。 前端直连意味着用量完全取决于用户行为，你在服务端没有任何拦截手段，被刷只能事后发现。
- 无法审计。 谁在什么场景调用了多少 token、花了多少钱，前端直连的架构里这些问题都答不上来——而管理者恰恰最需要这些数字。
解决思路很简单：在小程序和 AI 服务之间加一层自己的代理服务，Key 只存在于服务端。 我们团队选择用统一 AI 网关(ThisToken.AI)作为模型出口，自己的代理层只做鉴权、限流和记账。
二、管理者要盯的三个流程节点
方案落地前，建议先把这三件事在团队里定成规矩，比技术选型更重要：
节点一：Key 的生命周期管理。 注册网关账号、生成 Key、谁有权查看、多久轮换一次，这些要有人负责。我们团队的规则是：Key 只在服务端环境变量里出现，代码仓库里出现的任何 Key 视同事故。
节点二：额度与预算的硬上限。 在网关后台为每个 Key 设置额度上限，同时在自己的代理层按用户做限流。双重保险的意义在于：即使一层失守，损失是可计算的。
节点三：调用日志的归属。 代理层记录的每次调用要能关联到功能模块，月底拉账单时，你能直接回答“聊天模块花了多少、推荐模块花了多少”。这决定了下个月预算怎么分。
三、十分钟跑通：注册、拿 Key、第一段代码
下面是实操部分。
第一步，注册账号。 打开 https://api.thistoken.ai/register ,用邮箱完成注册。这一步建议用团队共用的工作邮箱，而不是个人邮箱——账号本身也是资产，归属要清晰。
第二步，创建 API Key。 登录后进入控制台的 API Key 管理页面，创建一个新的 Key 并立即复制保存。注意平台只在创建时展示一次完整 Key。具体的计费方式和额度，以官网价格页为准，不要依赖任何二手信息。
第三步，跑通第一段代码。 这里用 Python,代码体现的核心是 base_url="https://api.thistoken.ai/v1"——所有请求都指向这个统一入口：
import os
from openai import OpenAI
# Key 只从环境变量读取,绝不写进代码
client = OpenAI(
api_key=os.environ["THISTOKEN_API_KEY"],
base_url="https://api.thistoken.ai/v1"
)
def chat(prompt: str) -> str:
"""代理层的核心函数:小程序后端只暴露这个能力"""
resp = client.chat.completions.create(
model="gpt-4o-mini",
messages=[
{"role": "system", "content": "你是一个简洁友好的助手。"},
{"role": "user", "content": prompt},
],
max_tokens=300,
)
return resp.choices[0].message.content
if __name__ == "__main__":
print(chat("用一句话介绍什么是API网关"))跑通这段代码，说明三件事同时成立：账号有效、Key 正确、网络链路通畅。建议团队里每个新成员入职时都跑一遍，作为环境验证的标准动作。
四、把代理层补成“管理者可用的”架构
上面的代码只是链路验证。真正上线时，代理层至少要补上四块，每块都不复杂，但缺一块就少一层风险控制：
- 用户鉴权：校验小程序端的登录态(比如微信的 session),没有合法身份的请求直接拒绝；
- 按用户限流：每个用户每天 N 次调用，超限返回友好提示，防止单个用户刷爆预算；
- 模块标记：调用日志里打上功能标签，月底出账时能按模块拆分成本；
- 失败兜底：模型超时或报错时，给用户降级回复，而不是让小程序白屏。
这套东西部署到任意一台轻量云服务器即可，对外只暴露你自己定义的接口，小程序前端调用你的域名，全程接触不到任何 Key。
五、最后说两句管理视角的体会
技术方案本身半天就能写完，但真正让团队安全运转的，是流程：Key 谁保管、额度谁监控、账单谁复盘。把这三个问题写进你的团队文档，代理代码才有意义。
那次凌晨的异常调用，最终因为我们事先在网关后台设了额度上限，损失停在一个可以接受的数字。事后我们做的唯一架构改动，就是把 Key 从小程序端挪进了服务端代理——一次整改，换来之后每一晚都睡得着觉。
如果你还没有注册统一的 AI 网关账号，可以从这里开始：https://api.thistoken.ai/register 。先注册、拿 Key、跑通上面那段代码，剩下的风险控制，我们下次接着聊。
---
本文的示例只需一个 API Key 就能复现：在 https://api.thistoken.ai/register 注册即用。