Jev：把语言模型收缩成一个可编程的判断器

先把它放在正确的位置

传统大语言模型擅长生成：解释、写作、代码和多步推理。即使要求它输出 JSON，底层任务依然是在生成一段文本，再由程序解析、校验和使用。

Jev 走的是另一条路。TypeSafe 把它称作 System One model：给模型一个 state，再给它若干个边界清晰的 questions，它直接返回类型确定的答案、概率分布与置信信息。它更像“理解自然语言的 if / switch”，而不是另一个聊天机器人。

这一区分很重要：Jev 提供判断，代码拥有流程。权限、业务规则、金额计算、真正的工具执行和最终责任仍然应该留在确定性的系统中。

三种判断原语

Jev 把常见的语义判断收敛成三种问题形状。与其先写一段开放式提示词，再从回答中“抠结论”，不如从一开始就决定程序需要哪一种结果。

{
  "state": {
    "message": "订单被重复扣款，请尽快处理",
    "customer_tier": "pro"
  },
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "应该由哪个团队处理？",
      "criteria": {
        "billing": "付款、账单、退款",
        "technical": "故障与集成",
        "sales": "购买与升级"
      }
    },
    "urgent": {
      "type": "noul",
      "instructions": "是否需要立即处理？"
    }
  }
}

同一份状态可以同时回答多个相互独立的问题。程序随后可以把高置信结果自动分流，把模糊结果送给人工或更强的推理模型。

为什么它会更快

速度来自任务形状，而不是魔法。通用 LLM 需要逐 token 生成可读文本；Jev 不生成长篇解释，而是在限定答案空间里给出分布。少了文字生成和结果解析，延迟与成本自然有机会下降，多项判断也可以围绕同一份状态并行完成。

它适合做什么，也不适合做什么

合适的任务

• 客服邮件和工单的分类、优先级判断与部门路由；
• 内容审核、风险分级、证据是否充分的快速检查；
• Agent 在有限候选项之间选择工具、模型或下一步动作；
• 批量给文章、商品、线索或反馈打标签与评分；
• 给昂贵模型的输出增加一道便宜、结构化的复核。

不该交给它的任务

• 写文章、生成代码、开放式解释或长链条推理；
• 需要精确计算、数据库事实查询或严格日期比较的工作；
• 直接理解图片、音频、视频或 Canvas 画面；这些内容需要先被转换成可靠的文字或结构化状态；
• 没有候选边界、目标不断变化、需要探索新答案的任务；
• 仅凭一次概率判断就执行删除、付款或权限变更等高风险动作。

放进 Codex 之后，谁在做什么

Jev 接入 Codex，并不是把 Codex 的主模型替换掉。更合理的分工是：

1. Codex 读取项目、理解目标，并把相关信息整理成最小但充分的状态；
2. Jev 对边界明确的问题做 Choice、Noul 或 Score 判断；
3. Codex 或应用代码读取结果，再依据权限、阈值和业务规则决定下一步；
4. 需要写代码、解释原因或处理模糊情况时，仍交给通用模型或人工。

官方 Agent Skill 的作用，本质上是教编程代理什么时候使用 Jev、怎样组织状态与问题，以及怎样处理不确定性。它本身不会绕过权限，也不会替应用执行最终动作。

怎样看视频里的速度对比

视频及作者的同主题图文给出了一组直观测试：用相同的 1000 封模拟邮件完成优先级、紧急度与部门路由。

这组数字能说明 Jev 在固定结构的批量判断中具有潜力，但不能被直接外推成“Jev 全面强于 DeepSeek”。数据集、网络、并发方式、提示结构、正确率判定与复现脚本都会影响结果。真正有意义的评测应该同时记录准确率、校准程度、延迟分位数、失败样本和业务后果。

视频中的连连看测试也揭示了另一个现实：Jev 的单次决策很快，不代表整个 Agent 就快。页面感知、DOM 解析、工具调用、等待与重试，都可能成为更大的瓶颈。模型延迟只是系统延迟的一部分。

我会怎样开始一个 Jev 项目

1. 先找一个重复、封闭、可判定的任务。例如“把工单分到四个队列”，而不是“帮我经营客服系统”。
2. 明确 state。只提供完成判断真正需要的事实；上下文不全时，模型无法凭空补齐。
3. 选对原语。类别互斥用 Choice，条件成立与否用 Noul，有序程度用 Score。
4. 给无匹配和不确定性留出口。候选项不完备时增加“其他 / 无法判断”，不要逼模型硬选。
5. 用历史样本定阈值。0.8 不是天然正确的分界线。误判代价越高，自动化阈值越应保守。
6. 把硬规则留在代码里。权限、金额、白名单、法务政策和不可逆动作不应依赖模型自由判断。
7. 记录输入、答案和最终结果。只有能回看错误，概率和置信度才有机会被真正校准。

最后的判断

Jev 最值得关注的地方，不是又多了一个模型名字，而是它提醒我：AI 组件不一定都要长成“会聊天的通才”。当问题已经能被压缩成有限选项、布尔判断或有序评分时，一个专门做决定的模型，可能比一个什么都能说的大模型更适合进入生产系统。

所以我不会把 Jev 看成通用 LLM 的替代品，而会把它放在两者之间：普通代码负责确定性，Jev 提供语义判断，通用模型处理生成与复杂推理。真正有价值的不是单个模型，而是把每类问题交给形状最合适的组件。