初见 Jev上模型会说还不够程序需要明确判断开场一个客服系统收到这样的消息我的信用卡被扣了两次。我已经提交过工单但一直没有解决可以直接帮我转人工吗人读完这句话很快就能抓住几个重点用户遇到了重复扣款对问题迟迟未解决感到不满还明确提出要转人工。客服系统接下来要做的就是分配处理团队、评估不满程度再判断是否进入人工队列。如果把消息交给大语言模型它很可能这样分析用户遇到了重复扣款对处理进度不满希望与人工客服沟通。这样的回答适合人读但程序还得从中提取处理部门、不满等级和转人工请求才能继续执行后面的流程。开发者通常会继续约束输出“只返回 JSON不要解释。”JSON 方便程序解析字段但程序最终需要的仍是几个明确的判断结果。如果模型读完消息后直接返回“账单问题”“不满程度较高”“用户要求人工”后续代码就不必再理解一遍模型的回答。Jev 处理的正是这类任务。开发者先明确软件需要哪些判断Jev 再根据给定内容逐项回答。程序拿到结果后可以直接分类、排序、路由或转交人工不必再分析模型到底“说了什么”。这篇文章暂不展开 SDK 和接口参数只从判断任务入手说明 Jev 是什么、适合用在哪里以及哪些事情不该交给它。1、Jev 到底是什么Jev 是 TypeSafe 推出的 System One 模型。一次请求包含model、state和questions三个顶层字段model指定模型state保存待判断的材料questions是一组带名称的问题。返回的答案沿用这些问题名称代码可以据此找到每项判断对应的结果。一次判断由 State、Question 和 Answer 三部分组成。State是模型实际能看到的材料也限定了这次判断的证据范围。它可以是一段字符串也可以是包含多个字段的 JSON 对象或数组。在客服案例中最简单的 State 只有用户消息如果还要参考订单、历史工单或退款规则可以把相关材料放进同一个对象用字段名说明它们之间的关系。如果 State 中没有某项事实就不该让模型替系统补齐。Question不是宽泛的分析要求而是一项边界明确的判断。与其问“请分析这名用户并告诉我应该怎么办”不如拆成“应该交给哪个团队”“用户有多不满”“用户是否明确要求人工处理”。每个问题都有开发者指定的 ID。这个 ID 只供代码匹配问题和答案不参与模型判断真正影响回答的是问题类型、instructions和criteria。Answer是程序最终拿到的结构化结果可能是从候选项中选出的部门、位于几个等级之间的分数或某件事成立的概率。程序按照问题 ID 读取答案后就能进入后续逻辑不必再从解释文字中寻找结论。同一份 State 可以同时对应多个问题每个问题各自完成一项判断。以前面的客服消息为例系统可以一次询问要判断的问题适合的问题类型程序希望得到什么应该交给哪个团队Choice从账单、物流、账户等选项中选择一个用户有多不满Score在一组有顺序的等级上给出分数用户是否要求人工处理Noul返回“是”成立的概率这三种类型解决的是不同问题。Choice 用于固定选项。它的criteria是一组“选项名称—选项说明”。选项名称供代码使用例如billing选项说明告诉模型哪些情况属于该选项例如“扣款、账单、发票或支付问题”。返回结果包含选中的名称、每个候选项的概率以及这次选择的置信度。如果选项说明相互重叠即使格式完全正确模型也可能难以区分。Score 用于有顺序的等级。它的criteria是一个从低到高排列的描述数组数组位置从 0 开始编号。例如四个情绪等级分别对应 0、1、2、3。Jev 会返回每一级的概率并根据这组分布计算分数因此结果可能是 1.7 或 2.3不一定正好落在某个整数等级上。程序既可以保留连续分数也可以按照业务规则将其映射为普通、高优先级或紧急工单。Noul 用于真假判断。它返回一个 0 到 1 之间的数值表示“是”成立的概率。以“用户是否明确要求人工处理”为例数值越接近 1模型越倾向于认为这件事成立。Noul 可以只写instructions也可以在criteria中分别说明什么算“是”、什么算“否”。它不会像 Choice 和 Score 那样另行返回 confidence因为这个概率本身就是判断信号。Choice 和 Score 的 confidence 由完整概率分布计算而来。概率越集中在某个选项或等级上confidence 越高分布越分散confidence 越低。它表示这次分布是否集中不等同于经过统计验证的单次正确率。理解 Jev 时不必先死记这三个名字。它的基本工作方式是开发者先定义答案的形状模型再针对 State 完成判断。代码不用等待一段自由文本也不用猜哪句话才是最终结论。上篇先讲 Choice、Score 和 Noul这三种类型已经足以说明 System One 模型与常见生成模型的差别。换个更小的场景会更直观。假设电商平台收到评价“充满电只能用半天其他方面还可以。”这段评价就是 State。系统可以设置一个 Choice判断主要问题属于续航、屏幕还是性能再设置一个 Noul判断用户是否明确提出退货。程序根据前一个 Answer 将评价计入电池问题统计再根据后一个 Answer 决定是否进入退货意图处理流程。模型只负责判断评价表达了什么商品信息查询和售后资格校验仍由其他程序完成。2、Jev 为什么不以生成文本为主要目标大语言模型擅长生成文本。写邮件、总结资料、解释概念、生成代码都需要模型根据上下文组织内容答案可以很长表达方式也不止一种。程序处理判断任务时关心的通常不是一段解释而是结果属于哪个类别。客服消息被判断为账单问题就进入账单流程属于账户访问问题就交给另一套处理逻辑。这里需要的是稳定的类别名称而不是意思相近、措辞却可能变化的说明。有些任务不能只看类别还要判断风险、严重程度或匹配程度。例如两条消息都表达了不满但一条只是在询问处理进度另一条已经多次投诉并要求立即升级。系统要安排优先级就需要可比较的等级或分数。程序还会关心某个条件是否成立例如用户是否提出退款、是否要求人工处理。拿到判断后系统仍要决定能否自动执行。如果几个候选结果十分接近说明模型没有形成明显倾向可能是信息不足、选项重叠也可能是输入本身存在歧义。此时应该补充上下文、检查问题设计或转交人工而不是强行采用概率最高的结果。如果用生成模型完成这类任务常见流程是输入内容 → 生成文本或 JSON → 校验格式 → 解析字段 → 进入程序分支Jev 的流程更接近输入 State 和类型化问题 → 返回结构化判断 → 进入程序分支两者的差别不只是少写一段解析代码。现在的 LLM 也能通过结构化输出、JSON Schema 或工具调用返回固定格式所以**“能不能生成合法 JSON”并不是 Jev 与 LLM 的核心分界**。真正的区别在任务接口。LLM 的结构化输出通常要求模型生成符合 Schema 的内容而 Jev 的接口直接由 Choice、Score 和 Noul 这些判断类型组成。Choice 返回所有候选项的概率Score 返回各等级的概率和据此计算的连续分数Noul 返回“是”成立的概率。程序拿到的不只是格式正确的最终标签还能看到其他候选答案各占多少概率以及这次判断是否集中。结果不够明确时代码可以暂停自动处理补充上下文、调用其他模型或交给人工复核。对判断系统来说解释得流畅不等于结果容易使用。一段很有说服力的文字程序仍可能无从下手类型清楚、带有概率的结果更容易接入实际工作流。这正是 Jev 不以生成解释为主要目标的原因。例如邮件系统收到一句“请不要再给我发送每周资讯”。生成模型可能回复“用户希望停止接收订阅邮件建议将其从邮件列表中移除。”这段话没有错但程序还要从中提取“取消订阅”这个动作。如果改用 Noul 提问“用户是否明确要求停止接收资讯”系统会直接拿到该命题成立的概率。后续程序先检查用户身份和订阅状态再执行取消操作不必解析模型生成的说明文字。3、Jev 与我们熟悉的大语言模型有什么区别Jev 和 LLM 都能理解自然语言输入但它们服务的任务不同。维度大语言模型Jev主要任务生成、总结、解释和开放式推理分类、评分和真假判断常见输出自然语言、代码或工具调用类型化答案、概率和部分问题类型的置信度答案范围可以开放生成由问题类型和判断标准约束主要使用者人、Agent 或其他模型软件控制流适合的位置内容生成和复杂任务处理路由、筛选、判断和复核节点例如用户问“请解释为什么这笔费用不合理”LLM 更适合根据材料组织回答。系统问“这条消息是否提出退款要求”Jev 更适合返回一个真假概率。判断和生成可以放在同一条流程中。系统可以先让 Jev 判断请求属于哪一类再由代码选择相应的 LLM也可以先让 LLM 生成答复再用结构化判断检查是否遗漏关键条件。具体怎样组合留到第三篇展开这里先记住Jev 和 LLM 不是同一个位置上的竞争者。Jev 和 LLM 之外普通代码仍要负责确定性操作。金额比较、权限校验、数据库查询、库存检查等结果明确的操作应继续由代码完成。模型适合处理非结构化信息中的语义判断不该接管所有控制逻辑。假设用户说“我换了手机以后一直登录不上去能帮我处理吗”Jev 可以将其判断为账户访问问题LLM 根据排查步骤生成用户能读懂的回复代码负责检查账户是否存在、验证码是否有效以及当前账号是否具备相应权限。三者处理同一条请求但职责不同Jev 判断请求该进入哪条流程LLM 组织沟通内容代码读取真实状态并执行操作。4、Jev 适用场景判断一个任务是否适合 Jev可以先问三个问题答案能否被定义成固定选项、有序等级或真假判断模型能否根据给定 State 在较短时间内完成这个判断程序拿到答案后是否会据此执行分类、排序、路由或复核三个问题大致都能回答“是”通常就值得考虑 Jev。还可以换个更直观的问法一个了解上下文的人能否迅速作出这个判断如果任务需要搜索外部资料、完成多步计算、制定计划或写长篇解释就不该硬塞进一个 Jev 问题。可以把其中能够快速判断的环节拆出来其余部分继续交给代码、工具或生成模型。固定选项工单应该交给账单、物流还是账户团队商品属于哪个类别请求应该交给哪个模型这些问题都有预先定义的答案集合适合使用 Choice。关键不在于“能列出几个选项”而在于程序会根据选中的答案进入不同分支。以工单路由为例billing、shipping和account不只是给模型看的标签还要对应代码中的处理器。模型返回billing后系统才能把工单交给账单流程。因此选项名称应该保持稳定选项说明也要写清边界重复扣款属于账单问题包裹迟迟未到属于物流问题无法登录属于账户问题。对于“发票上的公司名称写错了请帮我修改”这条工单Choice 可以返回billing代码再把它交给发票处理队列。如果billing的说明只写成含义模糊的“其他财务问题”它就可能与退款、扣款等类别重叠后续路由也会变得不稳定。Choice 默认是在候选项中选出一个最可能的答案。如果一条消息可以同时属于多个类别就不能用一个 Choice 把它们硬做成互斥选项。开发者可以把问题改成选择“主要处理团队”也可以将多个类别拆成独立的 Noul 问题。具体怎么设计取决于代码需要单选结果还是需要保留多个同时成立的标签。有序评分风险、严重程度、匹配程度和用户情绪通常不能简单地用“是”或“否”表示而是有从低到高的顺序适合使用 Score。例如客服系统可以定义“平静、轻微不满、明显不满、强烈不满”四个等级。等级顺序要有实际含义相邻两级也要能够区分。“明显不满”可以要求消息中出现问题持续未解决、重复投诉等信号“强烈不满”则可以要求出现立即升级、停止服务或向监管机构投诉等更强烈的表达。如果只写“低、中、高、非常高”却不说明各级对应哪些证据即使模型返回了分数开发者也很难判断问题出在哪里。Score 不只是选中某个整数等级。假设模型认为第 2 级最可能但第 3 级也有不小的概率最终分数就会落在 2 和 3 之间。代码可以用这个连续分数排序也可以结合置信度决定是否自动提高优先级。分数回答“结果大致位于哪里”置信度回答“这组等级是否形成了清楚的倾向”两者不能互相替代。例如用户写道“这是我第三次反馈同一个问题如果今天还不能解决请立即升级处理。”这句话既提到多次反馈也明确要求升级结果可能落在“明显不满”和“强烈不满”两个相邻等级之间。程序可以根据连续分数安排处理顺序同时查看置信度如果几个等级的概率过于分散就先保留原优先级交给人工复核。是非判断“用户是否要求退款”“文档是否包含个人信息”“当前请求是否明确要求人工介入”这些问题适合使用 Noul。Noul 的问题最好写成一个可以根据 State 判断真假的命题。“用户是否明确要求人工处理”比“要不要转人工”更合适前者只判断消息中是否有明确请求后者还混入了客服资源、服务时间和升级政策等业务规则。Noul 不会直接替程序作出最终决定。它给出“是”成立的概率接近 1 表示更倾向于成立接近 0 表示更倾向于不成立接近 0.5 则说明证据不足或正反信号接近。哪些结果可以自动处理哪些需要用户确认或人工复核仍要根据业务风险和实际测试来定。关键词不能代替命题判断。“先别给我退款我想等技术人员再看一下”虽然出现了“退款”表达的却是否定意图。如果问题写成“消息中是否出现退款相关词”结果会偏离业务需要写成“用户是否正在要求退款”模型才能结合否定词和上下文判断真实意图。一份内容多个独立判断实际系统往往要同时获得多项判断。客服消息既要分类也要评估严重程度还要检查退款和人工升级信号。Jev 可以让这些问题针对同一份 State 独立判断再由代码组合结果。这里的“多个问题”并不等于让模型替系统做一整套决策。部门分类、不满评分和人工请求可以共享同一条消息但每项答案仍对应一个明确问题。代码可以规定分类结果明确时自动路由不满程度较高时提升优先级用户明确要求人工时进入人工队列。哪项判断出了错、哪条标准需要调整、哪个动作必须增加复核都可以单独检查。如果后一个问题必须依赖前一个问题的结果例如先确定合同类型再按该类型查询规则最后判断是否允许退款就不该把它们塞进一次“综合判断”。这是一个存在前后依赖的流程需要代码或 Agent 负责查询和编排Jev 只处理各个步骤中边界清楚的语义判断。例如对于“包裹还没到我已经等了一周能直接找人工吗”这条消息Jev 可以分别判断主要问题属于物流用户表现出明显不满并且明确要求人工处理。代码再组合这些结果把工单交给物流团队、提高处理优先级并加入人工队列。Jev 不必再回答“最终应该怎么办”因为后续动作已经写在系统规则中。下篇预告Jev 能对消息分类或评分不代表程序可以据此直接执行操作。模型可以看出用户在要求退款却不能证明账户真的发生过重复扣款它可以判断用户希望转人工却不能代替系统检查客服是否在线也不能确认当前账号是否有权发起操作。下篇会继续使用开头的客服消息逐一拆开这些问题哪些内容由 Jev 判断哪些事实必须查询数据库哪些条件应该写进代码。接着再看程序如何读取 Choice、Score 和 Noul 的结果什么时候自动路由什么时候提高工单优先级什么时候因为答案不够明确而转交人工。最后会用一份完整的请求和响应把这些环节串成一条实际流程。结束语读到这里可以先把Jev 理解成一个专门回答判断题的模型。程序把用户消息、文档或其他材料交给它并写清需要回答的问题。Jev 不负责生成一段供人阅读的解释而是直接返回程序可以使用的答案。程序需要从账单、物流和账户中选出一个部门时可以使用 Choice需要判断风险或不满程度时可以使用 Score只关心某件事是否成立时可以使用 Noul。同一份内容也能同时回答多个问题再由代码决定接下来走哪条流程。判断是否需要 Jev可以先看最终答案是给人读还是给程序用。用户最终想要的是一封回复、一篇文章或一段解释就交给生成模型程序只是想知道“属于哪一类、程度有多高、这件事是否成立”Jev 才有用武之地。 
长河君 · 2026/10/29 11:09:13 · 阅读 1.2k 初见 JEV（上）
初见 Jev上模型会说还不够程序需要明确判断开场一个客服系统收到这样的消息我的信用卡被扣了两次。我已经提交过工单但一直没有解决可以直接帮我转人工吗人读完这句话很快就能抓住几个重点用户遇到了重复扣款对问题迟迟未解决感到不满还明确提出要转人工。客服系统接下来要做的就是分配处理团队、评估不满程度再判断是否进入人工队列。如果把消息交给大语言模型它很可能这样分析用户遇到了重复扣款对处理进度不满希望与人工客服沟通。这样的回答适合人读但程序还得从中提取处理部门、不满等级和转人工请求才能继续执行后面的流程。开发者通常会继续约束输出“只返回 JSON不要解释。”JSON 方便程序解析字段但程序最终需要的仍是几个明确的判断结果。如果模型读完消息后直接返回“账单问题”“不满程度较高”“用户要求人工”后续代码就不必再理解一遍模型的回答。Jev 处理的正是这类任务。开发者先明确软件需要哪些判断Jev 再根据给定内容逐项回答。程序拿到结果后可以直接分类、排序、路由或转交人工不必再分析模型到底“说了什么”。这篇文章暂不展开 SDK 和接口参数只从判断任务入手说明 Jev 是什么、适合用在哪里以及哪些事情不该交给它。1、Jev 到底是什么Jev 是 TypeSafe 推出的 System One 模型。一次请求包含model、state和questions三个顶层字段model指定模型state保存待判断的材料questions是一组带名称的问题。返回的答案沿用这些问题名称代码可以据此找到每项判断对应的结果。一次判断由 State、Question 和 Answer 三部分组成。State是模型实际能看到的材料也限定了这次判断的证据范围。它可以是一段字符串也可以是包含多个字段的 JSON 对象或数组。在客服案例中最简单的 State 只有用户消息如果还要参考订单、历史工单或退款规则可以把相关材料放进同一个对象用字段名说明它们之间的关系。如果 State 中没有某项事实就不该让模型替系统补齐。Question不是宽泛的分析要求而是一项边界明确的判断。与其问“请分析这名用户并告诉我应该怎么办”不如拆成“应该交给哪个团队”“用户有多不满”“用户是否明确要求人工处理”。每个问题都有开发者指定的 ID。这个 ID 只供代码匹配问题和答案不参与模型判断真正影响回答的是问题类型、instructions和criteria。Answer是程序最终拿到的结构化结果可能是从候选项中选出的部门、位于几个等级之间的分数或某件事成立的概率。程序按照问题 ID 读取答案后就能进入后续逻辑不必再从解释文字中寻找结论。同一份 State 可以同时对应多个问题每个问题各自完成一项判断。以前面的客服消息为例系统可以一次询问要判断的问题适合的问题类型程序希望得到什么应该交给哪个团队Choice从账单、物流、账户等选项中选择一个用户有多不满Score在一组有顺序的等级上给出分数用户是否要求人工处理Noul返回“是”成立的概率这三种类型解决的是不同问题。Choice 用于固定选项。它的criteria是一组“选项名称—选项说明”。选项名称供代码使用例如billing选项说明告诉模型哪些情况属于该选项例如“扣款、账单、发票或支付问题”。返回结果包含选中的名称、每个候选项的概率以及这次选择的置信度。如果选项说明相互重叠即使格式完全正确模型也可能难以区分。Score 用于有顺序的等级。它的criteria是一个从低到高排列的描述数组数组位置从 0 开始编号。例如四个情绪等级分别对应 0、1、2、3。Jev 会返回每一级的概率并根据这组分布计算分数因此结果可能是 1.7 或 2.3不一定正好落在某个整数等级上。程序既可以保留连续分数也可以按照业务规则将其映射为普通、高优先级或紧急工单。Noul 用于真假判断。它返回一个 0 到 1 之间的数值表示“是”成立的概率。以“用户是否明确要求人工处理”为例数值越接近 1模型越倾向于认为这件事成立。Noul 可以只写instructions也可以在criteria中分别说明什么算“是”、什么算“否”。它不会像 Choice 和 Score 那样另行返回 confidence因为这个概率本身就是判断信号。Choice 和 Score 的 confidence 由完整概率分布计算而来。概率越集中在某个选项或等级上confidence 越高分布越分散confidence 越低。它表示这次分布是否集中不等同于经过统计验证的单次正确率。理解 Jev 时不必先死记这三个名字。它的基本工作方式是开发者先定义答案的形状模型再针对 State 完成判断。代码不用等待一段自由文本也不用猜哪句话才是最终结论。上篇先讲 Choice、Score 和 Noul这三种类型已经足以说明 System One 模型与常见生成模型的差别。换个更小的场景会更直观。假设电商平台收到评价“充满电只能用半天其他方面还可以。”这段评价就是 State。系统可以设置一个 Choice判断主要问题属于续航、屏幕还是性能再设置一个 Noul判断用户是否明确提出退货。程序根据前一个 Answer 将评价计入电池问题统计再根据后一个 Answer 决定是否进入退货意图处理流程。模型只负责判断评价表达了什么商品信息查询和售后资格校验仍由其他程序完成。2、Jev 为什么不以生成文本为主要目标大语言模型擅长生成文本。写邮件、总结资料、解释概念、生成代码都需要模型根据上下文组织内容答案可以很长表达方式也不止一种。程序处理判断任务时关心的通常不是一段解释而是结果属于哪个类别。客服消息被判断为账单问题就进入账单流程属于账户访问问题就交给另一套处理逻辑。这里需要的是稳定的类别名称而不是意思相近、措辞却可能变化的说明。有些任务不能只看类别还要判断风险、严重程度或匹配程度。例如两条消息都表达了不满但一条只是在询问处理进度另一条已经多次投诉并要求立即升级。系统要安排优先级就需要可比较的等级或分数。程序还会关心某个条件是否成立例如用户是否提出退款、是否要求人工处理。拿到判断后系统仍要决定能否自动执行。如果几个候选结果十分接近说明模型没有形成明显倾向可能是信息不足、选项重叠也可能是输入本身存在歧义。此时应该补充上下文、检查问题设计或转交人工而不是强行采用概率最高的结果。如果用生成模型完成这类任务常见流程是输入内容 → 生成文本或 JSON → 校验格式 → 解析字段 → 进入程序分支Jev 的流程更接近输入 State 和类型化问题 → 返回结构化判断 → 进入程序分支两者的差别不只是少写一段解析代码。现在的 LLM 也能通过结构化输出、JSON Schema 或工具调用返回固定格式所以**“能不能生成合法 JSON”并不是 Jev 与 LLM 的核心分界**。真正的区别在任务接口。LLM 的结构化输出通常要求模型生成符合 Schema 的内容而 Jev 的接口直接由 Choice、Score 和 Noul 这些判断类型组成。Choice 返回所有候选项的概率Score 返回各等级的概率和据此计算的连续分数Noul 返回“是”成立的概率。程序拿到的不只是格式正确的最终标签还能看到其他候选答案各占多少概率以及这次判断是否集中。结果不够明确时代码可以暂停自动处理补充上下文、调用其他模型或交给人工复核。对判断系统来说解释得流畅不等于结果容易使用。一段很有说服力的文字程序仍可能无从下手类型清楚、带有概率的结果更容易接入实际工作流。这正是 Jev 不以生成解释为主要目标的原因。例如邮件系统收到一句“请不要再给我发送每周资讯”。生成模型可能回复“用户希望停止接收订阅邮件建议将其从邮件列表中移除。”这段话没有错但程序还要从中提取“取消订阅”这个动作。如果改用 Noul 提问“用户是否明确要求停止接收资讯”系统会直接拿到该命题成立的概率。后续程序先检查用户身份和订阅状态再执行取消操作不必解析模型生成的说明文字。3、Jev 与我们熟悉的大语言模型有什么区别Jev 和 LLM 都能理解自然语言输入但它们服务的任务不同。维度大语言模型Jev主要任务生成、总结、解释和开放式推理分类、评分和真假判断常见输出自然语言、代码或工具调用类型化答案、概率和部分问题类型的置信度答案范围可以开放生成由问题类型和判断标准约束主要使用者人、Agent 或其他模型软件控制流适合的位置内容生成和复杂任务处理路由、筛选、判断和复核节点例如用户问“请解释为什么这笔费用不合理”LLM 更适合根据材料组织回答。系统问“这条消息是否提出退款要求”Jev 更适合返回一个真假概率。判断和生成可以放在同一条流程中。系统可以先让 Jev 判断请求属于哪一类再由代码选择相应的 LLM也可以先让 LLM 生成答复再用结构化判断检查是否遗漏关键条件。具体怎样组合留到第三篇展开这里先记住Jev 和 LLM 不是同一个位置上的竞争者。Jev 和 LLM 之外普通代码仍要负责确定性操作。金额比较、权限校验、数据库查询、库存检查等结果明确的操作应继续由代码完成。模型适合处理非结构化信息中的语义判断不该接管所有控制逻辑。假设用户说“我换了手机以后一直登录不上去能帮我处理吗”Jev 可以将其判断为账户访问问题LLM 根据排查步骤生成用户能读懂的回复代码负责检查账户是否存在、验证码是否有效以及当前账号是否具备相应权限。三者处理同一条请求但职责不同Jev 判断请求该进入哪条流程LLM 组织沟通内容代码读取真实状态并执行操作。4、Jev 适用场景判断一个任务是否适合 Jev可以先问三个问题答案能否被定义成固定选项、有序等级或真假判断模型能否根据给定 State 在较短时间内完成这个判断程序拿到答案后是否会据此执行分类、排序、路由或复核三个问题大致都能回答“是”通常就值得考虑 Jev。还可以换个更直观的问法一个了解上下文的人能否迅速作出这个判断如果任务需要搜索外部资料、完成多步计算、制定计划或写长篇解释就不该硬塞进一个 Jev 问题。可以把其中能够快速判断的环节拆出来其余部分继续交给代码、工具或生成模型。固定选项工单应该交给账单、物流还是账户团队商品属于哪个类别请求应该交给哪个模型这些问题都有预先定义的答案集合适合使用 Choice。关键不在于“能列出几个选项”而在于程序会根据选中的答案进入不同分支。以工单路由为例billing、shipping和account不只是给模型看的标签还要对应代码中的处理器。模型返回billing后系统才能把工单交给账单流程。因此选项名称应该保持稳定选项说明也要写清边界重复扣款属于账单问题包裹迟迟未到属于物流问题无法登录属于账户问题。对于“发票上的公司名称写错了请帮我修改”这条工单Choice 可以返回billing代码再把它交给发票处理队列。如果billing的说明只写成含义模糊的“其他财务问题”它就可能与退款、扣款等类别重叠后续路由也会变得不稳定。Choice 默认是在候选项中选出一个最可能的答案。如果一条消息可以同时属于多个类别就不能用一个 Choice 把它们硬做成互斥选项。开发者可以把问题改成选择“主要处理团队”也可以将多个类别拆成独立的 Noul 问题。具体怎么设计取决于代码需要单选结果还是需要保留多个同时成立的标签。有序评分风险、严重程度、匹配程度和用户情绪通常不能简单地用“是”或“否”表示而是有从低到高的顺序适合使用 Score。例如客服系统可以定义“平静、轻微不满、明显不满、强烈不满”四个等级。等级顺序要有实际含义相邻两级也要能够区分。“明显不满”可以要求消息中出现问题持续未解决、重复投诉等信号“强烈不满”则可以要求出现立即升级、停止服务或向监管机构投诉等更强烈的表达。如果只写“低、中、高、非常高”却不说明各级对应哪些证据即使模型返回了分数开发者也很难判断问题出在哪里。Score 不只是选中某个整数等级。假设模型认为第 2 级最可能但第 3 级也有不小的概率最终分数就会落在 2 和 3 之间。代码可以用这个连续分数排序也可以结合置信度决定是否自动提高优先级。分数回答“结果大致位于哪里”置信度回答“这组等级是否形成了清楚的倾向”两者不能互相替代。例如用户写道“这是我第三次反馈同一个问题如果今天还不能解决请立即升级处理。”这句话既提到多次反馈也明确要求升级结果可能落在“明显不满”和“强烈不满”两个相邻等级之间。程序可以根据连续分数安排处理顺序同时查看置信度如果几个等级的概率过于分散就先保留原优先级交给人工复核。是非判断“用户是否要求退款”“文档是否包含个人信息”“当前请求是否明确要求人工介入”这些问题适合使用 Noul。Noul 的问题最好写成一个可以根据 State 判断真假的命题。“用户是否明确要求人工处理”比“要不要转人工”更合适前者只判断消息中是否有明确请求后者还混入了客服资源、服务时间和升级政策等业务规则。Noul 不会直接替程序作出最终决定。它给出“是”成立的概率接近 1 表示更倾向于成立接近 0 表示更倾向于不成立接近 0.5 则说明证据不足或正反信号接近。哪些结果可以自动处理哪些需要用户确认或人工复核仍要根据业务风险和实际测试来定。关键词不能代替命题判断。“先别给我退款我想等技术人员再看一下”虽然出现了“退款”表达的却是否定意图。如果问题写成“消息中是否出现退款相关词”结果会偏离业务需要写成“用户是否正在要求退款”模型才能结合否定词和上下文判断真实意图。一份内容多个独立判断实际系统往往要同时获得多项判断。客服消息既要分类也要评估严重程度还要检查退款和人工升级信号。Jev 可以让这些问题针对同一份 State 独立判断再由代码组合结果。这里的“多个问题”并不等于让模型替系统做一整套决策。部门分类、不满评分和人工请求可以共享同一条消息但每项答案仍对应一个明确问题。代码可以规定分类结果明确时自动路由不满程度较高时提升优先级用户明确要求人工时进入人工队列。哪项判断出了错、哪条标准需要调整、哪个动作必须增加复核都可以单独检查。如果后一个问题必须依赖前一个问题的结果例如先确定合同类型再按该类型查询规则最后判断是否允许退款就不该把它们塞进一次“综合判断”。这是一个存在前后依赖的流程需要代码或 Agent 负责查询和编排Jev 只处理各个步骤中边界清楚的语义判断。例如对于“包裹还没到我已经等了一周能直接找人工吗”这条消息Jev 可以分别判断主要问题属于物流用户表现出明显不满并且明确要求人工处理。代码再组合这些结果把工单交给物流团队、提高处理优先级并加入人工队列。Jev 不必再回答“最终应该怎么办”因为后续动作已经写在系统规则中。下篇预告Jev 能对消息分类或评分不代表程序可以据此直接执行操作。模型可以看出用户在要求退款却不能证明账户真的发生过重复扣款它可以判断用户希望转人工却不能代替系统检查客服是否在线也不能确认当前账号是否有权发起操作。下篇会继续使用开头的客服消息逐一拆开这些问题哪些内容由 Jev 判断哪些事实必须查询数据库哪些条件应该写进代码。接着再看程序如何读取 Choice、Score 和 Noul 的结果什么时候自动路由什么时候提高工单优先级什么时候因为答案不够明确而转交人工。最后会用一份完整的请求和响应把这些环节串成一条实际流程。结束语读到这里可以先把Jev 理解成一个专门回答判断题的模型。程序把用户消息、文档或其他材料交给它并写清需要回答的问题。Jev 不负责生成一段供人阅读的解释而是直接返回程序可以使用的答案。程序需要从账单、物流和账户中选出一个部门时可以使用 Choice需要判断风险或不满程度时可以使用 Score只关心某件事是否成立时可以使用 Noul。同一份内容也能同时回答多个问题再由代码决定接下来走哪条流程。判断是否需要 Jev可以先看最终答案是给人读还是给程序用。用户最终想要的是一封回复、一篇文章或一段解释就交给生成模型程序只是想知道“属于哪一类、程度有多高、这件事是否成立”Jev 才有用武之地。