三个团队抢一个模型接口，直到我们把商品图片描述生成这件事拆清楚
一、业务痛点：不是技术难，是协作乱
我们是一个二十人左右的二手交易平台团队，产品、运营、算法、风控四个小组都盯着「商品图片智能描述生成」这个功能——用户上传几张旧手机、旧家具的照片，系统自动生成一段规范的商品描述，减少卖家懒得写描述导致的成交率下降。
功能上线前，问题先爆发了：
- 重复采购：算法组接了一个视觉模型，运营组做品类审核又接了另一家，风控组识别违禁品再接第三家。三份合同、三套计费、三份安全评估，管理者每个月对账要花一整天。
- 质量口径不一：同一个二手包包，算法组生成的描述说“九成新”，运营侧审核模型判断“成色描述存疑”，两边标准没对齐，客服天天处理申诉。
- 风险没人兜底：视觉模型偶尔会把用户照片里的隐私信息（背景里的快递单、身份证）写进描述。这件事散落在三个组的 backlog 里，谁都觉得该别人做。
- 供应商锁定：某次主用视觉模型调价 40%，想切换时才发现调用代码散落在四个服务里，评估迁移成本要两周。
作为管理这个项目的人，我意识到问题不在模型选得好不好，而在于没有一个统一的治理层。AI 能力必须像基础设施一样被统一接入、统一计量、统一风控，而不是每个组自己拉一根线。
二、架构设计：一条网关管到底
重构后的架构分四层：
- 接入层：所有服务（描述生成、成色审核、违禁识别）统一走 AI API 网关，网关屏蔽底层模型差异，暴露统一的 OpenAI 兼容接口。
- 模型路由层：网关配置路由规则——商品主图描述走视觉大模型，批量审核走轻量专用模型，成本敏感场景自动降级到小模型。
- 治理层：按项目维度设预算和配额，按团队维度出用量报表；敏感内容（隐私信息、违禁品）在网关侧做统一出站过滤。
- 业务层：描述生成服务只关心 prompt 编排和业务兜底，不关心模型是谁。
这个架构对管理者最大的价值是：决策权收回来了。换模型是网关上改一行路由配置，不是四个组各排两周迁移任务。
三、关键实现步骤
从立项到上线，我们把流程拆成五步，每一步都有明确的验收物：
步骤一：统一描述规范（1 周）
产品和运营先对齐输出格式——固定结构：品类 / 成色观察 / 配件说明 / 建议标题。所有 prompt 围绕这个模板生成，从源头解决口径不一。
步骤二：网关接入与密钥收口（3 天）
废除散落在各代码库里的 API Key，全部收敛到网关侧管理，服务用网关颁发的访问凭证。
步骤三：描述生成流水线（2 周）
核心流程清单如下：
用户上传图片
├─ 1. 基础校验（大小/格式/EXIF 隐私信息剥离）
├─ 2. 违禁品识别（专用小模型，网关路由）
│ └─ 命中 → 转人工审核队列，流程终止
├─ 3. 商品要素识别（视觉模型：品类/品牌/成色线索）
├─ 4. 描述生成（视觉大模型 + 结构化 prompt 模板）
├─ 5. 出站内容过滤（网关侧：隐私信息/夸大用词/违禁词）
├─ 6. 质量抽检（低置信度样本回流人工标注）
└─ 7. 写入商品库，附带模型版本与成本标记步骤四：灰度与风控验收（1 周）
按 5% 流量灰度，每天对账：生成成功率、人工驳回率、单条平均成本。驳回率超过阈值自动回滚。
步骤五：运营复盘机制（持续）
每周出一份模型用量与质量报表，管理者看三个数：单条成本、驳回率、切换模型后的对比曲线。
一个简化版的调用示例（Go），展示业务侧如何做到「不感知底层模型」：
// 业务侧只调网关，模型选择由路由配置决定
resp, err := client.CreateChatCompletion(ctx, ChatRequest{
Model: "vision-auto", // 网关路由别名，非真实模型名
Messages: buildPrompt(images, categoryHint),
Metadata: map[string]string{
"team": "algo",
"project": "listing-description",
"trace_id": traceID,
},
})
// 成本、token 用量、模型版本由网关自动记录，无需业务埋点四、为什么统一 AI API 网关能显著降低维护成本
这是我作为项目管理者算过最清楚的一笔账：
- 一份对接代码代替 N 份。不同供应商的鉴权方式、请求格式、限流策略各不相同。直连意味着每换一家模型就要重写一遍适配层、重跑一遍测试。走统一网关后，业务代码只认一套接口，模型更换的成本从「周」降到「小时」。
- 密钥治理一处收口。过去密钥散在代码库、配置中心、甚至个人本地环境里，泄露排查极其被动。收敛到网关后，权限按项目隔离，轮换一次密钥只改一处。
- 成本可归因、可预算。网关按项目/团队维度记账，月底不用再人工拼凑三张供应商账单。某个功能成本异常上涨，当天就能定位到具体调用链。
- 风控策略统一迭代。隐私过滤、违禁词拦截这些规则只需要在网关侧维护一份，不会出现「算法组改了、运营组没改」的策略漂移。
- 故障有单一观测点。描述生成突然变慢或报错，先看网关的调用追踪，五分钟内判断是模型侧问题还是业务侧问题，避免三个组互相甩锅的会议。
粗算下来，仅「换模型不重写代码」和「月度对账自动化」两项，我们每季度节省的工程与协作时间就超过一个全职人力周。
五、管理者复盘
这个项目最终三周灰度全量，描述采纳率稳定、单条成本可控，更重要的是：后续任何 AI 新需求，团队默认先过网关——这套秩序比功能本身更值钱。对小团队的建议是：哪怕只接一个模型，也先建网关再写业务代码，治理的成本永远晚建贵过早建。
如果你也在规划类似的 AI 能力接入，可以从一个支持多模型统一接入、按项目计量计费的网关开始，先把架构的地基打好：https://api.thistoken.ai/register
---
本文的示例只需一个 API Key 就能复现：在 https://api.thistoken.ai/register 注册即用。