Jev 是什么，适合解决什么问题？

假设你维护一个小型 SaaS，每天要处理几十条客户消息。一条新消息写着：“本月订阅扣了两次款，而且今天登录失败了，请帮我处理。”你希望程序把它放进合适的处理队列。这件事有自然语言理解的部分，也有明确的业务规则：该识别哪些诉求、谁先接单、信息不足时怎么办。

Jev 是 TypeSafe 的模型。它的接口接收待判断的材料和带类型的问题，再返回结构化答案，供程序继续处理。这里的核心交付物是代码能读取的判断值。官方介绍

在这个工单场景里，你不必先要求模型写一段“分析”，再从分析中寻找部门名称。你可以先确定程序允许的部门值，然后问一个范围清楚的问题。不过，结构正确只解决了接入问题；分类是否符合你的业务标准，还需要用样例验证。

跟着一条工单走完四步

客户消息与相关材料 → state
要判断的维度与标准 → questions
模型给出的类型化值 → answers
校验、复核与队列选择 → 你的程序

state 是本次判断能看到的材料。简单场景可以直接放一段文本；有多种来源时，可以用 JSON 对象标明字段，例如客户原文、已有订单信息和当前规则。State 文档

下面是本书自拟的输入，不能据此确认客户真的被重复扣款：

{
  "ticket_id": "T-101",
  "customer_message": "本月订阅扣了两次款，而且今天登录失败了。",
  "account_facts": "No verified payment records supplied."
}

客户说了什么，与系统已经核实什么，要保持区别。若问题是“消息是否报告重复扣款”，上面材料足够供人标注；若问题是“是否应该退款”，还缺交易记录、退款规则和操作权限。把第二个问题塞进一个漂亮的提示词，并不会让这些信息自动出现。

questions 描述你要做的判断。对这个输入，可以分别问：它涉及哪个队列？是否报告无法登录？是否明确提到处理期限？每个问题负责一个维度。answers 是对应的返回值。最后由程序决定：保存建议、标记复核，或进入下一道确定性检查。

三种答案，对应三种程序需求

Choice 和 Score 提供概率分布与 confidence；Noul 返回 0–1 的 noul 值。字段细节见官方问题类型说明。不必现在记住全部字段，先确定程序究竟需要类别、程度，还是一个条件。

本书保留英文枚举值，是为了让中文与英文示例调用同一套代码。界面可以把 billing 显示成“账单”，保存的数据仍然使用 billing。显示文字与程序值分开后，翻译不会悄悄改变分支条件。

哪些任务值得试，哪些应该先用规则

以下是本书的设计选择，不是性能排行。

不要因为某个步骤能写成问题，就把它交给模型。假设系统已经知道订阅是否过期，直接比较时间即可。把确定事实重新交给语言判断，只会增加一个需要解释的环节。

反过来，关键词也不总能表达完整意图。“先别退款，我只想要发票”包含“退款”二字，却没有提出退款请求。这种反例适合进入你的试验集：保留简单规则作基线，再比较语义判断有没有减少错误。收益应来自你自己的数据，而不是工具名称。

有限选项不等于完整 Agent

工具路由会展示这个分工：模型选择 faq、order 或 human；程序验证是否有订单号、该订单是否属于当前用户、工具是否执行成功。有限选项判断不会自动生成可靠的工具参数，也不会替你建立身份权限。

同样，文章检查器只问稿件里有没有可观察的内容，例如一个可执行步骤或与主张相连的来源。它不会因为回答“有来源”就证明网页真实、结论正确或文章能获得搜索流量。需要这些判断时，必须增加对应的数据和验证流程。

这样的职责划分也便于排错。一次结果不好，你可以分别检查材料、问题、答案和本地规则，而不必把整个系统当成一个不可分的黑箱。官方构建指南也把控制流程与副作用保留在代码中。构建指南

读懂“确定”，再谈自动处理

Choice 中某个选项的概率，描述这次判断如何分布在候选项上；confidence 概括分布的集中程度。两者都不等于你在独立标注集上测出的正确率。Confidence 文档

假设一个教学样例对 billing 与 technical 的倾向很接近。你的第一反应可以是查看是否存在多个诉求，或者标准是否允许 mixed，而不是立即把阈值调低让程序强行通过。即使答案很集中，也仍要检查数据权限、动作条件和错误代价。

本书先让程序输出本地建议。你可以删除结果、修改标准、再次运行。当它准备进入真实业务时，再用保留的验证集决定哪些建议可自动采用，哪些需要复核。复核率本身也是结果：如果大部分输入都进人工队列，你需要判断这种设计是否仍节省了时间。

一个适合今天开始的练习

写下你最近重复做过的一项判断，收集十个合成或获准使用的输入。对每个输入，先由你写出预期类别和理由，再尝试回答三个问题：允许的输出能否列全？两位同事能否按同一标准得出一致结果？一个错误会发生在“分错队列”，还是会直接造成不可撤销的动作？

如果输出还写不清，先缩小任务。例如把“自动处理客户问题”改成“从四个值中选择待复核的工单队列”。如果标准有争议，先记录争议；这可能是业务定义的问题，不是模型还不够聪明。

中文材料应单独评测。官方当前说明英语表现最好，包含中文在内的其他语言虽可输入，但不保证同等准确性。本书提供双语阅读与代码说明，不代表已验证模型的中英文效果相同。模型与语言支持

下一步：第一次使用：从离线演示到真实判断。