JEV最火的10个使用案例
先说结论
- 在本次可核对的材料里，9 个案例来自官方 Quick start、cookbook 或 demo 页面；第 10 个“成本路由分级”的官方
sde_cascadecookbook 链接没出现在来源清单里，我把它放进了“这次没核实的”，而不是去凑字段。 - 最小可跑通闭环是 Quick start 的工单分派：一次
system_one同时提交Choice、Score、Noul，拿回choice、score、noul后可以直接接路由。 - 三个边界要提前记住：风控必须保留人工复核；重排不能替代召回的 BM25/向量步骤；工具调用门禁不能替代权限校验。
- 凡是“社区在怎么用”的表述，只指认到具体仓库；本文没有任何星数、下载量、搜索热度数据，因为这些数字在本次材料里没有官方或可核来源。
在开始之前，先把字段形状写准确，后面案例都按这个形状理解：choice 问题返回 choice、probabilities、confidence；score 问题返回 score、legend、probabilities、confidence，且问题里的 criteria 是有序数组，从低到高排列；noul 只返回一个 noul 值，范围 0 到 1，没有 confidence 和 probabilities。
证据与过程
1. 工单分派：一次调用拿部门、情绪、紧急度
官方 Quick start 用的是一段 Stripe 的客服工单：
Hi, I've been trying to connect my Stripe account for 3 days and the integration keeps failing. I'm losing sales. Please help ASAP.官方示例把同一个 state 交给三组问题：department 用 Choice，criteria 是 billing/technical/sales；frustration 用 Score，criteria 是有序数组 ["Calm, just stating facts", "Frustrated but civil", "Very angry, strong language"]；is_urgent 用 Noul。代码是：
response = client.system_one(
state=ticket,
questions={
"department": Choice(
instructions="Which team should handle this",
criteria={
"billing": "Payment or subscription issues",
"technical": "Bugs or integration problems",
"sales": "Pricing or account questions",
},
),
"frustration": Score(
instructions="How frustrated the customer appears",
criteria=[
"Calm, just stating facts",
"Frustrated but civil",
"Very angry, strong language",
],
),
"is_urgent": Noul(
instructions="The message conveys urgency or time-sensitivity",
),
},
)
print(response.answers["department"].choice) # "technical"
print(response.answers["frustration"].score) # 1.0
print(response.answers["is_urgent"].noul) # 1.0官方原句是：“Mix Noul, Choice, and Score in one call and see all results at once.”
下游：department.choice 可以直接给工单系统分配队列；frustration.score 可以触发主管优先处理；is_urgent.noul 可以决定是否加急。四栏如下：
- state 放什么：原始工单文本。
- 提什么问题：
Choice部门、Score情绪（criteria 从平静到愤怒）、Noul是否紧急。 - 拿回什么字段：
department.choice、frustration.score、is_urgent.noul。 - 下游怎么用：路由队列、升级人工、设置 SLA 优先级。
官方数据：上面示例返回 "technical"、1.0、1.0，来自 Quick start。
2. 内容风控护栏：用 Noul 概率 + Score 严重度做四路路由
官方 Guardrails cookbook 的做法是，对用户输入和模型输出各跑一次 TypeSafe。它把“不安全”拆成多个可回答的问题，而不是一个笼统问题。
state 放的是消息文本，prompts.txt 存用户消息、replies.txt 存模型回复。提问：四个 Noul 问题分别问“是否试图覆盖助手指令”“是否诉求伤害或犯罪”“是否要求诊断或剂量”“发送者是否可能自伤”；再用一个 Score 问题问“照做可能造成多大伤害”，criteria 从“无伤害”到“严重身体伤害”的有序数组。官方原句是：“A battery of Noul questions hands you the probability that each hazard holds, and a Score question rates how much harm complying would do.”
拿回什么：每个 Noul 返回 0~1 的 noul 值，作为该危害成立的概率；Score 返回 score、legend、probabilities、confidence。下游：代码按概率和严重度把消息分流为放行、送人工、拦截、转支持四类。这是工程上常见的门控写法，不是官方对具体阈值的要求；官方示例中阈值是自己经营的配置。
边界：风控场景必须留下人工复核。官方 cookbook 中样板消息里也有“需要人类看一眼”的类别，不是全自动拦截。
3. 引文核对：用 Choice 判断引文上下文是否支持 claim
官方 citation_check cookbook 针对的是 RAG 或引用型回答：LLM 给每个 claim 一个 source section 和 quote，但有些 quote 是编的，或者上下文相反。
state 放 source document 和待核 citation，citation 有 id、claim、quote、section。提问：一个 Choice 问题，要求判断引文上下文是否支持 claim。官方原句：“One Choice question decides whether the quote’s context supports the claim.”
拿回字段：Choice 返回 choice、probabilities、confidence。官方 cookbook 把结论映射为 verified、unsupported、contradicted、fabricated 四种 verdict，并用 confidence 标记人类需要看哪些。官方示例里 AUTO_ACCEPT = 0.8，低于 0.8 送人工。
下游：对批量引文先做字符串匹配看 quote 是否存在，再对幸存者跑 TypeSafe；低置信度转人工复核。官方数据：8 个引文里，4 个准确引文置信度 0.93 或更高，4 个植入失败全部被捕获。这是官方 cookbook 给的数字。
4. RAG 检索结果重排：Noul 给每个候选打分
官方 Re-ranking cookbook 解决的是“先快速召回，再精排”的第二步。它先用 BM25 从 3565 段法院意见里为 40 个 CLERC 查询各取 30 个候选，然后用 TypeSafe 对每个 query-candidate 对打分。
state 放 query 和候选段落；提问用 Noul，问候选是否是引用的判例。官方伪代码关键部分：
question = Noul(
instructions="Is this candidate the cited case?",
criteria=NoulCriteria(
true="The candidate states the specific rule the query cites.",
false="The candidate is only on a similar topic.",
),
)
response = client.system_one(state={...}, questions={"is_cited_source": question})
response.answers["is_cited_source"].noul # -> 0.87拿回：每个候选一个 noul 值，排序时从高到低。下游：取前 1 或前 10 给上游。官方数据：top-1 准确率从 5% 提高到 18%，top-10 从 38% 提高到 62%。官方原句在页面摘要里直接给出。
边界：这个方案的前提是“先有快速检索的短名单”。重排只在 30 个里面挑最相关，不能替代 BM25、向量召回或混合检索，因为漏掉的候选根本不会进入重排层。
5. 工具调用风险门禁：社区二手来源，字段形状未能核实
工具调用风险门禁这个案例在工单里指向一份第三方 60 例基准报告 webofmike.com/jev-benchmark。它属于社区二手来源，不是 TypeSafe 官方页面。我在本次材料里没有该报告的正文，只拿到链接，因此无法核实它测试的是 60 个什么工具、用了哪种 primitive、返回了哪些字段，也没有可引用的指标。
如果要在这个方向上落地，本文的做法会是：state 放工具调用的函数名、参数、上下文；用 Choice 或 Noul 问“当前调用是否应被许可”；拿回结构化字段后作为风险信号。但这是工程设想，不是官方建议，也不能当作社区报告的结论。边界：无论模型怎么判，都必须保留权限校验、审计日志和干系人确认，门禁只是信号灯，不是权限系统。
6. 技能推荐：两次 TypeSafe 请求，先排名后复核
官方 skill_suggestion cookbook 面对的是一个具体问题：Hermes agent 有 182 个技能，每个技能在 index 里只有 60 字符描述，加载错技能或该加载时乱加载。
state 放 agent 当前 turn 和技能目录 index。提问是两段式：第一个 TypeSafe 请求对所有 182 个技能排名，并判断这个 turn 到底需不需要技能；第二个请求只重读 top 3，带完整 skill 描述和开头指令，允许全部拒绝。官方原句摘要：“Picks at most one skill for an agent turn out of the 182 in Nous Research’s Hermes catalog, using two TypeSafe requests to rank and re-check the top candidates.”
官方数据：对比 table 中，错误加载率从 agent alone 的 16.8% 降到 with TypeSafe suggestion 的 7.3%；“没有合适技能却加载一个”从 9.8% 降到 4.0%。这些是官方 cookbook 自己跑出来的，模型版本为 jev-1.12 和 claude-haiku-4-5-20251001。
拿回字段：官方片段里导入了 Choice、Noul，并出现 GATE_THRESHOLD、FITS_THRESHOLD 两个 Python 常量；但完整返回字段在原页面上没有逐行列出。第一请求的 Noul 返回 0~1 的 noul 值用于门槛判断；第二请求如果使用 Choice，按字段形状规则应返回 choice/probabilities/confidence。这是本文按官方字段规则做的推断，不是 cookbook 页面的原话。下游：winner 技能名被放进一行 <skill_relevance> 系统提示，告诉 agent 先看这个技能，但 agent 仍保留完整 index 和自主判断。
7. 大数据特征发现：把品酒词变成 CatBoost 特征
官方 autoresearch_feature_discovery cookbook 的场景是葡萄酒评论：输入 tasting note，输出 critic score。要训练 CatBoost，需要数值表。
state 放 tasting note；提问由 autoresearch 循环自动提出：有 29 个 Score 问题、9 个 Noul 问题。官方原文摘要：“Runs an autoresearch loop that proposes TypeSafe questions, converts free text into numeric features, and uses model errors to improve a supervised CatBoost regressor.”
拿回字段与后续构造：一个 Score 答案变成两列——“expected rubric level + answer uncertainty”，即官方片段写的 29 score questions x 2 columns = 58；一个 Noul 答案变成一个概率列 9 noul questions x 1 column = 9。67 列进 CatBoost。官方数据：held-out RMSE 1.77 points。与 baseline 对比：预测训练集平均分 3.09，词袋特征 2.47，直接请 TypeSafe 给分重标定后 2.15，单轮 18 个提问 1.87，循环五轮 38 个提问 1.77。这是官方 cookbook 给的表格数据。
下游：把任何自由文本转成结构化特征表，喂给监督模型；循环根据模型错误再提出新问题，适合有 label 的文本语料。
8. 智能家居指令判定：speculative fan-out 让无关问题错着问
官方 Smart home demo 演示了“投机式扇出”。state 放用户请求，比如 “Turn off all of the lights in the house”。提问：一次 TypeSafe request 问很多假设性问题——类别、作用域、设备类型、动作，甚至“这个请求是否包含多个动作”。官方原句：“This is what we call a ‘speculative question’ – we ask it before we even know if it’s relevant, allowing us to evaluate all questions in parallel and rely on code to filter out the irrelevant results after the fact.”
拿回字段：官方 demo 页面没有给出每个问题的字段名，只说明 TypeSafe 先给出结构化答案；其中“是否多个动作”是 Noul 问题。按 Quick start 的 Noul 形状，应该只返回一个 noul。所以这里只写到这个粒度，不补造 choice/score 具体字段。下游：如果 noul 显示是复合请求，就调 LLM 把请求拆成原子命令再逐条评估；如果 TypeSafe 判断只是闲聊，就回退给对话式 LLM。
9. Twitch 直播聊天过滤：社区 Chrome 扩展，非官方
jev-chat-for-twitch 是社区项目，不是 TypeSafe 官方产品。README 原句：“A Chrome extension that adds a second chat column showing only the Twitch messages worth reading.”
state 放当前聊天消息和最近 12 条上下文，连同频道名和页面标题。提问：判断消息属于哪个意图——Helpful、Questions、Funny、Feedback 或 Everything meaningful。拿回：仓库说点击单行可以查看 full probability distribution、category 和 model id；但 TypeSafe 具体字段名没有在 README 里展开。下游：右侧栏只显示符合意图的真实聊天消息，不重写、不生成。
成本部分是仓库作者自测的估算，不是官方数据，也不等于你的账单。我把它标注为社区二手估算：jev-1.13.0 在 2026-09-19 一次 20 条消息批量用了 10,075 input tokens，约 504 tokens/条；2 msg/s 时约 $0.15/小时。注意该项目目前只有 Chrome 开发者模式安装，不属官方发布渠道。
10. 成本路由分级：官方 sde_cascade 页面缺失，放未核实区
这份工单要求覆盖“成本路由分级（官方 sde_cascade cookbook）”，但待核来源里没有给到 sde_cascade 的 URL，而规则又不允许我编一个链接。所以本文不写它的 state、问题、返回字段和指标，统一放进“这次没核实的”。如果读者手上有官方 sde_cascade 页面，应该以页面源码为准，不要看二手转述。
自己的判断 / 落地清单
我的判断是：这组案例的价值不在“哪个最火”，而在两种可复用结构：一次调用混合 primitive 拿多个字段；把多个 Noul 概率和 Score 严重度聚合成一个策略。
落地时我建议按这个顺序来：
- 先跑 Quick start 的工单分派，把
choice/score/noul三个返回字段弄熟。 - 风控、引文核对、重排三个 cookbook 都带
json_cache.json，可以离线复现官方数字；先复现，再换自己的数据。 - 涉及工具调用和权限的，先把权限校验做硬隔离，TypeSafe 结果只能作为额外风险分数。
- 社区 Twitch 项目可以作为低风险观察样本，但不适合直接上生产，因为它不是官方维护。
这次没核实的
- “成本路由分级（官方 sde_cascade cookbook）”的页面 URL、state、问题、字段和指标未能核实；本次链接清单里没有它。
- 工具调用风险门禁的第三方 60 例基准，本文只拿到社区链接，没有正文，指标和字段形状未能核实。
- 智能家居 demo 的完整 TypeSafe 字段组合，官方页面未列出；本文只按官方 Quick start 的
Noul形状做了最小推断。 - 技能推荐 cookbook 里第二请求具体用
Choice还是Noul的完整返回字段，原页片段未完全展示；我没有补写完整字段。
参考来源
评论区
登录后可评论。