上架一张照片要打三行描述——二手平台商品描述生成，我作为负责人怎么管住这条AI流水线
一、业务痛点：小事，但天天发生
我们团队运营一个区域性二手交易平台，日均在架商品约几千件。卖家上传照片后，需要手动填写商品标题和描述。这件看似简单的小事，实际带来三个问题：
效率问题：超过一半卖家只传照片、描述留空或写一句“看图”。商品信息缺失导致搜索命中率低，成交周期拉长，平台撮合效率直接受损。
质量问题：认真写的卖家，描述质量也参差不齐。有人夸大（“九九新”实际磨损明显），有人词不达意，客服介入纠纷的比例居高不下。
管理问题：这是我们最头疼的。描述生成如果接AI，涉及三个部门——产品定规则、运营审内容、技术做实现。如果没有一套清晰的流程和权责划分，AI生成的描述一旦出错（比如把翻新机描述成原装机），平台要承担信任损失。
作为负责人，我的结论是：这件事必须做，但必须以“可管控的流水线”方式做，而不是让某个开发随手接个模型API完事。
二、架构设计：分层、留痕、可回滚
整体架构分四层：
┌─────────────────────────────────────────┐
│ 应用层：上传页 → 生成按钮 → 卖家确认编辑 │
├─────────────────────────────────────────┤
│ 业务规则层：类目识别 / 敏感词过滤 / │
│ 成色描述规范 / 长度与语气约束 │
├─────────────────────────────────────────┤
│ 统一AI API网关：密钥集中管理、用量配额、 │
│ 请求日志、多模型路由与降级 │
├─────────────────────────────────────────┤
│ 模型层：视觉理解模型（图片→要素提取） │
│ 文本生成模型（要素→规范描述） │
└─────────────────────────────────────────┘几个关键的管理决策：
- 两段式生成而非一步到位。先让视觉模型输出结构化要素（品类、颜色、可见瑕疵、疑似成色），再让文本模型按平台模板生成描述。中间产物是JSON，可审核、可缓存，出了问题能定位是“看错了”还是“写错了”。
- 卖家确认制。AI生成的描述只是预填草稿，卖家可编辑后发布，页面明确标注“由AI辅助生成”。这是风险控制的第一道闸门，把最终责任落回发布者，同时降低法律与信任风险。
- 敏感词与合规校验独立于模型。不依赖模型自觉，规则层有独立的词库和校验逻辑，模型输出必须过这道关。
- 所有生成记录留痕。谁的商品、哪个模型版本、什么提示词、生成结果、卖家是否修改——全量入库。出现纠纷时能回溯，也是后续优化提示词的数据基础。
三、关键实现步骤
作为管理者，我把落地拆成六步，每步有明确验收标准：
- 第一步，规则先行：产品与运营共同制定《描述生成规范》，包括各品类的必填要素、成色用词标准、禁止出现的表述。没有这份文档，开发不动工。
- 第二步，网关接入：技术团队通过统一AI API网关接模型，不在业务代码里散落密钥。
- 第三步，两段生成链路开发：图片→结构化要素→描述文本，中间结果入库。
- 第四步，灰度验证：先对10%的新上架商品开放，人工抽检三百条，重点看要素准确率和描述违规率，达标后逐步放量。
- 第五步，卖家端上线：预填+编辑+标注，收集编辑率数据（卖家改动越多说明生成越不准）。
- 第六步，建立月度复盘：运营提问题case，技术调提示词或换模型，形成闭环。
核心生成逻辑示意（简化版）：
def generate_description(image_url, category_hint):
# 第一步：视觉模型提取要素（结构化，可审核）
elements = gateway.chat(
model="vision-model",
messages=[{
"role": "user",
"content": [
{"type": "image_url", "image_url": {"url": image_url}},
{"type": "text", "text": "提取品类/颜色/可见瑕疵/成色，以JSON输出，不确定的字段填null"}
]
}],
temperature=0.1
)
elements = validate_schema(elements) # 结构校验，缺失字段兜底
# 第二步：合规校验（独立于模型）
if contains_banned_words(elements):
return fallback_manual_review()
# 第三步：文本模型按平台模板生成
desc = gateway.chat(
model="text-model",
messages=build_prompt(elements, category_hint),
temperature=0.3
)
return compliance_filter(desc) # 发布前最后一道闸四、为什么坚持走统一AI API网关
这是我在团队内部拍板时解释最多的一个决定。业务代码直接调各家模型API，短期看快，长期维护成本会失控，原因有四：
密钥与安全集中。密钥只配置在网关侧，业务服务器和客户端不接触。否则换人、换服务器、上小程序端，密钥就得重新分发一遍，泄露风险成倍增加。
模型替换不用改业务代码。模型迭代很快，我们已经在灰度中换过一次视觉模型。因为业务代码只对接网关的统一接口，替换只是网关侧改一行路由配置，业务层零改动。如果当初每处调用都写死模型名，这次更换至少要动五个模块。
用量与成本可管。各部门、各场景的调用量在网关侧统一统计和限额。描述生成这种高频场景一旦被异常流量打爆，配额机制能自动熔断，账单不会失控——这是管理者最需要的“看得见”。
日志与审计天然齐全。所有请求有统一日志，配合前面说的留痕要求，纠纷回溯和效果分析都有了数据底座。
五、一点经验总结
这条流水线上线后，空描述商品占比明显下降，卖家编辑率稳定在一个可接受区间，说明生成质量过关。回头看，技术上并不难，真正决定成败的是三件事：规则文档先于代码、卖家确认制兜住风险、网关层让模型可换可管。对独立开发者和小团队，我的建议是：AI应用落地的差距不在会不会调API，而在有没有把流程、协作和风险控制设计好。
如果你正准备动手，可以从接入一个统一的AI API网关开始，把密钥管理、模型路由和用量监控一步到位：https://api.thistoken.ai/register
---
本文的示例只需一个 API Key 就能复现：在 https://api.thistoken.ai/register 注册即用。