开发者指南

如何使用 Jev AI 模型：开发者分步指南

了解如何使用 Jev AI 模型完成分类、路由、评分和安全判断，从 State、Typed Questions 到 Playground 与 API 集成，构建可执行的结构化决策。

文 / Jev AI2026年9月22日9 分钟阅读

如何使用 Jev AI 模型：开发者分步指南

如果你正在搜索 how to use jev ai model，可以先记住一个核心概念：Jev 不是用来替代聊天界面的模型，而是用来帮助软件做出结构化判断。你提供一段 State，提出一个或多个 Typed Questions，然后得到带有概率信号的结构化答案。

这使 Jev 适合处理支持工单分类、请求路由、风险评分、工具调用前的安全判断，以及 Agent 中的下一步模型选择。Jev AI 官网将它定位为面向软件团队的决策层。

本文将从第一次实验开始，完整介绍如何准备输入、选择问题类型、调用 API，并把结果安全地接回业务代码。

Jev AI 模型能做什么

传统大语言模型通常被要求生成文本，而 Jev 更关注一个可执行的问题：在当前 State 下，应用下一步应该使用什么结构化决策？

一次 Jev 交互包含三个部分：

State：提供上下文的文本、JSON 对象或文本数组。
Questions：你的应用真正需要回答的判断问题。
Answers：代码可以直接用于分支、排序、路由或人工复核的类型化结果。

例如，一个客服系统可以把工单作为 State，同时询问所属团队、紧急程度以及是否需要人工处理。多个问题可以共享同一份 State 并行评估。

Jev 最适合答案空间清晰的任务。如果你需要开放式解释、创意写作或长篇对话，生成式 LLM 通常更合适。两者也可以协作：让 Jev 先做路由和安全判断，再让 LLM 负责生成内容。

第一步：先选一个结果明确的决策

学习如何使用 Jev AI 时，第一步不是写更长的提示词，而是确定产品需要做出的具体决策。

适合作为第一个实验的问题包括：

这条支持请求应该交给哪个团队？
这个请求是否足够紧急，需要进入优先队列？
这次工具调用是否需要人工批准？
当前问题的严重程度属于哪个等级？
下一步应该选择哪个模型？

不要从“理解这个客户”这种宽泛任务开始。把它改写成“这个工单应该交给哪个已批准的支持团队？”这样的边界问题。问题越窄，越容易用历史数据评估，也越安全地连接到业务逻辑。

第二步：准备 State

State 是每个问题都会读取的上下文。Jev 当前支持三种常用输入形式：

文本 State

对于消息、工单、邮件或短文档，可以直接使用字符串：

{
  "state": "我的付款已经失败三次，明天发工资前需要解决。"
}

JSON 对象 State

当判断依赖多个字段时，使用对象可以让重要上下文保持清晰，而不是把所有内容塞进一段长文本：

{
  "state": {
    "message": "我的付款已经失败三次。",
    "account_age_days": 420,
    "recent_failures": 3,
    "requested_action": "retry payout"
  }
}

文本数组 State

当上下文由多条消息、备注或文档片段组成时，可以使用文本数组。只保留问题真正需要的证据，不要把无关历史记录全部发送给模型。

更小、更相关的 State 更容易调试，也更容易判断哪些信息影响了最终结果。需要注意的是，当前文档支持文本、JSON 对象和文本数组，图片、音频和视频不能直接作为 State 输入。

第三步：选择合适的问题类型

Jev 提供三种核心问题原语。应该根据判断结果的形状来选择，而不是把所有任务都强行改写成是非题。

问题类型	适用场景	典型结果
`Choice`	分类或路由	从预定义选项中选择一个，并返回概率与置信度
`Score`	严重程度、质量或强度	在有序等级上评分，并返回概率与置信度
`Noul`	聚焦的真假判断	返回答案为“是”的 0～1 概率

使用 Choice 做分类

当应用只有有限个目标去向时，使用 Choice。例如，一个工单只能被路由到 billing、technical 或 sales 之一。

使用 Score 表示连续等级

当判断存在低、中、高等有序级别时，使用 Score。等级应该从低到高排列，返回的分数是概率加权后的结果，因此可以落在两个命名等级之间。

使用 Noul 做具体命题判断

对于“这条消息是否表达了紧急需求？”或“这次操作是否应该人工复核？”这类问题，使用 Noul。它返回一个 0～1 的数值，表示命题为真的概率。

同一个请求中可以混合使用 Choice、Score 和 Noul。为每个问题设置稳定的 key，因为响应会使用相同的 key 返回对应答案。

第四步：在 Playground 中验证决策

在创建 API Key 或编写生产代码前，先用真实样例在 Jev AI Playground 中测试问题。

推荐使用下面的验证循环：

输入一条有代表性的 State。
添加一个目标明确的问题。
执行判断，观察答案和概率。
使用典型样例、边界样例和容易混淆的样例重复测试。
如果结果难以解释，就重新调整 instructions 或 criteria。

不要只让一个示例看起来正确。最好准备一小组能够代表真实流量的评估样例，并包含应该暂停、需要补充信息或必须交给人工处理的情况。

第五步：从服务端调用 Jev API

问题验证有效后，在服务端创建 API Key，并调用生产端点：

POST https://thejevai.com/v1/systemone

请求需要使用 Bearer Token，并在 JSON body 中提供 state、model 和 questions。当前 API 文档中的旗舰模型名是 jev-latest。

curl -X POST https://thejevai.com/v1/systemone \
  -H "Authorization: Bearer $JEV_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-latest",
    "state": {
      "message": "My payout has failed three times.",
      "days_waiting": 3
    },
    "questions": {
      "department": {
        "type": "choice",
        "instructions": "Which team should handle this request?",
        "criteria": {
          "billing": "Payments, invoices, refunds, or payouts",
          "technical": "Bugs, outages, or integration failures",
          "sales": "Pricing, upgrades, or new accounts"
        }
      },
      "needs_human": {
        "type": "noul",
        "instructions": "Does this request require human review?"
      }
    }
  }'

把 JEV_API_KEY 放在服务端环境变量中。不要把真实密钥写入浏览器代码、前端 bundle、公开文章或 Git 仓库。

第六步：把结构化响应接回业务代码

响应会根据问题 key 返回对应的 Answer。一个简化的响应如下：

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "billing",
      "probabilities": {
        "billing": 0.94,
        "technical": 0.05,
        "sales": 0.01
      },
      "confidence": 0.92
    },
    "needs_human": {
      "type": "noul",
      "noul": 0.87
    }
  },
  "usage": {
    "input_tokens": 180,
    "output_tokens": 24
  }
}

最终动作仍然应该由应用代码决定：

const department = result.answers.department.choice;
const humanProbability = result.answers.needs_human.noul;

if (humanProbability >= 0.8) {
  await queueForReview(ticket.id);
} else {
  await routeToTeam(ticket.id, department);
}

关键边界是：Jev 返回判断信号，业务代码拥有执行权。不要让模型未经应用层权限检查就删除数据、发起付款、发布内容或调用敏感工具。

如何安全使用概率和置信度

概率和置信度可以用于路由、排序和升级处理，但它们不是业务正确性的保证。应把它们当作帮助系统选择路径的信号。

一个实用策略可以是：

高概率、低风险：自动继续；
概率中等或案例陌生：收集更多上下文；
高风险操作或低置信度：要求人工批准；
输入不支持或格式错误：返回错误，或使用安全兜底。

阈值应该用历史样例进行评估，并在上线后持续观察误报和漏报。适合客服路由的阈值，不一定适合付款、账户访问或破坏性工具调用。

生产环境上线清单

上线 Jev 工作流前，逐项检查：

决策拥有明确的答案空间。
State 包含问题所需证据，没有大量无关数据。
每个问题只有一个清晰目的。
Choice 的 criteria 完整且容易区分。
Score 的等级按从低到高排序。
Noul 的 instructions 描述一个可验证的命题。
API Key 只存放在服务端。
超时、重试和 API 错误都有安全兜底。
概率与置信度阈值经过历史数据测试。
高影响操作仍受应用权限或人工审核控制。
日志记录输入版本、问题版本、结果和最终动作，但不暴露密钥。

当前字段、响应结构、输入边界和错误行为，应以 Jev AI API 文档为准。

使用 Jev AI 的常见问题

Jev AI 是聊天机器人吗？

不是。Jev 面向软件可以直接使用的类型化决策，不是以聊天记录生成器为主要目标。它可以成为更大 AI 产品中的一个决策模块。

一次请求可以问多个问题吗？

可以。多个问题可以共享同一份 State 并行评估。当一个工作流同时需要分类、评分和安全判断时，这种方式很有用。

Jev AI 应该替代我的 LLM 吗？

不一定。用 Jev 处理边界清晰的判断，用生成式模型处理写作、总结和开放式推理。在很多系统里，Jev 负责决定下一步应该调用哪个模型或工具。

可以把图片、音频或视频直接作为 State 吗？

当前 API 文档列出的 State 类型是文本、JSON 对象和文本数组。图片、音频和视频目前不能作为直接输入，应先在应用中完成转换或摘要，再提交给决策问题。

总结

使用 Jev AI 模型最简单的方式，是从一个低风险、答案空间清晰的决策开始：准备最小且有用的 State，定义 Typed Question，用真实样例验证，再把结构化结果接回代码。确认基础链路稳定后，再逐步加入并行问题、概率复核、模型路由和权限控制。

当应用需要可重复的判断和明确的下一步动作时，Jev 的价值最明显。让代码保留最终执行权，让 API Key 留在服务端，并用评估数据决定哪些情况可以自动化、哪些情况必须交给人处理。