分享AI图像服务
模板→数据驱动的实时生成
将用户运动数据、玩法规则与视觉风格转化为生成变量，构建可接入主链路的 AI 图像服务——让每一次完练分享都按当次状态产出差异化内容。
3.1pp
分享率提升
16+
上线玩法数量
92.4%
图像生成成功率
01 / 项目背景
分享内容的供给方式遇到瓶颈
完练分享是用户完成运动后的核心表达与传播场景。项目的核心目标并不是引入 AI ，而是重新设计分享内容的供给方式：
将用户运动数据、玩法规则和视觉风格转化为 AI 可消费的结构化输入，构建一套可接入业务链路的图像生成服务，使分享内容从
01
用户侧：分享动机衰减
画面差异主要来自数据字段变化，而非表达方式变化；连续使用后新鲜感与分享欲下降
业务后果
分享动机衰减，增长入口失效。
02
业务侧：策略上不去
分享模板让用户最直观感受的就是一张图。运营有图文呈现策略想上，固定模板承载不了。
业务后果
运营节奏受限，运营策略无法落地。
03
生产侧：扩展成本高
新增节日 / 运营主题需重做模板；数量上升后设计、适配、维护、版本管理成本同步上升
业务后果
内容供给呈线性成本，无法规模化扩展
02 / 核心难点
从一张图到一项 To-C 服务，需要攻克什么
难点不在于调用模型生成图片，而在于图像能力进入真实业务后，能否层层递进地跑通链路、覆盖长尾品类、保证首张可用，并最终产生分享价值——前三层决定「能不能落地」，第四层决定「有没有价值」。
能不能跑起来
To-C 链路从 0 到 1
公司首次将生成式图像能力接入 To-C 主链路，无成熟范式可循；
需从零构建输入、转译、生成、回传的端到端链路，并保证任一节点异常下服务不中断。
能否稳定进入业务主链路
跑起来准不准
长尾品类生成准确性
70+个运动品类在姿态、器械与场景语义上高度分化；
通用模型仅覆盖头部品类，长尾准确率明显下降，需以模型能力边界为约束设计品类映射与生成策略。
能否覆盖完整业务场景
准了用户愿不愿意等
首张图可用性
单次生成耗时约 30 秒，试错成本高，且 To-C 场景首张即定去留；
需以规则约束与质量下限守住首张的语义准确性，并压制明显 Badcase。
用户会不会有第二次
用了有没有业务价值
可用不等于愿意分享
技术达标只解决「可用」，内容能否被分享取决于情境、风格与数据表达；
需将用户运动状态与玩法策略转译为具备传播价值的视觉表达。
能否产生分享增长价值
03 / 解法判断
项目能不能落地，取决于四个关键判断
在模型能力尚不成熟、To-C 容错低、公司首次落地的约束下，如何判断、取舍并把不可控的风险拆成可验证的命题，决定了项目能否稳定推进。
引入 AI，重构供给方式
固定模板只能替换数据，无法按用户状态与玩法生成差异化内容；
AI 能把用户数据变成视觉变量、玩法变成规则配置、生图变成服务化链路。
人工模板→数据驱动生成
不一步到位，分阶段推进
继续堆模板安全但解决不了核心问题。
直接上实时会让长尾泛化、To-C 容错、链路从零建等难点同时暴露、风险不可控；选择分阶段服务化、每步只验证一个命题。
不可控风险→可控步骤
先验范式，再攻实时
实时性是可后置的工程问题，「AI 生产内容能否带来业务价值」才是范式成立的前提；
先用离线资产以最小改造验证价值，再投入实时工程。
最小代价→最关键的确定性
每阶段只验证一个命题
阶段一离线图库验证「数据驱动生成」范式
阶段二实时生成验证首张可用
阶段三数据驱动运营验证如何持续
能否产生分享增长价值
04 / 方案设计
一条把数据转译成分享图的可控链路
整套方案由一条端到端链路和一套工程保障构成，核心机制是把业务与用户数据转译为图像生成变量，分阶段的落。
MVP-AI 生产内容范式能否稳定成立
项目早期面临的核心约束是：实时生成耗时过长，模型稳定性和链路响应速度无法直接满足线上体验要求。因此，项目没有一开始就强行追求实时生成，而是采用更稳妥的分阶段策略：通过“图库预生成 + 动态检索”先验证业务价值。
运动数据非视觉语言，待建立图像模型生成稳定性、泛化性不足内容生成耗时过长、业务功能改造难度大0-1探索，SOP重塑需要验证、灵活迭代
0→1 数据驱动实时生成，可接入业务的服务
扩展用户数据、环境数据、业务数据范围，系统验证图像质量、泛化、时效。
逐步跑通完整链路：用户运动数据 → Dify 规则转译 → System Prompt / 图像 Prompt → 图像模型 API → 生成图像 → 前端拼合业务数据 → 分享卡片输出。
晴北京市春季早晨运动时间 01:27:15运动距离 4.78km运动消耗 458kcal户外行走
晴北京市春季中午运动时间 01:27:15运动距离 4.78km运动消耗 458kcal户外行走
晴北京市春季下午运动时间 01:27:15运动距离 4.78km运动消耗 458kcal户外行走
晴北京市春季夜晚运动时间 01:27:15运动距离 4.78km运动消耗 458kcal户外行走
雨北京市夏季早晨运动时间 01:27:15运动距离 4.78km运动消耗 458kcal户外行走
晴北京市夏季中午运动时间 01:27:15运动距离 4.78km运动消耗 458kcal户外行走
阴北京市秋季中午运动时间 01:27:15运动距离 4.78km运动消耗 458kcal户外行走
雪北京市冬季中午运动时间 01:27:15运动距离 4.78km运动消耗 458kcal户外行走
1→2 从"一个玩法能跑"到"怎么持续运营"
实时链路跑通后，重心从「能否实现」转向「能否持续」。随着玩法与版本不断增加，玩法矩阵的并行维护、风格生命周期判断与按档期迭代扩展成为新的工程与运营问题，需要一套以模块化架构和数据驱动运营为支撑的机制。
非节日晴天女运动距离 1.77km运动消耗 1699kcal运动时间 01:00:53小器械训练
情人节晴天女运动距离 1.77km运动消耗 1699kcal运动时间 01:00:53户外跑步
端午节晴天女运动距离 1.77km运动消耗 1699kcal运动时间 01:00:53户外骑行
中秋节晴天女运动距离 1.77km运动消耗 1699kcal运动时间 01:00:53羽毛球
圣诞节晴天女运动距离 1.77km运动消耗 1699kcal运动时间 01:00:53户外跑步
马年春节晴天女运动距离 1.77km运动消耗 1699kcal运动时间 01:00:53飞盘
元宵节晴天女运动距离 1.77km运动消耗 1699kcal运动时间 01:00:53乒乓球
0→1 构建新玩法
玩法架构设计 → 时间路由生成 → 多专家协作撰写 → 技术选型 → 质量自检 → 存档。
档期扩展
已有玩法增加节日 / 季节档：复用约 90% 骨架，仅修改差异视觉元素，并同步更新时间路由表，不重写整条链路。
迭代优化
提升已有提示词效果：质疑者先诊断问题类型，再按结构 / 视觉 / 映射 / 冗余分配主导专家修改，最后终审。
06 / 工程化保障
让 AI 从可生成→稳定上线的闭环控制
这套上线控制系统的核心价值，是把 AI 从不确定的生成能力，转化为可控、可验收、可监控、可持续迭代的业务能力。
重点是基于玩法复杂度、模型能力边界、耗时成本和线上稳定性，选择最合适的生成路径，并建立一套能够支撑真实业务运行的 AI 图像生成机制。
前置决策
先确定模型、路径与提示词规则，降低后续生成链路的不确定性。
Decision Layer
LLM选型
以规则转译准确率、结构化输出稳定性、复杂分支处理能力和成本为基准横向评估候选模型。
图像生成路径选型
“API 优先、ComfyUI Workflow 兜底复杂控制”的路径判断规则，统一质量、耗时与成本口径。
System Prompt 设计
玩法规则、字段优先级、视觉风格、构图边界和禁止项模块化，提升Image Prompt输出稳定性。
上线控制
把已验证规则拆进工作流、测试集和监控口径，支撑真实业务持续运行。
Operation Layer
Workflow 编排与链路控制
按玩法独立编排 Dify 工作流，将规则转译、提示词生成和输出标准化拆成可插拔模块。
测试与准出质量门控
统一记录输入字段、Prompt、模型配置与生成结果，正常、边界和历史 Badcase 建立准出标准。
线上监控与数据迭代
监控成功率、失败原因、环节耗时和行为反馈，反向调整规则、模型路径、版本上下线策略。