Jev 用例：System One 模型能做的 12 种判断

Jev 做的是那些可以事先列出所有可能答案的判断：工单归哪个团队、工具调用是否符合用户的要求、回答是否有检索内容支撑。 它从不写回复、摘要或理由。下面每个用例都是这样一个判断，写成一组类型化问题（Choice、Score、Noul），你可以在对应的工具页上用自己的文本直接运行。

这里的每个示例都只在一段简短的 state 上问两到四个问题，所以在 JevStation 上每次都是一次标准评估：只要 state 不超过 8,000 个字符、问题不超过五个，就是 1 点。所有问题针对同一个 state 并行作答，多问第三、第四个问题几乎不增加延迟。

先简单回顾三种问题形态，因为每个用例都由它们组成：

客服与运营

1. 客服工单分拣

一个 Choice 选出负责团队（billing、integrations、bug、account），一个五级 Score 给紧急程度打分，从"可以等"到"严重"，一个 Noul 给出客户即将流失的概率。最有用的输出往往是概率的分布：一张提到 Stripe、但实际是第三方服务连接问题的工单，会表现为两个团队分摊概率，而较低的置信度提醒你不要自动分派。LangChain 在介绍 Jev 的文章里点名的应用之一就是大规模邮件分流。客服工单分拣

2. 评价情感分析

一个 Choice 判断整体情感（正面、褒贬参半、负面），一个 Score 把评论映射到隐含的星级，一个 Noul 判断评论者是否要求退款。真正触发动作的通常是退款那个 Noul，另外两个用来喂数据看板。这里要谨慎：最接近的独立数据点是 jev-benchmarks 里的一个情绪分类数据集，而那正是 Jev 表现最差的地方（准确率 0.48，校准也差）。情感不等于情绪，但信任之前先测一测。评价情感分析

安全与审核

3. 内容审核

一个三选一的 Choice 决定允许、复审还是删除，每条规则（骚扰、引流到站外）各用一个 Noul，说明评论的问题出在哪。review 这个选项是有意设计的：它让不确定的中间地带有处可去，而不是被迫二选一，这部分正是要交给人工审核员的。"超过三个链接"这类计数规则留在代码里，因为 TypeSafe 的文档说明 Jev 计数并不可靠。内容审核

4. 提示词注入检测

两个 Noul 分开两种危害：试图覆盖或套取助手的指令，以及要求把数据发送到外部。一个 Choice 把两者合成放行、清理或拦截的决定，在输入到达你的 LLM 之前执行。Jev 没有可被劫持的指令通道，但 TypeSafe 自己的能力短板说明写明对抗性内容仍可能改变答案，所以把它当作其中一层防护，而不是安全边界。提示词注入检测

5. 工具调用守卫

state 里放用户的请求和智能体打算执行的工具调用。一个 Noul 判断这次调用是否符合用户的要求，一个 Score 给风险打分，从"无害"到"破坏性"，一个 Choice 决定执行、先确认还是拦截。示例里，智能体被要求清理 staging 的测试数据，却打算在 production 上执行 DELETE FROM orders;。LangChain 实验性的 AutoModeMiddleware 把同样的思路用在任意智能体上；一位 Vercel 工程师告诉 TechCrunch，公司把一个用来审查命令安全性的 LLM 分类器换成了 Jev，结果快了 5 到 18 倍。工具调用守卫

销售与招聘

6. 线索评估

一个 Score 评估线索与 B2B 产品的匹配程度，一个 Choice 判断所处的购买阶段（了解中、评估中、准备购买），一个 Noul 判断是否提到明确的时间表。这些足以决定谁该当天得到回复。关于商务邮件分类，唯一公开的实践者反馈来自 Bryo AI 的 CTO（经 TechCrunch 报道）：Gemini 略准一些，但贵 10 到 20 倍；这位 CTO 最看重的是 Jev 会返回真正的概率。线索评估

7. 简历筛选

一个 Score 评估候选人与岗位的匹配度，一个 Noul 判断是否达到资历要求，一个 Choice 建议拒绝、电话初筛还是直接进入技术面试。招聘就在 TypeSafe 自己的用例地图上。这也是缺少文字理由影响最大的用例：36Kr 的一篇分析认为，无法给出解释的决策在强监管领域常常会直接撞上合规墙。用它给人工排序队列，而不是让它独自拒绝候选人。简历筛选

智能体与 RAG

8. LLM 回答评判

一个 Noul 检查回答是否与参考事实一致，一个 Score 给整体质量打分，一个 Choice 决定发布、修改还是拒绝。这是独立证据最强的用例：在一项 AI 控制试验中，只用一个 Noul 就把含后门的代码排在正常代码之前，AUROC 为 0.976。同一项试验也发现了明确的失效方式，详见《用 Jev 当评判模型》。用 Jev 当评判模型

9. RAG 评估

两个 Noul 分别判断回答里的每个论断是否都有检索内容支撑，以及检索内容是否包含回答问题所需的信息。一个 Score 给回答打分，一个 Choice 指出错误回答坏在哪一环：retrieval（上下文里没有）还是 generation（上下文里有，但回答说错了）。最后这个问题把评估变成了修复方向，因为这两种失败归不同的人负责。RAG 评估

10. 引用核查

state 里放一段来源原文和一条论断。一个 Choice 判断完全支持、部分支持还是不支持，一个 Noul 判断论断是否夸大了原文。示例里，调查说的是 38%，论断却说"大多数" IT 负责人计划增加投入，这正是值得抓住的那种悄悄夸大。按 beam.ai 的建议，这个模式很适合与 LLM 搭配：让 LLM 抽取，再把抽取出的值和它的来源交给 Jev 核验。判断 38% 算不算"大多数"需要依赖数字，而数字是 TypeSafe 列出的短板之一，所以要专门测试这类例子。引用核查

11. LLM 路由器

一个 Score 评估提示词有多难，一个 Choice 选小、中或前沿模型档位，一个 Noul 判断回答是否需要写代码。一项独立的 Classmethod 测试在 40 次调用中全部得到了预期档位，但每个档位只用了一条提示词，作者也直说这不是准确率基准。Jev 只负责选档位，请求由你的代码发出。LLM 路由器

12. 上下文压缩

一个 Noul 判断一段对话记录里是否有智能体必须记住的决定或约束，一个 Score 评估它有多重要、该不该保留。压缩不再是写摘要，而是删掉得分低的部分，其余逐字保留。fast-jev-compaction 是一个完整的实例：一个 Claude Code 插件，对每次工具调用问两个是/否问题，节省不多时退回到内置的摘要。上下文压缩

什么时候 Jev 不是合适的工具

上面 12 种判断有一个共同形态。你的问题不符合这个形态时，换一个工具更好：

• 你需要文字。 回复、摘要、评语和文字理由都需要生成式模型。TypeSafe 的说明写得很直白：强迫 Jev 生成文本"效果不会好"。
• 你列不出答案。 开放式问题没有 Choice 可问。
• 判断的是计数、算术或日期。 "本周三张工单"、"已过续约日期"应该放在代码里算，再把结果放进 state。
• 规则是精确的。 屏蔽域名、关键词列表、长度限制都是代码的事，不是分类。
• 你的输入大多不是英文。 TypeSafe 说其他语言（包括中日韩文字）能处理，但效果不如英文。
• 被评判的一方能探测分数。 在那项 AI 控制试验中，能在提交前查看分数的攻击者让约三分之一的后门漏过，而不是十分之一。
• 标签集稳定，而且你有大量标注数据。 在调用量很大时，自己训练的分类器可能更简单、更便宜。《Jev 的替代方案》详细讲了这个取舍。

怎么选第一个用例

从三件事已经成立的地方开始，beam.ai 的说法很到位：你知道可能答案的集合，同一个判断要做很多次，你能根据置信度行动。落到实际，就是指向一个已经有人在手工分拣的队列，比如工单、评论或销售线索，因为过去的决定就是你的标注数据。

1. 打开与你的队列最接近的工具页，运行示例。
2. 在试验台里换成二十条你知道正确答案的真实输入。数据更多时，批量页可以用同一组问题跑完 CSV 的每一行。
3. 用你自己的话重写选项，每个选项配一行描述。
4. 看置信度在哪里把对的答案和错的答案分开，然后设三个区间：自动处理、人工复核、拒绝。

前 200 次评估免费，足够把这个测试做好几遍。为什么这三个条件很关键，见《System One 模型是什么，不是什么》；问题怎么措辞，见《设计 Jev 能回答的问题》。想一次浏览全部 12 个工具页，从工具开始。

来源

• 问题集和示例 state。上文链接的 12 个 JevStation 工具页 （我们的配置）
• 点数档位和免费额度。价格 （JevStation）
• 大规模邮件分流；AutoModeMiddleware。LangChain （第三方）
• Vercel 的命令安全审查；Bryo AI 的邮件分类。TechCrunch（经 Yahoo 转载） （第三方，实践者反馈，未公开数据）
• 招聘和模型路由作为用例。TypeSafe 用例地图 （厂商）
• 计数、日期、对抗性内容、文本生成。Jev 1.13 能力短板说明 （厂商）
• 语言支持。TypeSafe 模型文档 （厂商）
• 三个条件的经验法则；先抽取再核验的模式。beam.ai （第三方）
• 情绪分类结果。jev-benchmarks （独立）
• 后门监控试验、探测型攻击者。LessWrong （独立）
• 路由测试。DevelopersIO（Classmethod） （独立）
• 合规方面的担忧。36Kr （第三方）