用 Jev 把提示词路由到合适的模型

Jev 能决定由哪个模型处理一条提示词吗？

可以。TypeSafe 在使用场景示例中列出了模型路由：一个自定义路由器，决定每条提示词交给哪个语言模型。它的意图路由模式展示了基本结构：用一个 Choice 问题给收到的请求分类，再由普通代码把每一类交给相应的处理方，可能是一次数据库查询、一个专用模型，也可能是人工客服。

Jev 不负责撰写回复。它只在昂贵的决定之前先做一个小决定：让常规的提示词不必占用推理模型，也让困难的提示词不至于落到解决不了它的模型手里。

打开可编辑的路由模板。其中有一条虚构的工程类提示词和 4 个处理方。载入只会建立草稿，主动点击检查才运行。

按用途来描述处理方

模型的名字会变，职责却稳定得多。模板按各个去向适合承担的工作来描述它们，再由你的代码把标签映射到当前承担这一角色的具体模型。

每次只改一项，再比较结果

1. 运行模板，记录选中的处理方及其他选项的概率。
2. 把提示词换成“你们的客服时间是几点到几点？”，再运行一次。
3. 试试“取消我的合同，并退还今年的费用。”运行前先想好：你的政策是否允许软件直接处理这类请求。

模板没有预填正确答案，运行几次也无法衡量路由质量。要评估一个路由器，请给几百条真实提示词标注你本来会选择的处理方，再作比较，并把每种错误的代价一并计入。

用置信度兜底

在 TypeSafe 的意图路由示例中，代码先检查置信度，再看标签：只要低于下限，无论选中的是哪一类，请求都转给人工。置信度门控路由模式进一步指出，这个下限应当随风险高低而定：无害的操作可以低一些，涉及资金变动的操作则要高得多。具体数值请根据自己标注过的提示词来定；文档中的数值只是为了说明这一模式，并非推荐值。概率与置信度的区别解释了这两种信号。

那么裁剪上下文呢？

有一个相关的思路：对之前的每条消息各问一个是非问题，例如“这条消息现在还需要吗？”，然后丢掉其余的。对此要谨慎。一位社区作者在 2026 年 9 月 18 日报告说，在一项长期记忆基准测试上，一个简单的相关性过滤器最好的情况是毫无增益，最差的情况则是成绩大幅下滑。这只是单个作者自行报告的一次实验，只用了一种过滤方法，但它仍是一个有用的提醒：消息一旦丢弃，下游就无法找回。在依赖这种过滤之前，请分别测量启用和不启用过滤器时的回答质量。

路由出错往往悄无声息，因为较弱的模型照样能写出流畅的文字。请记录每一次决定，抽样复查，并了解 Jev 的能力与限制。