Jev 一夜爆火

刚在《自然语言就是新的程序设计语言》里谈到 Karpathy 对软件的划分：1.0 是人写代码，2.0 是从数据中训练出模型，3.0 是用自然语言给模型指定任务。

这周，到处都有人想拿 Jev 做点什么。第一次看到 TypeSafe 的发布文，我却没那么兴奋。System One Model、frontier intelligence、can’t hallucinate，几个词看下来，我冒出的念头是：这不就是分类器吗？给一段文字，从几个选项里挑一个，再带上概率。上过机器学习课的人，对这个太熟悉了。

后来我觉得，自己可能又犯了那篇文章里说过的毛病。知道这东西怎么来的，就容易忽略别人第一次用到它是什么感觉。分类器不新鲜，但一个从来没训练过模型的人，现在写几句说明，就能把它接进自己的小工具里，确实也是一个令人兴奋的体验。

只做判断

先不用管 Jev 的底层架构，官网也没有 Open Source 或者 Open Weight。对使用者来说，可以把它看成一个函数：把相关信息、问题和允许的答案交给它，它返回判断和概率。

比如我想给记账软件加一个自动分类功能。输入可以是这样：

消费记录：Uber Eats ¥2,380
问题：这笔消费属于哪一类？
选项：餐饮 / 交通 / 购物 / 娱乐 / 其他

程序拿到的会是选项以及各选项的概率，可以直接用来决定如何入账。

Jev 目前提供三种问法：Choice 从最多 255 个选项里选一个；Score 按你定义的 2 到 10 个有序等级评分；Noul 返回一个是非问题中“是”的概率，再由代码决定怎么处理。它不提供自由文本生成，也不会解释自己为什么这么选。

TypeSafe 把它叫作 smart if-statement。很多判断，规则写起来很烦，人却一眼就知道大概。Jev 想接手的就是这种难以人工编码的直觉。

普通 LLM 当然也能做。通过结构化输出，它也可以只给分类结果，不必先写一段客套话。Jev 值不值得用，要看完成同一个判断时，它的正确率有多高。毕竟更快地做出一个错误的决定，并非一件好事。

省在哪里

以前要给消费分类，可以写规则，也可以训练模型。用传统机器学习做这件事，收集样本、标注、训练和维护是一笔不小的成本。

Jev 省掉的是为每个新任务单独训练模型这一步。你写好问题和判断标准，就能先试起来。按目前官方定价，每百万输入 token 收 0.042 美元，输出免费。假设一次请求总共用了 1,000 个输入 token，一万次调用的模型费用是 0.42 美元。

相比 LLM，这很便宜。不过，用 Jev 也要整理输入、测试错误、维护分类标准，这些成本不会出现在 API 账单上。

更要看的是尝试成本。一个想法还不值得专门训练模型，却已经值得花一点时间写好问题、调一次接口。记账、邮件整理、工单分派，都是这种小需求。

早期也有零样本分类器，比如 BART-MNLI。它经过专门训练，学会判断两句话的关系：前一句能不能推出后一句，两句是否矛盾，还是信息不足、无法判断。这叫自然语言推断，NLI。

比如想知道某个报道的主题是“体育、财经还是科技”，程序就把三个类别分别填进固定句式：“这段文字讲的是体育”“这段文字讲的是财经”“这段文字讲的是科技”。然后把原文分别和这三句话配对，交给模型判断。如果原文是“这支球队赢得了冠军”，模型就应该更支持第一句，于是程序把它归到“体育”。

它的 trick 就在这里：把分类问题改写成模型已经学过的句子关系判断。换一组类别，只要换掉句式里的词，不用再拿新类别的样本训练模型，所以叫零样本分类。它仍然是一个 Software 2.0 式的模型，通过巧妙地改写输入，获得了通用性。这和今天 LLM 能按自然语言指令处理各种任务的通用能力，还是有距离。

Jev 想做的，是把更广泛的语言理解能力放进一个便宜、快速的判断接口里。它真正要回答的是：换一个任务，能不能靠几句说明就用起来。它是不是第一个零样本分类器，没那么重要。

为什么是 Software 2.5

同一个 Jev 模型，今天给消费分类，明天给 issue 分配负责人，换一段问题和选项就行。当前官方服务不支持按客户数据做 fine-tune，各账号使用相同权重，行为通过输入和判断标准来调整。

叫它“2.5”，说的是它在程序里的用法：它像 LLM 那样允许你用自然语言写问题和判断标准，接入之后，它又像一个传统分类器那样，只负责流程中有限的几个判断。它想要接近 3.0 的任务适应性，同时保留 2.0 的成本和速度。

区别在于模型能不能理解你新写的判断逻辑，而不只是换几个标签。至于要不要搭流程，并不能拿来划代，LLM 应用一样要写流程和业务代码。

比如客服收到一条留言：“耳机左边没声音，换了手机也一样。”你可以让 Jev 在“故障反馈、使用咨询、购买咨询、其他”里选一个。各类怎么定义、分到哪支客服队伍，由你事先写好；它负责读这句话，判断更接近哪一类。

这种用法可以理解成语言直觉：读一段描述，直接判断哪个答案合适。有点像大模型不展开思维链、直接作答时的状态。它能做语义判断，并不意味着它就能一步步推导出答案。

日期比较、精确计算、寻找最优交通路径，这些工作应该交给代码和相应的算法。TypeSafe 的 jaggedness 文档也写了当前版本在计算、日期和多层间接关系上的短板，以及无关上下文对判断的干扰。拿它做什么，要看问题本身需要什么，不能只看最后的答案是不是一个选项。

《Jev 全网首测 benchmark 与架构解析》里做了两组测试，总共 400 道题。我看过原始测试数据：200 道简单单选题全对；另一组是 40 个问题族，每族 5 个变体，共 200 道题，需要从长文本里抓住关键事实，准确率只有 32.5%。这个数字很微妙，因为四个选项随机也有 25% 的概率。

有些变体把决定答案的关键事实反转了，它还是选原来的答案。在这组题里，置信度也没能可靠地区分对错。简单题上看着很稳，一遇到藏在长文本里的条件变化，就可能给出很笃定的错误判断。

这对接入方式有直接影响。测试时要专门改动那些本应改变答案的事实，看模型会不会跟着改。只拿几道一眼就知道答案的题来演示，看不出这种问题。

要把 Jev 用好，输入也得先整理。比如给消费分类，我会从邮件里取出商户名、商品描述等相关信息，去掉签名、广告和无关记录，再写清楚“餐饮”“购物”这些类别的边界。官方文档也建议先用代码筛选信息，只把当前判断需要的内容交给模型。

挑信息、组织输入这部分，让我想起 Software 2.0 时代做传统分类器时的 feature engineering，也就是特征工程。那时要把原始数据加工成有用的特征；现在可以用自然语言和结构化字段，把判断所需的信息交给 Jev。模型替你省掉了很多工作，但哪些信息值得看、该怎样组织，仍然需要你理解自己的业务。

再准备一批自己知道答案的真实样本，检查误判，调整问题、类别定义和置信度阈值，才算把它接进了程序。Jev 省掉了针对每个任务训练模型的步骤，但围绕模型做这些准备的功夫，还是很有 Software 2.0 的味道。

最自然的架构是：固定规则 → Jev → 大模型兜底。 能用写死的代码处理的，先交给成本最低的代码；规则处理不了、需要理解语义的，再调用 Jev；Jev 置信度低，再交给大模型判断。

营销确实厉害

我对 Jev 在技术上的 moat 还持保留意见，但这个产品的需求是真实存在的，至于为什么这么火，那我们得谈一谈营销了。

先说技术。复刻的门槛不高，开源实现已经冒出来了。Laya 用 4 亿参数的 ModernBERT 做底座，Apache 2.0 许可，还自带一个和 Jev 同协议的 HTTP 服务，原来调 Jev 的代码改一下 baseUrl 就能换过去。还有人直接拿千问的开源模型改一改：Kev 在 Qwen2.5-0.5B 上加了一个 LoRA 和一个小的打分头，Jeff-1 是 Qwen3-4B 的 LoRA，都提供同样的 Choice / Score / Noul 接口。当然，接口一样不等于判断一样准。Laya 自己公布的对比里，选项超过 20 个时就明显不如 Jev。

Jev 的名字取自 William Stanley Jevons，TypeSafe 在发布文里明确说了这个来历。杰文斯悖论讲的是，效率提高之后，新增需求可能超过节省下来的消耗，最后资源反而用得更多。我在《AI 不是节约型创新》里也讨论过这一点。

这个名字取得真好。它和 Claude 一样，有个人名的亲近感，短，好记，叫起来顺口。背后的 Jevons 又让人立刻想到每一个押注 AI 规模继续增长的投资者都希望成真的故事：智能越来越便宜，用它的人和地方越来越多，新增需求大到足以抵消效率提升省下的算力。

还有 System One 这个定位。大模型刚出来时，就有人说它是 System 1，靠直觉和联想直接给答案。Bengio 和 Edward Hu 在 2023 年的一篇文章里就写过，很多人把语言模型比作 System 1，期待未来的 System 2 来处理可靠的推理。到了 o1、DeepSeek R1 这一波推理模型，慢思考成了卖点。2025 年甚至有篇综述，题目就叫《从 System 1 到 System 2》。

现在 Jev 又来做 System One。这个位置找得很巧：让大模型去慢慢推理，自己负责快速判断。这样一讲，输出能力有限就成了一种分工，便宜、快也和“直觉”这个说法对上了。一个判断接口，听起来成了智能系统里值得单独做出来的一部分。

这套说法很会抓人。但 System 1 和 System 2 在这里终究是比喻。它能帮助人理解产品，证明不了 Jev 的内部机制，也不能替它回答前面那些长文本测试。研究里用了多年的说法，到了产品发布时，又成了一个新品类的名字。

发布文里所谓的“没有幻觉”也是如此。答案 100% 落在预先规定的类型和选项里，因为这个约束就是普通的代码，也就是 Software 1.0。“没有幻觉”不代表判断是对的。

更要紧的是它对置信度的承诺。TypeSafe 在发布文里明确写道：“Calibrated: higher confidence means higher accuracy.” 置信度越高，准确率越高。它还拿普通 LLM 来对比：如果模型不知道自己什么时候会错，就没法放心拿来做自动化。使用文档也建议按置信度分流，高的自动处理，低的交给人或其他系统。这是它的一项核心卖点。

前面那些关键事实反转的题，正好考验这个承诺。答案错了，置信度却仍然很高，意味着按置信度分流时，这些错误可能直接被程序放行。问题落到了它承诺解决的地方：模型犯错时，能不能提醒你别信它？至少在这组测试里，这个信号没有起到应有的作用。要验证这个卖点，得把高置信度的答案单独拿出来，看看究竟对了多少。

还有那两个很适合做标题的数字：快 193.6 倍，便宜 444.6 倍。TypeSafe 的发布文交代了，这是自家 workflow 评测的结果，而且偏向实际收益的高端。这套评测预先写好流程，再比较各模型在流程里的判断，参照标签来自 GPT-6 Astra 和 Fable 5.1 这两个旗舰模型的平均输出。它可以说明这些流程里的表现；转发时如果只剩两个倍数，适用范围就丢了。

官方发布之外还有一些纯噱头，可以说是造假。我看过的“用 Jev 瞬间生成网页”，组件其实已经预先写好，Jev 只负责选模块；拿来对比的 LLM，却要从头生成网页代码，这种方法未免对 LLM 太不公平。

还有一个 Minecraft 通关演示：通关流程已经写死在程序里，就算把 LLM 和 Jev 都拿掉，也不影响通关。

我个人的应用场景

最贴近我手上工作的，还是记账软件 PocketBean。邮件里进来一笔消费，最后需要的是一个分类。如果 Jev 在我自己的记录上够准，这种地方就值得试。分类也得先约定清楚：Uber Eats 买的一顿外卖，我会归“餐饮”；买菜则可能单列。模型再便宜，也不会自动知道我的记账习惯。

还有派单。我在做的 Bonsai 需要把不同请求交给合适的模型；给 coding agent 派活用的 Multica，需要判断一个 issue 该交给谁。它们都可以拿来做对比实验。不过，“哪个模型适合这个请求”比挑出一个模型名难得多，后面的任务有没有做成，才是路由对不对的依据。

我看到 Jev 的第一反应，其实是让它当海龟汤主持人。玩家一轮轮提问，主持人根据汤底回答“是”“不是”或者“无关”。答案范围刚好很小。

然后我搜了一下，发现已经有人做了。比如 Soupbase，就把 Jev 接进了海龟汤的提问判定。得益于 Jev 的能力，还支持用户提交自己的题目。大家可以点进去玩玩看。

自己试一下

下面的接入信息核对于 2026 年 9 月 23 日。价格、注册条件和接口仍可能调整。

  • TypeSafe 官方控制台：直接接入的入口，注册资格和赠送额度以当时页面及账号显示为准。
  • Vercel AI Gateway：模型 ID 为 typesafe-ai/jev。当前页面标注输入、输出免费，促销于 2026 年 9 月 25 日结束。
  • OpenRouter 教程：模型 ID 为 typesafe/jev-1.13，使用专门的 Decisions API。

下面是一条 Vercel 请求示例；接口形状可对照其 HTTP API 说明。运行前需要设置自己的 AI_GATEWAY_API_KEY，大家可以看一下 Response，马上就能理解 Jev 是什么了。

curl https://ai-gateway.vercel.sh/v1/evaluate \
  -H "Authorization: Bearer $AI_GATEWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "typesafe-ai/jev",
    "state": "Uber Eats ¥2,380",
    "questions": {
      "category": {
        "type": "choice",
        "instructions": "Which category does this transaction belong to?",
        "criteria": {
          "Food": "meals, groceries, restaurants, food delivery",
          "Transport": "trains, taxis, ride-hailing, fuel, parking",
          "Shopping": "clothes, electronics, household goods, online retail",
          "Entertainment": "movies, games, concerts, streaming subscriptions",
          "Other": "expenses that do not fit any of the categories above"
        }
      }
    }
  }'

延伸阅读

  • Diogo Almeida, Introducing System One Models and Jev（TypeSafe, 2026-09-14）——发布文。三种问法、价格、评测方法，以及他们给每个结论标注的 nuance；名字的来历在文末 FAQ。
  • TypeSafe, Jev 1.13 jaggedness（2026-09-17 修订）——官方列出的九种短板：计算、日期、无关上下文、对抗文本……比发布文更值得读。
  • Andrej Karpathy, Software 2.0（Medium, 2017）——2.0 的原始定义。
  • W. S. Jevons, The Coal Question（1865）——Jevons 悖论的出处，也是 Jev 名字的来历。
  • Daniel Kahneman，《思考，快与慢》（中信出版社，2012；原著 Thinking, Fast and Slow, 2011）——System 1 / System 2，System One Model 这个名字的来历。
  • What If We Put AI in the State Machine?（2026-09-20）
  • B 站视频：400 道题实测 Jev——简单单选 100%，长文本抓关键事实 32.5%，以及对架构的推测。
  • Intelligent Artifact, Introducing System One Models and Jev（2026-09-16）——Hacker News 四百多条评论的整理：它到底新在哪。
  • 编程范式的背景（Software 1.0 / 2.0 / 3.0）见自然语言就是新的程序设计语言；Jevons 悖论与“按任务而不是按技术分”见《AI 不是节约型创新》。