服饰推荐与运营平台

01 / 场景

场景与约束

把大模型接进业务，第一个月往往很惊艳，第三个月开始失控：同样的输入今天和明天答案不一样，运营改不了提示词，出了问题查不到是哪一版、哪个模板、哪次调用产生的。要让它变成产品，得先把模型输出纳入工程约束——字段固定、状态可查、结果可审、变更可回滚。

• 输出格式不稳定，前端与下游系统难以消费
• 提示词散落在代码里，运营无法自行调整
• 模型升级或更换后，业务口径与效果出现断层
• 生成内容缺少审核与留痕，无法对外发布

02 / 方案

方案构成

平台把“数据—提示词—模型—审核—发布”做成一条可配置的流水线：素材先经过治理进入结构化数据，提示词以模板形式由运营配置并绑定业务规则，调用结果经结构化约束后进入审核队列，审核通过才对外。每一次输出都记录模板版本、模型版本与输入快照，出问题可回溯。

• 数据治理：采集、清洗、分类、属性标签与素材质量检查
• 模板体系：场景模板、业务规则、变量与编排配置
• 模型服务：统一网关，支持多家模型与版本切换
• 结构化输出：字段与格式约束、任务状态与重试
• 审核与发布：人机协同审核、版本留痕、灰度发布

03 / 技术

技术要点

服务层用 FastAPI 承载，Pydantic 定义输出契约，把“模型说了什么”变成“系统能校验的结构”；模型侧通过统一网关接入，替换模型只需改配置而不动业务代码；提示词模板与业务规则入库，运营在后台调整并即时生效，历史版本可回滚；审核队列与发布状态机保证任何对外内容都经过人工确认。

• 服务：FastAPI + Pydantic 结构化输出
• 模型：多provider 网关、版本与灰度切换
• 配置：提示词模板与业务规则入库管理
• 治理：审核队列、发布状态机、调用留痕

04 / 交付

交付与验收

AI 项目的验收要落到可测量的指标上，否则很容易变成“感觉还行”。我们会和业务方一起定义一组回归样本，覆盖典型输入与边界输入，每次改模板或换模型都跑一遍，看结果是否退化。

• 数据治理规则与标签体系说明
• 提示词模板与配置后台
• 结构化输出契约（字段、枚举、状态）
• 回归样本集与评测记录
• 审核与发布流程说明、操作培训

05 / 边界

可复用与边界

这套“模板 + 结构化 + 审核 + 留痕”的骨架几乎可以平移到任何大模型落地场景：客服话术、内容生成、单据识别、知识问答。边界要讲清楚：模型输出仍然是概率性的，必须保留人工审核环节；素材与数据质量决定效果上限，治理成本往往高于模型接入本身；涉及对外发布的内容，责任在审核环节而不在模型。

• 可迁移：客服辅助、内容生成、单据结构化、知识问答
• 依赖：业务数据治理程度与审核人力配置
• 不承诺：未经回归评测的效果指标