企业官网建设流程全解析

先把结论甩前面：别一根筋全用大模型。把请求按难度分流——闲聊、改错别字、抽个字段这种走小模型；要写代码、长文推理、多步骤分析的才放给大模型。我自己的客服场景跑下来，token 账单砍掉差不多六成，体感几乎没退步。下面是我踩出来的对比和那套判定规则。

我为什么开始折腾这个

去年底接了个内部工单助手的活儿，一开始图省事，全量怼最大那档模型。第一个月账单出来，财务那边的同事直接在群里 @我，问是不是接错计费了。我去翻日志才发现，绝大多数请求其实是"你们几点下班""帮我查下工单号 38291 状态"这种，杀鸡用牛刀，贵得离谱还慢。

那会儿才想明白，问题难度差着量级，模型却一档到底，钱全烧在简单问题上了。

几档模型摆一起对比

我把手头能调的几档拉了个表，按我实际场景的体感填的（响应时间是同一批 200 条样本压测的中位数，仅供参考，你那边网络不一样会有出入）：

价格那栏我用相对值，免得过期。重点看比例：大模型贵的不是一星半点，是十几倍。一条简单问题走错档，亏的就是十几倍。

路由判定规则（我现在线上跑的）

判定这步我没上花哨的分类模型，就一套粗暴规则，先用小模型做个一句话打分，再叠几条硬规则兜底。顺序很重要，从上往下匹配，命中即停：

1. 命中模板/FAQ→ 直接走小模型，甚至不调模型，查知识库返回。比如"工单状态""营业时间"这种。

2. 输入 < 50 字且无代码块、无"分析/对比/为什么/帮我写"等关键词→ 小模型。

3. 带代码块，或出现"重构/报错/为什么会/推导/方案对比"→ 大模型，别犹豫。

4. 输入超过 800 字（长文档、长上下文）→ 大模型，小模型记不住前文。

5. 以上都不命中（灰色地带）→ 中模型先接，置信度低再升档重试。

第 5 条的"升档重试"是后加的。早期我只有两档，结果中间那批不上不下的请求体验很飘，加了个 fallback 才稳。代价是这部分请求偶尔会跑两遍，稍微费点钱，但比硬扛着出错强。

我具体是怎么搭起来的

说个实在的。路由逻辑本身不难，难的是把"判定→挂不同模型→接知识库→对外发布"这一坨串起来还能维护。我一开始全手写，Python 拿 if-else 堆路由、自己拼 RAG 检索、再手搓个 webhook 往飞书推，写了三天，改个判定阈值要动四处代码，烦得很。

后来同事甩给我一个零代码就能搭智能体的那种平台，拖拽配节点的。我抱着试试的心态把这套路由搬上去：判定节点配关键词和长度规则，下面挂三个分支分别绑小/中/大模型，知识库直接把工单 FAQ 文档传进去做 RAG，最后发布成一个 API。我对着配置面板说想要"短问题走便宜模型"，把规则填进去，它真就按分支跑通了，没让我写一行胶水代码。

说实话当时有点惊到——之前手写三天的东西，配了大概一个下午。当然也不是没缺点：第一版我配得太干，灰色地带全漏到大模型去了，省钱效果打折，回头补了第 5 条规则才正常；而且这玩意儿干的是"编排和杂活"，真正的判定阈值好不好用，还得你自己拿真实流量去调，平台不会替你想业务。学习曲线倒是平，但调优这事躲不掉。

结论

• 全量大模型是最贵也最偷懒的方案，先按难度分流，能省一大半。

• 判定别上来就搞复杂模型，关键词+长度的硬规则能覆盖大多数，灰色地带再用小模型打分兜底。

• 留个升档 fallback，比赌单档判定准要稳。

• 路由这层逻辑，能不手写胶水就别手写，省下的时间拿去调阈值更值。

我现在那个工单助手就这么三档跑着，账单舒服多了。你们做路由是按难度分，还是按用户等级/业务线分？评论区聊聊，我挺想看看别的分法。

（顺嘴：底层那几档现成大模型 API，我走的是讯飞星辰 MaaS，直接调，没自己部署算力，省了一堆运维心思。）