一、引言
前段时间Jev挺火。我一开始也以为它是又一个新模型，实践之后才发现它的与众不同！它是一个可以在AI工作流中，工程化地实现轻量决策层的工具，帮助流程降本提效！
我实践的工作流场景来自测试域，其中有不少任务，它们最终只需要一个明确的分类或选择，例如用例打标、UI用例执行时的操作选择，以及检索结果筛选。这些任务，虽然同样可以由通用大模型完成，但在高频执行时，响应时间、调用成本和输出处理都会影响整体效率。
因此，我选取了三个日常测试场景，在AI Testing平台上实践Jev的接入方式和实际落地，结果超出预期的满意！
本文记录了我的操作过程、运行数据和实现示例，相关平台链接、技能包、参考框架及脚本也一并列出，便于大家参考和引发新思路。
二、快速认识Jev
Jev和普通大模型的区别
为了直观理解输出方式的区别，我先用一个简单问题作对比：蝙蝠是鸟类吗？ 下面分别是通用大模型和Jev的回答：
通用大模型：回答格式默认不受控
示例回答：生成式模型会自由发挥，展开说明
Jev：回答结构化的判断结果
示例判断：回答是固定的标准结构，干脆利落
从这两张图中，我首先注意到的是输出形式的差异：通用大模型给出结论后，会继续解释分类依据；Jev则从预先定义的「属于／不属于」中返回判断及相应分值。这组示例用于说明输出形态，不构成同条件下的性能或准确率评测。我将输入、输出、耗时和价格整理在下表中，便于进一步比较：
Jev是什么？
通过这组对比，我对Jev的定位有了更具体的理解：面向答案范围明确的选择和判断任务，以较低延迟和成本返回结构化结果。
使用时，我需要先提供待判断内容、问题和候选答案，由Jev结合语义返回结果。预先定义答案范围，也让后续脚本能够直接处理输出，继续执行流程。
这里我会特别区分模型分值和实际正确率。「置信度 100%」只是当次输出的分值，不代表模型必然正确，也不等于经过校准的真实正确率。是否自动采纳，我会结合任务风险、人工标注样本和独立验证结果来确定。
Jev的适用场景
在需求分析、方案设计和代码编写中，我通常需要通用大模型展开推理和生成内容。但在工作流的一些环节，需求要简单得多：判断用例类别、识别内容相关性，或从候选动作中选择下一步。通用大模型也能完成这些任务，并可通过提示词和结构化输出约束结果；不过，当调用频率较高时，生成及结果处理带来的耗时和开销仍值得单独评估。
对这类环节，我更关注两点：能否正确理解上下文，以及能否在明确的答案范围内稳定返回结果。输出可以直接被代码使用，也有助于减少后续解析工作。
基于这个需求，我将Jev的接入范围限定为：在脚本中处理边界明确的小型判断任务，并依据结果驱动后续操作。这样的分工是否有效，还需要在实际任务中验证。接下来，我重点观察接入后的耗时、费用和结果处理方式。
Jev发布后，X上晒作品的帖子多到有人专门做了个Jev社区实践聚合页。截至9月23日，它从113,386条帖子里收录了5,721个作品，来自4,424位作者。
结合这些实践，我整理了几个与日常业务较接近的应用方向：
-
意图识别和Agent调度
-
Hook（安全审查、幻觉评判、完成治理）
-
大量数据分拣、打标、过滤
-
快速决策
-
品种排名
-
趋势预测
-
代码审查
本次我选择了用例打标、UI自动化和检索过滤三个场景，在AI Testing平台上分别验证。以下介绍每个场景的实现过程和运行结果。
三、场景一：用例打标——批量任务高速执行
场景和思路
我首先选择了用例打标。测试用例生成后，通常还需要标注优先级、识别是否涉及资损，后续才能按标签筛选执行范围。这类任务的判断边界相对明确，也适合观察批量处理的效率。
本次我使用Python脚本并发处理300条测试用例，将优先级标为P1、P2、P3，并为涉及资损的用例添加「资损」标签。
随后，通过Python读取用例，并发调Jev API完成打标。脚本也可以由AI辅助编写：在AI Testing平台的技能市场拉取ep-aitesting-jev后，AI可以参考技能说明完成接口接入：
执行脚本后，可以看到Jev并发处理用例的过程：
成果验证
本次运行在数秒内生成了打标结果文件：
结果中包含「疑似资损-待复核」标签，这是我在脚本中设置采纳阈值后的处理结果。未达到阈值的判断会保留给人工复核，Jev返回的概率和置信度则作为分流依据之一。
为评估这次接入的收益，我对比了两套方案处理同一批300条用例的耗时和费用：
本次DeepSeek方案耗时4分5秒，Jev方案耗时5秒，前者约为后者的49倍；费用分别约为0.31元和0.01元，后者约比前者节省31倍。这组结果表明，在本次用例打标任务中，Jev方案减少了整体耗时和调用费用。费用显示值经过取整，比例仅供参考；对比范围是两套脚本方案的整体运行结果。
这里需要补充请求方式的差异：DeepSeek方案将多条用例合并为一次请求，因此共发起42次请求；本次Jev方案采用每条用例一次请求，共300次。Jev也支持在一次请求中包含多个判断项：将用例及编号放入state，在questions中定义对应问题。是否合并请求，我会结合输入长度、并发限制和实测效果决定。这组对比应结合两套方案各自的请求方式理解。
四、场景二：UI 自动化——UI用例加速执行
场景和思路
第二个场景是交互式UI自动化。使用Playwright等工具时，模型需要结合当前页面和用例步骤定位目标元素，再由浏览器工具执行操作。相比随页面变化调整固定脚本，交互式方案尝试根据当前页面状态选择下一步动作。
我关注的是逐步判断所带来的累积开销：操作步骤增加后，每一步的模型响应都会影响整体耗时。因此，我尝试让浏览器工具先收集可见控件和必要文本，再由Jev根据测试步骤从有限候选中选择操作目标。
实操过程
在实现上，我参考了公开的npm包easy-jev-e2e。它根据文本用例，借助Jev选择下一步要操作的页面元素。使用者主要维护文本步骤，由框架处理具体执行。
参考这一思路，我在AI Testing平台上选择了一个典型场景：输入账号和密码，验证网站登录结果。
从中间结果可以看到，Jev根据文本用例步骤和当前页面状态选择下一步动作，再由浏览器工具执行：
作为对照，我将同一个登录案例交给另一个子Agent，使用通用大模型完成传统的交互式UI测试：
成果验证
我将两套方案的耗时和费用汇总如下：
本次通用大模型方案耗时90秒，Jev方案耗时7秒，前者约为后者的13倍；费用分别约为0.93 元和0.01元，后者约比前者节省93倍。对这类逐步选择操作目标的任务，这组结果提供了进一步验证的依据。费用显示值经过取整，比例仅供参考；对比范围是两套UI测试方案的整体运行结果。
五、场景三：知识库召回——向量检索高效精排
场景和思路
第三个场景是检索结果过滤。在使用Agent分析需求、补充测试场景时，我通常会先检索历史需求和基线用例，作为分析参考。
本次我查询的是「XXX 业务」。目标是找到实际验证 XXX 业务相关收付汇、支付通道、退款、对账、合规拦截或通道切换的用例。因此，我更关注用例验证的业务链路，而非文本是否包含「XXX 业务」「银行」「支付」等关键词。
向量检索能够召回语义相近的候选，但这些候选未必适用于当前业务目标。为说明我希望过滤的内容，下面列出两个经过脱敏处理的示例；它们不代表本次实测召回的原始数据：
-
绑定支持的境内银行卡后，完成商城人民币支付，验证支付成功并生成订单。 这条用例同时包含「银行」和「支付」，但验证的是境内支付收单，既不涉及目标业务银行，也不涉及跨境链路，和目标业务相差很远。
-
打开目标业务银行汇率展示页，切换币种，验证汇率和银行名称显示正确。 这条用例甚至出现了「目标业务银行」，但实际验证的是页面展示，没有验证跨境支付交易；业务名称和机构名称吻合，仍不能说明业务相关。
如果将这些候选直接交给Agent，无关的支付流程和展示校验也会进入上下文。我希望在这一阶段减少噪音，避免后续分析引用不适用的材料，同时让真正相关的业务约束更容易被关注。
因此，我在向量召回之后增加了一步判断：由Jev评估业务相关性和内容质量，再由脚本筛选分流。 具体使用noul判断验证对象是否直接相关，使用choice区分业务主题，使用score判断场景、操作对象和预期结果是否完整。这样可以分别处理业务不符和内容待补全两类情况。
我将最终输出分为三类：业务匹配且质量满足要求的用例交给Agent，不相关候选剔除，相关但内容不完整的候选单独保留待补全。
实操过程
在AI Testing平台上，我通过Python脚本串联这一过程：调用知识库接口召回候选，再调用Jev判断，最后将筛选结果返回给Agent。
在这条链路中，我将Jev放在向量召回之后，承担候选精排判断与质量筛选。
实际链路：向量Top-10召回 →Jev三维判断 → 脚本筛选分流
本次知识库包含16条基线用例。我以「XXX业务」为查询，先执行向量Top-10召回，再由Python脚本逐条请求本地Jev网关，进一步判断候选的验证对象是否属于目标业务。
每次请求中，我将一条用例放入state，并在questions中定义三个判断项，共享同一份用例内容：
-
relevance/noul： 判断「验证对象是否直接属于XXX业务」，返回命题成立的概率，判定依据是核心链路、通道和交易场景，不能只看关键词。
-
topic/choice： 在XXX业务、其他跨境支付、境内支付收单、非支付域四个互斥主题中选择最准确的一项，并返回候选概率分布与置信度，区分业务边界。
-
quality/score： 围绕场景、操作对象、预期结果三要素，使用「要素缺失或表述含糊/基本完整但细节不足/三要素完备可直接执行」的有序量表判断内容质量。
我用这三个维度分别判断「是否相关」「属于哪类业务」「能否直接使用」。下面第一张图中，relevance为98%，topic归为目标主题的概率为100%，但quality的「基本完整但细节不足」档位概率为84%。这个结果也说明了单独评估质量的必要性：业务相关，并不意味着用例内容已经完整。
Python示例：直连Jev API完成三维判断
下面是用于三维判断的Python示例。示例从已有向量检索结果文件开始，未实现向量召回，筛选阈值及排序方式仅用于演示。脚本读取data.answers 中的noul、choice、score。运行前需将JEV_URL替换为实际地址，并配置AUTH_TOKEN；如AI Testing会话中直连，可按接入文档改为读取会话自带的ANTHROPIC_AUTH_TOKEN。
import json
import os
from urllib.request import Request, urlopen
JEV_URL = "..."
QUESTIONS = {
"relevance": {
"type": "noul",
"instructions": (
"该用例的验证对象是否直接属于XXX业务？"
"核心链路、通道或交易场景涉及XXX业务的收付汇、"
"跨境通道（含代理行、业务通道、退款、对账、合规拦截、通道切换）才算相关；"
"仅出现XXX业务、银行、支付等词，但验证其他业务，不算相关。"
),
},
"topic": {
"type": "choice",
"instructions": "该用例最准确归属的业务主题是哪个？",
"criteria": {
"target_business": "XXX业务（通道、收付汇、退款、对账、合规、切换）",
"other_crossborder": "其他跨境支付（非目标业务的其他通道）",
"domestic_payment": "境内支付收单",
"non_payment": "非支付域（汇率展示、开户、物流、登录、营销等）",
},
},
"quality": {
"type": "score",
"instructions": "作为基线测试用例，场景、操作对象、预期结果三要素是否完备清晰？",
"criteria": ["要素缺失或表述含糊", "基本完整但细节不足", "三要素完备可直接执行"],
},
}
def judge_case(case):
payload = {"state": json.dumps(case, ensure_ascii=False), "questions": QUESTIONS}
request = Request(
JEV_URL,
data=json.dumps(payload, ensure_ascii=False).encode("utf-8"),
headers={
"Content-Type": "application/json",
"Authorization": "Bearer " + os.environ["AUTH_TOKEN"],
},
method="POST",
)
with urlopen(request, timeout=30) as response:
body = json.load(response)
# 接口业务错误也可能返回 HTTP 200，必须检查信封内 code。
if body.get("code") != 200:
raise RuntimeError(f"Jev 调用失败：{body.get('code')}{body.get('message')}")
return body["data"]
def refine(candidates):
accepted, review, rejected = [], [], []
total_cost = 0.0
for case in candidates:
data = judge_case(case) # 每条候选一次请求，同时完成三个判断。
answers = data["answers"]
relevance = answers["relevance"]["noul"]
topic = answers["topic"]["choice"]
quality = answers["quality"]["score"]
row = {"case": case, "answers": answers, "trace_id": data.get("u_trace_id")}
total_cost += data.get("usage", {}).get("cost", 0)
# 以下阈值与排序仅为示例，不代表截图中原脚本的实际配置。
if relevance < 0.8or topic != "target_business":
rejected.append(row)
elif quality < 2:
review.append(row)
else:
accepted.append(row)
accepted.sort(key=lambda x: x["answers"]["relevance"]["noul"], reverse=True)
return {"accepted": accepted, "review": review, "rejected": rejected,
"jev_cost": total_cost}
# 在已开启 Jev 的 AI Testing 会话终端运行，复用会话自带 token。
# 输入文件由现有向量检索脚本输出，内容为 Top-10 候选用例的 JSON 数组。
if __name__ == "__main__":
with open("vector_top10.json", encoding="utf-8") as f:
candidates = json.load(f)
print(json.dumps(refine(candidates), ensure_ascii=False, indent=2))
在结果处理上，我保留了可采纳、待补全和剔除三组数据，并记录answers，便于复查概率与档位；响应中若包含u_trace_id，也会一并保存。示例遇到调用错误会停止，避免将接口失败误判为用例不相关。
第二张图展示了本轮产物：kb_baseline_cases.json保存16条基线用例，retrieve_baseline_cases.py执行向量召回与Jev精过滤，result.json保存运行结果。每次判断均通过本地Jev网关实际执行，并附追溯信息。本轮Top-10最终采纳6 条、待补全1条、剔除噪音3条，Jev总成本为$0.000336
成果验证
本轮10条候选经过判断后，最终采纳6条，保留1条待补全，剔除3条噪音。 脚本执行耗时约4 秒，Jev总成本为$0.000336。对这个场景，我更看重的是在数据进入Agent上下文之前，以较低开销完成相关性和质量筛选。
六、结语
完成这三个场景后，我对适用边界有了更明确的认识：它们都可以先定义答案范围，再根据判断结果驱动下一步操作。接入时，我会优先明确输入、选项、采纳条件和兜底路径，再评估Jev是否适合承担这一环节。
结合这些实践，我更容易理解Jev（TypeSafe System One）作为专用结构化决策模型的定位：不生成自然语言，而是返回带概率的判断结果。
后续接入时，我会继续从脚本中边界明确的判断任务开始，分别验证准确性、耗时和费用，再决定是否扩大使用范围。下面整理了相关能力、限制和接入要点，便于查阅。
重点关注的三种判断能力：
-
Noul： 是非判断，返回0~1概率值。
-
Choice： 从预设选项（最多255 个）选一项，附带各选项概率。
-
score： 按自定义有序档位打分，返回评分及各档含义。
评估接入价值时关注的特点：
-
低延迟： 端到端 70–500ms，适合实时路由、拦截。
-
低成本： 输入0.3 元/百万token，输出免费。
-
输出强结构化： 直接返回机器可读结果，省去LLM输出文本后解析、JSON 修复步骤。
-
自带概率置信度： 可配置阈值，低置信自动降级转人工/强LLM。
-
适合高频琐碎判断： 工单分流、内容打标、LLM输出安全校验、Agent动作路由、风险分级。
在选型时考虑的限制： 不能做开放式生成、长程推理、复杂规划，没有记忆，复杂多步任务不能单独靠Jev。依赖清晰的选项/评分定义，prompt要写清楚每个选项语义，定义模糊会明显掉精度。只适合答案空间预先固定的判断场景，不适合答案未知的开放式问题。
在Agent流程中的职责划分： 在Agent流程中，将分析、规划和工具调用交给通用大模型，将边界明确的路由分支、结果校验、风险打分和输入过滤交给Jev。未达到采纳阈值的结果，再由主模型或人工复核。
接入时检查的要点： 把待判断内容作为state传入，同时定义好判断问题与选项描述。选项描述应明确区分，避免歧义。根据返回概率设置采纳、复核与兜底条件，避免直接采信所有结果。适合批量、高频、简单决策；复杂推理任务交给通用LLM。
我的建议是，从一个高频且判断边界明确的环节开始验证。先定义答案范围和判断标准，用一批样本检验准确性与失败路径，同时记录耗时和费用。确认收益及复核机制都符合要求后，再逐步扩大使用范围。这也是我在这三次实践中采用的思路。
往期回顾
1.国产算力·昇腾 910C 大模型推理优化（下）：源码修改与算子优化，提速30%｜得物技术
2.国产算力·昇腾 910C 大模型推理优化（上）：镜像更新与参数调优，提速 40%｜得物技术
3.动态规则的 Agent 实践：用确定性工程驾驭 LLM 的资产智能验收
4.发一张图，它居然"跃"出屏幕了？一文读懂得物 3D 空间图片技术实践
5.别再只卷向量检索了，得物交易搜索如何用“生成式”实现召回范式跃迁?
文 /元思
关注得物技术，每周四更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～
未经得物技术许可严禁转载，否则依法追究法律责任。
