AI Endpoint vs 传统 API：设计逻辑的根本差异

把 AI 接口当成普通 API 来写，最后大概率会被 Token 账单或者随机的输出格式搞崩溃。我之前习惯的后端逻辑是：验证请求 → 执行业务 → 返回结果。这种确定性在面对大模型时完全失效了。

传统的 API 是确定性的，只要状态一致，输入 A 永远得到 B。但 AI 接口是概率性的，即便输入一样，输出也可能在合法与非法之间反复横跳。

一个真正能上生产环境的 AI Endpoint，其实际工作流应该是这样的：

验证请求 (Request Validation)
↓
构建 Prompt / 注入上下文 / 挂载 Tools
↓
调用模型产生概率性输出 (Probabilistic Output)
↓
Schema 校验 / 语义检查 / 安全过滤
↓
重试、修复、拒绝或走回退方案 (Fallback)
↓
返回最终结果

在这个流程里，最让我踩坑的是“校验”这个环节。在传统 API 里，校验只在入口处做一次；但在 AI 接口里，校验变成了前后双向：

• 前置校验： 除了基础的参数检查，还得限制输入长度、过滤恶意指令（Prompt Injection），防止用户通过接口刷爆我的 Token 配额。
• 后置校验： 这是最麻烦的。模型可能会漏掉某个必填字段，或者返回一个格式正确但逻辑离谱的 JSON。因为 Token 贵，你不能无脑重试，必须得有一套修复机制或者兜底方案。

这种转变直接影响了工程实现。比如延迟（Latency）变得不可控，幂等性处理变得复杂，甚至连测试用例都不能写死。现在我写 AI 接口时，会把重点放在“如何处理模型不听话”的边界情况上，而不是单纯地调通接口。