JEV 模式

所有 JEV 模式共享的骨架

TypeSafe 自己的文档把这个架构画成一根竖线：非结构化状态流进类型化提问，类型化提问流进 Jev，Jev 返回带分布的 choice、score 和 noul，然后代码里的确定性组合把结果分成两路——一边是可逆的动作，一边是复核或兜底。

这张图里最要紧的词是「可逆」。下面每个 Jev 模式都假定：Jev 的答案所触发的事情是可以撤销、重试或升级的。Jev 是一个快、便宜、校准良好的猜测器，而把一个快而便宜的猜测器放在什么位置才对？放在一个偶尔出错也能承受的判断前面，绝不放在承受不了的那种后面。

TypeSafe 把边界说得很直白：Jev 该回答的是「这个请求属于哪条已知路由」「这个问题按这份细则有多严重」「这条消息是不是在要求退款」「这段引文能不能支撑这个论断」。Jev 不该成为「要不要删掉这个账号」「要不要打出这笔钱」这类高影响决定的唯一决策者。

为什么需要 JEV 模式

一个只有三种提问类型、还不输出文本的模型，听起来应该不需要什么文档。实际恰恰相反，因为这个限制把所有设计工作都挤到了一个大多数人不习惯思考的地方：提问本身的形状。

用聊天模型你可以含糊，让模型自己捋。用 Jev 不行。每个选项都要命名，每个档位都要描述，每个阈值都得你自己定，而不是靠 prompt 暗示。把这件事做对是门手艺，而这些 Jev 模式，就是第一周里大家反复做错的那些问题的沉淀答案。

第二个原因是组合。单个 Jev 提问本身很少有意思。让 Jev 值得引入的，是对同一份状态在一次并行请求里问六个问题，然后写那二十行把六个概率变成一个动作的路由逻辑。一个 Jev 模式，主要讲的就是后半部分——Jev 不替你做的那部分。

怎么挑对 JEV 模式

从你的程序已经知道的东西出发。如果它有一组固定的去向、需要挑一个，那你要的是路由型 Jev 模式，真正的设计工作只是把这些去向命名得足够精确、彼此不重叠。如果它有一个东西、需要知道它有多糟，那你要的是带描述细则的打分型 Jev 模式。如果它有一个待执行的动作、需要放行许可，那你要的是用 Noul 搭的防护栏型 Jev 模式。

如果你分不清自己属于哪一种，通常说明这个判断还没有清晰到可以交给 Jev。把你能接受的答案全部写下来：如果这个列表是开放式的，Jev 就是错的工具，文本模型才是对的；如果列表是封闭的，那你刚刚已经把 Jev 提问设计出来了。

第二个有用的筛子是量。这里的每个 Jev 模式，都只在判断跑得足够频繁时才值得那份工程投入。一个系统一天只做两次的判断，留在你已经在付费的模型上就行；Jev 的理由建立在第一千次调用上，不是第一次。

JEV 模式里的提问怎么设计

杠杆最大的习惯是：描述选项，而不是给选项贴标签。一个选项是「bug、账单、其他」的 Jev Choice，明显不如每个选项都配一句话的那个——「产品缺陷、服务中断或集成失败」「一笔扣款、退款、发票或订阅问题」「以上都不明确符合」。模型读的就是你的描述，描述含糊，判断就含糊。

第二个习惯是给 Jev 留一个出口。几乎每个 Choice 都该带一个明确的「都不是」选项，因为逼一个模型从一个不含正确答案的列表里挑，必然得到一个自信的错答案。再配上代码里的置信度下限，含糊的那些就会自己转去复核，而不是硬猜。

第三个是让每个 Jev 提问只问一件事。如果你发现自己写的选项集里，有两个选项是沿着两个互不相关的维度分开的，那你有两个问题，拆开。因为 Jev 是并行求值的，拆开几乎不花钱，而且通常两边的答案都会变好。

最后，把 Jev 指向状态里真正相关的那部分。playbook 自己的例子里都是显式引用字段的——写 ticket.messages[0].text 而不是整个对象——当状态很大时，这份精确会明显收紧答案。

JEV 模式的阈值放哪

放代码里，永远放代码里，而且写成你找得到、改得动的常量。人很容易把置信度阈值埋进某个辅助函数，或者更糟——试图把它写进给 Jev 的 instructions 里。这两种做法都撑不过线上，因为你真正想要的那个数字是盯着真实流量发现的，不是事先推理出来的。

有效的做法是一道小而显式的阶梯：高于高阈值，自动执行；两个阈值之间，执行但打标抽检；低于低阈值，不执行——转人工，或者回落到你本来想绕开的那个贵模型。

因为 Jev 是为校准训练的，这些数字是有意义的。Jev 给 0.9 时应该大约十次对九次，这让你可以对那剩下的一成做成本估算，而不是瞎猜。这个特性才是真正的产品，比速度和价格都重要。

有一句提醒值得反复说：校准是关于大量调用的统计承诺，不是对任何一次调用的保证。Jev 完全可能在某个具体用例上自信地答错，而且不会给你解释。抽检从第一天就要接上。

先从哪个 JEV 模式开始

如果你只打算先实现一个 Jev 模式，挑防护栏那个。它最小，就一个 Noul，它自己不拦截任何东西，而且能在你把 Jev 交给任何要紧的事之前，给你真实流量去校准一个阈值。

从那里自然的下一步是路由，因为钱在那儿：一次 Jev 调用挡在贵模型前面，决定每个请求真正配得上多少贵模型。这里省下的不是换个便宜供应商的那两成，而是干脆不调用那次的九成。

本页的每个 Jev 模式都改编自社区 playbook，每一个都有自己的页面，把完整的 state、类型化提问和路由策略写出来了。它们是用来读和抄的，不是用来欣赏的。