情感陪伴应用上线三个月就换了一次模型——先说说我们错在哪

做情感陪伴类产品的独立开发者，最容易犯的错不是“选错模型”，而是“用选型一次性定终身”。我先把我们踩过的三个坑摆出来，再讲后来怎么改的。

三个常见的失败做法

失败一：拿通用对话模型的直觉去套陪伴场景。 我们最初按“哪个模型综合能力最强”来选，接入后用户留存不错，但成本是同类产品的两倍多。情感陪伴的对话有个特点：绝大部分轮次是日常闲聊、情绪抚慰、记忆回溯，这类内容对推理深度的要求很低，但对语气一致性、人格稳定性的要求极高。用旗舰模型跑全部轮次，等于用跑车送外卖——用户体验没有可感知的提升，账单先爆了。

失败二：反过来，全程用最便宜的模型。 有朋友为了省成本全程上了轻量模型，结果遇到两个问题：一是用户情绪激烈波动或表达复杂处境时（比如深夜倾诉、危机话题），模型回应变得模板化，用户立刻察觉“它不懂我”，流失集中出现在这类关键时刻；二是长对话记忆的摘要质量下降，人格逐渐“漂移”。情感产品的体验是靠低谷时刻建立的，在最需要模型的环节用最弱的模型，是本末倒置。

失败三：模型选型当成一次性的技术决策。 定了一个模型、写死了调用逻辑，三个月后供应商调整策略、或者出现了更合适的候选，切换成本高到没人愿意动。更麻烦的是，我们根本说不清“现在的模型到底贵在哪、该在哪个环节换”——因为所有轮次都混在同一条调用路径里，没有分层数据。

正确路径：按场景分档，而不是按模型分档

反思之后我们换了个思路：不再问“选哪个模型”，而是问“哪类轮次需要什么档位的模型”。先把对话拆成场景，再给场景配档位。

关键洞察是：在情感陪伴场景里，真正需要旗舰级模型的轮次往往不到总量的一成，但这一成决定了用户会不会留下来。分档之后，我们的单位成本降了约六成，而用户满意度相关的投诉没有上升——因为我们只降了不需要强模型的环节。

需要提醒的一点：危机话题的识别和兜底（自伤倾向、极端情绪）不要参与降档。这条链路宁可保守，检测到后可以无缝升到最高档位模型处理，同时在产品层准备人工介入入口。

为什么需要统一网关，而不是直接调各家 API

分档方案落地时立刻遇到工程问题：不同档位可能来自不同供应商，直接对接意味着维护多套 SDK、多套鉴权、多套错误处理。这就是统一网关的价值所在，具体到陪伴类应用有三点：

第一，模型切换变成配置变更，不是代码重构。 陪伴场景的人格设定写在 system prompt 里，只要网关层保证接口一致，把某个场景的档位从 A 模型换成 B 模型，就是改一行路由配置。这意味着你可以在供应商波动、价格变化或出现新模型时快速响应，选型从“终身决策”变成“可持续调优”。

第二，灰度和回滚有了抓手。 我们上线新模型时会先让 5% 的对话走新档位，在网关层对比错误率、响应延迟和平均 token 消耗，异常就一键切回。没有网关，这套流程基本做不了。

第三，成本归因终于清晰了。 之前说不清“钱花在哪”，是因为所有轮次混在一起。通过网关按场景打标签后，每类场景的调用量、token 消耗、单价一目了然，月底复盘时能直接看出哪一档占比异常，而不是对着一张总额账单猜。

几条落地建议

1. 先加观测，再谈优化。 上线第一周别急着分档，先把轮次分类的埋点和网关日志跑起来，用真实数据决定分界线。
2. 人格设定独立于模型维护。 提示词模板做版本管理，换模型时回归测试的重点是“它还是不是它”。
3. 保留一路始终在线的强模型。 给复杂情绪轮次一个不降档的通道，这是产品的底线体验。
4. 把审核链路单独预算。 陪伴类应用的内容风险高于一般对话，这条成本不要省。

回过头看，情感陪伴应用的模型选型不是一次考试，而是一个持续运营的过程。场景会变、模型会变、价格会变，你需要的是一套让“变”变得便宜的架构——统一网关加上按场景分档的路由策略，就是这套架构的核心。

如果你正在搭建这套体系，可以试试通过 https://api.thistoken.ai/register 接入统一网关，把分档路由和成本观测从第一天就做对。

---

不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。