大模型圈正在发生一件安静但意义深远的事：不再让 AI 说话，而是让 AI 做决定。
过去两年，开发者们用 Instructor 把大模型的输出从自由文本变成了结构化的 JSON。Pydantic 模型、类型提示、自动重试——这些工具让 AI 的输出终于可以被类型检查器兜住。但从根本上说，Instructor 仍然是在帮 AI「表达」：你喂给它一段文字，它返回一个结构化的回答，回答本身依然是对用户输入的一种文本式回复。
2026年9月26日，Instructor 的作者 Jason Liu 在 GitHub 上发起了一个 RFC，提议在 Instructor 中增加「决策模型」支持。这听起来像是一个库的常规功能扩展，但它的底层含义要深得多：AI 应用正在从「生成内容」走向「做出决定」。而这一变化的首个落脚点，是那个连话都不会说的模型——Jev。
一个 RFC 透露了什么
9月26日，567-labs/instructor 的 Discussion #2706 上线。Jason Liu 提出为 Instructor 增加一套全新的运行模式：DECISIONS mode。
这套模式的核心思路是：不再是让大模型生成文本，而是让大模型在给定上下文的基础上，回答一组预定义好的类型化问题。每一个问题都有自己的类型约束——二分类（Noul）、多选（Choice）、打分（Score）——并且所有问题共享同一个上下文，一次性推理，一次性返回。
以内容审核为例。传统方案中，你需要写一段 prompt 告诉大模型「请判断以下内容是骚扰、仇恨还是其他」，然后从模型的文本回复中解析结果。如果格式飘了，解析就挂。而 DECISIONS 模式的做法是：定义一个 Pydantic 模型，每个字段都是一个类型化问题。category 字段是一个 Choices 枚举，policy_violation 字段是一个 Noul（返回 0–1 之间违规概率），severity 字段是一个 Score（0–10 分的严重度评分）。直接传入共享上下文，一个调用返回全部答案，每个答案都是类型安全的。
代码示例中，一行就建立了决策客户端。这套 API 首发对接的是 TypeSafe AI 的 Jev 模型和 OpenRouter。同时直接使用 TypeSafe API 也是支持的——只需要将 provider 换成 typesafe/jev-latest。
值得注意的是，这套功能目前仍处于 RFC 讨论阶段，尚未进入 Instructor 的正式版本。这意味着社区还有机会参与设计——这也正是 Jason Liu 将其以 RFC 而非 PR 形式发出的原因。
Jev：那个「不说话」的模型
Jev 是 TypeSafe AI 在 2026 年 9 月 15 日发布的「System One」模型。它最反直觉的设计是：不生成文本。
这不是什么修辞手法。Jev 真的不生成自然语言。你给它一个结构化的状态（state）和一组类型化问题（typed questions），它只返回选择、分数和概率分布。没有对话式的回答需要做 NLP 解析，没有理由需要剥离——开发者拿到的是可以直接用作程序控制流输入的数值。
Jev 出自 Diogo Almeida 之手。他是 InstructGPT 论文的同等贡献第一作者，也是 GPT-4 的贡献者。TypeSafe 将其训练方法命名为 RLCD——Reinforcement Learning for Calibrated Decisions。Almeida 认为，RLHF 优化的是「人类喜欢的回答」，RLVR 优化的是「可验证正确的结果」，而 RLCD 的目标是让模型决策的统计概率与其最终正确率相匹配。这个区分不仅是理论上的，它对整个 AI 应用的架构设计有深远的实际影响。
从定价看，Jev-1.13 的输入价格是每百万 token 0.042 美元——按 TypeSafe 自己的说法，大约是传统大模型的 1/100。输出完全免费，因为 Jev 几乎不输出内容。它的响应时间在 70 到 500 毫秒之间。这个定价逻辑本身就说明了一切：当一个模型只是用来「决定」而不是「表达」时，它的成本结构完全变了。
有趣的是，Jev 这个名字本身就藏着一个隐喻。TypeSafe 致敬的是杰文斯悖论（Jevons paradox）——当一种资源的利用效率大幅提升时，它的总消耗反而会增加。TypeSafe 的赌注不是「卖更便宜的聊天」，而是「让机器判断渗透到软件的每一个角落」。
生态接纳速度惊人。LangChain 在 9 月 17 日发布了 Jev 集成，其 TypeSafeClassifier 专为 Agent 路由、升级和工具调用决策场景构建。9 月 20 日，LangChain 发布了一项独立测试结果：Jev 在 500 个样本上匹配了人工审核者的每一次判断。Spring AI 在 9 月上线了 Spring AI TypeSafe 社区项目；OpenRouter、Requesty、Vercel AI Gateway 等多个网关在同一天就开始提供 Jev API。截止 9 月 26 日，已有超过 1,300 个社区讨论围绕 Jev 展开。
从「生成」到「决定」：AI 接口的范式转移
此前，大模型的 API 始终围绕「生成文本」设计。无论是 Chat Completions API 还是 Instructor 的 response_model，本质上都是把 AI 当成一个知识渊博的对话者。
但现实世界中的应用逻辑并不总是需要对话。
一个内容审核系统不需要 AI 写一段话告诉你「这段内容可能违反了我们的社区准则」。它只需要一个布尔值：违规或不违规。一个客户工单分类系统不需要自然语言的解释；它需要一个枚举值：退款、退货、投诉。一个风险评估工具不需要长篇分析报告；它需要 0 到 1 之间的一个分数。
把「文本生成」作为 AI 的唯一输出接口，本质上是成本不对称的：你为一个只需要输出 2 个 token 的任务支付了生成几百个 token 的推理成本，然后在外面再花额外工程成本去解析和校验。
Jev 加 Instructor 的 DECISIONS 模式打破了这种不对称。它将大模型从一个「会说话的专家」变成了一个「只做决定的引擎」。
对比传统方案：写 prompt 到输出文本再到解析 JSON 再到校验类型再到格式不对时重试——而 DECISIONS 路径只需定义 Pydantic 模型、传入上下文、拿到类型安全的答案。这个转变意味着 AI 可以直接嵌入程序的控制流中，而不是作为外部服务被调用后再后处理。
Anthony Maio 在其深度分析中将 Jev 描述为「一种学习的语义分支指令」——它处理模糊判断，而确定性代码保留对执行的控制。在笔者看来，这个表述或许是对 Jev 最准确的定位：它不是替换你的程序逻辑，而是在程序决策链中填补那个「需要看上下文才能决定」的模糊节点。
Instructor 的进化：从结构化输出到决策即基础设施
Instructor 自 2024 年 1.0 发布以来，在 GitHub 上积累了超过 13,800 个 Star，成为最受开发者欢迎的结构化输出库之一。它的成功在于用一个极其简洁的理念打穿了痛点：用 Pydantic 模型定义你想要的数据结构，然后 Instructor 负责让大模型按照这个结构输出。
DECISIONS mode 标志着 Instructor 的一次重大跳跃。
以往，Instructor 的所有模式（FUNCTION_CALLING、JSON_MODE、TOOLS 等）都在做同一件事：告诉大模型「请以这个格式回复」。回复仍然是文本生成。但 DECISIONS 模式引入了一个不同的假设——模型不需要「回复」，它只需要「回答」。
从 API 设计可以清晰地看到 Jason Liu 的意图。create_with_completion 返回两个值：一个经过类型校验的 Pydantic 模型和一个包含原始概率分布的 raw 响应。通过 raw.answers 可以获取每个问题的单独概率分布、置信度和原始 Score。这意味着开发者不仅得到了决策结果，还得到了决策置信度——而置信度不是赢家概率，而是整个概率分布形状的一个汇总值。不同分布可能得到相同的加权平均，所以 TypeSafe 的原始 API 同时保留了分布和解析后的数值。
一个值得关注的细节是 Noul 的 when_true 和 when_false 参数。它不是简单的布尔标签，而是允许开发者定义「什么样的输入应该返回 True，什么样的输入应该返回 False」，并配以具体示例。Choice 的每个选项也有自己的 description 和 examples。
这种设计把 prompt engineering 变成了类型注解的一部分。以前需要写在 prompt 里的样本和判断标准，现在变成了 Pydantic 模型的字段描述。这不仅仅是 API 层面的改进，更是将「AI 行为规范」从运行时文本转移到了编译时类型系统——IDE 的自动补全、类型检查和静态分析，第一次能够触及「AI 应该如何做决策」这个问题。
谁需要决策模型
DECISIONS 模式不是解决所有问题的万能药，但它精准地切入了几个最痛的场景。
内容审核与安全。OpenAI、Google、Meta 每年花费数亿美元在内容审核上。DECISIONS 模式让开发者可以用一个调用同时完成分类、违规概率评估、严重度评分，全部结构化的，可以直接接入人工审核工作流。Jason Liu 在 RFC 中给出的样例就是内容审核——这不是巧合。
路由与分类。在 Agent 架构中，模型需要在不同工具之间做路由选择。传统做法是让 LLM 用 function calling 决定用哪个工具，但 DECISIONS 模式允许开发者显式定义 Choice 选项并附上示例，路由决策的准确性和可解释性都更高。LangChain 的 TypeSafeClassifier 已经直接在这个场景上做了集成。
评估与护栏。当 AI Agent 变得复杂，评估另一个 AI 的输出成为刚需。Jev 的定位是「在每次聊天调用前面放一道便宜的门」。每次调用只需 70 到 500 毫秒，成本为每百万 token 0.042 美元——它可以作为哨兵模型，在每次推理前后快速判断输入和输出是否符合安全策略。Almeida 之前的研究中提过一个核心区分点：一个 AI 助手可以给出人们喜欢的回答，而不提供软件可靠行动的基础。自动化需要的是能够指导行为的概率，而令人安心的语言做不到这一点。Jev 就是从这个认知中长出的产品。
不确定性的处理哲学
DECISIONS 模式与传统的 LLM 调用还有一个根本区别：它把「不确定」变成了类型的一部分。
当你问 GPT-4o「这段内容是否违规」，你得到的是一段文本，其中无论是「是的」还是「不确定，让我分析一下」都只是字符串。但 DECISIONS 模式下，policy_violation 字段返回一个 0.84。这不是一个二值判断——它是一个概率。你的代码可以在这个概率上设置阈值：0.80 以上送入人工审核，0.95 以上直接拦截，0.50 以下放行。
OpenRouter 的 Jev 教程中指出了这种设计的一个关键细节：置信度不是赢家概率的置信度，而是整个概率分布形状的汇总值。在内容审核的例子中，如果模型在「骚扰」和「仇恨」之间犹豫不决，即使「骚扰」的绝对概率最高，置信度也会偏低。这意味着开发者获得的信息比「模型选择的结果」要多得多——他们能看到模型在哪些选项之间摇摆，以及摇摆的程度。
这种设计迫使开发者显式地处理不确定性，而不是假装模型总是对的。在生产环境中，这可能比提升 1% 的准确率更重要。
独立验证：它到底有多准
截至 2026 年 9 月底，关于 Jev 最值得关注的独立测试来自 Beri 团队。在 2,000 封钓鱼邮件识别测试中，当 Jev 被问一个笼统的问题时，准确率仅为 62.6%。对比之下，Claude Haiku 4.5 在同一数据上达到了 81.3%。这看起来不是一个好消息。
但当 Jev 被配置为将同一任务拆解为 5 个窄问题，并且在 1,000 个样本上拟合权重后，在另外 1,000 个样本上，它的准确率达到了 95.0%。成本仅为 Haiku 4.5 的 1/12 到 1/27。
这个对比揭示了一个反直觉的真相：Jev 的能力不在「单次回答的准确率」上，而在「你可以为它设计一个决策分解方案，然后用极低的成本做大量并行判断，最终在系统层面取得更好的效果」。它像是一把需要调音的乐器——调好了，效果惊人；不调，远不如直接用一把现成的。
LangChain 的独立测试给出了另一个数据点：在 500 个 Agent 评估样本上，Jev 的判断与人工审核者完全一致。但同样需要说明，LangChain 作为集成方有动机展示 Jev 最好的一面。
两个测试的共同点是指向同一个结论：Jev 的效果高度依赖于「问题设计」的质量。这不是一个即插即用的模型——它是一个需要开发者投入精力去定义的决策引擎。
谁会被影响
DECISIONS 模式不会立即改变大模型的整体格局。它解决的是一个特定但高频的问题：需要快速、低成本、可预测的决策，且输出必须直接对接程序控制流。
受益者首先是 TypeSafe 这样的新 AI 公司。Jev 的存在证明了「非生成式 AI」也有巨大市场空间，且它不是为了抢占聊天模型的市场——它是为聊天模型无法触及的场景开辟新赛道。OpenRouter 等网关作为分发平台也将获得更多的模型多样性。
受到最大冲击的可能是那些「用大模型完成分类和路由任务」的传统做法。Beri 的测试显示，Jev 在分解决策后可以超过 Haiku 4.5 的精度，而成本只有后者的不到 1/10。在这种成本落差下，大量分类和路由任务的 ML 推理栈将被重写。不是所有任务都需要替换，但每一个每月处理百万级请求的分类系统，都值得重新算一遍账。
对于 Instructor 本身，DECISIONS 模式是一次关键的差异化。在 PydanticAI、LangChain 等竞品还在围绕文本生成做文章时，Instructor 率先进入了「决策即基础设施」的领域。这会将它从一个「结构化输出工具」升维为一个「AI 决策框架」。
三个不可忽视的问题
第一，也是最大的问题：Jev 的精度和校准度至今没有独立的可验证结果。正如 Anthony Maio 在其深度分析中所言，「截至 2026 年 9 月 15 日，TypeSafe 已经描述了 RLCD 的意图，但没有发布足以让任何人评估该算法的信息。奖励函数、架构、训练过程、校准方法论——全部未公开。没有校准曲线，没有独立可复现的论文。」Beri 的测试也指出，Jev 的概率在不同问题上需要重新校准，且 TypeSafe 没有发布任何校准误差（ECE）数据。在独立验证出来之前，Jev 的一切效果承诺都是单向的。
第二，DECISIONS 模式依赖模型本身对「定义」的理解能力。如果你的分类问题本身就边界模糊——比如「这篇文章是否具有攻击性」和「这篇文章是否构成骚扰」之间的界限——模型返回的 0.84 概率可能更多反映的是问题定义的不确定性，而非模型对输入文本的理解。Beri 的测试已经表明，同一个问题拆成 5 个窄问题和 1 个笼统问题，效果差距超过 30 个百分点。使用 DECISIONS 模式的开发者需要对「问题分解」和「权重拟合」投入大量精力，这和写 prompt 一样是一门手艺，甚至更难——因为你的输出不是一段人类可读的文字，而是一组需要被代码精确处理的数值。
第三，生态锁定风险。当前的 DECISIONS 模式首发对接 Jev。Choice、Noul、Score 这些底层概念是 TypeSafe 定义的，而非大模型通用的接口标准。如果开发者将决策逻辑与 Jev 的特定行为深度耦合——比如在特定阈值上拟合了权重——那么将来换模型时，整个决策流水线都需要重新测试和调优。Instructor 的抽象层能做到什么程度，目前还是未知数。
结语
如果 2024 年属于「让 AI 说对的话」，2025 年属于「让 AI 听懂人话」，那 2026 年正在发生的第三件事也许更加安静，却更为根本——让 AI 不再说话，只做决定。Instructor 这条 RFC 正在为这种「少说多做」的 AI 搭建第一块基础设施。而 Jev 的那个名字，或许已经暗示了最终的结局：越来越便宜、越来越快的机器判断，终将渗透到软件的每一个毛细血管——不是因为它们更聪明，而是因为它们只做一件事，且从不开口。
快报