三个月重写两次训练计划引擎后，我明白了健身应用接AI的正确顺序
一、先说失败的那一版
去年我和两个朋友做一款健身App，核心卖点很明确：用户填完身高体重、训练经验、可用器械和目标，系统几分钟内吐出一份四周训练计划。听起来简单，我们第一版也是这么想的——直接把提示词塞进模型调用，两周就“上线”了。
结果第一周就翻车了。
失败点一：提示词里堆需求，输出格式全靠祈祷。 我们把用户画像、训练目标、动作库说明全塞进一个巨型Prompt，让模型直接输出完整计划。用户一多，问题就来了：有的输出是Markdown表格，有的是纯文本，有的是JSON但缺字段。解析层写了三百多行容错代码，比生成逻辑本身还长。
失败点二：让模型编动作。 模型偶尔会推荐不存在的动作名，或者给腰椎间盘突出的用户安排大重量硬拉。这不是格式问题，是安全问题——健身领域出一次错误建议，用户受伤，应用就完了。
失败点三：单模型硬扛。 我们只用一个模型，高峰期限流，用户等40秒拿到一份残缺计划，评分直接跌穿地板。想换模型备用，发现SDK、参数、计费逻辑全都耦合在业务代码里，换一次牵动半个代码库。
失败点四：没有反馈闭环。 计划生成完就完事，用户第二周有没有练、练完什么感受，全都不知道。所谓“个性化”，其实只是第一次问卷的个性化。
三个月后我们推倒重来。这一版思路完全不同，下面是正确的路径。
二、正确架构：生成是最后一步，不是第一步
核心转变：AI不负责“编”计划，只负责“编排”计划。
用户问卷 → 结构化画像 → 规则引擎筛选动作池
→ RAG检索相似训练模板 → LLM编排与个性化解释
→ Schema校验 → 安全规则二次过滤 → 输出计划
→ 用户反馈回流 → 画像持续更新关键设计决策：
- 动作库完全自建。约600个动作，每个带标签（部位、难度、器械需求、禁忌症）。模型只能从这个池子里选，从根上消灭“编造动作”。
- 规则先行，AI殿后。硬性约束用代码写：膝盖不适的用户，代码层直接过滤高冲击动作，不依赖模型“自觉”。LLM只做它擅长的：排布训练日结构、控制容量递进、生成给用户看的解释文案。
- 输出强制JSON Schema。用结构化输出约束，字段缺失直接打回重试，解析层从三百行容错降到零。
- 分层模型策略。问卷理解和最终编排用能力强的模型，解释文案、反馈分类这类轻任务用便宜的小模型。
三、关键实现步骤
- 建动作数据库（标签体系是重点，花了一周打磨）
- 写规则过滤引擎，纯代码，可单测
- 用向量检索匹配历史成功模板，作为LLM的参考上下文
- 设计PlanSchema（训练日→动作→组数/次数/负重建议/RPE）
- 编排Prompt：输入画像+候选动作+参考模板，输出严格Schema
- 安全审计层：校验禁忌、总量合理性、递进幅度
- 反馈闭环：用户标记“太难/太简单/动作不喜欢”，回流更新画像
核心调用伪代码：
async def generate_plan(profile: UserProfile) -> TrainingPlan:
# 1. 硬规则过滤，代码说了算
pool = exercise_db.filter(
equipment=profile.equipment,
level=profile.level,
exclude_conditions=profile.injuries
)
# 2. 检索相似成功模板作为few-shot
refs = template_store.search(profile.embedding, top_k=3)
# 3. LLM只做编排
raw = await llm.chat(
model=route_by_task("plan_compose"), # 网关智能路由
messages=build_prompt(profile, pool, refs),
response_format=PlanSchema # 强制结构化输出
)
# 4. 安全二次校验
return safety.audit(raw, profile)四、为什么统一AI网关救了我们的维护成本
重构期间最值钱的决定，是所有模型调用都走统一网关，而不是在代码里直接挂各家SDK。原因很具体：
- 换模型不改代码。网关兼容OpenAI协议，上层只写一套调用逻辑。我们后来把反馈分类从大模型换到小模型，改的是一个路由配置，代码零改动，单次调用成本降了约七成。
- 限流降级有兜底。高峰期主模型限流时，网关自动切到备用模型，用户端几乎无感。第一版那种“40秒等一份残缺计划”的场景再没出现。
- 密钥与计费集中管理。三个模型、两套环境，密钥只在网关配置，不进代码仓库，账单也合并可查，我们这种小团队没有精力管五个平台的控制台。
- 日志统一。所有调用的延迟、token消耗、失败原因在一个地方看，排查“为什么这条计划生成失败”从翻三个平台的后台变成查一条日志。
对小团队来说，这等于把“多模型运维”这件事外包了出去，两个人也能撑起看起来像是有专职AI基础设施团队的架构。
五、结果与几点建议
重写后的版本：计划生成平均耗时降到6秒内，格式错误率基本归零，用户第二周留存明显改善（具体数据就不展开了，各家的用户结构差异很大）。回头看，最大的教训是：AI应用里最不该交给AI的，恰恰是那些可以用规则和Schema钉死的部分。
给准备做类似功能的独立开发者三句话：先建数据，再接模型；硬约束写代码，软决策交LLM；第一天就走统一网关，别等换第二个模型时才后悔。
如果你也在规划AI应用的模型接入，可以从一个统一的API网关开始，注册入口在这里：https://api.thistoken.ai/register
---
不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。