9 月 22 日，Hacker News 出现一篇标题很挑战的帖子：「Jev in 25 Lines of Python」，作者用 Qwen3-0.6B 加 25 行代码演示了 Jev 的核心工作机制，帖子拿下 138 分。要理解这段代码为什么能引起共鸣，得先回到 Jev 本身：这是 TypeSafe AI 在 9 月 15 日发布的「系统一模型」（System One Model），一类专门做结构化决策的模型。它不生成聊天文本，收到输入后直接输出类型安全的决策结果和校准过的概率。官方给它的定位是一行话：非结构化状态进，类型化的概率决策出（frontier-intelligence function call）。
传统路线的瓶颈在哪里
TypeSafe 创始人 Diogo Almeida 曾在 OpenAI 参与让语言模型学会遵循指令的研究，这部分工作后来成了 ChatGPT 背后的研究基础。他在官方博客里解释了创业的出发点：聊天模型已经superhuman多年，但自动化没有随之爆发，缺的是能让软件直接消费的决策接口。
现有 LLM 的输出是字符串。程序要用这个输出，得经过解析和校验，还要承受模型偶尔跑偏的风险。官方博客给出一组对比：前沿模型端到端响应时间 3 到 329 秒，输出 token 单价比输入贵约 5 倍；对自动化场景来说，这两个数字都是瓶颈。Jev 的思路是把延迟压到 70ms 到 500ms，输入价格定在每百万 token 0.042 美元，输出侧因为不生成字符串、只返回既有选项的概率分布，边际成本接近于零。
训练方法上，TypeSafe 提出了 RLCD（Reinforcement Learning for Calibrated Decisions），替代 RLHF/RLVR：优化目标从「人类偏好的回答」换成「带认识论诚实概率的校准决策」。采样方式也是并行的，所有输出在一次查询里同时给出，与 LLM 逐 token 自回归生成的方式完全不同。
25 行代码的核心机制
NobodyWho 博客的 Duarte O.Carmo 用 Qwen3-0.6B 的 GGUF 版本演示了这套机制的最小实现。作者自己标注这是一篇 parody（戏仿），用来回应当时铺天盖地的 Jev 讨论，但代码本身完整展示了「决策模型」和「生成模型」的分界线。
第一步，加载模型，关键是 logits_all=True：
model = Llama.from_pretrained(
repo_id="Qwen/Qwen3-0.6B-GGUF",
filename="Qwen3-0.6B-Q8_0.gguf",
n_ctx=512,
logits_all=True,
verbose=False,
)第二步，把分类任务写成 prompt。选项以 A. Legitimate / B. Spam / C. Phishing 的形式放进 user 消息，assistant 消息只留一个空的 <think> 块收尾。这个空块的用途是占住位置：模型在这个位置之后要产出的第一个 token，就是对选项的选择。
labels = ["A", "B", "C"]
choices = ["Legitimate", "Spam", "Phishing"]
email = "Payroll asks for your password on a non-company sign-in page."
options = "\n".join(
f"{label}. {choice}" for label, choice in zip(labels, choices, strict=True)
)
prompt = f"""<|im_start|>system
Choose one option.<|im_end|>
<|im_start|>user
Email: {email}\n\n{options}<|im_end|>
<|im_start|>assistant
<think>\n\n</think>\n\n"""
model.eval(tokens=model.tokenize(text=prompt.encode(), add_bos=False, special=True))第三步是全部机制的关键：取最后一个 token 位置上的 logits，只挑出 A、B、C 三个 token id 对应的分量，做 log-sum-exp 归一化：
logits = model.scores[model.n_tokens - 1]
token_ids = [model.tokenize(text=label.encode(), add_bos=False)[0] for label in labels]
choice_logits = numpy.asarray([logits[token_id] for token_id in token_ids])
logprobs = choice_logits - numpy.logaddexp.reduce(choice_logits)
probabilities = numpy.exp(logprobs)
# Logits: {'Legitimate': 26.254, 'Spam': 27.262, 'Phishing': 29.614}
# Log probabilities: {'Legitimate': -3.482, 'Spam': -2.474, 'Phishing': -0.122}
# Probabilities: {'Legitimate': 0.031, 'Spam': 0.084, 'Phishing': 0.885}一封要求在非公司登录页提交密码的邮件，模型给出的钓鱼概率是 0.885。整个过程只做了一次前向传播：没有自回归循环，没有生成任何一段解释文字，程序拿到的是可以直接写进 if 语句的概率。
这段代码揭示了决策模型和生成模型的分界线。生成式路线要做同样的事，通常让模型输出一段 JSON 再解析；决策式路线把选项编码进 prompt 结构，直接读特定位置 logits 向量的一个切片。输出永远是候选集上的一个概率分布，类型错误在数学上不可能出现，这也是 TypeSafe 官方博客把「无类型错误」列为核心卖点时给出的证明方式。
未校准的 0.6B 与真 Jev 的差距
25 行版本展示的是机制，不是完整产品。作者在文中列出了自己没有做的事：没有做 RLCD 校准训练，没有构建合成数据，没有并行采样基础设施。0.6B 基座模型的原始概率并不可靠，某个候选在未经校准时给出 0.9 以上的置信度，不代表它有 90% 的准确率。
校准正是 TypeSafe 声称的核心资产，而开源社区很快给出了可对照的数字。Jared Palmer 的 Kev 项目（GitHub 4.6k star）基于 Qwen3.5 训练了 0.8B、4B、9B 三个决策模型，API 与 TypeSafe 的 System One 完全兼容。在其评测集上，Jev 的新数据源准确率是 0.857、Brier 分数 0.211；Kev-9B 达到 0.852（测试集）、Brier 0.237。校准处理上，Kev 给每个检查点拟合一个约 2.1 到 2.4 的温度系数，让 Kev-9B 的高置信错误率从 8.7% 降到 4.0%，Jev 的这个数字是 3.7%。
Kev 的 README 同时诚实地记录了这类小模型的边界：知识问答差距明显（MMLU 上 Kev 0.74 对 Jev 0.90，MMLU-Pro 上 0.52 对 0.84，且这个差距由基座模型决定）；改变选项顺序可能改变答案；日期算术需要额外处理。这些局限同样适用于理解「决策模型能做什么」：它们擅长在给定框架内做判断，不擅长补充框架外的事实。
官方评测里的位置
TypeSafe 发布了一套 workflow evals：给定一个用代码写死的计算图（工作流），让各模型对图中的每个决策点给出概率，以 GPT-6 Astra 和 Fable 5.1 的平均输出作为参考概率，衡量各模型与「最强模型共识」的吻合度。
散点图里，Jev 位于最左上：约 68% 的平均吻合度，单次工作流成本低于 0.001 美元，是全图成本最低的点；吻合度更高的 sol（74%）和 opus 5（约 73%）成本高出约两个数量级，官方在图上画出了「nothing is both cheaper and more accurate」的前沿线。首页「193.6 倍快、444.6 倍便宜」的口号就来自这套评测，官方同时注明这是偏高端的估计，且评测工作流由自家能力团队制作，可能存在偏向。
两类错误率数据补充了细节。结构化输出错误率上，Jev 为 0%（模式匹配由数学保证，非实测），GPT-6 系列的 luna/terra/sol 在 0.6% 到 0.8%，Fable 5.1 为 8.5%，haiku 4.5 高达 45.6%。工具调用错误率上，Jev 同样为 0%，opus 5 为 0.6%，而 GPT-6 的 astra 和 sol 分别是 16.6% 和 17.0%。
官方公开的最简单一个工作流是安全告警处置：一条未授权活动的告警进来，经过 Triage（三读告警与关联记录）、Disposition（决定关闭、排队还是上报）、Containment（判断凭证、会话、持久化等风险维度的处置级别）、Playbook（按条件触发一系列处置动作）四个阶段，中间穿插大量布尔判断、评分和多选决策，最终落到 close、queue、page、轻度隔离、重度隔离这些离散动作上。
这类工作流的可靠性依赖细粒度概率而非单次离散判断，官方对生产级用法的描述也在此：最可靠的场景通常由许多相互独立的分解问题组成，行为依赖概率阈值而非单点结论。
生态的两种玩法
围绕 Jev 出现的开源复现走了两个方向。Kev 代表「正经复现」：完整训练代码、评测数据、温度校准、支持 CUDA/ROCm/Apple Silicon（MLX），4B 和 9B 模型能在 32GB 内存的 Mac 上本地运行，服务器 API 与 TypeSafe SDK 直接兼容。
另一个方向更具实验性。Kyle Pena 的 jevchat 把方向反过来：既然 Jev 能对任意选项集合输出概率分布，那把「下一个字符是什么」当作选择题反复问，就能把决策模型变回一个生成模型。项目实现了 choice、bisect、buckets、refine 四种采样策略和 beam search，其中 hypothesis 呈现方式（把候选字符追加到已有文本后再让模型对完整句子打分）让字符级任务的成功率提升约三倍。代价是生成一个字符需要多次 API 调用，作者自评成本「somewhat impractical」。这个实验从反面验证了 Jev 放弃字符串生成的合理性：决策模型的结构（一次前向、全量概率）对生成任务是一种昂贵的错配。
社区对 Jev 技术底座的判断也趋于一致。Arcturus Labs 的分析文章指出，OpenAI 从 tool calling 诞生起就在用 LLM 做隐式分类：assistant 消息开头第一个 token 预测换行还是 to=function.，本身就是一次二分类；选择调用哪个工具是又一次分类。Jev 把这类分散的 micro-classifier 泛化成了独立产品，而真正构成护城河的是训练数据（大规模「输入与已知真实结果」的配对数据）和 RLCD 流程，这部分外界无法直接验证。
对开发者的实际含义
把这场讨论收敛到工程视角，Jev 类模型改变的是 AI 应用中「判断层」的构建方式。此前判断类需求（路由、审核、评分、重排）普遍复用生成式模型，调用一次 LLM、解析一段 JSON，为的是拿一个布尔值或类别标签。决策模型把这一层拆成了独立组件：毫秒级延迟让它能进实时链路，校准概率让阈值驱动的设计变得可行（概率高于 0.8 进人工审核，低于 0.5 自动放行），按次计费的成本结构让高频调用不再受 token 价格约束。
Kev 的存在同时给出了另一个信号：这套模式在开源侧已经可以本地复现，0.8B 到 9B 的模型在消费级硬件上可跑，API 兼容 TypeSafe 官方 SDK。对要处理敏感数据、不能外发的场景，这意味着决策层可以完全留在本地基础设施里。
当然，这类模型的适用边界同样清晰：判断框架需要预先定义（候选集、评分刻度、布尔问题），框架外的事实补充仍依赖生成式模型；选项顺序敏感性、知识问答的短板都记录在 Kev 的评测里。未来一段时间的看点在于两条路线的融合方式：是独立决策模型成为 AI 应用栈的标准一层，还是如 Arcturus Labs 预判的那样，前沿实验室把这套校准分类能力折叠进通用模型内部。从 Vercel 的观察（Jev 是 AI Gateway 历史上采用速度最快的模型）来看，这个方向的需求已经被市场验证，剩下的问题是它最终以独立组件还是模型内能力的形式普及。
资料来源：TypeSafe AI 官方博客（2026-09-15）、NobodyWho《Jev in 25 lines of Python》（2026-09-22）、jaredpalmer/kev 与 kyle-pena-nlp/jevchat 的 GitHub README、Arcturus Labs 分析文章（2026-09-21）。评测数字均为各项目官方口径，Kev 与 Jev 的对比因训练数据集不同而非严格受控实验。