Jev 术语表：System One、判断模型与 API 术语

Jev 核心术语的通俗解释：System One、判断模型、判断题/选择题/打分题、置信度、依据、兜底、渠道、类型化输出、示例数据。

TL;DR： 读懂本站其余内容所需的 11 个术语：System One 是什么、Jev 的三种题型、类型化输出的四个字段，以及指南和案例反复用到的工程词汇——兜底、渠道、示例数据（example fixture）。

System One

“System One”（系统一）指快速、自动化的思维模式——你还没来得及推理，就已经认出一张脸、判断”这句话不礼貌”。TypeSafe AI 从心理学的双过程理论借来这个词命名自己的模型家族：做任务中”快速识别”那一层的模型，而不是负责写长文的模型。Jev 就是 TypeSafe AI 的 System One 判断模型，2026 年 9 月发布。落到实用层面，“System One”对你要调用的工具意味着三件事：它不聊天、它输出的是决策、决策以类型化 JSON（answer、confidence、rationale）返回，而不是一段需要你去揣摩的散文。本站指南说”这一步用 System One 模型”时，意思是：这一步是决策环节——路由、标记、打分——聊天模型在这里形状就不对。参见什么是 Jev AI。

Judgment model（判断模型）

判断模型产出的是决策，不是对话。聊天模型续写文本，判断模型回答结构化的问题——这条评论是不是垃圾？这封邮件归哪个团队？这个答案 1 到 10 分能打几分？——并返回带置信度的类型化结果。Jev 正是在这个意义上是判断模型：输入是一道题加上被判断的材料，输出是代码可以直接分支的 JSON。工程上的直接推论是架构层面的：判断模型以门禁或路由器的身份嵌入流水线，位于数据源和动作之间，不需要靠一轮提示词工程才能从一大段话里抠出可用答案。它同时也意味着你不该让它起草邮件、写摘要——那是两步之后聊天模型的活。和下面三种题型对照着看，那就是它全部的输入面。

Judgment question（判断题）

Jev 三种题型里的第一种。判断题的答案空间是封闭的：yes、no、unclear，没有别的。凡是能用一句话问出来的二元政策都适合它：这条评论是不是垃圾？这张工单要不要加急？这张发票符合自动批准的条件吗？unclear 选项是功能，不是敷衍：它给了模型一个体面的方式说”这个处在灰色地带”，而成熟的流水线会把 unclear 当成独立路由路径（通常是转人工），而不是把它并进 no。本站示例数据中，一次判断调用返回 {"answer": "yes", "confidence": 0.97, "rationale": "..."}——字段名请与官方文档核对。生产形态见工单分诊案例和发票审批门禁案例。

Choice question（选择题）

第二种题型：从你给出的列表里恰好选一个。选项列表由你定义——billing / technical-support / sales，spam / abuse / policy-violation——这让选择题天然适合路由和分类。两条规则保它不出事。第一，选项列表必须与你的代码能处理的落地端完全一致；多出一个路由器没有对应队列的选项，就是埋了一颗雷。第二，答案带置信度返回，低置信度的选择应该兜底转人工，而不是硬塞给某个团队。本站示例数据中，一次选择调用返回 {"answer": "billing", "confidence": 0.94, "rationale": "..."}——这是示例数据（example fixture），不是线上抓包。带兜底的完整模式见邮件路由三团队案例。

Scoring question（打分题）

第三种题型：在声明的量程上（通常是 1-10）返回一个数字。当二元答案颗粒度太粗时用打分题——简历匹配度、RAG 片段相关性、问答答案质量——你仍然要的是一个能排序的数值，而不是一段文字。示例数据结构是 {"answer": 8, "scale": [1, 10], "confidence": 0.86, "rationale": "..."}：分数、所用的量程、模型有多确定、一行理由。scale 字段兼任哨兵——它回显你声明的量程，一旦对不上就说明这次调用畸形了。分数适合用来排队列、触阈值（7 分以上发布、8 分以上参与重排），低置信度的分数当成”再看一眼”，而不是当成真理。批量打分——比如 8 个 RAG 片段——的模式见RAG 重排案例。

Confidence（置信度）

模型对自己答案的自我报告确定度，以 0 到 1 之间的数字随每次 Jev 响应返回。置信度是把”一次模型调用”变成”一道门禁”的关键：yes 配 0.97 可以自动批准，yes 配 0.55 就不该。三个习惯让它真正有用。一，永远与答案成对使用——自信的 no 和迟疑的 yes 路由方式不同。二，阈值用你自己的流量校准，别照抄指南里的示例数字；先记录两三周的置信度分布，回看低置信度桶里到底是什么，再选一个人工扛得住的切点。三，防御式解析——confidence 缺失或不是数字，含义是”走兜底”，绝不是”继续放行”。版本升级可能移动校准，这正是1.13 版本说明建议在升级前后对比置信度直方图的原因。

Rationale（依据）

模型对自己答案的一句话解释，在本站所有示例数据中都随 answer 和 confidence 一起返回。Rationale 不是装饰——它是有史以来最便宜的审计线索。自动隐藏了一条评论？rationale 就是解释原因的日志行。把一封邮件分给了账单团队？rationale 告诉接收团队这封邮件为什么路由过来。把一张发票转人工了？rationale 告诉会计先看哪里。两个提醒：rationale 是一个听起来合理的解释，不是证据——它应该辅助复核，而不是在高风险决策上替代复核。它是生成文本，解析时要把长度和格式当成柔性的；出现异常记日志，不要崩。本站所有案例都把 rationale 与决策一起归档，就是为了这个。

Fallback（兜底）

决定”模型不够确定时怎么办”的那条规则。兜底建立在置信度和 unclear 之上：比如只有 yes 且置信度不低于 0.8 才自动批准，其余一切——迟疑的 yes、所有 unclear、字段缺失——全部转人工。这是生产环境使用 Jev 最重要的模式，因为一个”自信地错”的判断模型比没有模型更糟，而任何模型都会有不确定的时候。好的兜底有三个共性：阈值放在配置里而不是代码里；兜底路径是有归属者的真实目的地（审核队列、分诊文件夹），而不是一个报错；兜底率要被监控，因为它突然升高通常说明你的输入构成变了。阈值怎么选见置信度与兜底指南，代码长什么样见发票审批门禁案例。

Channel（渠道）

你实际调用 Jev 的端点。本站所有演示都走 OpenRouter 的 OpenAI 兼容端点——https://openrouter.ai/api/v1/chat/completions，模型 id 为 typesafe/jev-1.13——因为这是试模型最快的路径：你现成的 OpenAI 形状的客户端直接能用，换一个 base URL 就行。渠道同时决定了你付的价格：本站引用的 $0.0462 / 1M input tokens 是 OpenRouter 2026 年 9 月的挂牌价，做预算前请在 OpenRouter 模型页同时核实 slug 和价格——版本迭代时两者都可能变化。TypeSafe AI 也提供官方 API，其权威细节归属 typesafe.ai，本站不复述官方端点。无论选哪个渠道，都请把模型 slug 固定在配置里，这样渠道侧的任何变化都不能悄悄改变你流水线的行为。

Typed output（类型化输出）

每次 Jev 响应的形态：字段固定的 JSON——answer、confidence、rationale，打分题另有 scale——而不是自由文本。“类型化”三个字是承重墙。它意味着答案到达时已经解析完成：代码对 "answer": "billing" 做分支就像对任何枚举做分支，对整数分数做排序，对浮点置信度做门禁，完全不需要对一大段话动正则刀。它还意味着契约是可检查的：answer 应该在你声明的选项之内，confidence 应该是 [0, 1] 内的数字，scale 应该回显你声明的量程——畸形响应因此可被识别，而识别到异常的正确反应是走兜底路径，不是崩溃。本站所有示例都建立在这个契约上，但有一句诚实的提醒：我们展示的 JSON 是示例数据（example fixture），硬编码之前请先与官方文档核对字段名。这个核对动作本身就是你的第一次 API 调用的一部分。

Example fixture（示例数据）

本站通篇使用的带标注的示例响应——比如 {"answer": "yes", "confidence": 0.97, "rationale": "..."}——用来讲解请求和响应的形态，而不是用来声称实测跑分。用示例数据有一个诚实的原因：模型行为会随版本变动，任何”实测抓包”都会过时，而本站拒绝编造跑分对比表。示例数据能可靠给你的是契约——字段名、取值范围、scale 如何回显量程——这套结构稳定到可以照着写解析器，前提是你先与官方文档核对字段名。示例数据不能给你的是”你的提示词一定会返回这个答案、这个置信度”的承诺。所以请把这里的每个 fixture 当成”带示例值的 schema”：结构照抄，输入自己跑，行为是否可信，用1.13 版本说明里的自测步骤验证后再上生产。