我做产品经理五年了，经手的需求少说上百个。但去年冬天那个"换个模型试试"的需求，差点把我整抑郁了。

事情要从十一月初说起。

业务方提了个需求：现有的文档摘要功能效果不够好，想换一个更强的模型试试。听起来很简单对吧？我在需求评审会上拍着胸脯说"两周搞定"。

然后就开始了长达十四天的噩梦。

第一天，研发说先评估几个候选模型。我拉了个对比表，列了四个选项：两个国产的，一个Claude，一个GPT-4。研发看完摇摇头，说每个模型的API格式都不一样，得分别写适配代码，光调研就要三四天。

第三天，研发跑来说第一个国产模型接上了，但摘要效果不理想，换第二个试试。我问要多久，他说得重新改接口调用代码，再跑一遍测试，大概两天。

第五天，第二个模型效果还行但偶尔抽风，业务方说想再试试Claude。研发的脸当时就绿了。Claude的API和前面两个完全不是一个路子，参数结构、返回格式、错误码全得重写。他跟我说"这等于推倒重来"。

第八天，业务方又改主意了，说Claude太贵，要不还是用国产的，但能不能两个混着用——简单的走便宜的，复杂的走贵的。

我当时差点从椅子上摔下来。

第十天，研发开始写"智能路由"逻辑。所谓智能路由，就是在业务代码里加一堆if-else：判断输入长度，判断问题类型，判断该调哪个模型。代码越改越乱，测试用例越写越多，bug越改越多。

第十二天，线上出了个事故。因为路由逻辑判断失误，一批本该走便宜模型的请求被发到了贵模型，当天Token费用直接翻倍。业务方跑来质问我"不是说换模型能省钱吗"。

第十四天，需求勉强上线。但研发私下跟我说，这个路由逻辑写得太脆弱，以后再加新模型还得改一遍，每次都是地狱。

需求上线那天晚上，我一个人在办公室坐着，盯着屏幕发了半天呆。

我在想一个问题：为什么"换个模型"这件事，会这么难？

后来我想通了。我们把模型选择这件事，硬塞进了业务代码里。模型和业务深度耦合，牵一发动全身。这就像装修房子的时候，把电线直接埋进了墙里，想换一根线得砸墙。

真正的问题不是哪个模型好用，而是我们缺少一个中间层——一个能把模型选择和业务逻辑分开的东西。

转机出现在今年三月。

公司技术架构师搞了个AI网关的方案，用的是魔芋的MAI Gateway。他跟我说"以后换模型不用改业务代码了"的时候，我是不信的。被折腾过的人都有这种本能的怀疑。

但他演示了一遍，我就服了。

他在网关后台改了一条路由规则，把摘要功能的模型从A换成了B。全程没动一行业务代码，业务方完全无感知。整个过程不到两分钟。

两分钟。我上次干这事花了十四天。

更让我惊讶的是，网关自带智能路由。以前我们研发吭哧吭哧写的那堆if-else判断，网关在后台配置一下就行。短输入走小模型，长输入走大模型，重复问题直接命中缓存返回。以前那套"地狱路由逻辑"，变成了几个下拉菜单的配置项。

上个月又来一个类似需求，业务方说想试试某新出的模型。我内心毫无波澜，在网关后台点了几下，切过去了。试了三天不满意，又切回来。全程研发没参与，业务代码没动一根毛。

这种"换模型像换壁纸一样简单"的感觉，真的会让人上瘾。

我后来反思过，为什么当初会那么痛苦。

根子上是因为我们没把"模型管理"当成一个独立的能力。我们默认模型是业务代码的一部分，每次调整都要从业务层改起。这种思路在小规模的时候能跑，一旦业务复杂起来，就会变成一团乱麻。

网关做的事情其实很朴素：在模型和业务之间加了一层抽象。但就是这一层抽象，把我从十四天的地狱里救了出来。

如果你也是做产品或者项目的人，下次提"换个模型试试"这种需求之前，先问问研发：咱们有没有网关？如果没有，做好心理准备，这可能不是一个两周的需求，而是一个两个月的坑。

魔芋AI大模型网关I全球大模型一站式调用及服务平台魔芋AI大模型聚合平台（大模型网关平台）专注于提供高效能、低成本的多品类 AI 模型服务，助力开发者和企业聚焦产品创新。https://www.moyu.info/register?aff=zFsq

我不想再经历一次那种十四天了。希望你也别踩。