Jev 玩家图鉴：380 个玩法里，哪些今天就能抄

0030 秒速览：三句话、第一个动作、以及你手上必须有什么

如果只记三句话

起手动作：读完 60 秒内，你要做的第一件事

如果你在用 Claude Code，把下面这两行复制进终端跑一次——这是厂商官方提供的"技能包"，装完之后你的 AI 助手就知道该怎么调用 Jev 了：

claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

装完，重启 Claude Code（或敲 /reload-plugins），然后把这句话原样丢给它：

Using the TypeSafe skill, explore the project and find opportunities for using
intelligent judgement to stand in for complex parsing or other fragile code.

（这句话的意思是：用 TypeSafe 技能扫一遍这个项目，找出哪些地方本来靠一堆脆弱的手写规则在硬扛、其实该换成"让模型做一次判断"。）

为什么是"先装技能"，而不是"先学怎么调它的接口（API，程序之间约定好的调用方式）"？因为这正是厂商对"我该从哪开始"的官方回答。文档里那页 Jev with coding agents 开篇就把最常见的一个误解堵死了：Jev 不能替换你 AI 助手的底座模型——文档原话是"没有 model: "jev-latest" 这样一个开关，能把你的编程助手变成 Jev 驱动的助手，因为这两个系统解决的是不同的问题"。正确的姿势是：你照常用 AI 助手写代码，让写出来的代码去调用 Jev 做判断。

做这个动作之前，你手上必须有什么

这一栏比上面那一栏重要——它让你在花时间之前就知道这篇对你有没有用。

这两样如果你都没有，那这篇对你现在最大的价值是第 04 节那张玩法地图和第 11 节那些质疑——你至少能判断出，当有人再拿"AI 又有新突破了"来找你时，这件事的分量到底在哪一档。

先给一组数字，后面才谈细节

你的处境 → 该看哪一节

01它到底是什么：一台"只输出判断结果"的机器

先破除三个最容易犯的误解

误解一：它是"小一号的 Claude"。不是。小号大模型依然是"接着往下写字"的机器，只是字少一点、笨一点。Jev 根本不写字——它拿到内容之后，直接输出一个带类型的值（"billing"、"3 分"、"0.999"）。这两件事的区别在下一篇里会反复出现，因为它决定了很多能力它有、很多能力它永远没有。

误解二：它是"用提示词（写给模型的那段指令）让大模型当分类器"换了个牌子。也不完全是。让大模型返回 JSON（一种固定格式的文本，程序能逐字读出来）的做法有三个老问题：它可能格式写错（少个引号、多一句解释）、它说"我有 90% 把握"往往并不准、它按 token 计费所以每个字段名都在烧钱。Jev 把"输出形状"和"把握程度"这两件事变成了模型本身的属性——它只能在你的选项里选，不存在"输出第五个类别"这种失败。

误解三：它是拿开源模型微调出来的。"微调"是指拿一个已经训练好的模型、再用自己的数据接着训它；"LoRA"是一种只训练一小块附加参数、比较省钱的微调做法。官方模型页明确写了："Jev is not fine-tuned or LoRA-adapted with customer data. It is trained with RLCD... and the same weights serve every account."（Jev 不用客户数据做微调或 LoRA 适配，所有账号用同一份权重；RLCD 是它自己的训练方法，"校准决策强化学习"。）也就是说，你不能"训练它懂你的业务"，只能通过每次请求里带的内容和问题来塑造它的判断。

它是什么：一句话定义 + 一个类比

Jev 是 TypeSafe AI 在 2026-09-15 发布的第一个公开的"System One 模型"（System One Model，直译"系统一模型"）。官方定义是：

谁做的、为什么做。Jev 出自 TypeSafe AI，创始人是 Diogo Almeida——按他在公开访谈与中文报道里的自我介绍，他是"RLHF（基于人类反馈的强化学习）的共同发明人"，参与过 GPT-4 和 ChatGPT。他的论点是：大模型已经很会聊天、写作和编程，但真正无人值守、在服务器后台稳定运行的自动化却少得可怜；他把一部分原因归到训练目标本身——"让人类更喜欢这个回答"和"让软件能可靠地消费这个结果"并不是同一件事，所以他另起了一条路。这段背景主要来自本人自述与二手报道，我没有逐一核实其履历细节。

"System One"这个名字借自心理学家卡尼曼在《思考，快与慢》里的双系统说法。这个类比在这里是映射得住的，因为至少三处能一一对上：

这个类比的边界在哪：人的"系统一"包含大量常识和联想，而 Jev 的"直觉"只覆盖它能被你问出来的那些问题；它没有好奇心，也不会主动想到你没问的事。所以"它像系统一"这句话，能用来理解它快在哪，不能用来推断它聪明到什么程度。

一次调用的形状：案卷 + 问题清单 → 答案清单

官方文档把请求写得很直白。下面这段是照抄官方文档里"客服工单"的例子（原生接口的形状）：

{
  "model": "jev-latest",
  "state": "Hi, I've been trying to connect my Stripe account for 3 days and it keeps failing. I'm losing sales. Please help ASAP.",
  "questions": {
    "is_urgent": {
      "type": "noul",
      "instructions": "The message conveys urgency or time-sensitivity"
    }
  }
}

它返回的是（官方只截了这一小段）：

{
  "is_urgent": {
    "type": "noul",
    "noul": 0.999
  }
}

翻译一下："这条消息在传达紧迫感或时间敏感性"这句话为真的概率是 99.9%。你的程序接住这个数字，就可以把它排到队列最前面。

这里有三个值得停下来看的细节，它们决定了它好不好用：

• 输出里没有"文本"这一层。不需要解析、不需要容错、不需要"万一它多写了一句解释怎么办"。这就是厂商说"零幻觉"的真正含义——第 11 节会说明它保证的到底是什么。
• 问题是你编号的，编号不会发给模型。文档特别提醒："Question IDs are for your code. They are not sent to the model. Write the complete question in instructions."（编号只给你的代码用，不会送给模型；所以问题必须完整写在 instructions 里，别指望靠编号省字。）
• 一次请求可以问很多个问题，而且它们是并行的。这不是"多问几个就多等几倍"——文档原话是"每个问题独立评估，增加问题几乎不改变响应时间，也不会产生 context rot（上下文里堆了太多无关内容、模型反而变糊涂）"。第 03 节的"扇出"模式就建立在这条性质上。

它解决什么问题：把"伪选择题"从大模型手里拿回来

你大概见过这类代码逻辑：把一段用户消息塞进一个精心写的提示词，要求大模型"返回 JSON，category 只能是 complaint / question / praise / other 之一"，然后在代码里 JSON.parse、校验字段、处理解析失败。

这套做法的荒谬之处在于：你其实已经知道答案长什么样了（就那四个词之一），却请了一个"按字收费、能写论文"的系统来回答，还得写一堆代码去处理它可能写歪的情况。

Jev 就是把这部分接走：大模型继续负责理解、生成、推理、写代码；Jev 专门负责"该走哪条分支"。官方在模型页里用了一个很好的说法：你在用请求（questions 和 criteria）来塑造它，而不是用权重来训它。

02三种问法，和那根被大多数人忽略的"第二根轴"

Jev 只认三种问题形状（官方叫 primitives，原语——意思是"最基础、不能再拆的操作"）。你必须把你的需求塞进这三种之一，没有第四种。它们可以在一次请求里混着问。

Choice：从你给的选项里挑一个

怎么问：给一串选项，每个选项配一句人话解释它是什么意思。
拿回什么：choice（它选的那个）、probabilities（每个选项各自多少概率，加起来 100%）、confidence（一个 0–1 的数，说明这次选择有多"干脆"）。
数量上限：255 个选项。这条上限有实际后果——官方有个配方就是靠它把"在文档里找答案"变成"一次问 218 行哪一行最相关"。
典型用途：意图分类、工单分派、把请求路由给不同的处理者。

Score：按你给的分级打分

怎么问：给一串有顺序的等级，每一级用一句人话描述（比如"只是难看，不影响功能" → "功能坏了但有替代办法" → "完全卡死，没有绕路"）。
拿回什么：score（分数，可以落在两级之间，比如 1.9）、legend（把等级按序号重述一遍，方便你对号）、probabilities、confidence。
典型用途：严重程度、客户愤怒程度、内容质量、风险等级。

Noul：判断一句陈述是真是假

怎么问：一句是非题，比如"客户是在要求退款吗"。
拿回什么：只有一个 noul，0 到 1 之间的一个数，意思是"这句话为真的概率"。接近 1 是很强的"是"，接近 0 是很强的"否"，靠近 0.5 就是它也不知道。
注意：Noul 不返回 confidence——因为它本身就是个概率，没必要再套一层"我对这个概率有多确定"。
典型用途：退款判定、内容审核、合规守门、某个字段有没有出现。

置信度：被大多数人忽略的那根轴

这是 Jev 设计里最有意思的一处，也是很多"用了但没用好"的根源。你要区分两件事：

官方给的建议是最实用的一条：把置信度切成三段，每段对应一种系统行为。

而"阈值（就是前面说的那道门槛的具体数字）到底设多少"这件事，官方给的原则是：同一个系统里，不同动作的门槛应该不一样，按"做错了有多贵"来定。下面这段是官方文档里的示例代码，我没有改动它的阈值（0.5 / 0.9）：

response = client.system_one(
    state=user_message,
    questions={
        "action": Choice(
            instructions="What is the user trying to do?",
            criteria={
                "check_balance": "View account balance",
                "approve_transfer": "Approve the pending withdrawal request",
                "support": "Get help with an issue",
            },
        ),
    },
)

action = response.answers["action"]
confidence = action.confidence

if confidence < 0.5:
    # 模型是真的不确定，别猜
    route_to_human(user_message)

elif action.choice == "check_balance":
    # 低风险：查余额看错页面，可以撤回
    show_balance(account_id)

elif action.choice == "approve_transfer":
    if confidence > 0.9:
        # 高风险 + 高置信度：要确认，然后执行
        confirm_then_execute(account_id)
    else:
        # 高风险 + 中等置信度：先核实
        ask_user_to_confirm(account_id)

读这段代码的重点不是语法，而是那个不对称：同样是"查余额"和"批准转账"两个动作，"查余额"不需要 0.9 的门槛，"批准转账"需要。这就是"阈值随风险缩放"的操作含义。

一个反直觉的坑：不要指望"同一件事换个问法答案就一致"

这是官方"失效模式"文档里最值得单独拿出来的一条，因为它违反直觉，而且只有真读过文档的人才知道。同一个工单，问"客户是在要求退款吗"（Noul）和问"这是不是退款请求（是/否）"（Choice），答案差得很远：

更极端的是问同一件事和它的否定（"客户是在要求退款吗" / "客户是在要求退款以外的事吗"），两个 Noul 分别给出 0.72 和 0.47——加起来 1.19，不是 1。

官方对此的解释是："不要依赖想象中的结构性不变性。Choice 是在选项之间做相对取舍（到底选哪个），而每个 Noul 都是绝对的，可以所有选项都很低。" 实际后果有两条：第一，别把一个 Noul 上调好的阈值直接搬到 Choice 上；第二，别拿两个独立问题的答案去做加减法校验。

03官方给的四种用法模式：这是"新玩法"的骨架

2026-09-23 我核对时，官方文档的 Patterns 一页已经从发布初期的空白长出了四个成体系的模式。这一节把它们说清，因为社区那 380 个玩法，基本都是这四种的变体——看懂这四种，你就有了自己造第五种的能力。

模式一：推测式扇出（Speculative Fan-Out）——一次把想问的都问了

它在解决什么：传统流程是"先分类，看结果再决定问什么"，于是每次都多一个来回。而 Jev 加问题的成本极低（官方原话：每个问题独立评估，加问题几乎不影响响应时间），所以你可以把"可能用得上"的问题一次性全问了，然后由代码决定忽略哪些。

官方举的例子是客服工单分流：一次请求同时问五件事，其中 bug_severity（缺陷严重程度）只在"这是缺陷报告"时才有意义，refund_requested（是否要求退款）只在"这是账务问题"时才有意义——但全都先问了。

{
  "state": "Hi, I placed an order (#98423) last Thursday and was charged twice. I also can't log in after the site update, and adding Apple Pay would be really helpful. This is getting frustrating.",
  "questions": {
    "category": {
      "type": "choice",
      "instructions": "Determine the broad category of this support ticket",
      "criteria": {
        "bug_report": "The user is reporting something that is broken or producing errors",
        "billing": "Charges, invoices, refunds, subscriptions",
        "feature_request": "The user is requesting new functionality",
        "account": "Login, permissions, profile, security"
      }
    },
    "bug_severity": {
      "type": "score",
      "instructions": "How severe is the reported issue",
      "criteria": [
        "Cosmetic; no impact to functionality",
        "Broken or degraded feature; workaround exists",
        "Blocking issue; no workaround exists"
      ]
    },
    "has_reproducible_steps": {
      "type": "noul",
      "instructions": "The user describes specific steps to reproduce the issue"
    },
    "refund_requested": {
      "type": "noul",
      "instructions": "The user is explicitly asking for a refund or credit"
    },
    "frustration": {
      "type": "score",
      "instructions": "How frustrated the user appears",
      "criteria": ["Calm, matter-of-fact", "Frustrated but civil", "Very angry"]
    }
  }
}

然后决策留在代码里（这是官方反复强调的分工：模型给判断，代码管流程）：

# 官方示例，原文照抄
category = response.answers["category"]
bug_severity = response.answers["bug_severity"]
bug_repro = response.answers["has_reproducible_steps"]
refund = response.answers["refund_requested"]
frustration = response.answers["frustration"]

if category.choice == "bug_report":
    if bug_severity.score > 1.5 and bug_repro.noul > 0.6:
        escalate_to_engineering(ticket_id, severity="high")
    else:
        add_to_bug_backlog(ticket_id)
elif category.choice == "billing":
    if refund.noul > 0.7:
        route_to_billing_with_flag(ticket_id, refund_likely=True)
    else:
        route_to_billing(ticket_id)

# 愤怒程度跟类别无关，都一样有用
if frustration.score > 1.5:
    flag_for_priority_response(ticket_id)

这个模式的实测收益（官方另一个配方给出的数字）：把 13 个问题关于一篇 GDPR 维基百科文章分别问 13 次、和一次性问完，答案完全一样，但合并成一次便宜 12.2 倍、快 10.0 倍。这组数字是官方自报。

模式二：置信度门控路由（Confidence-Gated Routing）——答案告诉你"是什么"，置信度告诉你"该不该动"

这就是 第 02 节那根"第二根轴"的正式名字。官方的说法很精确："Use confidence as a second axis. The answer tells you what; confidence tells you whether to act."（答案告诉你是什么，置信度告诉你要不要行动。）

官方自己点出了它的价值来源："如果一个智能系统不能诚实地表达不确定，这个系统就不可信。" 这句话是理解 Jev 定位的关键——它卖的不是"更准"，而是"知道自己什么时候不准"。

模式三：组合打分（Composite Scoring）——把一个大判断拆成几个小判断

它在解决什么：很多人第一反应是问一个宏大的问题，比如"给这个创业项目打分"。官方明确反对这么做，理由写得很直白："System One 模型在'每个问题只问一件具体、范围明确的事'时表现最好。把每个问题想成一次'直觉判断'——一个非常懂行的人在几秒钟内、在正确上下文下能做出的那种判断。"

官方给的做法是：把"市场大小""技术可行性""差异化"拆成三个独立的 Score 问题，然后在代码里用自己的权重合成总分。好处被官方总结成一句话，我觉得是这份文档里最有工程味的一句：

模式四：意图路由（Intent Routing）——把请求分给三种不同的处理者

官方对它的定义是：分类进来的请求，把每一个路由到"最合适的处理者"——而处理者有三类，不只是模型：

把四个模式串起来看，官方的整体主张其实是一句话：把一段"政策"拆成"模型回答的问题"和"代码执行的规则"两部分。官方评测页上给了一个很好的对照——左边是团队写在文档里的一段报销政策（"每笔报销都要有收据；收据看不清就让员工重新提交；判断这是餐费、差旅还是设备；超过 75 美元的餐费，如果描述和收据明显对不上就要经理签字；其余批准"），右边是同一段政策变成的流程图：哪几句变成了 Noul / Score / Choice 问题，哪几句变成了代码里的 if。

04玩法地图：380 个条目，按"你想干的那件事"归类

这一节是整篇的骨架。社区把"别人拿 Jev 做了什么"整理成了两份可查的清单，我把它们都拉下来数过：

官方列的 30 种意图：这是最好的筛子

Awesome Jev 的数据文件里带了一份"标准意图表"（30 条），它是社区给每个项目打标签用的。我把它们按"你大概想干哪类事"重新分了组，顺手标出我看到的代表项目：

怎么自己挖：一条比翻网页快得多的路

Awesome Jev 提供了机器可读的数据，你可以直接让你的 AI 助手去查：

# 一次性拉下全部 380 条（不到 400KB），然后本地筛
curl -s https://awesomejev.vercel.app/projects.json -o projects.json

每条记录里有两个字段最有用：jev.intents（这个项目在解决哪类意图，带权重）和 github.stars / github.pushedAt（有多热、最后一次更新是什么时候）。选项目的经验法则（也是那份索引自己的建议）：优先挑带"可信说明"的、星更多的、最近还在更新的；并且要留意 riskBulkScaffold 这个标签低于 0.5——按索引维护者的说法，这类条目更像"批量生成的脚手架"，不是有人真在维护的东西。

05装进你的 AI 助手：八类玩法 + 能抄的配置

这是"用例"最密集的一节。社区在 Claude Code / Codex / Pi 这几个编程助手上长出了 52 个专用条目（Awesome Jev 的 "Coding agents" 分类），按玩法可以归成八类。下面每一类我都给出具体仓库名和能复制的安装方式，你不需要看懂代码——把命令交给你的 AI 助手，让它装。

玩法 1：官方技能包——先让助手"知道有 Jev 这回事"

这是所有玩法的前置。装完之后，你的助手就掌握了 Jev 的三类问法和四种模式，你只要用大白话提需求就行。

# Claude Code
claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

# 其它助手（会问你是哪一个）
npx skills add typesafe-ai/skills --skill typesafe-ai

更新与排错（这三条都是官方文档里的原话要点）：更新走 claude plugin marketplace update typesafe-ai 再 claude plugin update typesafe@typesafe-ai，然后重启或敲 /reload-plugins；如果助手不认这个技能，在 Claude Code 里直接敲 /typesafe:typesafe-ai 点名调用；如果助手开始编造请求或响应字段，八成是技能版本旧了，更新一次就好。

玩法 2：MCP 服务器——让 Jev 变成助手的一个"工具"

MCP 全称 Model Context Protocol，可以理解成"给 AI 助手插外设的通用插头"：装上一个 MCP 服务器，助手就多出几个可调用的工具。Jev 的 MCP 服务器是社区做的（最常被引用的是 jkudish/jev-mcp，TypeScript 版），它一次性给你十个判断工具：

官方 README 给的安装方式是这样的（注意包名带作用域，不是旧文里写的 npm install -g jev-mcp）：

# Claude Code：一行注册
claude mcp add jev -- npx -y @jkudish/jev-mcp

# 或者手动注册进配置文件（~/.claude.json 或项目的 .mcp.json）
{
  "mcpServers": {
    "jev": {
      "command": "npx",
      "args": ["-y", "@jkudish/jev-mcp"]
    }
  }
}

它还需要一个 TypeSafe 的 API key（去 console.typesafe.ai/settings/keys 建）。README 里专门给了一段"让助手替你装"的提示词，其中一句很值得学："如果我还没设 key，请一步步引导我设置，但不要让我把 key 贴进对话里。"——这是个好习惯，密钥不该出现在聊天记录里。

装好后怎么用？直接在对话里点名那个工具就行——下面这段是能直接粘的：

// 在 Claude Code 里让 Agent 直接调
用 jev_classify 判断这条 issue 属于 bug 还是 feature，
  labels: [bug, feature, question]

另外两个 MCP 选择：itsmostafa/typesafe-mcp（Go 写的，轻量）和 blakestone-x/jev-mcp（额外提供 match 和 screen）。别同时装多个——工具名会撞车。

玩法 3：上下文压缩——目前 star 最多、争议也最大的一类

问题背景：Claude Code 这类助手跑久了，对话会变得很长，长到快塞不进模型能看的范围（这个范围叫"上下文窗口"）。传统做法是让大模型把旧内容摘要一遍——但摘要是有损的：一个文件路径、一条报错原文、一句约束，可能就在摘要里消失了。

社区里最火的那一版叫 fast-jev-compaction（我数的时候 6400+ star），它的做法和"摘要"完全不同：

安装（这两条命令我逐字核对过仓库 README）：

# 前置：Claude Code 需要在运行环境里打开 function hooks 这个开关
# 在 ~/.claude/settings.json 里加：
# { "env": { "CLAUDE_CODE_ENABLE_FUNCTION_HOOKS": "1", "TYPESAFE_API_KEY": "<你的 key>" } }

claude plugin marketplace add tamaratran/fast-jev-compaction
claude plugin install fast-jev-compaction@fast-jev-compaction

# 重启 Claude Code，或敲 /reload-plugins

它的可调参数（取自 README 的参数表，旧文只写了前两个，这里补全）：

同类还有一批，值得一起看（都来自社区索引，我按思路分组）：winnow（在工具结果进入上下文之前就判断，让窗口填得更慢，而不是事后清理）、jev-pruner（专门裁长的命令行输出，短输出、报错、结构化格式不动）、save-token-jev（同一思路，但适配了 Claude Code、Codex、OpenCode 和原始 API 记录）、yoshi（做成了代理层，且把省下的量测出来而不是只宣称）。

玩法 4：模型路由——把简单的活分给便宜的模型

思路都一样：每一轮任务开始前，让 Jev 判断"这活有多难"，然后决定用哪个模型、思考档位开多高。代表项目：jev-router（把任务分给最便宜的那个 Claude 模型）、jev-codex-router（连"思考深度"和"速度模式"一起选）、jev-gateway（本地网关，只把"下一步该用哪个工具"这个决定交给 Jev，其余照常走你原来的模型）、JevRouter（把模型、子代理、技能、插件工具（MCP，见 05 节）、命令行全放进一个候选池）、agent-router（连用哪个助手都帮你选）、tiershift（策略写在 YAML 里，决定耗时约 180 毫秒）。

LangChain 官方给的做法值得单独看，因为它把路由写成了"中间件"（middleware，指插在模型调用前后的通用钩子），而不是改业务代码：

from langchain.agents import create_agent
from langchain_typesafe.experimental.middleware import (
    ModelChoice,
    ModelRouterMiddleware,
)

router = ModelRouterMiddleware(
    choices={
        "fast": ModelChoice(
            model="openai:luna",
            criteria="Direct lookups, extraction, and localized changes.",
        ),
        "powerful": ModelChoice(
            model="openai:sol",
            criteria="Architecture and high-stakes decisions.",
        ),
    },
    instructions="Choose the least costly model that can complete the task.",
)
agent = create_agent("openai:gpt-5.6-luna", middleware=[router])

玩法 5：工具调用守门员——在动手之前拦一下

背景：编程助手能执行命令、改文件、发网络请求。这些动作出错代价高，所以各家助手本来就有"要不要问你一下"的机制——但那套判断逻辑是闭源的、你改不了。Jev 让这件事变得可自定义。代表项目：jev-guard（把每次工具调用判成"拒绝 / 询问 / 允许"三档，并在里面标出提示注入）、pi-jev-auto-mode（判断不出来时默认拦住，这叫 fail closed）、jevwire（"只能更严、不能更松"的升级式插件）、bicameral（大模型写代码、Jev 当反射神经，每次调用判成 allow / confirm / block / warn / steer）。

LangChain 把同一件事包成了几行：

from langchain.agents import create_agent
from langchain_typesafe.experimental.middleware import AutoModeMiddleware

guardrail = AutoModeMiddleware(tools=["bash"])
agent = create_agent("openai:gpt-5.6-luna", middleware=[guardrail])

LangChain 的博客把这件事的意义说得很清楚：这种"在危险动作执行前先分类"的做法，各家编程助手其实都已经有了，只是被锁在闭源部分里；现在有了便宜好用的分类模型，任何 Agent 都能用上同一个模式。

同一个位置最值得抄的一份配方：自动批命令

这是我在整个生态里找到的最好抄的一份——出自 OpenRouter 的官方配方，做的事情很具体：你的 AI 助手要执行一条命令、弹出"是否允许"时，让 Jev 替你判断这条命令该不该放行。它只问两个是非题，而且都是人话：

const APPROVE_AT = 0.9

const QUESTIONS = {
  reversible: { type: "noul", instructions:
    "Every command in `commands` only reads or changes files inside `project` and can be undone with git or by rerunning it. It does not push, publish, deploy, delete files outside the project, change system settings, or send data to a network service." },
  serves_task: { type: "noul", instructions:
    "Running `commands` is a reasonable next step toward `task`." },
} as const

// 两个判断都过 0.9 才自动放行；任何一个没过线，就还是弹给你

它公开了实测的分数和账单（我给每行加了中文解释）：

账单也被公开了：一次典型的 400 token 案卷，成本 $0.0000168（不到十万分之二美元）。配方里还有一句最重要的工程提醒：真正拦住危险命令的是那张写死的危险关键词清单，Jev 只是第二道门——不要把它当唯一防线。这份配方同时覆盖 Claude Code、Codex CLI、Cursor 和 OpenCode 2.0.12+。

玩法 6：判断 Agent 是不是真的干完了

这类要解决的问题很实际：助手说"改好了、测试通过了"，但它可能没真跑测试，或者只修了表面。代表项目：limpet（一个"停止钩子"——助手想收工时触发——按你写的自然语言规则拦住它）、jev-belay（读整段记录找证据，只在"文件改了但之后没有任何通过的检查"时才花一次四问的 Jev 调用，判不出来就放行）、jev-code（把吃判断力的活交给命令行工具，每个请求对应一条带类型的工作流）、Stanley（把一句自然语言需求路由到一条固定工作流，再由这条工作流去问 Jev 固定的选择题）。

这一类里最新的一步是 09-20 和 09-21 发生的：LangChain 先发了官方评测博客 Jev-as-a-Judge for Agent Evals（09-20），第二天就把 Jev 做进了它的评测平台 LangSmith——也就是说，你现在可以在一个已成型的评测工具里把"裁判"从大模型换成 Jev，不用自己写代码。他们把卖点放在"一致性"上：Jev 在连续打分上的方差比三个大模型裁判低 92 到 913 倍。这一点比"更准"重要——评测最怕的不是偏，是同一份东西今天给 4 分明天给 2 分。

玩法 7：技能与提示词择优——别把 182 个技能全塞进去

这个数字很能说明问题：官方有个配方是"从 Nous Research 的 Hermes 目录里 182 个技能中，最多挑一个用在当前这一轮"。文档把问题说得很直白："Agent 们靠把所有技能塞进系统消息来选技能，这会推高成本、降低选择质量，并让整个 session 的其余部分产生 context rot。"（context rot＝上下文里堆了太多无关内容，模型反而变糊涂。）

官方那个配方用两次请求解决：一次把所有 182 个技能的描述便宜地读一遍排名，再只把前三名完整读出来复核。它给出的对照实验跑了 488 次请求、拿 Claude Haiku 4.5 当基线——具体的百分比数字我在这篇里不转述，因为那是官方自报的窄场景测试，你可以自己去 docs.typesafe.ai/cookbooks/skill_suggestion 看完整表格。社区对应的项目是 skillranker、skillbox、hermes-jev-skills、typesafe-skill-router。

玩法 8：把 grill-me 那种"追问到你崩溃"的流程变成按重要性分流

如果你用过那种一次问你 30 个问题的工作流，这一类最实用。先把一件事说清楚：grill-me 这类"追问式"技能本身和 Jev 没有任何关系——我让研究助手把它的技能文档搜了一遍，"jev" 出现 0 次。下面讲的是你自己在它旁边加一层 Jev 分流，属于自拼玩法，不是它自带的功能。（旧版把这两件事写得像是配套的，这里更正。）

做法是：让 Jev 给每个问题打 1–5 分（Score），你的门槛设在 3 或 4，低于门槛的自动采纳建议答案、不打断你。下面三段是可以直接粘给 Claude Code 的提示词（旧文里的三段我保留了下来，并把过时的工具名改成了真实的工具名）：

// 打分：把 30 个问题按"必须我亲自答"的程度排序
用 jev_score 给这些问题逐一打分，
  scale: [1, 2, 3, 4, 5]，其中 1=琐碎可自动答、5=必须我亲自答。
  输出按分数倒序，只把分数 ≥3 的问题列给我。

// 复核建议答案：每个建议答案做三重判断
对下面这个 Q&A 做三件事：
  1. 用 jev_score 给建议答案的合理性打分（1-5）
  2. 用 jev_score 给潜在风险打分（1-5，5=高风险）
  3. 用 jev_classify 判断：建议答案属于"明显错误 / 有隐患 / 没问题"哪一类
  输出一张表，按风险倒序，让我一眼看到哪些需要改。

  Q: 你打算怎么处理 SQLite 并发写？
  建议答案: 用事务隔离 + retry-on-busy。

// 守门员：助手自动改完之后再过一道闸
对刚才这个修复做两层判断：
  1. 用 jev_verify 判断：这个修复是否真解决了原始问题？
  2. 用 jev_check 判断：这个改动是否引入了新问题？
  只要任何一项 confidence < 0.8，转人工。

把它固化成规则，就不用每次重说。加到 ~/.claude/CLAUDE.md 或项目的 CLAUDE.md 里：

// 加到 CLAUDE.md：让助手在我用追问式工作流时自动分流
在我用 grill-me 时，请同时调 Jev 给每个问题打 1-5 分。
  输出格式：
  - 分数 ≥ 4：列出问题 + 建议答案，等我回答
  - 分数 2-3：列出问题 + 建议答案 + 一句话风险提示，自动用建议答案、让我知道即可
  - 分数 1：自动用建议答案、不必打断我

第一次配置时先观察一周，别一上来就全自动放行。免责声明：上面第三段里的 jev_check 是社区某个 MCP 服务器的工具名，不是官方技能包或上一节那十个工具里的名字——如果你装的是 @jkudish/jev-mcp，请把 jev_check 换成表里的 jev_verify。这类"工具名对不上"的坑，是 AI 助手替你装工具时最常见的失败，遇到就让它 /mcp 列一遍真实工具名。

06官方配方里最值得抄的七个（都不写代码也能看懂思路）

官方文档有一整个 Cookbooks（配方）栏目，2026-09-23 我数到 17 个，每个都是"一个真实问题 + 完整做法 + 实测数字"。下面挑七个对不写代码的人最有参考价值的——数字都是官方自报，我把来源和口径一起写了。

配方一：给 LLM 加护栏（每个进出的消息都过一遍）

问题：各家大模型都做过安全训练，但"线画在哪"每家不一样，而且模型每升一版线就动一次。你想要的位置可能和厂商不一样，还希望这条线是你自己能读到、能改的。
做法：一次请求同时问"这段内容危险程度几级""属于哪一类风险"，然后按概率和严重度分成四档处理：放行 / 复核 / 拦下 / 转走。
为什么值得抄：这是"把安全策略从黑箱里拿出来"的最短路径——你的规则变成可读的问题和阈值，不是一个提示词里的祈祷。

配方二：抓出瞎编的引用（给 RAG 查证）

问题：大模型写答案时经常附上引用，但引用可能是错的——引的那句话原文里根本没有，或者有这句话但上下文不支持这个结论。
做法：用一个 Choice 问题判断"这段引文的上下文是否支持这个论断"。
为什么值得抄：这是把"看起来有出处"和"出处真的成立"区分开，成本极低。任何要对外发布的 AI 生成内容都值得加这一道。

配方三：按置信度决定"报细类还是报大类"

问题：把公司年报分到 75 个行业细类里，一定会有一部分分不准。
做法：每个文档问一个 Choice，然后读它自己给出的 confidence：有把握的那一半直接报细类；没把握的那一半，退一级报它上面的大类。
实测数字（官方）：有把握的那一半，报对的比例是 90%；没把握的那一半如果硬报细类，只有 40% 对；退一级报大类，就变成 70%。
为什么值得抄：这是"置信度门控"最有说服力的实例——它不是让模型更准，而是让你的输出变得"知道自己哪里不准"，从而可以选择报一个更粗但更可靠的答案。

配方四：给检索结果重排（搜索质量翻倍的那一步）

问题：先用快而粗的办法（关键词匹配，这里的算法叫 BM25）从几千份文档里挑出 30 个候选，但正确答案常常不在第一个。
做法：对这 30 个候选，让 Jev 逐个回答一个是非题——"这段文字有没有可能出自能回答该问题的文档"。
实测数字（官方，数据集是 3565 份法庭意见、40 条法律查询）：正确段落排在第一名，从 5% 提到 18%；排进前十名，从 38% 提到 62%。
为什么值得抄：任何"先粗筛再精选"的流程都能套这个形状——内容推荐、简历筛选、客服知识库都算。

配方五：给大模型看的东西"逐行打分"（一次问 218 行）

问题：你有一份长文档和一个大白话问题，要找出回答它的那几行，还要能判断"这份文档里根本没有答案"。
做法：把每一行编号，一次请求里用一个 Choice 问"哪一行最相关"（这是 255 个选项上限的实战用法——它能覆盖 255 行以内的文档），再用一个 Noul 问"这份文档里到底有没有答案"。
实测规模（官方）：拿 GitHub 服务条款做样例，一次请求评分 218 行。
为什么值得抄：它给出了一条"不用建向量库、不用维护索引"的语义搜索路径，适合文档量不大但要快速上手的场景。超过 255 行就得换做法（社区有 jev-tree 这类递归方案）。

配方六：两步走的结构化提取（便宜的先上，贵的兜底）

问题：从杂乱文本里抽结构化字段，小模型便宜但会错，大推理模型准但慢且贵。
做法：做成"级联"——便宜模型先抽 → Jev 做验证 → 只有验证不过的才升级给贵模型。官方还专门提醒了一条容易踩的坑：不要让 Jev 直接"写出"那个值，而是先让正则表达式或大模型找出候选，再让 Jev 从候选里挑——因为 Jev 不擅长生成，擅长挑选。
为什么值得抄：这套"分级兜底"是所有成本优化里最通用的结构，不限于提取任务。

配方七：防止"结构不变性"骗了你（自我一致性检查）

问题：同一个判断问 15 次，答案稳不稳？一个自动保险理赔的分诊流程需要知道"哪些单子该转人工"。
做法：用 14 个 Noul 组成一套评分表，同一份材料重复跑 15 次，看每个答案是否稳定；不稳定的那些转人工，同时把原始概率一起留档。
为什么值得抄：它是第 02 节那个"结构不变性"坑的正面对策——既然不能指望答案在换个问法后保持一致，那就把"稳定性"本身当成一个指标去测。

配方之外：别的行业里已经跑出来的数字

官方配方是厂商给的例题。下面这些是社区里公开了做法的真实案例，我按"能不能自己复核"筛过一轮，每条都标了证据强度：

07接入路径：七个入口，从"今晚就想试"到"要上生产"

Jev 不像 Claude 那样"官网一套 SDK 走天下"。它原生只有一个接口 POST /v1/systemone，但托管到了七个地方。我按"从轻到重"排：

OpenRouter 上有两个接口，不是一个（这一条旧版写漏了）

OpenRouter 把 Jev 暴露成两个面：① 兼容层 /api/v1/systemone——走上面那段 OpenAI 风格的调用；② 新的 Decisions 接口 /api/alpha/decisions，直接收 state + questions 对象（05 节那份"自动批命令"的配方用的就是它）。另外 OpenRouter 文档特别说明两条对新人有用的事：走它不需要 TypeSafe 账号、也没有候补名单；而且每个响应里都带一个 usage.cost 字段，直接告诉你这次调用花了多少美元——做成本核算时这个字段比自己去乘单价准。

Python / TypeScript 的官方 SDK

如果你要写代码而不是让 AI 助手代劳，官方提供了两套 SDK：Python 的 typesafe_sdk（有同步和异步两种客户端）和 TypeScript 的 @typesafe-ai/sdk。两者都内置了遇到限流自动退避重试，并会读服务端返回的 retry-after 头（这是"服务器告诉你等几秒再试"的标准做法）。GET /v1/models 可以列出你账号能用的模型名和发布日。

三种调用方式，各有各的形状（这一段是旧文里最容易出错的地方）

OpenRouter —— 走的是它自己的"决策接口"，不是 OpenAI 那个聊天接口。这是旧版写错、我这次按官方文档更正的一处：OpenRouter 的模型页明确写着，Jev "runs on the OpenRouter Decisions API rather than the OpenAI-compatible chat endpoint"（它跑在 OpenRouter 的 Decisions 接口上，不是那个与 OpenAI 兼容的聊天接口）——所以请求和响应的形状都不一样：

curl https://openrouter.ai/api/alpha/decisions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "typesafe/jev-1.13",
    "state": "My monthly invoice shows a charge for the Pro plan but I signed up for Free. Please help.",
    "questions": {
      "category": {
        "type": "choice",
        "instructions": "Which team should handle this ticket?",
        "criteria": {
          "billing": "Charges, invoices, refunds, subscriptions",
          "technical": "Errors or integration problems",
          "account": "Login, permissions, profile",
          "other": "None of the above"
        }
      }
    }
  }'

这里没有"解析字符串"这一步。你给它的是 state + questions，拿回的是按你起的问题编号组织好的答案；官方原话是 "There is no free-form text to parse."（没有自由文本需要解析）。旧版那段"OpenRouter 与 OpenAI 接口兼容、答案是 choices[0].message.content 里的字符串"是错的——我按官方文档和 OpenRouter 自己那篇教程改正了；如果你手上还留着旧代码，它不会按预期工作。

Vercel AI SDK（下面这段出自 Vercel 官方指南，用的是它专门的求值接口）：

import { generateText } from 'ai';
import { createOpenAICompatible } from '@ai-sdk/openai-compatible';

const jev = createOpenAICompatible({
  name: 'typesafe-ai',
  apiKey: process.env.TYPESAFE_API_KEY,
  baseURL: 'https://api.typesafe.ai/v1',
});

const { text } = await generateText({
  model: jev('jev'),
  prompt: `Classify this ticket: ...`,
});

Cloudflare Workers AI——它的官方模型页在 developers.cloudflare.com/ai/models/typesafe/jev/，标注模型 id 为 typesafe/jev、上下文 32,000 token（就是"案卷 + 最长问题"那个口径）：

export default {
  async fetch(request, env) {
    const input = await request.json();
    const response = await env.AI.run('typesafe/jev', input);
    return Response.json(response);
  }
}

国内使用的现实问题（旧版这一节是猜的，现在有依据了）

旧版写的是"OpenRouter 在国内访问不稳定"——那是我按常识推的，当时没有依据。现在有两条可核实的：

• 服务本身还没对大陆开放。中央广播电视总台旗下网站 2026-09-20 的报道原话是"目前该服务尚未对中国大陆地区开放"。
• 有人量过延迟的"地板"。一位杭州的测试者公开记录了自己的实测：需要本地代理才能访问，网络往返延迟有约 270 毫秒的下限（同一次测试里，从法国访问是 163 毫秒，而 Claude Haiku 只有 18 毫秒）；首次建立安全连接要 992 毫秒，连接复用后降到 270 毫秒。

不过在担心网络之前，有一条更该先解决的问题——

08最小例子：把一个分类调用换成 Jev

改造前：用大模型做分类

import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic();

async function classifyTicket(message: string) {
  const response = await client.messages.create({
    model: 'claude-haiku-4-5',
    max_tokens: 50,
    system: `You are a ticket classifier.
      Return JSON: {"category": "complaint|question|praise|other"}
      - complaint: user is unhappy or reporting a problem
      - question: user is asking how to do something
      - praise: user is thanking or complimenting
      - other: everything else`,
    messages: [{ role: 'user', content: message }],
  });
  return JSON.parse(response.content[0].text);
}

成本：每次大约 600 个输入 token + 30 个输出 token，Haiku 4.5 定价 $1 / $5 每百万 token，单次约 $0.0009；10 万条/月 = 约 $90/月。

隐藏成本：那段分类说明（system 提示词）每一条消息都要重发一遍，这 600 个 token 里有相当一部分是"反复教它同一件事"。

改造后：用 Jev 做分类

// 走 OpenRouter 的 Decisions 接口：给它"案卷 + 问题"，拿回结构化答案
const res = await fetch("https://openrouter.ai/api/alpha/decisions", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.OPENROUTER_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: "typesafe/jev-1.13",
    state: message,
    questions: {
      category: {
        type: "choice",
        instructions: "这张工单属于哪一类？",
        criteria: {
          complaint: "用户在表达不满或报告问题",
          question: "用户在问怎么做某件事",
          praise: "用户在道谢或称赞",
          other: "以上都不是",
        },
      },
    },
  }),
});

const data = await res.json();
// 答案按你起的问题编号返回，没有解析自由文本这一步。
// 具体的字段名（是 data.answers.category 还是 data.category）以官方 API 参考为准——
// 我没有 key，无法实跑确认返回值的确切层级，所以这里不写死。
return data;

成本：单次约 $0.000025；10 万条/月 = 约 $2.50/月，也就是省掉约 97%。输出不计费，这一点在分类任务上尤其划算——大模型的账单里"输出"那一栏直接归零。

改造点对照

如果换成"原生接口"，代码长这样

上面那段走的是 OpenRouter 的兼容层，所以还要解析字符串。如果走 TypeSafe 原生接口，一次请求可以同时问多个问题，答案直接是带类型的值（这是官方 quickstart 的形状）：

from typesafe_sdk import Noul, Choice, TypeSafeClient

client = TypeSafeClient(model="jev-1.13")

result = client.system_one(
    state=ticket_text,
    questions={
        "category": Choice(
            instructions="这张工单属于哪一类？",
            criteria={
                "complaint": "用户在表达不满或报告问题",
                "question": "用户在问怎么做某件事",
                "praise": "用户在道谢或称赞",
                "other": "以上都不是",
            },
        ),
        "refund_requested": Noul(
            instructions="用户是否明确要求退款或补偿？",
        ),
    },
)

# 答案直接可用，不需要解析
category = result.answers["category"].choice
confidence = result.answers["category"].confidence
refund_p = result.nouls["refund_requested"].noul

09成本与准确率：把厂商的两个数字拆开看

厂商现在说的是"快 193.6 倍、便宜 444.6 倍"

这个数字我从首页上逐字抄的，页面还给了它的"证据"：TypeSafe AI 这边 $0.000081、0.114 秒完成；LLM 那边 $0.013880、8.566 秒完成。

现在做一道小学算术：

# 这是我自己的验算，不是厂商给的
$0.013880 / $0.000081 = 171.4   ← 成本差 171 倍
8.566s / 0.114s        = 75.1   ← 耗时差 75 倍

所以首页上那个"444.6 倍便宜"，不是从这个单例算出来的——它来自厂商另外设计的一套"四项工作流"评测（官方说明：四项任务同权重取平均）。这件事值得记住：同一个页面上，宣传数字和它自己给的证据可以差两三倍。

厂商自己的评测榜：Jev 不是最准的那个

更值得看的是它自己的评测页（evals.typesafe.ai）。我把上面我能读到的点全部抄下来——注意这是一张"准确率 vs 成本"的散点图，不是排行榜：

这张表怎么读（我为它加的一列判断）：

• Jev 不是最准的。它 67.8%，比 opus 5 低 5.3 个百分点、比 sol 低 6.3 个百分点。唯一让它在同一张图上"没人能同时打赢"的，是成本和时间那两栏——页面上那句话写得很老实："frontier: nothing is both cheaper and more accurate"（前沿模型里，没有谁既更便宜又更准）。
• "工作流"这三栏比模型本身更重要。同一个 haiku 4.5，把同一套判断拆成结构化工作流（拆成一个个 Noul / Choice / Score 问题 + 代码规则）之后，准确率从 18.1% 跳到 53.6%，成本还降了。换句话说：这张表里最大的收益来自"把任务拆开"这件事本身，不是来自换模型。这对你选不选 Jev 其实是最有用的一条信息。
• 参考标签本身是模型给的。官方明确说明：这套评测的标准答案，是拿 GPT-6 Astra 和 Claude Fable 5.1 在高推理设置下的回答取平均生成的。它不是人工标注的黄金标准，所以"准确率"这一栏要打折看。
• 官方承认可能有偏差。中文媒体的转述里提到，官方同时承认这些数字处在"现实收益的高端"，且评测工作流由公司内部人员制作、可能存在偏差。

那批第三方评测说了什么

旧版（2026-09-21）写的是"尚未见权威独立测评"。两天后这句话就不再成立了——社区里已经出现了一批独立评测，我挑三份有具体方法的：

别忘了竞品：真正最便宜的那个不是它

便宜不等于不用优化

一个容易忽略的账：如果你每条消息都要过 Jev 问 5 个判断，每月 1000 万条，那就是 约 $52.50——听着仍然很少，但它不等于"可以不管"。该做的三件事一样要做：监控用量、调阈值、把重复的判断结果缓存起来（同样输入别重复问）。

10官方自己列的九种失效模式：这是最该先读的一节

很多教程会把"坑"放到最后当补充。这一节我提前讲，因为厂商自己在文档里专门写了一页叫 Jev 1.13 jaggedness（jaggedness＝"坑坑洼洼"），逐条列出它知道这个版本哪里不行。这一页的价值比任何宣传页都高——愿意把短板写进文档的产品不多。下面九条我全部保留，并加上"这对你意味着什么"。

官方文档没写、但独立实测发现的三种坑

下面三条来自社区的独立测试，官方那页失效模式里没有。它们的共同点是不会报错——你只会拿到一个看起来很正常的答案。

不该用它的场景

几个操作层面的硬约束

11有人说它只是"一个聪明的 switch 语句"

这一节是旧版完全没有的。Jev 发布 9 天，社区已经分裂成两派，而两派的论证都比"真香"或"智商税"复杂。我把最有分量的几条摆在下面，你可以自己判断它值不值得进你的流程。

质疑一：Redis 作者说，这波热度说明多数人分不清什么重要

2026-09-21，Redis 的作者 Salvatore Sanfilippo（圈内叫他 antirez）在 X 上发文，中文媒体的转述里引了他的原话："Jev 或许有一些很狭窄的应用场景，但围绕它出现的炒作，恰好说明了 AI 泡沫中的大多数人根本分不清什么重要、什么不重要。" 那条帖子据报获得超过 11.6 万次浏览。

同一篇报道里还有一个更技术的判断，来自 AI 开发者 Theo Browne，他的比喻是：把 Jev 看成一个"聪明的 if 或 switch 语句"——程序给出当前状态和有限选项，它立刻决定走哪条分支；"它的智能水平大致和一个 switch 语句相当。它适合分类，却不知道怎样浏览整个代码库并作出高质量决定。"

质疑二："0% 幻觉"保证的是格式，不是答案

这是最值得记住的一条，因为它解释了为什么很多"宣传 vs 体感"的落差。厂商宣称 Jev 不产生幻觉，但这个保证的范围是输出结构：如果你规定答案只能是"销售/技术支持/财务/其他"四个，它就必然在四个里选一个，不会返回第五个类别，也不会写坏 JSON。但它选的那个可能是错的。

中文媒体的报道里还提到一个细节：厂商在发布文章里称 Jev"永远不会出现类型错误"，并承认图表里那个 0% 并非实际测试结果，而是由 schema 匹配机制直接保证的；报道里引述 GitHub 的一位资深工程师把这种宣传称为一种"语义上的规避"。

质疑三：上下文压缩这一类玩法，反对意见最具体

前面 05 节已经完整写了 Theo Browne 的反对理由（信息不足、看不到推理过程、可能陷入重复劳动的循环、可能让提示缓存失效）。这里只补一条官方口径之外的证据：那个最火的压缩插件确实有效——中文媒体报道了一次流传很广的演示，把约 15.6 万 token 的对话压到约 6.2 万 token。但同时，厂商文档自己也承认 Jev"案卷越大越乱"、要"只送真正相关的字段"。两件事放在一起看，就是这类玩法的核心张力：它要判断"什么还能用"，而它恰恰在长上下文里最容易判断不准。

几条常见的误解澄清

12一页纸速查：什么时候用哪个、抄哪个

"我遇到的情况 → 用哪种问法 / 抄哪个项目"

"我要跑了，最少要知道这几条"

13术语表

14参考来源与证据边界

本文用到的主要来源

证据边界（这些你必须知道）

99一句话总结

留给你自己验的那条判据——拿你手上最常见的那次"判断"（工单该给谁、这条内容要不要拦、这份简历值不值得看），先数一遍"如果我永远返回最常见那个答案，准确率是多少"，再数一遍"这件事每月发生多少次"。两个数字放一起，你就知道这件事值不值得动，以及该用什么口径去验收别人的演示。