
从模板驱动到数据驱动的实时生成。将用户运动数据、玩法规则与视觉风格转化为生成变量,构建可接入主链路的 AI 图像服务——让每一次完练分享都按当次状态产出差异化内容。




INPUT



3.1
分享率提升(pp)
16+
上线玩法数量
92.4%
图像生成成功率
01 / 项目背景
完练分享是用户完成运动后的核心表达与传播场景。项目的核心目标并不是引入 AI ,而是重新设计分享内容的供给方式:
将用户运动数据、玩法规则和视觉风格转化为 AI 可消费的结构化输入,构建一套可接入业务链路的图像生成服务,使分享内容从
01
画面差异主要来自数据字段变化,而非表达方式变化;连续使用后新鲜感与分享欲下降
业务后果
分享动机衰减,增长入口失效。
02
分享模板让用户最直观感受的就是一张图。运营有图文呈现策略想上,固定模板承载不了。
业务后果
运营节奏受限,运营策略无法落地。
03
新增节日 / 运营主题需重做模板;数量上升后设计、适配、维护、版本管理成本同步上升
业务后果
内容供给呈线性成本,无法规模化扩展
02 / 核心难点
难点不在于调用模型生成图片,而在于图像能力进入真实业务后,能否层层递进地跑通链路、覆盖长尾品类、保证首张可用,并最终产生分享价值——前三层决定「能不能落地」,第四层决定「有没有价值」。
能不能跑起来
公司首次将生成式图像能力接入 To-C 主链路,无成熟范式可循;
需从零构建输入、转译、生成、回传的端到端链路,并保证任一节点异常下服务不中断。
能否稳定进入业务主链路
跑起来准不准
70+个运动品类在姿态、器械与场景语义上高度分化;
通用模型仅覆盖头部品类,长尾准确率明显下降,需以模型能力边界为约束设计品类映射与生成策略。
能否覆盖完整业务场景
准了用户愿不愿意等
单次生成耗时约 30 秒,试错成本高,且 To-C 场景首张即定去留;
需以规则约束与质量下限守住首张的语义准确性,并压制明显 Badcase。
用户会不会有第二次
用了有没有业务价值
技术达标只解决「可用」,内容能否被分享取决于情境、风格与数据表达;
需将用户运动状态与玩法策略转译为具备传播价值的视觉表达。
能否产生分享增长价值
03 / 解法判断
在模型能力尚不成熟、To-C 容错低、公司首次落地的约束下,如何判断、取舍并把不可控的风险拆成可验证的命题,决定了项目能否稳定推进。
固定模板只能替换数据,无法按用户状态与玩法生成差异化内容;
AI 能把用户数据变成视觉变量、玩法变成规则配置、生图变成服务化链路。
人工模板→数据驱动生成
继续堆模板安全但解决不了核心问题。
直接上实时会让长尾泛化、To-C 容错、链路从零建等难点同时暴露、风险不可控;选择分阶段服务化、每步只验证一个命题。
不可控风险→可控步骤
实时性是可后置的工程问题,「AI 生产内容能否带来业务价值」才是范式成立的前提;
先用离线资产以最小改造验证价值,再投入实时工程。
最小代价→最关键的确定性
阶段一离线图库验证「数据驱动生成」范式
阶段二实时生成验证首张可用
阶段三数据驱动运营验证如何持续
能否产生分享增长价值
04 / 方案设计
整套方案由一条端到端链路和一套工程保障构成,核心机制是把业务与用户数据转译为图像生成变量,分阶段的落。

接入运动记录、地图轨迹、环境信息等数据,为生成内容提供场生成原始语料

用户实时上传的个人图像,使画面结果能够响应真实用户状态。
将业务目标与用户数据转化为 Dify Workflow 中的系统提示词、参数约束、素材标签和检索规则,连接产品逻辑与生成模型能力。
依据提示词与配置产出画面,产出可用图像素材。

将用户数据、业务模板和图像素材组合成最终可分享的完练视觉结果。
项目早期面临的核心约束是:实时生成耗时过长,模型稳定性和链路响应速度无法直接满足线上体验要求。因此,项目没有一开始就强行追求实时生成,而是采用更稳妥的分阶段策略:通过“图库预生成 + 动态检索”先验证业务价值。
运动数据非视觉语言,待建立
图像模型生成稳定性、泛化性不足
内容生成耗时过长、业务功能改造难度大
0-1探索,SOP重塑需要验证、灵活迭代
扩展用户数据、环境数据、业务数据范围,系统验证图像质量、泛化、时效。
逐步跑通完整链路:用户运动数据 → 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.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乒乓球
玩法架构设计 → 时间路由生成 → 多专家协作撰写 → 技术选型 → 质量自检 → 存档。
已有玩法增加节日 / 季节档:复用约 90% 骨架,仅修改差异视觉元素,并同步更新时间路由表,不重写整条链路。
提升已有提示词效果:质疑者先诊断问题类型,再按结构 / 视觉 / 映射 / 冗余分配主导专家修改,最后终审。
06 / 工程化保障
这套上线控制系统的核心价值,是把 AI 从不确定的生成能力,转化为可控、可验收、可监控、可持续迭代的业务能力。
重点是基于玩法复杂度、模型能力边界、耗时成本和线上稳定性,选择最合适的生成路径,并建立一套能够支撑真实业务运行的 AI 图像生成机制。
先确定模型、路径与提示词规则,降低后续生成链路的不确定性。
Decision Layer
以规则转译准确率、结构化输出稳定性、复杂分支处理能力和成本为基准横向评估候选模型。
“API 优先、ComfyUI Workflow 兜底复杂控制”的路径判断规则,统一质量、耗时与成本口径。
玩法规则、字段优先级、视觉风格、构图边界和禁止项模块化,提升Image Prompt输出稳定性。
把已验证规则拆进工作流、测试集和监控口径,支撑真实业务持续运行。
Operation Layer
按玩法独立编排 Dify 工作流,将规则转译、提示词生成和输出标准化拆成可插拔模块。
统一记录输入字段、Prompt、模型配置与生成结果,正常、边界和历史 Badcase 建立准出标准。
监控成功率、失败原因、环节耗时和行为反馈,反向调整规则、模型路径、版本上下线策略。