我在做一个内部小工具，用大语言模型给支持工单分类。最初对着 DeepSeek 的接口写，功能本身——分类逻辑、提示词、输出解析——大概二十分钟就完成了。后来论坛上有人说另一个模型在短文本分类上表现略好，我就想换上去对比一下输出。

那个“快速测试”最后花了接近两个小时，而且没有一分钟是用在评估模型上的。时间全花在改写跟我要验证的事情毫无关系的代码上。

打开网易新闻 查看精彩图片

原来的代码长什么样

最初的实现很直接：用 OpenAI 客户端指向 DeepSeek 的接口，传入系统提示和工单文本，温度设为零，返回分类结果。分类只有三类：账单、技术、通用。代码简单，跑起来也没问题。

问题出在我想把它指向另一家服务商的时候。认证方式不一样，消息参数的处理略有差异，还有一个我之前没考虑到的限流错误。单独看每个问题都不难，但它们都不是我真正想测试的东西。

后来才用的模式

修复本身不复杂，只是我之前觉得这是个一次性副项目，没费心去做。我把同一个请求改走 RouteAI，一个兼容 OpenAI 接口的网关，它前面接了好几家服务商。只改了两处：基础地址和模型名。

函数签名里加了一个模型参数，默认还是 deepseek-chat。要对比不同模型时，调用就变成传入不同的模型名。准备三条工单示例，再列三个模型名，循环打印每个模型对每条工单的分类结果。

这就是完整的对比过程。没有新的认证配置，没有重写错误处理，也没有为每家服务商单独写限流逻辑。同一个函数，换个参数而已。

实际发现了什么

针对这个具体分类任务——短文本、三个固定类别——不同模型给出的结果差异并不大。真正花掉两小时的，是服务商之间的接入差异，而不是模型本身的优劣。网关把这件事抹平之后，换模型才真正变成改一个参数的动作。