一份训练计划生成从45分钟压到40秒 - 我给健身应用接上AI后的账本
业务痛点：教练产能是天花板
我朋友做了一个小型健身应用，注册用户几千人，核心卖点是“定制训练计划”。但所谓定制，实际流程是这样的：
用户填问卷（目标、经验、伤病史、可用器械、每周可训练天数）→ 计划由后台的兼职教练手写 → 教练微信回传 → 客服录入系统 → 通知用户。
一个熟练教练写一份靠谱的入门计划平均需要 25–45分钟，加上沟通往返，用户从付费到拿到计划平均等 18小时。兼职教练按份计费，一份计划人力成本约 30元。旺季日订单80单时，光计划生成就烧掉 2400元/天，而且教练排不过来，用户流失率肉眼可见地上升——有近三成用户在等待期内申请退款。
这就是典型的“人力密集型个性化”：个性化本身是产品价值，但生成方式不可扩展。
方案选型：AI生成 + 人工抽检，而不是全自动
我们没敢做全自动。健身计划写错可能涉及安全问题（高血压用户安排大重量憋气动作），所以架构上定位为“AI初稿 + 规则校验 + 人工抽检”：
- AI负责结构化生成：把用户问卷转成计划草案
- 规则引擎负责硬约束：伤病史过滤动作库、训练频率与恢复日校验、强度递增幅度上限
- 人工抽检：前1000份全检，之后抽检5%，并保留用户一键“申请人工复核”入口
架构设计
用户问卷 → 计划生成服务
│
├─ 结构化Prompt模板（按目标类型分5套）
├─ 用户画像组装（目标/经验/伤病史/器械/时间）
│
▼
统一AI API网关（多模型路由）
│ ┌─ 简单计划 → 轻量模型（成本优先）
│ ├─ 有伤病史 → 旗舰模型（质量优先）
│ └─ 主模型限流/故障 → 自动降级备用模型
▼
输出解析（JSON Schema校验 + 重试）
│
▼
规则引擎（动作黑名单 / 恢复日 / 强度上限）
│
通过 → 落库 → 用户可见
失败 → 自动重写 or 转人工队列关键实现步骤
- 把计划定义成JSON Schema。动作名、组数、次数、休息时长、周安排，全部结构化。模型输出必须能通过schema校验，否则自动重试（最多3次）。这一步做了，后面所有校验、展示、修改都省事。
- 动作库白名单。模型只能从预置的300个动作中选，杜绝幻觉动作。每个动作带标签（关节负荷、禁忌症、器械需求），规则引擎据此过滤。
- Prompt模板按场景拆分：减脂/增肌/力量/康复/居家五套模板，而不是一个大prompt包打天下。拆分后单次输出token量降了约40%。
- 模型分层路由：约70%的简单需求（无伤病史、常规目标）走轻量模型，复杂case走旗舰模型。
- 灰度上线：前两周AI结果全走人工确认，教练改什么就记录什么，反哺prompt迭代。
核心生成代码（简化版）
async def generate_plan(user_profile: UserProfile) -> TrainingPlan:
# 1. 规则引擎先过滤动作池
pool = action_repo.filter(
exclude_injuries=user_profile.injuries,
equipment=user_profile.equipment,
level=user_profile.experience
)
# 2. 选择模型：有伤病史走旗舰模型
model = "premium-model" if user_profile.injuries else "lite-model"
# 3. 网关统一调用，自动处理限流与降级
resp = await ai_gateway.chat(
model=model,
messages=build_prompt(TEMPLATE[user_profile.goal], user_profile, pool),
response_format={"type": "json_object"}
)
plan = TrainingPlan.parse_raw(resp.content)
# 4. 硬校验：恢复日、周训练量、强度递增
violations = rules_engine.check(plan, user_profile)
if violations:
plan = await revise(plan, violations) # 带着违规项重写
return plan效率账本：前后对比
| 指标 | AI接入前 | AI接入后（稳定运行后） |
|---|---|---|
| 单份计划生成时间 | 25–45分钟（人工） | 35–60秒（含校验重试） |
| 用户等待时长 | 平均18小时 | 平均40秒，P95在3分钟内 |
| 单份人力成本 | 约30元 | 约0.4元token成本 + 抽检摊销约1.5元 |
| 日产能上限 | 受教练排班限制（约80份） | 无实质上限 |
| 退款率 | 接近30%（等待期流失） | 降到个位数 |
教练的角色从“写计划”变成“审核与处理复杂case”，两个人管住了全部日订单量，还顺带做起了付费的“教练深度定制”高价档——AI标准化处理长尾，人往高价值环节上移。
为什么必须用统一AI API网关
这个项目早期我们直连了某家模型SDK，一个月后就吃到了苦头：
第一，模型切换成本。健身计划这种文本任务对模型价格极其敏感。当模型A涨价、模型B出了更便宜的新版本，直连SDK意味着改代码、改鉴权、改错误处理、回归测试，一次切换至少两天。走统一网关后，切换只是改一个模型名参数，半小时上线——文章开头提到的账本里，token成本从预估每月4000多元压到1400元左右，靠的就是两次无痛的模型路由调整。
第二，密钥和计费只管一处。小团队最容易出的事故是密钥散落在多个服务里。网关模式下应用只持有一份网关密钥，上游几十个模型的key全在网关侧轮换管理，泄露面和审计成本都小得多。
第三，限流、降级、重试不用自己写。生成服务只关心prompt和schema，超时切换备用模型、429自动排队这些脏活在网关层解决。上线三个月，我们没写过一行模型供应商SDK的容错代码。
粗算下来，网关帮我们省掉的适配与维护工作量约 每周4–6小时，对两三个人的团队来说，这就是一个完整的人日。
结语
健身计划生成只是“结构化个性化内容”这个大类的冰山一角——膳食方案、学习路径、旅行行程，套路几乎一样：JSON Schema + 白名单 + 规则校验 + 分层路由。如果你也在做类似的产品，建议从统一AI API网关开始搭底座，别让模型选型和密钥管理在三个月后变成你的技术债。想动手的话，可以先到 https://api.thistoken.ai/register 注册一个账号，把网关密钥跑通，再回来对照本文的架构图搭第一版生成服务。
---
想直接跑通示例？访问 https://api.thistoken.ai/register 注册 ThisToken.AI，获取 API Key 后即可开始。