火爆全网的 Jev，不聊天、不写代码，测试能拿来干点啥？

本文来源： 未署名（公众号：未署名）
原文链接： https://mp.weixin.qq.com/s/QybogNfbhb5Uv8aw_nh3Ww
发布时间： 2026-09-23 11:35

作者： 未署名　　发布时间： 2026-09-23 11:35

关键词：Jev、TypeSafe、AI 测试、LLM-as-judge、置信度门禁
栏目：AI × 测试落地笔记（15）
字数约 3000 字（正文），含代码表格约 5000 字符 · 阅读约 8 分钟
摘要：AI 时代测试最难的不是判得准，是判不准的时候有地方去

「AI 应用的输出，到底怎么断言？」

assert == 预期 用不了，每次都不一样；
让大模型打分，它先写一段「我认为可以打 8 分，因为……」，
你还得正则去抠那个 8，抠不到就报错。

断言从「判对错」退化成了「猜格式」。

这两天刷屏的 Jev，恰好是从另一个方向捅了这个问题一刀。

📌 「AI × 测试落地笔记」又更新了。前面几篇聊的是怎么让 AI 少写、怎么写得对，
这篇换个方向：AI 自己成了被测对象之后，判定这件事该怎么重构。

一、30 秒说清 Jev 是什么

Jev 是 TypeSafe AI 在 2026 年 9 月 15 日发布的模型，不生成任何文字。

你给它一份 state（要判断的内容），再给一组定义好类型的问题，
它返回带概率的类型化答案，不做解释、不写理由、不寒暄。

问题只有三种（官方叫 primitives，来源：docs.typesafe.ai，截至 2026-09-23）：

原语	问法	返回	上限
Noul	这句话是真的吗？	noul（0–1 的概率）	—
Choice	是这几个里的哪个？	choice + probabilities + confidence	最多 255 个选项
Score	在这个刻度上处于什么位置？	score + legend + probabilities + confidence	2–10 个等级

几个官方口径的关键事实：

定价：输入 $0.042 / 百万 token，输出免费
延迟：官方称端到端 70–500ms
官网标语： 193.6x faster、444.6x cheaper
训练方法： RLCD（面向校准决策的强化学习）
当前版本： jev-1.13.0

创始人 Diogo Almeida 是前 OpenAI 研究员、InstructGPT 论文共同作者。
9 月 21 日取消候补名单，可直接注册，新账号送 $5 额度。

二、测试为什么该关心它？不是因为快

网上写 Jev 的都在算「快多少倍、省多少钱」。

那些数字跟测试关系不大。真正有关系的是这三个变化：

以前用 LLM 当 judge	换成 Jev
输出一段话，你要解析	输出锁在 schema 里，官方称类型错误 0%
只有 pass / fail 二值	每次判断带概率，能设门禁阈值
一次问一个，串行等	一次请求并行问 N 个，延迟几乎不变

第三条尤其值钱。官方原话：所有问题共享同一份 state，
并行、独立评估，多问一个几乎不增加耗时。

翻成测试语言：以前一条 AI 用例要调 4 次大模型、等 4 轮；
现在一次调用判完 4 个维度，每个维度还带一句「我有几成把握」。

测试最缺的从来不是「谁来判」，而是「判完能不能设一条线」。
覆盖率有门禁、失败率有门禁，
唯独 AI 输出的质量判定一直是个二值开关——
过，或者不过，中间地带没人管。

Jev 给的正是那条线。

三、场景 1：AI 应用的输出断言（最直接的用途）

一次请求，把质量拆成 4 个维度同时问：

12345678910111213141516171819202122232425262728293031from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()

result = client.system_one(
    state=f"用户需求：{user_query}\n---\n模型回答：{actual_output}",
    questions={
        "answered": Noul(
            instructions="回答是否正面回应了用户提出的问题？"
        ),
        "hallucinated": Noul(
            instructions="回答中是否出现了需求文档里不存在的承诺或事实？"
        ),
        "tone": Choice(
            instructions="这条回答的语气属于哪一类？",
            criteria={
                "calm": "平和陈述事实",
                "apologetic": "有明确致歉或补偿表示",
                "defensive": "推诿、辩解或把责任推给用户",
            },
        ),
        "severity": Score(
            instructions="若存在问题，严重程度如何？",
            criteria=[
                "无任何影响",
                "体验受损，但存在替代路径",
                "流程阻断，无法继续",
            ],
        ),
    },
)

然后把概率变成门禁：

123456789101112def assert_answer(result):
    # 新版 SDK 把答案按类型分装成三个字典
    if result.nouls["hallucinated"].noul > 0.5:
        return fail("疑似幻觉承诺")
    if result.nouls["answered"].noul < 0.9:
        return fail("未正面回应")
    sev = result.scores["severity"]
    if sev.score >= 2 and sev.confidence > 0.8:
        return fail("阻断级问题")
    if sev.confidence < 0.5:
        return mark_for_human_review()   # 模型自己都说不准，别自动判
    return pass_()

fail / pass_ / mark_for_human_review 是你自己断言框架里的函数，
这里只示意分支怎么走。

最后那条才是这段代码的价值所在。

第四个分支承认了一件事：
模型会拿不准，而「拿不准」应该是一个一等状态，
不是硬塞进 pass 或 fail 里。

⚠️ 但先别急着抄——这段代码里有三种「0 到 1 之间的数字」，
它们不是一个东西，看混了阈值就全错了：

字段	含义	取值	谁有
noul	命题成立的概率	0–1	仅 Noul
confidence	模型对这个判断有多少把握	0–1	Choice / Score，Noul 没有
score	落在刻度的第几级	0 ~ N-1，可带小数	仅 Score

对应到上面那段：noul > 0.5、noul < 0.9 卡的是概率；
confidence > 0.8、< 0.5 卡的是把握；
score >= 2 卡的是等级（3 级刻度里的最高级）。

两个容易踩的点：

官方口径：Noul 不返回 confidence，
所以是非题只能直接卡概率，没有「把握」这一维可调。
score 是概率加权平均，

只有几乎全部概率压在最高级时它才会到 2。
想放宽一档，就写成 >= 1.5。

⚠️ 还有个版本坑：typesafe-sdk 0.7.1（2026-09-21 发布）起，
答案按类型分装进 nouls / choices / scores 三个字典，
上面这段代码用的就是这套。
网上很多教程还在写 result.answers["xxx"]——那是旧形状，
装了新版 SDK 照抄会直接取不到值。

对照一下常见的两种写法：

写法	问题
assert "好" in llm_judge(输出)	二值、无阈值、模型换个措辞就挂
score = llm_judge(输出) 然后 assert score > 7	分数看着客观，其实是模型随口编的，没校准过
上面那段：多维 + 阈值 + 低置信转人工	判据可见、可调、可审计

中间那行最危险——它把一个没校准过的数字当成了真分数，
而团队会因为这个数字长得像数字就信它。

上面这套阈值是我给出的示例，不是官方推荐值。
官方文档里也举了 0.5 和 0.9 两个数，但明确写了
「这些只是例子，不是默认值」，分界线要你在自己的数据上跑出来。

四、场景 2：CI 失败日志的分诊

跑完一轮回归，800 条失败摆在那儿，
其中大概七成是 flaky、环境抖动、数据没清理干净。

人工分诊一上午，分完还经常标准不统一。

这种场景的形状和 Jev 完全对得上：
同一份日志、多个独立的判断维度、量大、允许有中间态。

一次调用把这些全问了：

123456789101112131415161718192021result = client.system_one(
    state=log_excerpt,
    questions={
        "is_flaky": Noul(instructions="这次失败是否由不稳定因素导致，"
                                      "而非代码逻辑错误？"),
        "cause": Choice(
            instructions="失败最可能的原因",
            criteria={
                "env": "环境、网络、依赖服务不可用",
                "data": "测试数据问题，如数据缺失或脏数据",
                "product": "被测代码的真实缺陷",
                "script": "自动化脚本自身的问题",
                "other": "以上都不是",
            },
        ),
        "urgency": Score(
            instructions="需要人工介入的紧迫程度",
            criteria=["可延后处理", "本迭代内处理", "阻塞发布"],
        ),
    },
)

三个判断一次返回，代码按 result.choices["cause"] 路由、
按 result.scores["urgency"].score 排序，
confidence 低于阈值的单独丢进人工队列。

⚠️ 写 Choice 时一定要留一个 other。
模型总得从你给的选项里选一个，
选项覆盖不全时它会硬选，而不是告诉你「都不对」。

社区里有人用 Jev 在 40 秒内对 724 条广告做了 8724 次判断
（来源：PANews 报道的社区 demo，非官方 benchmark，别拿去写汇报）。

五、场景 3：给 AI Agent 加一道护栏

官方列的应用场景里有一条原文就是：
「Score, judge, verify, guardrail, and detect jailbreaks」。

verify 和 guardrail——这就是测试的活。

最实用的接法是在 Agent 执行动作前插一道判断：
这条命令是只读的、可撤销的，还是破坏性的？

阈值按风险分级（0.5 / 0.9 是官方文档示例里的数字，需自行校准）：

置信度	处置	典型动作
> 0.9	自动执行	只读查询、读取文件
0.5 – 0.9	确认后执行	写入、可回滚的修改
< 0.5	转人工	删除、对外发送、资金相关

原则只有一句：判错的代价越高，门槛定得越高。

六、别急着上，这三个坑先记下

1. 校准是群体性质，不保证单次。
官方口径：概率描述的是成组预测的统计行为，
给出 90% 置信的 100 个判断里大约 90 个是对的，
但不代表其中某一条一定对。
所以别把单次 confidence 0.9 当免检证。

2. 「快 193.6 倍、便宜 444.6 倍」是官方自测的上限。
官方博客自己写了这组数字来自他们的 workflow evals，
且「我们预期这些处于真实收益的高位」。
拿它去写技术方案会被挑战。
（下面是我的建议，不是官方说法：）在自己样本上跑一遍再说话。

3. 国内能不能用，得你自己确认。
TypeSafe 的使用条款写明网站核心面向美国境内访客，
截至 2026-09-23 未见中国区运营声明、人民币计费或中文客服。
想先本地验证思路，可以看社区的开源复现
（如 APUS 的 fast-browser-use，MIT 协议，支持本地离线跑）。