Jev Model 是什么？从 System One 到可执行 AI 决策的完整指南

如果你搜索“what is Jev Model”或“Jev Model 是什么”，最有用的简短答案是：Jev Model 是一个面向软件决策的概率型 AI 模型。你把一段状态（例如客服工单、智能体上下文或结构化记录）发送给它，再提出一个或多个类型化问题。Jev 返回具有明确形状的答案、概率，以及 Choice 和 Score 问题对应的置信度信息，应用程序可以直接把这些结果接入自己的控制流。

这和以聊天为中心的大语言模型不同。传统 LLM 通常用于生成文字、解释、摘要，或者返回一个需要继续解析的灵活 JSON。Jev 更适合处理产品里那些反复出现的小判断：这张工单应该进入哪个队列？一次工具调用是否需要人工批准？请求有多紧急？下一步应该使用哪个已批准的模型？

本文会从产品定位、工作流程、三种问题类型、与 LLM 的协作方式、API 接入和上线评估几个角度解释 Jev Model。如果你想先看官方定义，可以先阅读 Jev Model 官方介绍，再回到本文按步骤理解它的工程用法。

目录

• 一句话理解 Jev Model
• 为什么叫 System One 模型
• Jev Model 如何工作
• 三种 Jev 问题类型
• Jev 应该如何与 LLM 配合
• 一个实际的工单路由示例
• 概率、置信度与安全自动化
• 如何开始使用 Jev Model
• 使用边界与评估清单
• Jev Model 价格与使用方式
• 常见问题

一句话理解 Jev Model

Jev Model 把共享的状态和一组类型化问题，转换为代码可以分支、排序、路由或存储的结构化决策。

这里的 System One 模型，强调的是它和软件之间的交互方式。它不是主要用来在聊天窗口中写一段很长的答案，而是一个面向机器的决策组件：应用先定义允许的答案边界，Jev 在边界内评估当前状态，然后由业务代码决定下一步动作。

这种分离很重要，因为很多生产流程并不需要另一段文字，而是需要一个形状明确的值，例如：

• 在 billing、technical、sales 中选择一个工单队列；
• 按照已经写好的优先级标准返回一个分数；
• 判断“这次工具调用是否需要人工批准”的 yes 概率；
• 从允许列表里选择 fast-model 或 reasoning-model；
• 在继续执行、请求澄清和人工升级之间选择路径。

Jev 不会替代你的队列、权限、业务政策、重试逻辑和审计日志。它提供的是一个可以被这些确定性系统使用的判断信号。

为什么叫 System One 模型

最有价值的对比并不是“Jev 是否要替代所有 LLM”，而是开放式生成和有边界的软件决策之间的区别。

以聊天为中心的 LLM 优化的是语言能力：它可以写作、总结、解释、头脑风暴，也可以面对陌生问题展开推理。它的输出本来就应该灵活，这对人类阅读很有价值。但当软件需要消费结果时，灵活性也会带来额外工作：解析文本、校验 schema、处理多余内容、判断它是否真的回答了预期问题，以及应对输出格式变化。

System One 模型从更窄的契约开始。你提供 state，并用少数几种问题类型定义需要的判断。输出会尽量贴近这个契约，同时提供可以影响下一步分支的概率信号。

关注点	以聊天为中心的 LLM	Jev Model
主要任务	生成语言或进行开放式推理	为软件做有边界的决策
输入方式	Prompt 加上下文	State 加类型化问题
输出方式	文本或灵活结构化内容	Choice、Score 或 Noul 答案
一次多个判断	常常需要串联或从一段回复中解析	多个问题可对同一 state 并行评估
不确定性	通常需要另外设计方法	结果包含概率；Choice 和 Score 还包含置信度
最终动作	容易和回答混在一起	保留在应用程序代码中

因此，Jev 更适合作为系统内部的一层，而不是所有模型的替代品。LLM 可以负责写回复，Jev 可以判断请求是否属于账单问题、草稿是否需要复核，或者某次工具调用是否超出了允许范围。

Jev Model 如何工作

Jev 的核心流程可以拆成四步：准备状态、定义问题、读取类型化结果、让应用程序执行动作。

1. 准备 state

State 是一次请求中所有问题共同读取的上下文。它可以是普通字符串、JSON 对象，或者文本数组。简单工单使用字符串即可；当判断依赖客户等级、订单状态、政策版本和最新消息等多个字段时，JSON 对象更合适。

好的 state 应该足以支持判断，同时尽量小，不要默认把整行数据库记录全部发送出去。只放入人工审核时真正需要的事实。如果字段中包含密钥、个人信息或不必要的内部数据，应当先删除或最小化。

目前的输入边界也需要注意：Jev Model 支持文本、JSON 对象和文本数组，但暂时不直接支持图片、音频和视频作为 state。如果流程从截图或录音开始，可以先使用合适的预处理步骤，把内容转换为文本或结构化事实，再交给 Jev 判断。

2. 定义小而明确的类型化问题

每个问题应该只代表一个判断。“请分析这个客户并决定所有事情”太宽泛，因为它把意图、紧急程度、情绪、欺诈风险和动作建议混在了一句话里。更好的方式是拆分维度，让每个问题都有清楚的标准，而且可以独立评估。

多个问题可以在一次请求中读取同一个 state。例如，一张工单可以同时得到意图分类、紧急程度评分和是否需要人工处理的判断。问题负责产生独立信号，业务代码负责在之后组合这些结果。

3. 读取结构化响应

响应会使用请求中相同的问题 ID。Choice 返回选中的选项、所有候选项的概率和置信度。Score 返回按概率加权的分数、各级别的 legend、每个级别的概率和置信度。Noul 返回 0 到 1 之间的数值，代表一个是/否陈述为真的概率；它不额外返回单独的 confidence 字段。

类型化结果可以减少解析歧义，但应用边界仍然应该校验 HTTP 状态、响应结构和允许值。任何模型结果都不应该绕过防御式编程。

4. 让代码执行动作

Jev 回答问题，系统负责执行动作。结果可以调用 route_ticket()、加入队列、阻止工具、请求确认，或者把 state 交给一个更强的推理模型。权限检查、不可逆操作、速率限制和审计日志都应该留在模型之外。

这也是生产设计中最重要的原则：可以让模型判断，但不要把控制平面也交给模型。

三种 Jev 问题类型

三个原语都很简单，但选择正确的类型会让输出更容易测试，也让业务政策更容易调整。

Choice：从允许的集合中选择

当答案必须是一个已知选项时，使用 Choice。常见场景包括：

• 把客服工单分给 billing、technical、account 或 sales；
• 从已批准的模型列表中选择快速模型或推理模型；
• 把文档归入一组固定的内容分类；
• 选择工作流的下一条分支。

要为每个选项写出清楚的 criteria，说明它具体代表什么。如果现实中可能出现“没有任何选项合适”的情况，可以加入 other、unknown 或 needs_review，不要强迫模型选择一个错误分类。返回的概率分布也能帮助你发现两个选项是否非常接近。

Score：按照有序标准进行评分

当需要表达低、中、高这样的连续层级时，使用 Score。它适合紧急程度、风险、质量、满意度或运营影响。请按顺序定义等级，并写出具体边界。只写“高”并不是好的标准；“面向客户的生产故障，需要在一小时内处理”才是更容易复核的描述。

Score 是按概率加权的，因此结果可以落在两个等级之间。这对队列排序有帮助，但不要把排序信号直接等同于业务政策。最终由代码决定什么分数触发升级、哪些例外需要人工处理。

Noul：判断一个陈述是否为真

当问题是一个聚焦的“是/否”判断时，使用 Noul。例如：

• “这条请求是否明确要求退款？”
• “这次工具调用是否需要人工批准？”
• “这条消息是否描述了生产环境故障？”

Noul 返回陈述为真的概率。它很适合安全检查和升级判断，但陈述必须足够具体。如果一个结论包含多个相互独立的条件，应该提出多个 Noul 问题，然后在代码中组合，而不是把所有条件隐藏在一句话里。

Jev 应该如何与 LLM 配合

Jev 和生成式 LLM 解决的是 AI 工作流中的不同部分，成熟的架构往往会同时使用二者。

当你需要长篇解释、草稿、摘要、新代码或开放式推理时，使用生成式 LLM。当应用需要在生成前后做一个有边界的判断时，使用 Jev：

1. 在生成前路由。 判断请求是否适合快速模型，还是需要更深的推理模型。
2. 保护工具调用。 在删除数据、扣款或修改权限之前，检查意图是否明确、动作是否需要批准。
3. 分流运营队列。 同时分类意图、评分紧急程度，并判断是否需要人工接管。
4. 验证任务是否完成。 根据一组清单判断任务是已完成、需要更多验证，还是仍未完成。
5. 管理长流程上下文。 当智能体压缩会话时，判断哪些工具结果和事实仍然需要保留。

可以把这个组合记成一句话：“Jev 负责判断，代码负责控制，LLM 在需要生成时负责生成。”这样可以让决策边界保持可见，而不是把所有政策都藏在一个越来越长的 prompt 中。

一个实际的工单路由示例

假设客服系统收到如下状态：

{
  "message": "My annual plan was charged twice and I need a refund today.",
  "customer_tier": "business",
  "channel": "email"
}

服务可以基于同一个 state 提出三个问题：

{
  "model": "jev-latest",
  "state": {
    "message": "My annual plan was charged twice and I need a refund today.",
    "customer_tier": "business",
    "channel": "email"
  },
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which approved team should handle this request?",
      "criteria": {
        "billing": "Payments, invoices, duplicate charges, or refunds",
        "technical": "Bugs, outages, or integrations",
        "account": "Login, profile, or workspace access",
        "sales": "Pricing, upgrades, or new accounts"
      }
    },
    "urgency": {
      "type": "score",
      "instructions": "How urgent is this for operations?",
      "criteria": ["Routine", "Needs attention soon", "Time-sensitive"]
    },
    "needs_human": {
      "type": "noul",
      "instructions": "Does this request need a person before any refund action?"
    }
  }
}

应用程序随后可以执行自己的政策：把工单分配给 billing，按照 urgency 排序，并在真正退款前要求人工确认。Jev 不会替客户退款、不修改账户，也不会绕过支付权限。它只给服务提供一个结构化信号，让服务可以更稳定地完成这些动作。

概率、置信度与安全自动化

概率的价值在于：不同请求应该拥有不同程度的自动化。概率不是业务准确率保证。

对于 Choice，概率集中在一个选项上，通常说明候选边界比较清晰；如果分布很平，可能意味着输入模糊、criteria 重叠，或者缺少一个选项。Score 也会返回各个等级的概率。Noul 直接返回 yes 概率。Choice 和 Score 还会根据分布给出 confidence。

建议采用和风险匹配的策略，而不是全产品只用一个阈值：

• 低风险、可撤销： 可以自动完成分类或展示层决策，但要保留修正路径。
• 中等风险： 增加确认、抽样审核，或把模糊案例交给人工复核。
• 高影响、不可逆： 同时使用确定性授权、业务政策、审计日志和人工批准。

阈值属于你的产品。一个只读标签可以容忍比删除、扣款或修改权限更高的不确定性。上线前要在自己的标注数据上评估，并同时关注误报和漏报。

如何开始使用 Jev Model

最快的方式是先验证一个判断，而不是一开始就设计整套自治工作流。打开 Jev Model Playground，输入一个真实但低风险的 state，先定义一两个问题，再观察结构化结果是否真的有用。

当这个判断已经有价值后，按照 Jev Model 开发者文档 创建 API key，并从服务端连接接口。最小 REST 请求可以是：

curl -X POST https://jevmodel.net/v1/systemone \
  -H "Authorization: Bearer $JEV_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-latest",
    "state": "Three deploys failed and production is returning 500s.",
    "questions": {
      "needs_human": {
        "type": "noul",
        "instructions": "Should this be escalated to a person now?"
      }
    }
  }'

API key 应该放在服务端环境变量中，不要写进浏览器代码、Markdown 示例中的真实值或 Git 仓库。上线前还应加入输入最小化、超时和重试、响应校验、避免记录敏感 state 的日志策略，以及对 429 或暂时过载响应的备用路径。如果需要复盘决策，还应该记录问题定义版本和模型版本。

使用边界与评估清单

Jev 是一个聚焦的决策组件，并不适合所有任务。当你需要长篇叙事、开放式头脑风暴、直接理解原始媒体，或者无法提前描述答案空间时，Jev 不是首选。那部分工作可以交给生成式或多模态模型；当结果被收敛为一个有边界的判断后，再用 Jev 做路由或校验。

上线前建议检查：

1. 标注质量： 人工审核者是否能对正确答案和评分标准达成一致？
2. 边界案例： 没有选项合适或两个选项非常接近时会发生什么？
3. 语言覆盖： 中文、英文、行业术语和用户真实表达下的表现是否稳定？
4. 风险控制： 哪些动作可撤销，哪些动作必须经过确定性校验或人工批准？
5. 运营指标： 在目标并发量下，延迟、限流、重试和 fallback 的行为是什么？
6. 可观测性： 能否在不暴露隐私的前提下查看 state 版本、问题版本、结果、阈值和最终动作？

最好的第一个用例通常很小、可衡量：减少人工工单分流，阻止一次不安全的工具调用，或者只把真正困难的请求交给成本更高的推理模型。

Jev Model 价格与使用方式

公开方案目前包括 Starter、Pro 和 Enterprise，不同方案在使用时长、工作区数量、并发限制和支持方式上有所区别。产品页面将 Starter 定位为验证一个真实工作流，Pro 定位为接入生产产品，Enterprise 面向多工作区、团队协作和定制化生产集成；购买的访问周期内包含不限量使用。

价格和权益可能调整，因此在做预算或发布对比文章前，应查看 Jev Model 当前价格页面。成本评估不要只看方案名称，还要估算决策次数、一次请求中的问题数量、输入大小、重试比例，以及最终仍需要人工复核的案例比例。

常见问题

Jev Model 是聊天机器人吗？

不是。Jev Model 的设计目标是让软件消费类型化决策。它可以成为聊天机器人或智能体的一部分，但通常负责分类、评分、安全检查、路由和验证，而不是直接写出最终的对话回复。

Jev Model 和大语言模型是同一种东西吗？

它同样是 AI 模型，但交互方式和目标工作不同。LLM 擅长开放式语言和推理；Jev 面向有边界的判断，并且输出形状提前定义。一个产品完全可以同时使用两者。

System One 在这里是什么意思？

它指一种面向机器的模型模式：输入是 state 加类型化问题，输出是结构化判断和概率信号。这个名字强调的是软件消费，而不是以聊天为中心的交互。

Choice、Score 和 Noul 有什么区别？

需要从集合里选择一个答案时使用 Choice；需要按有序标准评分时使用 Score；需要判断一个具体陈述是否为真时使用 Noul。Choice 和 Score 会返回概率分布与置信度，Noul 返回 yes 概率。

Jev 可以替代我的 LLM 吗？

通常不能，也没有必要。生成、摘要和开放式推理仍然应该交给适合的 LLM；Jev 用来处理这些能力周围的控制判断，例如模型路由、工具调用检查、队列分流和任务完成验证。

概率很高，就代表答案一定正确吗？

不代表。概率和置信度是帮助系统决定自动化程度的控制信号，不是业务准确率保证。应该使用真实数据评估，在不同风险等级上设置阈值，并为高影响动作保留人工或确定性备用路径。

第一个用例应该怎么选？

选择一个低风险、答案边界清晰、结果可衡量的判断。先在 Playground 中验证，再从服务端接入 API。第一个工作流越小，越容易观察错误、调整 criteria，并确认它确实减少了重复人工工作。

总结：先让一个小判断变得可靠

那么，Jev Model 是什么？它是一个 System One 模型，把真实业务上下文转换成软件可以直接使用的类型化、带概率的决策。它的价值不在于再生成一段文字，而在于把智能体和工作流中原本隐藏的小判断显式化，让这些判断可观察、可评估，也更容易接入代码。

可以从一个问题开始：工单应该去哪儿、紧急程度是多少、工具调用是否安全，或者当前任务应该交给哪个已批准模型。定义答案边界，发送最小必要 state，检查概率与置信度，并把最终动作留在应用程序中。这样使用 Jev Model，它就会成为一个帮助 AI 系统更可控、更可测量、更容易演进的决策层。

---

研究日期： 2026-09-25

主要来源： Jev Model 官方网站与开发者文档。