工程化 / Jev

1. Jev到底是什么

原文备份 · 第 2 / 10 篇 · 查看极客时间原知识库 ↗

本篇目录 · 12 节

来源：Jev

预计阅读时间：20 分钟
本篇目标：理解 Jev 与聊天模型、传统规则和普通分类器的区别，并能判断一个需求是否适合使用 Jev。

我们已经很习惯让 AI “生成”东西：写一封邮件、补一段代码、总结一份文档。可是在很多软件流程里，真正高频的工作并不是写内容，而是做一个很小的判断：

这条留言应该进入哪个队列？
这段反馈有多紧急？
这条命令是否可能破坏数据？
这份检索结果与问题相关吗？
当前结果要自动通过，还是交给人看一眼？

这些问题需要一点语义理解，却不需要一篇回答。让通用大模型先写一段话，再从话里解析出 yes、billing 或 high，总觉得绕了一圈。

Jev 就是为这类位置设计的。

一、先用一句话说清 Jev

Jev 是 TypeSafe AI 发布的第一个 System One Model。你向它提供一份当前状态，再定义几个答案范围明确的问题；它不会生成说明文字，而是返回类型确定的判断结果和概率。

TypeSafe 官方把这种接口概括为：状态和类型化问题进去，结构化答案出来。官方文档：Introduction、System One。

可以先把它想成一个带语义理解能力的函数：

普通函数：明确数据 + 明确规则 -> 确定结果
Jev：自然语言状态 + 预先定义的答案空间 -> 概率化判断
聊天模型：开放问题 -> 一段新生成的文字

比如收到下面这条留言：

我连续两次收到扣款通知，但只买了一份会员，请尽快帮我核对。

你可以事先定义三个问题：

类别：billing / technical / account / other
紧急程度：low / medium / high
是否明确要求退款：是或否

Jev 返回的不是一段客服分析，而是类似下面的结构：

{
  "category": {
    "choice": "billing",
    "probabilities": {
      "billing": 0.94,
      "technical": 0.02,
      "account": 0.03,
      "other": 0.01
    },
    "confidence": 0.88
  },
  "refund_requested": {
    "noul": 0.37
  }
}

这里有一个很重要的区别：留言明显与扣款有关，但它只是要求“核对”，未必已经明确要求退款。一个系统可以把 category 用来分流，同时因为 refund_requested 不够明确而继续询问用户，而不是擅自创建退款操作。

这正是概率有价值的地方。它不仅告诉程序“最像什么”，还让程序知道这个判断有多确定。

二、Jev 不是缩小版聊天模型

Jev 能理解文本，但它并不负责写文本。官方文档明确列出了当前边界：它不会写回复、生成代码，也不会解释自己的推理过程；目前接受的是文本内容，包括字符串、由文本组成的 JSON 对象或数组，暂不支持图片、音频和视频。

因此，下面这些任务并不适合直接交给 Jev：

写一封有礼貌的客服回复；
总结一份二十页的研究报告；
根据需求生成程序代码；
对一个开放问题给出完整解决方案；
解释为什么某个架构设计更好。

Jev 可以参与这些流程，但它只负责其中答案范围明确的判断。例如：

在写客服回复前，判断问题类别和情绪；
在总结报告前，筛选哪些段落与主题相关；
在编码 Agent 执行命令前，判断命令是否涉及删除、凭据或越界路径；
在多个工具之间，选择更适合当前任务的一个；
在生成结果后，按几个明确维度打分，决定是否转人工检查。

真正的写作、推理和执行仍然由普通代码、通用模型或人来完成。

三、先认识三个核心输入输出

完整语法会在第三篇讲，这里先建立整体认识。

State：需要被判断的当前状态

state 可以是一段留言，也可以是包含留言、账号状态和处理规则的 JSON 对象。它相当于你在请别人判断前递给他的材料。

{
  "message": "我连续两次收到扣款通知，请尽快核对。",
  "account_plan": "monthly",
  "recent_charge_count": 2
}

事实和原始材料放在 state 中，不要把它们偷偷混进问题描述里。这样后续增加问题时，可以继续复用同一份状态。

Questions：你希望 Jev 做出的具体判断

Jev 当前提供三类问题：

类型	适合回答什么	典型结果
`Choice`	从一组已知选项中选一个	`billing`
`Score`	在定义清楚的等级上评分	`1.6`
`Noul`	某个判断为真的概率	`0.87`

一个问题应该只判断一件事。与其问“这条留言重要吗，应该怎么处理”，不如拆成“紧急程度”“信息是否完整”“是否需要人工处理”三个问题，再由代码组合答案。

Answers：由代码直接读取的类型化结果

答案只能落在你定义的范围内。Choice 不会突然返回一个没有定义的部门；Score 会落在你给出的等级范围中；Noul 返回 0 到 1 之间的概率。

这让代码不需要从一段自由文本里猜测模型到底想表达什么。不过，它只能保证“输出形状正确”，不能保证“每次判断都正确”。这个区别必须牢牢记住。

四、“不会输出幻觉”不等于“不会判断错”

TypeSafe 在发布 Jev 时强调类型安全：模型不会返回答案空间之外的值。比如你只允许 billing、technical 和 other，程序就不需要防备它突然输出 maybe_sales_team。

但这不代表 Jev 永远会选对。

官方 System One 文档也明确提醒：概率校准是从一组预测的统计表现来衡量的，并不保证某一个具体答案正确。Jev 仍然可能：

把含义模糊的留言分到错误类别；
因为状态缺少关键信息而给出不可靠判断；
因为选项设计重叠而在两个答案之间摇摆；
在与主要训练语言不同的文本上表现下降；
对超出其适用形状的复杂推理任务给出不好的结果。

所以更准确的说法是：Jev 避免了自由生成带来的“格式失控”，但语义判断依然需要评估、阈值和人工兜底。

五、Jev、规则和通用大模型怎么选

三者不是替代关系，而是适合处理不同形状的问题。

方法	更适合	不适合
普通代码规则	金额比较、字段校验、精确关键词、权限列表、数学计算	表达方式很多、边界模糊的语义判断
Jev	已知答案范围内的分类、评分、路由、筛选和校验	写作、长推理、开放式回答、执行副作用
通用大模型	生成文字、解释、规划、编码、综合推理	大量高频且答案空间固定的小判断

以退款流程为例：

是否存在两笔相同订单号和金额的扣款 -> 普通代码
用户是否表达了退款诉求               -> Jev
根据情况起草一封解释邮件             -> 通用大模型
真正发起退款                         -> 业务系统 + 权限与人工确认

把每一层放在合适的位置，比寻找一个“什么都能做”的模型可靠得多。

六、一个需求适不适合 Jev

可以先问下面五个问题：

这个步骤需要理解自然语言或带语义的状态吗？
合法答案能否在调用前定义清楚？
结果是否会被代码用来选择、排序、过滤或分支？
不确定时，系统是否有暂停、补充信息或转人工的路径？
能否准备一批真实样本验证它，而不是只凭几个演示判断效果？

如果前三个回答为“是”，Jev 可能合适。如果第四、第五个回答为“否”，先不要自动化。

下面这些判断适合用来练习：

为个人收件箱区分账单、日程、学习资料和其他内容；
按信息完整程度给反馈评分；
判断搜索结果是否与问题相关；
为编码 Agent 选择技能或工具；
判断一段操作描述是否可能涉及删除或泄露凭据。

下面这些则应优先使用确定性代码：

文件扩展名是不是 .pdf；
金额是否超过 1000 元；
测试进程的退出码是否为 0；
用户是否拥有某个明确权限；
一段 JSON 能否通过 Schema 校验。

不要为了“用 AI”而把本来可以精确解决的问题改成概率问题。

七、中文用户需要提前知道的限制

TypeSafe 当前的 Models 文档说明，Jev 的主要训练语言是英语，英语也是目前准确率最好的语言。中文、日文、韩文等 CJK 文本可以作为输入，但表现并不等同于英语。

这不等于中文完全不能用，而是意味着：

不要拿英文示例跑通，就默认中文业务也同样可靠；
教程中的中文案例用于理解结构，真正上线前必须使用自己的中文数据评估；
高风险判断应该使用更保守的阈值并保留人工确认；
如果中文效果不满足需求，可以尝试更明确的状态结构、不同方案或暂时不自动执行。

后面的 Decision Inbox 会刻意保留一小组中文样本。第七篇我们会把这些样本变成可重复运行的评估，而不是靠感觉判断“看起来不错”。

八、这套教程要做的项目

接下来我们会完成一个小型 Decision Inbox：

留言进入
  ↓
Jev 判断类别、紧急程度和是否明确要求行动
  ↓
普通 Python 代码读取概率和置信度，决定是否需要人工复核
  ↓
进入正常队列 / 人工复核 / 停止自动处理

这个项目故意不加入数据库、网页界面和复杂账号系统。我们只保留最能体现 Jev 价值的部分：如何定义状态，如何拆判断，如何读取不确定性，以及如何让代码始终掌握最终控制权。

下一篇先完成两件实事：在 Playground 里看见 Jev 的真实返回结果，再用 Python SDK 发出第一次调用。

本篇检查

读完后，你应该能解释：

Jev 为什么不是聊天模型；
类型安全与判断正确为什么是两回事；
哪些工作交给代码、Jev 和通用模型；
为什么低置信度结果不能直接触发高风险操作。

如果这四点还混在一起，先不要急着写 API 调用。后面所有工作流设计都会建立在这些边界之上。