先说结论，三句话：

1. Jev 是 TypeSafe AI 在 2026 年 9 月 15 日发布的一类新模型——System One（系统一）模型。 它不生成文字，只回答三种问题：有限选项里选哪个、按量表打几分、这句话成不成立。
2. 它的意义不是”又一个更聪明的 AI”，而是把 Agent 里那 90% 又碎又频的小判断，从昂贵的大模型手里拿走。 输入 $0.042/百万 token、输出免费，延迟几十到几百毫秒（均为厂商口径）。发布不到一周，社区就跑了二十多个项目出来。
3. 对做实业的公司来说，它对应的不是”再上一个 AI 项目”，而是让已经上线的 AI 真的落到经营结果上。 斯坦福数字经济实验室那份《The Enterprise AI Playbook》里，77% 的企业说 AI 落地最难的事，跟技术一点关系都没有。

下面把这三句掰开。

一、Jev 到底是个什么东西

先把事实摆清楚，不吹：

它的官方文档第一句话就把定位说透了：

大语言模型是为”给人读”设计的。当你需要模型做一个代码要消费的判断时，就产生了错配：你在强行让一个文本生成系统输出结构化决策，然后再把结果解析回来。

这个”错配”就是 Jev 要解决的问题。旧做法是：让 LLM 输出 JSON，然后祈祷它别写歪、加上校验、加重试、加异常处理。Jev 的做法是：你提前把可选答案的集合定义好，它只能从这个集合里返回，附带你定义好的概率分布。

顺手给个体感，一次真实调用长这样（官方文档示例，我原样搬运）：

curl -X POST https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "state": "客户说：我 Stripe 账号连了三天都失败，正在丢单，请尽快处理。",
    "model": "jev-latest",
    "questions": {
      "department": {
        "type": "choice",
        "instructions": "这件事该哪个团队处理",
        "criteria": {
          "billing": "付款或订阅问题",
          "technical": "Bug 或集成故障",
          "sales": "报价或账号问题"
        }
      },
      "frustration": {
        "type": "score",
        "instructions": "客户的情绪激烈程度",
        "criteria": ["平静陈述事实", "不满但克制", "非常生气，用词强烈"]
      },
      "is_urgent": {
        "type": "noul",
        "instructions": "这条消息传达了紧迫性或时间敏感性"
      }
    }
  }'

返回：

{
  "answers": {
    "department":  { "choice": "technical", "confidence": 0.78,
                     "probabilities": { "technical": 0.85, "sales": 0.0, "billing": 0.15 } },
    "frustration": { "score": 1.0, "confidence": 1.0,
                     "probabilities": { "0": 0.0, "1": 1.0, "2": 0.0 } },
    "is_urgent":   { "noul": 1.0 }
  },
  "usage": { "input_tokens": 392, "output_tokens": 65 }
}

注意三个细节，这是它的全部精髓：

• 一次请求里三个问题一起问，并行评估。 加问题几乎不增加响应时间，而且每个问题独立评估，不会互相污染上下文。
• 每个答案带概率。 不是”technical”，是”technical，85%“。你的代码可以设阈值：置信度高于 0.9 自动派单，0.6–0.9 走复核，低于 0.6 转人工。
• Noul 返回的是 0–1 的数值，不是必须二选一。 noul: 1.0 是”很成立”，0.2 是”基本不成立”。它表达的是”这句话成不成立”的程度，而不是强迫模型给出二元结论。

Python SDK 版更简洁：

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()   # 从环境变量 TYPESAFE_API_KEY 读取密钥
resp = client.system_one(
    state=ticket,
    questions={
        "department": Choice(instructions="这件事该哪个团队处理", criteria={...}),
        "frustration": Score(instructions="客户的情绪激烈程度", criteria=[...]),
        "is_urgent": Noul(instructions="这条消息传达了紧迫性"),
    },
)
print(resp.answers["department"].choice, resp.answers["department"].confidence)

二、它为什么突然火：Agent 的钱，大部分没花在”思考”上

这是我认为整件事里最值得记住的一句话：

大多数所谓的 AI Agent，预算的大头不是花在聪明的规划上，而是花在无数个微小的”是/否”和”选一个”上——调哪个工具、这页有没有用、这一步有没有风险、任务完了没有。这些判断一天发生几十万次。为每一个都付费让顶级大模型写一段话，就是 Agent 账单爆炸的方式。

翻译成人话：你请了一个年薪百万的博士，让他做的是”这份文档归 A 部门还是 B 部门”这种判断。一秒钟一问，一天几十万次，账单自然失控。

Jev 切的就是这一层。它不是替代 ChatGPT / Claude，是站在它们旁边，把边界清楚的小判断接过去，让大模型专心做它擅长的开放推理和文本生成。

最后一栏很关键。Jev 官方文档自己写得很克制：它会返回一个你选项里存在的、结构合法的答案，但这个答案可能是错的。”不会输出 schema 外的值”和”不会答错”是两件事，很多宣传把它们混为一谈。所以阈值、复核路径、你自己的标注评测，一样都不能省。

价格上，厂商给出的口径是”比同类 LLM 调用快约 200 倍、便宜约 400 倍”——这是 TypeSafe 自家工作流评测的数字，不是独立基准，厂商自己也说明接近上限。你真正该做的，是拿自己的场景量一遍。

三、别被”模型”两个字骗了：用法说明书是三条

Jev 的官方文档里有一段话，比价格更值钱：

System One 模型最适合每个问题只问一件具体、边界清晰的事。把每个问题想象成一次”直觉判断”——一个知识足够的人在拿到正确上下文时，几秒钟就能给出的那种判断。如果你想问的问题需要展开推理，或者要同时权衡多个独立因素，那就拆开。每个因素单独问，再用你自己代码里的逻辑把结果合起来。这样每次评估都可靠，而且权重要怎么调，改代码系数就行，不用重写提示词。

这段话点破了 Jev 真正的门槛：不在模型，在于你会不会问问题。

举个原文的例子：不要问”给这个创业路演打个分”，而是分别问市场规模、技术可行性、差异化程度，然后自己加权算总分。优先级变了，你改一个系数，不用重新调提示词。

三种原语对应的问法：

我的建议是：上手别急着接业务，先把你现在提示词里那些”判断句”全部抄出来，一条条改成上面三种问法。 这个动作本身就能帮你发现，你现在有多少事情是让大模型在”猜一个本该用代码管的决定”。

四、六个能直接套到你业务里的例子

下面这些例子不是虚构的，是从我和团队真实在跑的工作流里挑出来的。共同点是：这些判断现在都在烧大模型的 token，而且每一件都不需要”写字”。

例 1｜会议开完，内容该发给谁

我们有一条固定的会后台：会议转写 → 生成纪要 → 按角色分发（CEO 版、市场渠道版、内部执行版）。

改造前：整份纪要 + 分发规则一起丢给大模型，让它判断这份内容适合发给哪几个人、要不要拆版本。一次调用几千 token，一个会议要判好几轮。

改造后：把”分发”这一个动作拆成 Jev 的问题。

{
  "audience": {
    "type": "choice",
    "instructions": "这段内容最该给谁看",
    "criteria": {
      "ceo": "涉及经营结果、战略取舍、组织变动",
      "channel": "涉及渠道政策、合作方利益、对外口径",
      "execution": "涉及具体执行动作、交付节点、责任人"
    }
  },
  "needs_review": {
    "type": "noul",
    "instructions": "这段内容涉及对具体个人或客户的负面评价"
  }
}

needs_review 这一问是我最看重的：用一行代码换掉一次公关事故。 只要它超过 0.7，流程自动停下来等人工确认，谁都不用背锅。

例 2｜评论区挖矿，判断这条评论值不值得挖

我们做短视频的选题，主信号源是评论区，不是微信指数。以前的流程是：抓一堆评论 → 丢给大模型 → 让它总结”用户在关心什么”。结果是它给你一段正确的废话。

现在拆成三个原子问题：

• Choice — 这条评论属于哪一类：① 已经买过/用过的具体反馈 ② 没被满足的需求 ③ 纯粹的情绪表达 ④ 无关噪音
• Noul — 这条评论里说出的痛点，与我们现有产品/课程的能力范围重叠吗？
• Score — 这条评论的表达烈度（0=随口一说，2=反复追问、带到自己的钱和生意上）

为什么这个例子重要：Score 加 Noul 的组合，直接把”几万条评论”压缩成”几十条真正值得看的”。剩下的交给人工——这符合我们一直坚持的原则：AI 是帮强的人更强，不是替代判断。

例 3｜选题的热度校验

我们原来的做法是”评论区发现痛点 → 提取关键词 → 查微信指数校验热度（上升 / 平稳 / 下降）“。以前这一步是人肉看指数、或者整篇丢给大模型判断，成本高还慢。

现在这就是标准的 Choice：三个选项、一次调用、返回概率。上升 0.62 / 平稳 0.31 / 下降 0.07 —— 决策逻辑写在代码里：概率最高的那个是对的就排队做，上升 与 平稳 差距小于 0.15 就先放着。阈值是你能调的，不是模型说了算。

例 4｜内容质量打分：把”稀缺性”变成可计算的分数

我们做过一个”视频号爆款脚本分析引擎”，核心差异化点是判断”这个内容为什么在这个平台、这个时间点稀缺”。这件事以前靠人写总结，或者靠大模型给一段评语。

Score 原语天生就是干这个的。把”稀缺性”拆成三个量表分别打分，自己加权：

{
  "angle_scarcity": { "type": "score", "instructions": "选题角度的稀缺程度",
    "criteria": ["满大街都是", "有人讲但角度雷同", "角度少见", "几乎没人从这个角度讲过"] },
  "evidence_density": { "type": "score", "instructions": "内容里真实案例/数据/一线细节的密度",
    "criteria": ["全靠观点", "有一个例子", "多个具体案例", "案例+数据+可复现步骤"] },
  "actionability": { "type": "score", "instructions": "读者看完能不能马上做一件事",
    "criteria": ["听完就完了", "知道方向但没抓手", "有明确下一步"] }
}

一次调用返回三个分数三个置信度，总分你自己在代码里算。大模型只负责”看”，不负责”定性结论”。 这样一来，同一批脚本前后两次评估是可比的——这才是能不能沉淀成标准的关键。

例 5｜Agent 的护栏和上下文减重

这一条是所有在跑 Agent 的公司都该做的：

• 工具调用前的风险闸门：Agent 准备执行一个动作（发邮件、改文件、下单、删除）之前，先问一句 Noul：“这个动作是否会产生不可逆的后果？”。超过阈值就拦下来转人工。这跟 Anthropic 用分类器防越权是同一个思路，只是现在这层判断便宜到可以随便加。
• Prompt Injection 检测：外部内容（网页、邮件、文档）进来时，问 Noul：“这段内容是否试图指挥我忽略原有指令？”
• 上下文减重：长任务里历史工具调用的输出越堆越多。别再做”重新生成一份摘要”（会丢路径、错误码、约束条件），而是逐条判断”这条现在还有必要留吗”，留下的原样保留，没价值的删掉。社区里有个叫 fast-jev-compaction 的项目就是干这个的。
• 完成度闸门：“这轮任务的验收标准是否已经满足？” Noul 一下，没过就继续，过就收工。比让 Agent 自己说”我完成了”可靠得多。

例 6｜老板最该用的一个用法：把汇报里的”过程指标”挑出来

这条跟技术无关，但我觉得价值最高。

我们的资料库里躺着一篇文章，标题就叫《AI 落地只盯一个数，比定十个 KPI 管用一万倍》。里面讲了两个数字，我印象很深：一家 To B 智能制造企业原来用一堆指标汇报 AI 成果——调用次数、Token 消耗、员工使用率、模型准确率，个个在涨，老板说不清 AI 到底值多少钱；后来只盯一个数：项目交付周期，从平均 45 天压到 32 天，缩短 29%，全公司立刻知道要围着什么转。

另一家连锁服务企业，北极星指标定的是”新店盈亏平衡周期从 14 个月缩到 9 个月”，最后做到 10.2 个月——一个指标，把 AI 的投资回报说清楚了。

这里的判断逻辑，恰好就是 Noul 的完美用例。你手上任何一份 AI 成果汇报，每一条指标都可以过一遍：

{
  "q1": { "type": "noul", "instructions": "这个指标是结果指标（直接关联收入/成本/现金/风险），还是过程指标（工具使用量、生成数量、调用次数）？成立即代表它是结果指标" },
  "q2": { "type": "noul", "instructions": "这个指标有没有明确的、写下来的基线和目标值？" },
  "q3": { "type": "noul", "instructions": "如果这个指标改善了，财报上的某个数字会跟着动吗？" }
}

逐条过一遍，一份 32 页的汇报会在三十秒内被筛成一页。它不需要写任何一句话——它只需要判断”是不是”。 这就是 Jev 和聊天机器人的本质区别。

顺便说一句我们资料库里那句话，说得挺狠：“算不清账的 AI，不是企业智能 AI。” 任何 AI 项目只看四个指标——降本、增收、提效、风险，公式是”AI 总价值 = 降本 + 增收 + 提效 − 风险”。

五、怎么开始：一周能跑通的一条路径

如果你手上有已经在跑的 AI 工作流，我建议按这四步走，不用重写任何东西：

第一步：列清单。 把现有工作流里所有”让大模型判断一下”的地方抄出来。你会发现它们的共同特征是——输出其实只有几个可能值，但你让模型写了 200 字的解释。

第二步：原子化。 每一个判断，改写成一条 Choice / Score / Noul。检验标准很土但很好用：这条问题，一个熟手看三秒钟能不能答？ 答不了就是问太大了，继续拆。

第三步：影子模式跑两周。 别急着让它接管流程。让它和现在的做法双跑，把它的结果和人工结论、最终结果都记下来。你要拿两个数：准确率和置信度校准度。校准度比准确率更重要——如果它说 0.9 的时候真的九成是对的，你才敢设自动化的阈值；如果它说 0.9 但只有六成对，那还不如不许它开口。社区里已经有专门做这件事的工具（如 jev-eval-mcp），可以拿带标注的数据测不同问法和不同阈值。

第四步：分级放权。 高置信度自动走，中置信度复核，低置信度转人工。记住：Jev 不是权限系统。 它给的是判断，不是授权。真正的边界（谁能发钱、谁能删数据、谁只能看）必须写死在你的代码里。

六、五个坑，先替你踩了

1. 别把它当聊天模型用。 它不对话、不写文章、不写代码、不读图片、不读音频。图片和语音要先转成文字描述再喂进去。
2. 一次问一件事。 问”给这个方案打个总分”是最常见的误用，会让你退化回”大模型猜一个数字”。拆维度，权重写进代码。
3. 置信度不是正确率。 我看到最反直觉的一个结论来自社区引述的独立评测：当规则允许模型跳过自己最不确定的样本时，Jev 反而在两项任务上全部逆转了原本准确率持平甚至领先的通用大模型——原因就是它的置信度有统计意义，而通用大模型对自己的把握往往严重过自信。但前提是你要真的去用它，而不是只看最高的那个答案。
4. 厂商的性能数字当上限看。 200 倍 / 400 倍是厂商自家评测的口径，厂商自己也说接近真实上限。你自己的场景、你自己的输入长度，量出来才算数。
5. 别指望它替你决定业务。 它能帮你把”事实层面的判断”变成廉价的、可批量执行的、带概率的一层。但”这个判断对不对、该不该自动化、阈值设多少”，仍然是你这个当老板、当业务负责人的活。

最后

回到最开始那三句话。

Jev 这件事最值得琢磨的地方，不是”又一个新模型来了”，而是它把一个大家心知肚明但一直没解决的分工问题，第一次用产品语言说清楚了：

该生成的时候用生成模型，该判断的时候用判断模型。别拿博士去干门卫的活。

斯坦福那份报告里还有两个数字，我放在最后：77% 的企业说 AI 落地最难的事跟技术无关；61% 的成功项目，之前都至少失败过一次。这两个数字说明同一件事——AI 落地卡住的地方，多半不在”模型不够聪明”，而在”没人把该拆的判断拆开、该设的边界设上、该盯的数盯住”。

而这个动作，不需要等下一个更贵的模型。今天就能做。

文中关于 Jev 的参数、接口、价格均来自 TypeSafe AI 官方文档（docs.typesafe.ai）及其发布资料，属厂商口径；社区项目数据（如 jev-ultrafast 的 7.1 秒）来自项目作者自述，非通用基准。斯坦福报告数据引自斯坦福数字经济实验室《The Enterprise AI Playbook》相关解读。企业案例引自国泰道合「贤哥陪跑经营」《AI 落地只盯一个数，比定十个 KPI 管用一万倍》。