Jev 可以用来做什么？

选模型前，先找出需要作出的决策

适合起步的任务，应有范围明确的问题、足够作答的证据，以及清楚的下一步。对客户消息而言，这些可能是客户需要的服务、相关账户记录和建议进入的队列；对文档而言，则可能是读者的查询、文档文本和待查看的位置。

这里的工作流，除非明确标注为官方示例或社区报告，否则均为设计建议。本站已进行实时调用以检查网站功能，但未独立复现第三方案例，也未发布质量或性能基准评测。演示能运行或某次模型返回了结果，不能证明这些应用的准确率。

社区案例：开发者如何使用 Jev

这些公开分享展示了开发者实际测试过的具体判断任务。每个摘要都链接到作者原文；收录不代表 TypeSafe 或案例团队为本站背书。

去官方 Playground 尝试写作检查

原创虚构教学示例，不包含模型运行结果。 这是受写作审阅场景启发的独立练习，不是 Every 的提示词或对其实验的复现。Orbit Notes 是虚构产品。输入和问题在各语言页面中保留相同英文，方便复制。

前往官方 Playground

此链接打开 TypeSafe 的外部页面。需要使用自己的账号登录并具备相应访问权限；加入 waitlist 本身不代表已获准使用。

1. 将下方示例粘贴到 state 输入区。

2. 按下方名称和说明添加 3 个 Noul 问题。官方快速入门介绍了如何填写 state 和问题。

3. 在官方 Playground 运行请求。结合每个问题阅读返回的概率，再按需要修改示例、重新运行。

虚构输入

Orbit Notes saves your drafts locally.
Your drafts are stored on your device.
Click Export to download a copy.

待填写的问题

repetition (Noul)
Does the text repeat a claim without adding new information?

clear_action (Noul)
Does the text explain what happens when the reader clicks Export?

guaranteed_safety (Noul)
Does the text claim that a draft can never be lost?

检查前两句是否提供了不同信息、Export 操作的结果是否说明清楚，以及原文是否承诺草稿永远不会丢失。这些问题相互独立，概率不必加起来等于 1。把模型判断作为人工审阅的线索；本练习不提供预期分数或自动决策阈值。

四类角色，四个起点

开发者：检查一项语义规则

可以尝试一条常规 lint 检查难以覆盖的明确约定：某个改动是否新增了面向用户的错误提示，却没有说明如何恢复？提供相关 diff 和规则，让模型返回辅助审核的信号。官方使用场景图谱包含语义代码检查；这里的具体检查项是我们提出的示意性方案。

保留编译器、测试套件和精确的 lint 规则，让审核者查看被标记的代码行，并判断问题是否成立。可以先以建议性评论的形式接入，了解误报成本后，再决定是否把它设为合并条件。这是一种集成建议，不是本站提供的现成 PR 机器人。

客服团队：把归属与紧急程度分开判断

情绪激动的客户可能需要的是账单团队，而非工程团队；语气平静的消息却可能描述紧急故障。分别询问处理去向和时效性，再应用队列规则。下面的工单示例来自官方快速入门。

你的应用仍需检索账户事实、对工单去重，并落实退款或账户变更规则。分类结果不能证实客户报告的故障确实发生了。

搜索与 RAG 团队：先选证据，再写答案

检索增强生成（RAG）把检索到的材料提供给文本生成器。可以评估将 Jev 放在检索与生成之间。TypeSafe 的 RAG 片段实用示例分别检查相关性、可用证据、矛盾和试图发出的指令，再由代码决定纳入、标记还是排除片段。

将来源标识符与判断结果一起保存。相互矛盾的证据可能应该明确提醒读者，而非悄悄删除。要评估筛选器会不会剔除回答某个难题所必需的唯一片段。最终措辞仍由生成器负责；检索与生成两个阶段都不应绕过文档访问权限。

安全团队：安排分析人员的关注顺序

TypeSafe 的防护检查实用示例演示了如何检查传入消息和生成的回复，输出各类风险的概率及有序的严重程度评估，再由代码执行响应策略。

初次集成时，保留现有检测路径，把建议的审核队列与分析人员的决策进行比较。分别追踪漏报事件和不必要的升级处理。模型给出低分，不应因此授予工具权限、关闭现有控制措施，或认定附件无害。参见恶意输入相关限制。

完整示例：在文档中查找答案

1、任务与输入

使用 jev-1.12，搜索实用示例中的 GitHub 服务条款文本：共 218 行，每行带有 ID。实用示例与完整脚本链接了全部输入，并解释了如何重放示例。

2、问题

一次请求提出两个问题：where（Choice，选项为行 ID）和 exists（Noul：文档中是否包含答案？）。

3、已公布的输出摘录

以下是选取的数值，并非完整的 API 响应：

query: who owns the code I upload?
exists: 0.98
L052: 0.95

匹配到的原文行开头为：L052 | You own Your Content.

4、后处理

该实用示例按各行概率排序，并把 ID 关联回原文。其答案存在性规则为：数值至少为 0.7 时标记为有答案，低于 0.35 时标记为无答案，两者之间标记为部分有答案。因此，这个示例指向 L052，并通过答案存在性检查。

5、限制与来源

这些阈值和较早的模型版本属于该示例本身。重放示例不等于获得新的测量结果。它演示的是检索，不是法律解释，也不能证明模型在其他文档上的准确性。原始案例与展示的输出

为什么需要两个信号？

Choice 在给定选项之间分配概率，各项之和为一。因此，领先的选项只是相对胜出，并不能独立保证选项中一定存在合适的答案。TypeSafe 文档规定，Choice 最多支持 255 个选项。Choice 的语义与限制

我们的实现建议是：在结果记录中同时保留位置和答案存在性的判断。不要把排名第一的行直接视为无条件成立的答案。展示原文供检查，明确处理证据缺失或不完整的情况，并保留文档版本，避免后续编辑悄悄改变某个 ID 对应的含义。

调整这一设计时，请把没有答案的文档纳入审核集，也要包含答案跨越多行的情况，以及问题措辞中带有错误前提的情况。这些样例能检验实际需要的检索规则，而不只是判断排名第一的行看起来是否合理。

完整示例：分流客服工单

输入、问题与文档给出的输出

示例中的客户描述了持续三天的 Stripe 连接失败、销售损失，并表示急需帮助。请求询问负责部门、挫败程度和紧急性。此处对客户消息作了转述。

来源：快速入门中的请求与响应。

把结果转成建议

以下是我们编写的解释性代码。阈值是示意性的策略选择，不是经过验证的设置：

function proposeRoute(response) {
  const department = response.answers.department;
  const urgency = response.answers.is_urgent.noul;

  return {
    queue: department.confidence >= 0.7
      ? department.choice
      : "manual-triage",
    priority: urgency >= 0.9 ? "urgent" : "normal",
    suggestedTeam: department.choice,
  };
}

对于文档公布的数值，这个函数建议紧急人工分流，并给出技术支持团队作为建议。概率领先的部门未达到我们选定的置信度阈值。这个示例不会实际分派任何工单。

概率和置信度是不同的字段。TypeSafe 根据分布计算 Choice 和 Score 的置信度；Noul 没有单独的置信度字段。置信度文档

把这类建议接入工单系统前，应校验响应、定义冲突解决方式，并让故障能够被观察到。错误路由与漏掉紧急工单应分别评估。该示例无法确认客户账户的实际状态，也没有解决集成故障。

社区报告：探索钓鱼邮件分流

一位 Discord 参与者在 2026 年 9 月 17 日 14:24–14:27 UTC 介绍了一项早期 Python SDK 实验，希望辅助安全运营，并在之后接入 SOAR 工作流。该参与者称初步结果令人鼓舞，同时观察到结果对评判标准的措辞和详略程度较为敏感。实验介绍、后续观察

这是社区参与者的自述。 它不能证明检测准确率、误报率、速度、节省幅度、确定性行为，或已经完成生产集成。我们没有复现该实验。在所记录的对话中，未观察到经核实的官方回复；研究只覆盖选定的讨论，并非完整的社区历史。链接可能需要社区访问权限。

选定下一步

选择一项结果可检查、审核过程可控的决策。从获取访问权限并发送请求开始，用定价指南为流程制定预算，并在把输出接到自动操作之前，阅读限制说明。