产品与理念
Jev AI Demos:六个 Jev 模型交互演示详解
详解六个 Jev AI 模型演示:航班搜索、Wiki 导航、客服分流、购物车、发票审核与安全告警,并说明如何评估每一步决策。

搜索 Jev AI demos 或 Jev model demos 时,值得关注的不只是模型能否选出一个看似合理的答案,更是能否看清它拿到了什么状态、有哪些候选项、返回了什么,以及外围软件最终执行了哪一步。Jev 演示总览中的六个交互场景,正是围绕这一检查过程设计的。
这些案例涵盖不断变化的航班网站、只能点击链接的百科竞赛、购物车、客服工单分流、应付账款审核和安全告警。网站、工单、价格、发票及事件都属于模拟数据。页面说明演示会调用 Jev 作实时决策;登录后启动场景,可以查看请求和响应。这有助于理解接口,但一个流畅的模拟流程并不能证明同样的策略会在你的真实数据上表现良好。
本文说明每个演示应该观察什么、决策边界在哪里,以及如何把演示变成可衡量的小型评估。场景描述依据 2026 年 9 月 27 日可公开访问的演示页面;本文不声称任何一次具体运行已成功完成任务。
目录
- 快速结论
- 六个演示的共同机制
- 六个 Jev 模型演示一览
- 浏览器操作类演示
- 客服分流 每张工单三个判断
- 发票审核 先查证据再给结论
- 安全告警 先看证据再选响应
- 如何评估一次演示运行
- 从模拟场景走向真实工作流
- 常见问题
快速结论
Jev 演示展示模型如何在软件工作流内做有边界的决策。 在浏览器场景中,页面会随着每次获准执行的动作而变化,Jev 需要从当前可用的控件中选择。在客服、财务和安全场景中,模型判断结构化证据,再由代码决定如何分流或复核。页面提供手动模式和定时自动模式,设有决策面板,启动交互需要登录。如果想逐步查看请求和答案,建议先用手动模式。

六个演示的共同机制
反复出现的流程是观察 → 决策 → 复核 → 执行 → 再观察。模拟界面给出一组控件或记录。Jev 请求描述当前状态,并提出一个范围明确的问题。决策面板展示请求、响应和后续动作。新的页面状态成为下一步的输入。模型返回的答案本身不会点击按钮、退款或隔离设备;外围应用决定是否以及如何应用该答案。
这种分工是最重要的设计启示。模型可以排列下一步控件的优先级,或评估工单的严重程度;普通代码仍负责权限、阈值和状态变更。在明确写着不会真实结账、付款、发送消息或执行安全操作的演示中,这条边界尤其清楚。
Jev 的三种问题类型也解释了这些案例与聊天记录有何不同:
| 问题类型 | 答案形式 | 演示中的用途 |
|---|---|---|
| Choice | 从预先定义的选项中选择,并给出概率 | 选择当前页面动作或客服队列 |
| Score | 在有序等级上评分,并返回分布 | 评估工单严重程度或告警风险 |
| Noul | 估计一个明确命题为真的概率 | 判断案例是否需要人工复核 |
官方开发文档说明,一段状态可以在一次请求中配合多个类型化问题。文档还说明,目前状态输入支持文本、JSON 对象或文本数组,暂不支持直接输入图片、音频和视频。在这些演示中,应用把页面或记录转成可供模型评估的状态。访客看到浏览器式界面,并不意味着模型直接看到了像素。

六个 Jev 模型演示一览
| 演示 | Jev 要做什么 | 值得检查什么 | 重要边界 |
|---|---|---|---|
| 航班搜索 | 在不断变化的航班表单和结果页上选择动作 | 当前控件、目标控件、更新后的搜索状态 | 航班和价格都是样例 |
| Wiki 链接竞赛 | 选择可见文章链接,逐步接近目标主题 | 候选链接、已走路径、下一篇文章 | 虚构百科;禁止搜索及直接访问 URL |
| 客服分流 | 分类问题、评估严重程度、判断是否人工复核 | 三个答案以及分流规则 | 不退款、不回复、不改账户 |
| 购物车 | 找出严格符合购物条件的商品 | 商品比较、购物车内容、停止条件 | 不会真实结账 |
| 发票审核 | 检查关联记录并选择处理方向 | 给出最终分流前打开了哪些证据 | 虚构财务记录;不付款 |
| 安全告警 | 检查证据,判断授权、风险和响应 | 证据是否完整、响应门槛 | 模拟事件;不改变真实设备 |
这些演示呈现的是不同的决策形态,不是模型排行榜。某个浏览器动作在当前页面可能正确,页面变化后就可能错误;某个分类结果可以完全符合输出类型,却仍被分到了错误队列。观看时应把这两种正确性分开。
浏览器操作类演示
三个场景让“观察、决策、执行”的循环变得具体。每个场景都从一个受约束的任务和模拟网站开始。模型从当前页面暴露的控件或链接中选择;应用提供任务中的具体值,并执行获准的动作。逐步检查动作是否确实可用、是否让任务更接近完成,比只看最终画面更有价值。
航班搜索 每次操作后表单都会变化
航班演示提供苏黎世到伦敦、新加坡到东京等路线。默认任务是搜索 2026 年 10 月 20 日一名成人乘坐经济舱从苏黎世到伦敦的单程航班。模拟的 AeroFinder 页面从搜索控件开始,之后可以出现结果。演示将流程标为读取页面、选择动作、复核和执行。页面说明城市与日期值来自任务本身,Jev 负责选择动作及目标控件。
注意,选对字段与凭空生成字段的值是两回事。一条有用的轨迹应展示当前索引化控件、Jev 选择的控件、由任务提供的值,以及变化后的页面状态。如果布局或可用控件变了,下一次判断就应根据新状态作出,不能继续假设固定的点击顺序。示例价格不是实时机票报价,不能用于实际出行计划。
Wiki 链接竞赛 不走搜索捷径
链接竞赛从“Rubber duck”出发,目标是抵达“Machine learning”。搜索和直接输入 URL 都被禁用。模拟的 OpenAtlas 文章只暴露当前页面上的链接,Jev 必须一跳一跳地选择。起始页包含“rubber duck debugging”“waterfowl”和“toy”等链接,分别通往虚构百科图中的不同路线。
这是一个在局部信息下规划的小型实验。每一跳都可以检查:选中的链接是否可见、是否看起来与目标相关、路径是否有所进展。名称看似合理的链接仍可能走进死路。因此,结果取决于模型判断,也取决于模拟网站提供的页面图谱。可见的完整路径,比单一的“成功”标签更有参考价值。
购物车 精确匹配并及时停止
购物演示要求购物车中恰好有一盒 1 升全脂牛奶、一盒 12 枚散养鸡蛋,以及一条低于 4 美元的 600 克全麦面包。Jev 搜索样例商店、比较相似商品并填满购物车。任务明确要求商品齐全后停止,不要结账。
这个场景考察的不只是找到名字相近的商品。容量、品类、数量、价格及是否重复加入购物车都很重要。复核时,应拿每件商品对照完整条件,并确认系统在恰好加入所需三件商品后停止,没有越权进入结账流程。价格和库存都是样例;真正值得检查的是动作轨迹和最终购物车状态。

客服分流 每张工单三个判断
客服分流演示使用三张样例工单。页面说明,每张工单通过一次请求得到三个判断:用 Choice 判定问题类型,用 Score 评估严重程度,用 Noul 给出需要人工复核的概率。访客查看答案后,模拟服务台才按代码中定义的规则分流。
公开的规则十分具体:**严重程度为 critical、人工复核概率不低于 50%,或主题分类置信度低于 55%,就交给人工。**这些数字是演示策略,不是所有业务通用的阈值。第一张样例工单涉及连续重复扣费,以及上月无人回复的账单联系记录。另外两张工单分别是生产 API 报错和常规导出问题。案例之间的差异便于观察三个判断是否真的表达了不同维度,而非把全部问题压成一个模糊标签。
认真观看时,应记录问题类别、完整的严重程度分布、人工复核概率,以及分流代码实际走了哪一支。如果最终队列让人意外,需要判断是模型答案有误,还是解释答案的业务规则有问题。页面明确说明,它不会发送消息、退款或修改账户;模拟结果只是队列分配。

发票审核 先查证据再给结论
发票审核演示提供三类案例:记录一致、已付款、银行信息变更。在虚构的 LedgerFlow 工作台中,Jev 可以先检查发票、采购订单、交付记录、供应商资料和付款历史,再选择处理方向。起始发票显示供应商、采购单编号、条目、总额和经过遮蔽的收款账户。页面还显示五份记录中已有多少份被查看。
这样一来,证据覆盖程度也变得可见。仅凭发票本身作结论,可能漏掉重复付款或收款账户变更。观看时,记录 Jev 接下来打开哪份记录、获得什么新事实、最后的分流能否由综合证据支持。三类案例可以用来对照:记录完全吻合也许可以正常流转,已付款案例应关注重复付款,银行信息变化则应触发不同的复核路径。演示使用虚构记录且不执行付款,不能拿它证明真实支付控制已经可靠。
安全告警 先看证据再选响应
安全演示从陌生的生产环境访问或预发布环境部署活动开始。任务要求检查告警及三个证据面板,再在一次请求中判断授权、风险和下一步响应。可选方向包括关闭告警、交给分析员,或隔离资产并通知值班人员;这些操作都只发生在模拟控制台中。
关键问题是响应是否与已观察到的证据相称。陌生管理员登录后尝试访问生产服务器的凭证库,与预期内的预发布环境部署活动,代表不同状态。观看时,核对实际上打开了哪些证据、类型化答案如何表述,以及最终响应通过了哪一道策略门槛。高风险评分是给代码和人员使用的信号,不等于有权修改生产设备。公开页面明确指出事件是虚构的,设备不会真的被隔离,告警也不会真的关闭。

如何评估一次演示运行
先使用手动模式。页面还提供每三秒推进一步的自动模式,但手动复核能让你在下一动作前读完请求。公开场景需要登录才能启动。每一步保留四类观察:状态、允许的候选项、Jev 答案、实际发生的状态变化。缺少这四项的结果卡片,很容易掩盖错误来源。
不要只看场景最终有没有完成,可以用下面的检查表:
- **状态是否真实:**请求是否包含判断所需的信息,且没有提前使用当时尚未出现的事实?
- **动作是否合法:**选中的控件、链接或处理方向是否确实在可用选项中?
- **条件是否满足:**日期、数量、价格上限及禁止执行的动作是否得到遵守?
- **证据是否充分:**在财务或安全结论前,是否查看了相关记录?
- **不确定性如何处理:**低置信度或高人工复核概率是否按书面规则改变了路径?
- **执行边界是否清楚:**代码是否只执行获准动作,并拦住结账、付款、退款或真实隔离?
- **结果能否复现:**相似状态是否得到相似判断;若走了不同分支,能否审计原因?
一次运行只是产品导览,不是准确率估计。要评估自己的工作流,应收集带标签的案例,纳入模糊及对抗性情况,使用相同的问题定义运行,并将模型判断与真实结果比较。对 Choice,测量分类准确率及混淆类别;对 Score,观察相邻严重等级是否容易混淆;对 Noul,将预测值分组,与实际需要复核的比例比较。还要计算交给人工的比例:一个看似很准确的系统,也可能只是把绝大多数情况都推给了人工。
决策策略也应与模型分开。演示中的 50% 复核阈值便于理解,但适合你的阈值取决于漏掉升级与不必要复核各自的成本。应在留出数据集上设定阈值、记录取舍,并在工作流或客户构成变化后重新调整。如果来源数据不完整,确定性的“缺少证据就转人工”规则可以先于任何概率生效。
从模拟场景走向真实工作流
把演示当作参考模式,而不是上线证明。先选择一个范围很窄的生产决策,例如分配客服队列或判断文档是否需要复核。写清允许的答案、状态字段、每种答案可能触发的动作,以及不确定时的兜底方式。然后参考Jev API 文档,用自己的案例测试状态与类型化问题。把密钥留在服务端,验证响应,让应用代码负责所有副作用。
对于浏览器流程,先暴露一小组经过验证的可用控件,不要让模型凭空编造选择器或执行看不到的动作。对于财务和安全流程,分开“收集证据”与“给出处置”,并要求先具备策略规定的必需记录。对于客服,先从分流或优先级开始,不要一开始就赋予系统联系客户或修改账户的权限。
最后,保留紧凑的审计记录:问题版本、状态引用、可用选项、答案和概率、策略版本、审批状态及执行动作。这样团队才能解释意外结果,并比较系统随时间发生的变化。演示能帮助你理解组成部分;部署则需要实测错误率、明确的复核政策和运营责任人。
常见问题
Jev AI 演示可以免费看吗
公开页面无需运行便可查看场景说明和模拟起始状态。交互运行处显示“Sign in to start”,需要登录。具体账户权限和用量条款应以网站当前信息为准。
演示会控制真实网站或执行真实交易吗
不会。公开页面把航班网站、百科、商店、财务工作台和安全控制台标为模拟环境,并说明不会真实结账、付款、隔离设备或发送客户消息。演示的目的是展示决策和应用控制的状态变化。
Jev 会在这些演示中读取截图吗
Jev 开发文档目前列出的状态输入是文本、JSON 对象与文本数组,并说明暂不支持图片输入。演示可以向访客展示可视化页面,同时由应用向 Jev 提供当前控件和记录的文本或结构化表示。
应该先试哪个 Jev 模型演示
如果想了解一次请求中如何组合 Choice、Score 和 Noul,可以先试客服分流;如果想检查页面变化后的连续动作选择,可以先试航班搜索;如果重点关心系统在建议处理方向前是否收集了足够证据,可以先试发票审核。
什么证据能说明 Jev 适合我的场景
需要来自自身业务的留出案例、清晰的人工参照标签、成文的策略,以及错误、概率校准、人工复核量和被阻止动作的测量。演示轨迹可以解释机制;自己的评估才能判断它是否符合运营要求。
资料说明:场景细节依据 2026 年 9 月 27 日公开可见的 Jev AI 演示页面和开发文档,并参考了 TypeSafe AI 官方快速入门核对模型接口。Jev AI 声明独立运营,与 TypeSafe 没有关联,也不由 TypeSafe 运营或背书;集成任一服务前请核对其凭证、端点及条款。