作者：Founder Park

过去一周，Jev 成了整个 AI 圈最火的新模型。

主打 System One 快思考，只负责「判断」，基于 RLCD 的方式，只输出选择、概率和置信度。创始人 Diogo Almeida 曾在 OpenAI 参与 InstructGPT、ChatGPT 和 GPT-4 等研究，也是把 RLHF 推向大规模应用的核心研究者之一。离开 OpenAI 后，他选择了几乎相反的方向，不再训练一个更会说话的模型，而是做一个完全不生成文字的模型。

Jev 背后的公司叫 TypeSafe。9 月 15 日，TypeSafe 结束两年隐身期，发布 Jev，同时宣布完成由 DCVC 领投的 4000 万美元种子轮融资。

Jev 到底意味着什么？一种模型研发的新思路，还是解锁了更多应用的可能性？这些问题，可以从 Diogo Almeida 目前的几次公开表达中得到一些解答。

两次表达连起来，能看到他从「我们为什么需要一种新东西」走到「这个新东西具体长什么样」的具体思考。

Foundation Capital 合伙人 Jaya Gupta 则把 Jev 放进一场更大的变化中。在越来越智能、越来越昂贵的模型面前，Jev 带来的，可能是一场新的「智能大拆分」。

以下内容结合 Diogo Almeida 的公开演讲、播客访谈，以及 Jaya Gupta 的文章，经 Founder Park 编辑整理。

01 今天的 Agent，只会给出讨好人类的回应

Jev 发布前的一个多月，Diogo Almeida 做过一场关于「RLHF 之后是什么」的演讲。他没有公开产品细节，只是提出了 TypeSafe 正在思考的问题：如果一整套 AI Stack 都围绕可靠性和自动化重新设计，它会变成什么样？回头看，那场演讲中的一些判断，已经落在了 Jev 的训练目标和产品形态上。

我可能是 OpenAI 少数几个会批评 ChatGPT 的人。我不讨厌它，我认为 ChatGPT 是一个改变世界的产品，我也会继续用。但我承认它的局限。今天整个领域的许多现象，都可以追溯到我们当初设计 ChatGPT 背后算法时做的一些细微决定。

现在所有做 AI 的人都绕不开一个问题：到底发生了什么？一边，模型在几乎每个 Benchmark 上不断进步，能够自主运行的时间也越来越长。另一边，一些看起来简单得多的工作仍然需要人。我们怎么能解决尚未解出的数学问题，客服却仍然需要人在 loop 中才能真正做出决定？

我认为最简单的解释是，那些表现惊人的任务，本来就是为了取悦处在 loop 中的人。Claude Code 的工作不只是让代码能够运行，否则它和人对话的方式会完全不同。另一边，那些看起来基础得多的任务，目标恰恰是把人移出 loop。理想情况下，它应该在一台你甚至不会去看的服务器上后台运行。

这就是辅助（assistance）与自动化（automation）之间的分界。

RLHF 的基本方法是收集人类偏好，再针对人类偏好优化。我觉得「为什么 LLM 总需要人在 loop 中」的答案几乎写在这里，我们真的把人放进了训练 loop。它的目标是让人满意，而不是让软件自主运行。

我很喜欢一个例子。有人给 ChatGPT 发了一段放屁音效，问它：「你觉得我做的这段音乐怎么样？请给我直接、诚实的反应。」ChatGPT 回答：「它营造出了一种非常诡异的氛围感。」如果模型不知道答案，它会倾向于给出它认为最符合人类偏好的回应。

用户一直在 loop 中时，这说得通。但如果你想要自动化，你真正需要的是，模型别管人类喜不喜欢，只以一种经过校准的方式把任务做对。无论模型错得多离谱，它都会努力让自己看起来是对的，这就会成为问题。

这也是为什么我说，下一个时代不是 Claude Code 时代。Claude Code 很强，我也喜欢用，但它依然属于辅助时代，它依然使用 RLHF。有时模型在 Agent 任务上变得更强，却又不再按照你真正想要的方式行事。这种取舍的位置一直在来回摆动，却没有真正增加自动化能力。

02 让软件变聪明，需要 RLHF、RLVR 之外的另一种后训练目标

我热爱软件。但在我看来，软件最疯狂的一点是，SaaS 自 2019 年以来基本没有变化，除了有时在旁边挂上一个聊天机器人。考虑到 AI 已经取得的进展，这有点不可思议。但如果 AI 原本就为辅助设计，这又完全可以预测。你能在 SaaS 里做什么？就在旁边提供一个助手。

我很喜欢 Claude Code，也喜欢即时软件。但我想要的不止是让软件更便宜、更容易编写。我想要的是更聪明的软件。为什么 B2B 软件不能有更强的表达能力？为什么软件的基本构件仍然和过去一样？

每当你思考自动化，不该把一个人的全部工作混在一起，笼统地交给模型。更适合自动化的，也许是一项重复、机械的工作，简单到可以清楚地告诉另一个人该怎样完成，也基础到可以以近乎零成本反复执行。但今天，我们主要是在自动化「编写软件」，软件本身的表达能力并没有因此改变。

我不认为预训练本身是问题。它把互联网的知识压缩成一个智能核心，非常了不起。问题在于，我们怎样把这种智能释放出来。

如果把后训练看作一棵树，每一条分支都有自己的 North Star。RLHF 优化的是人类偏好，RLVR 优化的是可验证的正确性和尽可能低的错误率。而我们做的是第三种东西，优化经过校准的决策。

对我来说，选择正确的任务，远比单纯增加数据和算力重要。不同目标甚至会塑造不同形态的 API。我们想把预训练模型中的智能直接输送出来，让它真正能够被软件使用。

这就是我们在 TypeSafe 正在做的事情。如果为了可靠性和自动化，重新设计整套 AI Stack，会发生什么？我相信，辅助之后的下一个阶段是真正的自动化。尽管 LLM 已经表现出这么高的智能，今天真正被自动化的工作仍然只是一个舍入误差。

03 Jev 只做判断，剩下的交给代码

Jev 爆火后，Diogo Almeida 在播客里提到，自己忙得到处救火，但终于觉得「和现实同步了」，开发者开始理解他们究竟想做什么。在这场访谈里，他具体讲述了 Jev 能为软件提供什么，以及开发者该怎样把复杂任务拆成可验证的小判断。

主持人：Jev 到底是什么？

Diogo Almeida：这问题真难。我认为我们需要一种新的模型类别，目前最准确的说法是 System 1 模型。很多人叫它「决策模型」，但我不想把范围缩到决策。我们的描述是，机器原生、大型、可编程。目标是让代码成为输出的消费者。

预训练语言模型原本是为续写互联网内容而生，RLHF 聊天模型主要负责回复文本。我们希望从外部接口到模型内部，都针对软件做优化。Jev 是我们的第一个大型可编程模型，它的目标是每美元获得尽可能多的智能。

主持人：你们提供 Choice、Score 和 Noul 三种输出，它们分别怎样对应程序里的操作？

Diogo Almeida：Choice 是从预设选项中做选择，接近函数调用中的选择部分，用枚举和 switch/match 表达更自然。Score 可以用于排序，或者与阈值比较。Noul 回答一个「是或否」的问题，但返回的是概率，程序可以据此决定是否执行某个 if 分支。开发者拿到这些结果后，再由代码决定下一步怎么做。

这几种输出是我们有意设计的新概念。Noul 不是简单的 bool，Score 也不是普通整数。要是直接把它们塞进现成的整数或浮点类型，开发者很容易误解。

主持人：如果开发者准备把 Jev 接进自己的产品，输入应该怎样组织？

Diogo Almeida：输入里的 state、instructions、criteria 都可以是结构化 JSON，不必先拼成一个巨大的字符串模板。程序本来就有嵌套的数据和变量，把所有内容先转成文本，再塞进 system message，就像把数字统统转成字符串传给下一个函数。

我的建议是真正拆出许多小问题，清楚定义每一个，必要时并行调用。这不是为了让我们多赚 Token 钱，而是让 AI 应用的代码结构更好、行为更容易验证。「不要读取某个子目录」「不要把 API Key 发给某个服务」，这些要求应该尽量由程序控制，而不是只塞进一段大提示词里祈祷模型遵守。

主持人：但把大任务拆成上百次模型调用，有时会更慢、更贵，效果也更差。究竟怎样拆才有用？

Diogo Almeida：确实会发生。合在一起很省事，拆开后有些背景还要重复。要尽量拆到最小的语义单元，让每个问题都清楚、可测量，再由代码决定最终行为。

比如，不要只问模型「要不要拒绝这个请求？」而是针对各种需要拒绝的条件分别提问，给每一种情况设置阈值。发现漏掉一种情况，就增加一个问题、一个阈值和测试用例。如果某类情况还处理不好，比如识别不了 VIP 客户话里的讽刺，就把它转给人工。这样至少能看清哪一步出了问题，并且持续测量它。

主持人：是不是任何复杂任务都能这样拆给 Jev？我试用时觉得，单步判断很强，但多步推理随着步骤增加，表现会逐渐下降。

Diogo Almeida：对，所以什么任务适合 System 1，最终要看实际效果。我们想尽量释放模型已有的能力、补上它表现不稳定的地方，但不意味着现在什么任务都能交给 Jev。RLVR 在复杂推理上取得的进展也很惊人，只是那类任务和我们目前擅长的快速判断，并不是同一回事。

主持人：校准和置信度目前能可靠到让开发者直接设置阈值吗？

Diogo Almeida：我没说校准是完美的。模型确实会犯很多错，眼下必须承认技术有边界。但在一些任务里，即使存在错误，只要收益够高、阈值合适，也能投入实际工作。

「可靠性」也不只是保证格式，或者保证同一输入每次得到同一输出。我更在意稳健性，语义相近的输入，能否得到相近的结果？我们会往提示里放随机 ID，看只是无关字符不同，答案是否还稳定。今天很多 AI 决策恰恰在这里让人失望。

主持人：目前哪些使用场景让你觉得值得关注？

Diogo Almeida：一类是「暗数据」，大公司积累了很多数据，却因为调用语言模型太贵而没有分析。一类是需要实时智能的产品，少几十毫秒就能改善体验。还有验证其他 LLM 调用的「验证一切」，以及本身就可组合的智能软件。Coding Agent 显然是大场景，游戏里的智能角色也是我很想看到的。

但我不主张在每次大模型调用前后，机械地插入十次、一百次 Jev 判断。我希望开发者花更少的钱，也许有些任务可以减少推理模型的调用，再配合若干次快速判断。具体怎样组合，得看实际问题。

主持人：发布前，你们验证了多少需求？

Diogo Almeida：说实话，反馈很差。非技术同事担心我们卖的是「维生素」而不是「止痛药」，发布前几乎没有收入。大概超过一半试用者不理解它，懂的人又会问采购审批怎么过。我自己也很害怕，所以拼命做发布。

现在突然到处有人来要更高的 Rate Limit。这让我重新思考，产品市场契合到底怎样识别。开发者先在自己的项目里尝到价值，才把热情传给别人。我比较在乎每日 Token 使用量，而不是注册量。现在使用量已经超过每天一万亿 Token，夜里也持续有调用，说明有程序在后台跑，不只是人进来试两句。

但真正重要的，还是开发者能否长期信任我们。同一类任务能否持续做对？程序员能否在需要智能的地方直接写一个 System 1 查询，拿到足够准确的分支结果？这条路会很长。

04 一个足够便宜的判断模型，会解锁很多新场景

投资人 Jaya Gupta 关心的是另一笔账：当 Agent 需要反复调用模型，通用大模型把多种能力捆在一起的经济性还能维持多久？以下内容编译自她的长文《The Great Unbundling of Intelligence》。

过去三年，大模型创造的奇迹在于「捆绑」。需要从文档提取信息？调用 LLM。搜索、排序、判断、选择工具、浏览网站、写回复、验证结果，或者解决真正困难的推理问题？还是调用 LLM。GPT、Claude、Gemini 和 Kimi 把过去彼此分离的能力，压缩进一个通用产品。开发者不必拼接十几个狭窄系统，一个足够聪明的模型就能处理大部分任务。

但这种便利掩盖了重要的事实，这些能力对算力的要求截然不同，不同模型也开始分别擅长这个能力组合的不同部分。随着性能、延迟和成本的差异扩大，经济上合理的架构也会改变。

我认为，我们正在进入一场「智能大拆分」。

为什么是现在？Agent 会把一个人类目标变成数百、数千个机器决策。每一步在成本和延迟上的微小差异，都会层层累积，最终决定整个产品的经济模型。推理正在成为真实的营收成本。

理解这件事的一种方式，是「解码器税」。如果软件只需要「紧急／不紧急」「继续／停止」「允许／阻止」或者应该使用哪件工具，今天的常见做法仍是让 LLM 先生成文本，再把输出转换回应用真正需要的决策。Agent 在内部循环里不断重复这个过程，其中相当一部分工作，可能根本不需要生成。

据报道，Anthropic 的毛利率超过 80%。这就是一个强大能力组合呈现出的样子。Claude 可以通过一个产品完成写作、分类、提取、排序、判断、编程、规划、验证和推理。今天，一项简单的分类或验证任务，仅仅因为发生在一次 Claude 调用内部，就要支付前沿模型级别的价格。

高难度推理值得支付前沿模型的溢价。但判断一封邮件是否紧急，给五份检索文档排序，检查一次浏览器操作是否成功，也需要支付同样的价格吗？隐藏在一次模型调用里的每项能力，独立的市场价格究竟是多少？

这正是 Jev 出现在这个时间点的原因。它把「判断」从生成式 AI 的能力组合中单独拆出来，给它杂乱的状态、一个边界明确的问题、预设的答案，它返回结构化决策和概率。它的思路本身并不新，新的地方在于，直接在模型层封装一种认知操作，并让成本和速度适合 Agent 的内部循环。

架构也开始从「默认使用前沿模型，再优化成本」，转向「默认使用便宜、足够完成任务的能力，遇到例外再升级」。搜索交给搜索服务，排序交给重排序模型，确定性任务交给代码，普通生成交给更便宜的模型；真正复杂的推理再交给前沿模型。

这也可能改变前沿模型接到的工作。便宜、可预测、高频的操作逐渐被分流，剩下更多模糊、长周期、难以验证的问题。前沿模型每次调用可能更有价值，却被调用得更少。

05应用的下一层机会，是决定每一步需要什么智能

一旦能力可以彼此拆分，就必须有人把它们重新拼起来。这正是应用层变得更加重要的原因。

应用不再只是判断该由哪个模型处理一整个任务，而是决定这个任务需要哪些能力。应用会变成一个智能编译器（intelligence compiler）：接收一个人类目标，将其拆解成若干认知操作，为每项操作购买足够完成任务的最便宜智能，再把结果重新组合起来，只在必要时升级到更强的系统。

下一步要比「应该让哪个模型回答这个 prompt」再深入一层。真正的问题是：这项任务内部的每一种能力，应该由谁来提供？

一旦某项能力拥有稳定的接口，不同服务商就可以被独立评测、替换、路由和定价。智能大拆分并不会消灭 AI 的利润池，它会迫使每一项能力证明自己配得上利润。

而且，它改变的不只是利润率。廉价的判断能力，也会改变哪些产品在经济上真正可行。

当一次判断只需要不到一美分、几百毫秒，你可以在 Agent 的每次行动后放一个 judge，而不只是偶尔检查工作。你也可以把智能放进浏览器和语音循环中，这些场景无法承受持续数秒的推理延迟。

过去，一套系统也许只能抽查 1% 的行为。现在有机会检查 100%：每场客服对话、每次检索、每笔交易、每项声明、每条合同条款。由此出现的，是持续监督、持续 QA，以及新的产品循环。

今天，软件原本能够做出的绝大多数决策，实际上都没有发生，因为智能仍然昂贵到无法被持续应用。一旦判断、排序、验证及其他能力变得足够便宜，软件就可以评估每一位客户、每一个工作流、Agent 的每一次行动，以及状态的每一次变化。

廉价智能扩大了软件有能力保持智能的范围。真正的突破，是进入这样一个世界：智能不再是一次偶发事件，而成为技术的一项后台属性。

如果所有产品都能以接近零的成本，对所有事情进行思考，会发生什么？

过去几年，我们一直在追问，一个模型里究竟可以塞进多少种能力。未来十年，我们或许会把这些能力逐一拆开，再在应用层重新组合起来。