如果把时间拉回到半年前，我们在给 SaaS 产品接 AI 时，关注点非常单一：
选哪个模型。
Opus、GPT、Gemini 对比了一轮又一轮，
测效果、测准确率、测“看起来聪不聪明”。
当时的直觉很简单：
模型选对了，后面的事就会顺。
现在回头看，这个判断并不完全错，但非常不够用。
一、前 1 个月：选模型阶段，一切都很乐观
项目最初进展得很顺：
- 单一模型直连
- Prompt 调一调
- Demo 很快就跑起来了
当时我们选了一个整体表现比较稳定的模型作为主力，用在核心功能上。
效果不错，内部评审也顺利通过。
那时候，几乎没有人担心“稳定性”这种事——
毕竟请求量不大，模型也没出过什么明显问题。
二、第 2～3 个月：需求一多，模型开始不够用了
真正的变化，来自业务侧：
- 不同客户开始提不同需求
- 有的要长文本分析
- 有的要响应速度
- 有的对输出一致性要求极高
于是很自然地，我们开始引入第二、第三个模型：
- 核心流程继续用原模型
- 部分能力用 GPT
- 长文本或分析任务交给 Gemini
这时候，系统还能“勉强跑”。
但工程侧已经开始感到不对劲了。
三、第 4 个月：问题集中爆发，但不是模型能力问题
问题并不是“模型不好用”，而是：
- 三套 API
- 三种参数风格
- 三种错误码和限流策略
很快就出现了这些情况：
- 同一类请求，不同模型处理方式完全不同
- 模型一波动，业务逻辑跟着受影响
- 为了兜底，代码里开始出现大量 if / else
- 排查问题时，很难快速定位是模型问题，还是系统问题
最折磨人的一点是：
这些问题，在单模型阶段根本不存在。
这时我们第一次意识到：
现在拖慢进度的，已经不是“模型选得好不好”，
而是“模型是怎么被接进系统里的”。
四、第 5 个月：我们开始换一个问题问自己
这时团队里出现了一个关键转折问题：
业务系统，真的有必要直接面对这么多模型细节吗？
仔细想了一下，其实不合理：
- 业务只关心“我要一个结果”
- 并不关心这是 Opus 还是 GPT
- 更不关心哪个模型今天限流、哪个策略调整了
但我们的系统，被迫知道了所有这些细节。
这本质上是一个架构问题，而不是模型问题。
五、第 6 个月：引入统一接入层，变化开始显现
后来我们做了一个并不激进、但影响很大的调整：
不再让业务系统直连模型，而是统一通过一个接入层。
在这个阶段，我们开始使用类似 poloapi.cn 这样的聚合型 API 接入方式，核心目标只有一个：
把模型变化挡在业务系统外面。
调整之后，变化非常明显：
- 业务代码开始变“安静”
- 模型切换不再是高风险操作
- 兜底、重试、限流集中处理
- 出问题时，更容易定位问题边界
模型还是那些模型，
但系统的状态，已经完全不一样了。
六、半年后回头看：我们真正解决的不是“选型问题”
现在回头看这半年，会发现一个很清晰的事实：
- 模型能力，确实重要
- 但稳定交付，靠的不是模型能力本身
真正让系统跑得久、跑得稳的，是：
- 接受模型一定会波动
- 用结构去消化变化
- 不把复杂度扩散到业务层
POLOAPI 这样的聚合站，对我们来说，并不是“用了更强的模型”，
而是换了一种更可持续地使用模型的方式。
七、给同样在做 SaaS AI 的一点建议
如果你现在也在做 SaaS AI，我会给你三条非常朴素的建议：
- 不要过度纠结“选哪个模型”
很多问题，选型阶段根本暴露不出来。 - 多模型几乎是必然结局
与其等复杂度失控，不如提前想好怎么承载。 - 稳定交付是结构问题，不是参数问题
Prompt 再好，也挡不住架构层的问题。
总结
我们这半年，并不是换了一个“更厉害的模型”，
而是慢慢意识到：
SaaS AI 能不能走远，取决于你是否把“变化”留在了系统该承受的地方。
模型会变，需求会变，客户会变。
架构如果不变，系统才跑得下去。
如果你也正在经历类似阶段，
希望这次复盘，能帮你少走一点弯路。
