Codex 和 Claude Code 都跑偏了，前 OpenAI 研究员称 Jev 出现前 AI 世界是个悲剧
点击查看原文>
编译 | 林绮蓓、蔡芳芳
策划 | Tina
“它会逐渐退到软件背景中，像数据库、正则表达式或其他基础设施一样，成为开发者随手调用的普通能力。”
这是 TypeSafe CEO、Jev 创始人 Diogo Almeida 对 AI 的设想：当智能真正融入软件，用户甚至不必意识到它的存在。但怎样才能让开发者放心地把判断交给 AI，而不用守在旁边反复检查？
几个月前，在 AI Engineer 大会的演讲中，这位曾参与 OpenAI InstructGPT 工作的研究者就提出，“下一个时代并不是 Claude Code”时代。在他看来，Claude Code 与 Codex 本质上仍属于同一个阶段——AI 的主要角色仍然是围绕人提供辅助。他关心的是，为什么 AI 如此聪明，能解决数学界的千禧年难题，却连最基础的活都无法实现自动化工作？
9 月 22 日，做客 Latent Space 播客接受采访时，Diogo 再次谈起这份不满，措辞更加直接：“在我看来，Jev 出现之前的 AI 世界，简直是个悲剧。”在他看来，问题在于：强大的“智能引擎”已经有了，把它接进实际业务流程的接口却仍然欠缺。
这一次，他带来了自己的答案——Jev。通过面向校准决策的强化学习（RLCD），团队希望让模型输出可供代码直接使用的选择、评分和概率，让开发者能够依据不确定性设置阈值，决定何时执行、何时交给人处理。
从参与训练听懂人类指令的模型，到尝试让代码直接调用智能，Diogo 为什么要重新选择训练目标？他又准备如何让 AI 成为像数据库一样普通的软件能力？这场两小时的访谈讲述了他的判断与尝试。
太长不看版：
Swyx：对于那些可能不太了解情况或者只想得到确切答案的人来说，Jev 到底是什么？
Diogo Almeida：目前最准确的称呼是 System One 模型，它的能力范围远远超出决策本身。这类模型的目标，在于让代码成为模型输出的直接使用者。
Swyx：你对 RLHF 的一个核心看法是：模型的回答会向用户想听的内容，而不是反映它对一件事真正的内部置信度。能具体谈谈吗？
Diogo Almeida：几乎没人注意到 RLHF 的缺点，特别是“模式坍缩”（mode dropping）。RLHF 的模式坍缩会让模型偏向生成更安全、更常见的答案，而牺牲概率分布的真实校准，这既掩盖了长文本中的错误累积，也解释了为什么文本模型不擅长决策。
Swyx：RLCD 与 RLHF 的核心区别是什么？
Diogo Almeida：区别首先在于优化目标：RLHF 侧重让模型遵循人的指令、给出获得认可的回答，RLCD 则希望模型成为软件能够可靠调用的能力。
Swyx：为什么 Jev 不把拒答机制直接放进模型底层？
Diogo Almeida：我不反对安全本身，但我认为不应把特定价值判断直接写进通用模型底层能力，而应像数据库一样划清技术能力与具体使用责任的边界。
Swyx： 你所说的可靠性是什么？开发者能否相信同一个版本的行为保持稳定？
Diogo Almeida： 我更重视稳健性：问题含义没变，就不该因为加入无关字符而大幅改变判断，而不只是追求相同输入得到相同输出。已经部署的模型，我们不会悄悄修改，因为 API 是别人程序里的依赖。但我们会快速发布新版本，目前还不能承诺永久维护每个旧版本。
Swyx： 不依赖公开榜单，你们怎样判断模型是否真正做到了更高的性价比？
Diogo Almeida： 我们会通过内部评测比较成本和能力，追求同等成本下更强、同等能力下更便宜。我不反对评测，反对的是围绕榜单优化，让分数脱离真实价值。开发者最终还是要把模型放进自己的工作流，测量实际表现，不能只看价格、速度或一个总分。
Swyx： 开发者应该怎样组织任务，才能更可靠地使用 Jev？
Diogo Almeida： 我建议把复杂任务拆成最小、可以独立判断的语义单元，用结构化输入提供必要信息，再由代码控制最终行为。Choice 对应选择分支，Noul 对应条件判断，Score 对应评分、排序和筛选。每一步都可以单独评估、调整阈值；能力不足时，就转交人工或暂不部署。
Swyx： 对企业开发者来说，Jev 有哪些值得尝试的应用方向？
Diogo Almeida： 我们梳理了四类：分析因处理成本太高而闲置的“暗数据”；为实时流程提供快速判断；检查其他模型的调用和输出；把智能判断嵌入软件核心逻辑。我尤其看好暗数据分析和编程 Agent，但具体如何组合模型，仍要看它能否降低成本、解决原本解决不了的问题。
Swyx： 面对前沿 AI 的风险，放慢发展速度是唯一选择吗？
Diogo Almeida： 我认为，这种讨论往往默认大家必须沿着现有 RLVR 路线继续加大投入，但研究目标和技术路线都可以重新选择。为了提升表现而给模型多大行动空间，本身就是设计决定，不该被当作不可避免的前提。我更希望探索其他方向，让已有智能可靠地进入软件，自动化实际工作。
Swyx： 如果研究者在前沿实验室得不到资源，你会建议他们出来创业吗？
Diogo Almeida： 要看为什么离开。如果只是想自由尝试课题，现有实验室可能仍然最合适；如果找到了值得长期投入的新任务，我会支持创业。我不认为漂亮的研究履历会自动创造价值，也不看好拿到资金后重复已有工作的做法。先明确自己的核心目标，再围绕真正值得解决的问题展开研究。
Jev 发布的第一周，创始人的情绪糟糕透了
Swyx：欢迎来到录音室。就在本周，我的好朋友 Diogo 发布了 Jev，它几乎占领了社交平台的热点话题。此时此刻，你感觉怎么样？
Diogo Almeida：情绪上来说，从来没有这么糟过。我现在简直像一具疲惫不堪的行尸走肉，因为同时发生的事情太多了，到处都有问题等着我处理。
但是，从心理层面来说，那反而完全不一样。我经常讲这件事，并且这几年我在那些大小项目活动里也反复说过，整个 AI 领域就像游乐园里的哈哈镜屋，所有人都像疯了一样。每个人都在说各种奇怪又说不通的话。
可是就这一周，我好像和现实更合拍了，像是突然之间感受到：“哦，大家终于看见了。”——AI 能做到的事情，远比过去人们想象的多。我们真的可能推动了一场由 AI 驱动的经济革命，这件事重新回到桌面上了，简直实在是太棒了。我特别兴奋的一点，是开发者真的能够理解我们在做什么，这种感觉非常强烈。我也想对这些开发者表达我长久的感激。我对整个开发者社区以及现在发生的一切都特别兴奋，真的太棒了。
Swyx：你昨天还跟我说，你决定优先去做 town hall，也就是社区公开交流，而不是把时间都花在 VIP 和投资人之类的人身上。因为你希望确保真正得到你最多注意力的，是工程师、开发者这些真正使用产品的人。
Diogo Almeida：是的。当时确实会有一种感觉，像是“天啊，我现在正在跟一些非常重要的人说话。”我可能不该透露是谁。但对我来说，如果在我那个列满了待聊对象的庞大日程表里，开发者社区竟然不在其中，这对我来说会很不舒服。实际上，如果按照我的理想状态，我会一直和开发者社区在一起交流。我刚才甚至在想，“我要不要一边走来你的演播室，一边开一场社区大会？”后来我又觉得，“不行，这也太疯狂了。”
Swyx：对于那些可能不太了解情况或者只想得到确切答案的人来说，Jev 到底是什么？
Diogo Almeida：这个问题其实挺难回答的，但我是这么看这件事的：我们需要一种全新的模型类别。至于这一类别到底叫什么，我们没有执着于某个名字。
目前我们想到最准确的称呼是 System 1 模型。之所以没有把它称为“决策模型”，是因为 System 1 的能力范围远远超出决策本身。我现在只能说这么多。我们原本没想到这次会成为一次这么受关注的发布，所以手里还有东西没有拿出来。
Swyx：你们当时就该说这是一次“低调的研究预览”。
Diogo Almeida：某种程度上确实就是，它其实真的有点像一个研究预览。总之，我们内部有几个词来描述出现的这一类新的模型。比如机器原生模型（machine-native）、System 1 模型、大型可编程模型（large programmable）。我的理解是，这类模型的目标，在于让代码成为模型输出的直接使用者。
预训练大语言模型最初面向的是互联网文本补全；经过 RLHF 训练的聊天和指令遵循模型，面向的是文本回复；RLVR 则和 RLHF 之间有一块界限不太清晰的区域。而我们希望这类模型的输出能够直接被代码消费，所以公司才会叫 TypeSafe。
我们真正想要的，是让 AI 尽可能强大。而我们认为，实现这一点的方式是让它与软件结合。因此，我们设计时考虑的不只是模型外部的使用方式，连模型深层的内部机制也要针对软件进行优化。Jev 是我们的第一个大型可编程模型，也可以叫 System One 模型，随你称它为什么。它的优化目标是“每美元智能”，Jev 这个名字也由此而来。
Swyx：Jevons Paradox，杰文斯悖论。
Diogo Almeida：对，就是杰文斯悖论。它的目标是实现性价比最高的智能模型。我特别喜欢跟人讨论，在可靠性、成本、校准和速度之间，到底什么最重要。Jev 这个名字以后会代表一系列站在“每美元智能”方面处于领先地位的前沿模型。当然还有别的优化方向。在机器学习里，至少对于擅长机器学习的人来说，一切都关乎取舍。而我们决定在这个方向上全力以赴。
从模式坍塌到校准失真：RLHF 的另一面
Swyx：我觉得“校准”是近来才开始受到关注的一个问题。我们之前请 Hugging Face 的 Clementine Foreia 做过一期节目，当时有聊到了这个话题。这也是你对 RLHF 的一个核心看法：模型的回答会向用户想听的内容，或者最可能出现的内容收拢，而不是反映它对一件事真正的内部置信度。
Diogo Almeida：我听说你们的听众技术背景很强，所以正想深入讲讲这个问题。发布视频里的每一项表述，我都花了很大力气核对，确保准确、真实。显然，这种做法还挺少见。视频里有一点几乎没人注意到，就是 RLHF 的缺点，尤其是“模式坍缩”（mode dropping）。
Swyx：mode dropping 还是 mode collapse？
Diogo Almeida：在这里我说的是一回事。以后我想专门写一篇博客，但现在我想尽可能把这件事讲给更多人听。我其实很认同 Yann LeCun 的不少判断。但他有一页很有名、也很有争议的幻灯片，大意是“大语言模型注定行不通”。
Swyx： 你说的是那个“蛋糕”比喻？
Diogo Almeida： 不是，是讲序列长度的那一页。他的推理是：如果生成每一步都有出错概率，文本越长，至少犯一次错的概率就越高。这个推理看起来在数学上很直观，但模型的实际表现并没有简单地照这个趋势发展。我很喜欢拿它来问：数学推导和观察结果之间，差异出在哪里？
Swyx： 问题出在哪里？
Diogo Almeida：问题在于，如果模型试图覆盖整个分布，或者它的概率分布经过了良好校准，那么它不会因为产生少数离群结果而受到过度惩罚。你会预期它有时生成落在常见分布内的内容，有时生成分布之外的内容；覆盖整个分布，就会出现这种情况。你可以想想生成对抗网络出现之前的图像生成模型：它们生成的图像往往是模糊的。
而生成对抗网络会模式坍塌：它会直接丢掉占比很小的类别，只生成那些最常见的类别。也正因为如此，前面那个“序列越长错误必然累积到不可用”的效应并没有按最简单的方式出现。为了生成很长、又不容易出现明显错误的文本，模型就得极其保守，因为一旦犯错，人很容易看出来；相反，一个看上去没问题、其实遗漏了微妙之处的回答，就很难被察觉。为了让模型的概率分布保持校准而带来的要求，对文本序列的生成方式会产生很大的影响。这层关系很微妙。我认为，它既解释了为什么那种直观的错误累积推论没有应验，也解释了为什么文本模型不擅长决策：让本来用于生成文本的模型承担过多决策任务，效果往往不好。
Swyx：既然说到 Yann，你认同他的解决方案吗？也就是用世界模型，比如 JEPA 这一类嵌入模型的方法。问题的一部分似乎在于，我们让模型基于已经输出的词元（token）继续推理，再把输出送回去，反复循环，直到生成完整的一句话。Yann 提出的解法是联合嵌入预测架构（JEPA），你觉得这就是解决办法吗？你对此有什么看法？
Diogo Almeida：我可能不该把机器学习内部的事讲得太细。不过，除了说话有时比较放得开，我做事其实很务实。刚才对模型的判断也是从实际效果出发。
我是不是 Scaling Law 的支持者？要看它能带来什么。Scaling Law 告诉你：投入一定量的资源，某项能力能提高多少。通常，资源投入要大幅增加，收益却不会同比增长。除非那一点能力提升非常有价值，否则看起来就不是一笔好投资。对我来说，更重要的问题是：用手头已有的资源，我们怎样才能带来最大的实际改变？
我的出发点始终是实用性。比如 Yann LeCun 的 JEPA 方向，我觉得早期研究很精彩，也很喜欢看到优秀的研究工作。至于它现在是否已经足够实用，我暂时不想下判断。
目前研究界还有很多没有被充分挖掘的好成果，像未经打磨的钻石。它们没有进一步变成有用的技术，部分原因是大家还没找到适合发挥其价值的任务。
Jev 的发布当然对 TypeSafe 有利，但我希望它带来的影响不止于此。一方面，开发者可能会基于 Jev 做出大量新软件；另一方面，也会有人沿着不同方向探索：还能用什么方式把模型能力提供给程序，让软件做出更多以前做不到的事。如果这些尝试同时出现，那种感觉就有点像早期互联网那种充满活力的氛围——大家纷纷探索，新的用法不断冒出来。我想这也是为什么推特上大家一提到“Jev”，就像在开派对一样。
Swyx：这很让人振奋，因为它和我们习惯听到的说法太不一样了。过去常有人说：“抱歉，这件事你做不了。模型研发要遵循缩放规律，只有大实验室才有资源参与。”
Jev 的开发理念：AI 做决定时，不能突然拒答
Diogo Almeida：Discord 上经常有人问我：为什么反对安全对齐，为什么 Jev 不会拒答？我还没来得及完整解释。先说清楚，我并不反对安全本身。我认为，常见的安全对齐方式往往与使用者的目标不一致；而对供程序调用的模型来说，突然返回一句拒绝，简直像是发生了类型错误。
如果你是人在和聊天机器人互动，或者用编程工具时碰到“抱歉，我不能读取 DNA.py”，当然会觉得烦，但至少你能看见它、换个办法继续。大家用久了，甚至习惯了处理这种情况。可如果模型是后台运行的软件依赖，某次调用突然拒绝了，会发生什么？调用它的用户可能根本不知道底下还有这个模型。难道只因为输入里出现一条特殊消息，就让整个软件流程随机中断吗？
我认为，这种设计沿用了“AI 是一个聊天同事”的想象，没有充分考虑模型作为软件组件时需要满足什么要求。
Swyx：你想要的是一种能在各种地方使用的基础能力。
Diogo Almeida：对，一个足够通用的“认知核心”。它要能适应未来各种我们现在想不到的用例。用户已经拿 Jev 做了不少出乎意料的东西，我们当然没针对那些具体应用训练过它。不过，这并不让我意外；我们训练时就让它处理过更多样的情况。
再回到安全对齐。我认为，对 ChatGPT、Claude 这种直接面向人的产品，设置安全规则是可以理解的。但需要区分能力对齐和安全对齐：能力对齐是让系统尽可能按使用者的要求完成任务。软件工程师很需要这一点——行为越可预测，越容易把模型集成进程序，也越少需要反复试探。
Jev 现在离理想状态还很远。我们希望把可靠性再提高几个数量级，最终让调用智能像执行数据库查询一样自然：需要时调用，不必每次都担心它会怎样回应。
而我所说的安全对齐，往往意味着模型除了遵循当前使用者的指令，还要优先服从模型提供方——比如 OpenAI 或 Anthropic——设定的另一套规则。这两套要求有时会发生冲突。
Swyx： 你说的是不同层级的规则和价值取舍。
Diogo Almeida： 对。对于直接面向用户的产品，这样做有道理。比如 ChatGPT 的提供方不希望产品支持某些成人角色扮演内容，那是他们的选择，也可能符合他们面向家庭用户的产品定位。
但 API 不一样。开发者需要根据接口的行为来写程序。如果模型在程序运行过程中突然按提供方的另一套规则拒绝执行，开发者很难处理。我对此确实有点激动，得让自己冷静一下。
Swyx： 大家能感受到你很在意这件事。不过我想提出一个更严肃的反例：如果有人用这个 API 来杀人呢？成人内容或许属于私人选择，但 AI 也可能被用于战争。公司完全可以合理地决定，不希望自己的 API 被用于这类用途。
Diogo Almeida： 我理解。企业可以出于实际考虑持有这种立场。我自己也不希望我们的技术被用来伤害人，当然希望它更多地用于有益的事情，也愿意为此作出努力。但我不认为应该把这些偏好直接写进通用技术的底层能力。
我的顾虑是，每当你为了某一种特定规则，强行让模型在某些问题上改变判断，就可能进一步割裂它的能力。现在的模型已经有不少这样的不一致了。
我更倾向于把智能看作数据库，而不是一位“AI 同事”。我们通常不会要求数据库在执行查询时，自行判断用户最终会不会把结果用于坏事。我认为，对通用智能接口也应该考虑类似的责任边界。
还有一件事让我觉得奇怪：有开发者在 Slack 上告诉我们准备部署某个应用，问“我们可以这样用 Jev 吗？”我的第一反应是：我们提供的是 API，你是开发者，具体应用怎么设计，不该事事由我们批准。理想情况下，复杂任务会被拆成许多较小的调用；作为底层服务提供方，我们甚至不应该知道下游用户的完整任务是什么。这种边界能给软件工程师更大的自主空间。
我希望他们把能力用于好的事情。我们也讨论过开源、公益支持等办法，只是眼下还没精力落实。但只要由我负责，我就不希望把这些价值偏好直接固化进模型的底层判断里。
Swyx： 既然说到平台与开发者的关系，也想澄清一下你们的隐私条款和使用条款。之前有些人产生了误解，觉得你们对 API 用途限制得很严。
Diogo Almeida： 我不确定你具体指哪一条，不过我看到过一些关于基准测试的讨论。
Swyx： 对。你之前公开说过，相关限制是预览期条款里留下的，正式发布时没有及时移除，团队准备修改。
Diogo Almeida： 团队有些进展我甚至还没跟上。我请他们和律师确认这件事。我们显然不打算阻止用户测试和比较模型；恰恰相反，我支持他们这么做。
但这和我怎么看公开基准榜单是两回事。我非常不喜欢公开榜单。至于用某些内部基准作为实际能力的替代指标，我的态度也比较审慎。
Swyx： 你担心的是榜单很快饱和，还是模型可能见过公开测试题，因此容易刷分？
Diogo Almeida： 刷分容易，是原因之一。假设两年后，市场上有很多公司在做与 Jev 类似的产品，我们提供的价值可以说是“每美元获得多少智能”，或者“每秒获得多少智能”。大家很容易盯着价格和速度，因为它们好测量。但价格和等待时间是用户付出的成本，用户真正想得到的是有用的智能。
难就难在，模型到底有多好，有些部分很难用一个分数概括。Jev 发布后，开发者亲自试用产生的反应，甚至比发布视频更让我在意。他们感受到模型在实际使用中的表现，也感受到我们为此下了多少功夫。
公开基准想用数字帮助大家建立信任，但它太容易被针对性优化。即使团队主观上不想刷榜，也可能不断收集与测试集相似的数据，让模型在榜单上表现更好。过去有些实验室收集类似 MMLU 的题目来训练，在我看来，这不过是绕了几步优化基准成绩。
所以我认为，开发者可以先凭实际体验建立初步判断，随后必须把模型放进自己的工作流，测量它在那个具体任务上的表现。我们的工作则是持续提高可靠性，让它越来越值得信任。可靠性始终是 TypeSafe 要解决的问题；如果只想尽早发布一个能力不够好的版本，我们一年半前就可以推出 Jev 了。
“最苦涩的教训”：先选对任务，再谈模型和数据
Swyx： 你前面提到自己的“最苦涩的教训”（The Bitterest Lesson），我们来展开讲讲。
Diogo Almeida： Sutton 的“苦涩的教训”强调算法和计算的重要性。但在我看来，数据比算力重要得多；而最难、也最重要的，是先选对任务，找到研究的 North Star（核心目标）。
大语言模型的发展中，研究目标发生过几次这样的转变。RLHF 把重点转向指令遵循，当时没人意识到模型能在这件事上做到那种程度。RLVR 又把方向往前推了一步。现在，我们用 RLCD 定义了另一个任务：让程序能够把模型放进运行流程，可靠地调用它的判断。数据对此至关重要。我怎么强调都不为过。
Swyx： 所以你们更愿意把 TypeSafe 称为一家“数据实验室”，而不是“模型实验室”？
Diogo Almeida： 完全正确。我们会一直非常重视数据。对我来说，模型能力的提升，很大程度上就是数据问题。数据工作极其复杂，却也能把可靠性一位一位地往上推。数据选取和处理方式稍有变化，结果就可能大不一样。
Swyx： 你们也在大量招聘数据人才。怎样才算优秀的数据工作者？你说过你们使用合成数据，但“数据是合成的”显然只说到了表面。是不是还要有人认真检查这些数据，指出问题，再回去重新生成？
Diogo Almeida： 是，但完整回答会复杂得多。我给新入职的数据同事做的培训，可能比这期播客还长。这里先讲最重要的几层意思。
首先，任务决定数据的形态。RLVR 需要的数据在某种程度上是供模型探索的环境；RLHF 需要人类反馈。每种任务都有自己的数据形式，我们也一样。所以我们做的合成数据，并不是一个通用模板生成出来的东西。
其次，我们不想用用户数据训练模型，即使取得许可、技术上也做得到，我们仍不想依赖它。真实世界的数据有很强的偏向：很多人反复提出相似问题，需求呈现幂律分布。直接按这些数据训练，模型容易对高频场景过拟合，其他能力反而变得不均匀。
我们瞄准的是多年后的应用。到那时，模型也许会成为深入软件技术栈各层的通用基础设施，支撑今天还没人想到的产品。如果打个比方，可以把一般的大语言模型想成 UDP，把我们的模型想成 TCP：开发者能在上面构建各式各样的应用。即使我们拿到了今天所有用户数据，它也只能让模型更适应今天，未必能帮助开发者做出未来的软件。
因此，数据团队的工作有点像艺术创作。他们研究模型的“认知核心”，找出能力不平整、不稳定的地方，再有针对性地处理。我们认为自己的模型在这方面已经相对平滑，但不可能做到完美。一次修正最好能改善一类问题，在过去、现在和未来不同情境下都有效，而不只是修好某一道题。
Swyx： 解决普遍问题，而不是只解决一个具体案例。
Diogo Almeida： 正是这样。每次做到这一点，都需要很强的判断力。
“Jev 出现之前的 AI 世界，是个悲剧”
Swyx： 你刚才说，我理解数据的方式受 RLVR 影响很深，这个批评挺公允的。那我们具体聊聊 RLCD。你们目前还没有发表介绍它的论文，对吗？在不了解技术细节的情况下，大家怎样判断 RLCD 确实代表一种不同的方向，而不只是一个新造的术语？“校准”这个概念我能理解，但 RLCD 与大家熟悉的 RLHF 究竟有什么区别？
Diogo Almeida： 还没有发表论文。你的问题很好，不过要回答它，我想先反问一句：RLHF 指的是什么？
这个词在不同时期指过好几种工作。最早有通过人类偏好反馈，让系统学会完成难以精确规定的任务的研究。我记得有一项工作涉及教机器人做后空翻，可能与 Paul Christiano 等人的研究有关，但具体是哪篇，我也不能完全确定。PPO 是一种算法，并不天然意味着奖励一定来自人类反馈。
后来 OpenAI 做了“学习摘要”的工作，把 PPO 用在语言模型上，让模型学习完成摘要这类很难用简单规则规定好坏的任务。人们也会把这称为 RLHF，不过我没有参与那篇论文。
但当我说 RLHF 时，我更想强调的是指令遵循这个任务，而不是某篇论文采用了 PPO。真正重要的，是研究者确定了一个新的 North Star：让模型理解并遵循人的指令，是一个值得持续优化的方向。今天的 DPO 及其后续方法即使没有使用那篇论文里的算法，也仍是在做这个意义上的 RLHF。
同样，RLCD 对我们来说是在提出一个新的任务目标。我使用这个名字，是想准确说明我们在优化什么：让 AI 能被程序调用，成为软件可以使用的能力。
Swyx： 也就是说，关键词是“可编程的 AI”：让程序能够在不需要人每一步介入的情况下使用模型，进而自动化更多工作。我理解你的 North Star 对吗？
Diogo Almeida： 对，但还要加一个前提：必须务实。我们得看清当前语言模型实际擅长什么。有些面向程序的新输出类型在概念上可能很棒；如果技术还不足以让它可靠工作，暂时不推出，也没什么可遗憾的。
在我看来，Jev 出现之前的 AI 世界，简直是个悲剧。这话听起来很狂妄，但这个想法在我创办公司很久以前就有了。
Swyx： 这点我可以作证。你已经谈了好几年。
Diogo Almeida： 是。我起初以为做出一个能供程序调用的模型不会太难，整个项目一周就能完成。事实证明我错得离谱。以前我甚至觉得：“这个问题我马上就能解决。”现在想来，我得向当时被我低估的 OpenAI 同事道歉。
AI 领域还有另一件令人遗憾的事：承诺很大，实际交付却跟不上。我认为 RLHF 和 RLVR 路线都存在这个问题。但让我一直放不下的，是 AI 明明已经表现出很强的能力，却仍有大量简单工作无法自动化。
我在演讲时常问：为什么 AI 能处理极其困难的数学问题，却连许多基础、重复的工作都接不过去？这些工作不要求人有多高的智力，也谈不上令人满足，但现实中仍得有人做，因为软件还没法可靠地把它们自动化。我们已经有了一台很强的“智能引擎”，却缺少合适的接口，把它接进那些有经济价值的流程。
即使有一天 TypeSafe 不复存在，这个方向也已经被打开。别人也许需要一两年追上来，也可能更快；如果模型质量的差异持续重要，我们会有更长时间的优势。但比公司竞争更重要的是，整个领域开始探索：智能还可以怎样接入软件。我相信这会改变技术接下来的发展路径。
Swyx：我完全同意。你们真正创造的是一种新的可能性。我试着替你概括一下，方便大家理解：不要把 TypeSafe 和 Jev 的成功看成仅仅是“出现了一种新的模型类型，我可能可以继续沿用之前的路径去做事”。不是这样，实际上，可能还有好几种别的模型类型值得探索，这个行业应当是百花齐放的态势，应该让各种尝试奋都发展家里。其中有些方向，你们大概也会亲自去做。
Diogo Almeida：完全正确。那种早期互联网的活力又回来了。我觉得我们重新回到了某种技术乌托邦时刻，再也不用像以前那样感慨：“唉，有时候我的编程智能体能工作，但真正最好的东西都被公司内部藏起来了”。创造新东西又成了一种真实的可能。当然，接下来会是一个相当疯狂的世界，大家最好坐稳了。我对此兴奋极了。
Swyx：现在你们有了资金，也有了发布后的势头，终于能把想法做出来给大家看。
Diogo Almeida： 对。以前一直讲，却不能把最关键的东西拿出来，感觉像总在吊大家胃口。我的演讲尤其如此：我说 AI 应该推动自动化，却没法展示它具体怎样做到。你之前看过我们的宣言，还说有些地方写得太模糊：“第一步是什么？你们说的智能模型究竟是什么？”
Swyx： 我当时问你模型在哪里，你只说“快有了”。我主要对“可组合”这个词有意见，不过 “Build Prod, Not God” 这句口号很好。
Diogo Almeida： 谢谢。团队很认同这句口号。我们对正在做的事很兴奋，但大家也很务实。
Swyx： 宣言里还有一份“秘密总体计划”，讲怎样一步步构建面向机器、可组合的 AI。
Diogo Almeida： 写成“秘密总体计划”是你的建议，我得正式把功劳记给你。
Swyx： 谢谢。不过你当时只给我看了一半故事，没有告诉我还要发布模型。那时候也没有《Doom》演示，没有性能数字，我自然会问：你们到底打算拿什么证明它？
Diogo Almeida： 问题是，我不相信公开基准榜单能证明这件事。模型好不好，最终得让人放进实际任务里体验。这种做法有助于建立长期信任，但也让我们吃过苦头。去年融资时，很多人不相信我们，只想看基准测试成绩。我们不愿意为了拿出好看的数字，去迎合一套容易奖励刷榜行为的评价方式。
Swyx： 选择这条更难的路，最后也让你建成了一家自己愿意待的公司。
Diogo Almeida： 是。我不太后悔这个选择。昨晚聊到为什么离开 OpenAI，我还挺激动的。发布前，我常这样想：如果 AI 最终因为承诺过多、实际交付不足而进入新一轮低谷，而我没有尽力探索另一条路，我会觉得自己也有责任。一方面，我参与过 RLHF 这条路线；另一方面，我相信让 AI 真正进入软件自动化，能创造很大的价值。
发布后，我对这件事的说法有些变化。至少在我看来，自己担心的那种“AI 寒冬”已经不那么不可避免了。 Jev 上线还不到一周，我已经看到开发者把它用在真实工作中。眼下就像西部拓荒时期一样，充满了未知，各种尝试都在冒出来。
爆红之后，Jev 更在意什么
Swyx：能不能分享一些发布之后的具体数据？例如注册的用户数量之类的。
Diogo Almeida：具体数字主要是团队在跟进，而且每天都在变。不过有一个里程碑我记得很清楚：日调用量已经超过一万亿 Token。这不是发布当天大家尝鲜带来的短暂高峰。夜里调用也没有停下来，说明有程序在持续使用 Jev，而不只是人在界面里试几次。这让我特别兴奋。
相比之下，我没那么在意注册人数。我们发布时没有专职营销人员，大家看到的宣传基本就是团队自己的表达。候补名单一度增长很快，我们也在不断放人进来。平台团队承受住了这次发布带来的流量，做得非常出色。
但我们后来意识到：对开发者平台来说，候补名单上的人数并不能说明多少问题。其中可能有不少人不是开发者。他们进来试了几个问题，发现 Jev 不是聊天机器人，就会疑惑：“我的下一个 ChatGPT 在哪里？”我还没有精确计算过，不过我的直觉是：哪怕全世界每个人都来试几次，调用量可能还不如一个真正用它创造价值的开发者写下的一段循环程序。
我们起初以为，放多少人进入候补名单需要非常谨慎。后来发现，更紧张的是速率限制：开发者一旦把 Jev 用进程序，获得了实际价值，就会希望大幅提高调用额度。软件就是这样运行的——先花时间定义一个重复任务，之后让它持续执行；只要创造的价值超过最初投入，就可以把它放到后台，再让其他功能依赖它。
Swyx： 设置好，让它自己运行。
Diogo Almeida： 对。之后开发者还能在这些能力之上构建更复杂的东西。许多早期互联网的创造，正是通过不同软件能力的组合才发生的。虽然你不喜欢“可组合”这个词，我仍想在宣言里强调它：我们希望 Jev 成为催化剂，让开发者做出连我们也没预料到的应用。为此，我愿意继续在 Discord、公开交流和播客里跟他们沟通，哪怕要在直播里套个垃圾袋出镜。
Swyx： 长访谈也有这个好处。我们可以越过发布初期比较表面的讨论，让人理解你们究竟想做什么。认同这个方向的人，也许会加入团队，或者“买下你们”——抱歉，我是说成为客户。
Diogo Almeida： 哦，作为客户（笑）。
Swyx： 对，作为客户。发布视频也确实很受关注，刚才看到是 3600 万次播放。
Diogo Almeida： 现在到 3800 万了。
Swyx： 如果只看 2026 年新兴 AI 实验室的发布声量，你们可能排在最前面。
Diogo Almeida： 谢谢，不过我不太在意“新兴 AI 实验室”这个标签。我们还有周边专门拿它开玩笑，比如“你最喜欢的新兴实验室最喜欢的新兴实验室”，以及“有产品的新兴实验室”。
我真正想做的是一个可靠的开发者平台。希望发布热度过去之后，开发者仍能长期依赖它、信任它。
模型不能说变就变：Jev 如何兑现“可靠”？
Swyx：你们一直强调可靠性。我原以为主要指 RLCD 里的概率校准，但看下来，它也包括服务可用性、扩展能力，以及常说的“几个 9”，对吗？
Diogo Almeida： 那些都是可靠性的一部分。但模型的判断本身也要可靠：它能不能持续完成你希望它做的事？现在的大型推理模型很聪明，可在我看来，仍有不少任务是它们看起来足够聪明、企业也有动力自动化，最后却不敢交给它们做，因为结果还不够稳定。我们离理想状态也有很长的路要走。
我想先把容易的工作自动化，再去处理难的工作。我的目标是，有一天开发者需要一处智能判断时，可以像写数据库查询一样，直接在程序里写一个类型安全的 System 1 调用，让程序准确地走向相应分支，而不必每次都先试探模型能否胜任。这会是一个漫长的过程。
Swyx： 说到可靠性，我注意到 API 里没有随机种子（seed）参数。同样的输入，每次都会得到同样的输出吗？如果不会，为什么？
Diogo Almeida： 这是个好问题。“可靠性”其实是一个总称。AI 无法自动化某件事，可能是输出不符合类型要求，可能是结果不确定，也可能是能力分布不均匀。你问的确定性，指相同输入得到相同输出；它对单元测试等场景可能有价值，但我不认为它应该是首要目标。
我更重视稳健性：语义相近的输入，应该得到相近的判断。大语言模型在这一点上有时很不可靠。我们的一个测试办法，是在提示词里加入不同的 UUID 作为随机标记。问题的实际含义没有变，只是多了一个无关的字符串；模型的判断就不该因此大幅变化。开发者在让 AI 做决定时，常常会被这种细微变化导致的结果波动坑到。
当然，我们也可以做确定性模型。如果开发者能告诉我们它在哪些场景确实重要，我们愿意考虑。但确定性可能需要在成本与能力之间作取舍。我们一直努力站在“每美元智能”的帕累托前沿，为此尝试了很多不那么常规的模型组合与工程方法。
Swyx： 所以，回到最初的问题：将来会不会提供随机种子或确定性模式？
Diogo Almeida： 有可能。只要需求足够明确，而且我们没有被 GPU 资源严重卡住，就可以做。只是按我们目前的判断，它可能降低每美元能提供的有效智能。
Swyx： 从 OpenAI 和 Anthropic 的发展过程看，我猜开发者迟早会要求这个功能。即使你告诉他们稳健性更重要，他们可能还是会想要确定性。
Diogo Almeida： 那就看后面会怎样吧。有人说我们品牌的一部分是“立场坚定”，其实就是委婉地说我固执。
Swyx： 但我以前和你争论过。证据充分时，你也会改变原先的判断。
Diogo Almeida： 是，你在开发者需求方面说对过很多次。这一点我认。不过，我怀疑我们会在很长一段时间里受到 GPU 供给限制。如果一种方案提供同等智能却消耗更多 GPU，我们就更难让更多人用上它。我们当然希望服务企业，但眼下更想让尽可能多的开发者拿到 Jev，去实验、去做那些出乎意料的东西，让这个方向真正热闹起来。
Swyx： 这种探索已经开始了。不过我想提醒你一个开发者可能会担心的问题：你说会尽一切办法提高“每美元智能”，又面临 GPU 限制，大家可能会猜，你们会不会在发布后把模型进一步量化，以节省显存或带宽，却让同一个模型的质量下降？
你现在不一定要作承诺，但至少应该考虑明确告诉开发者：已经发布的模型，其质量和行为会不会保持稳定。过去有些 API 虽然模型名称没变，背后的模型却变了。你们现在有版本号，这是好事；还可以进一步说明，同一个版本上线后是否会保持不变。
Diogo Almeida： 已经部署的模型，我们不会悄悄改动。 对开发者来说，那太离谱了。直接面向用户的产品可以持续调整背后的模型，只要产品体验变好就行；但 API 是别人程序中的依赖，不能按同样的方式处理。
不过，我们更新模型的速度可能会比大家习惯的快得多。我们会不断发布新版本，也暂时不能承诺每个旧版本都有长期支持，因为还有很多改进要做。眼下有不少人在使用 Jev 1.13.0，我们可能会暂时把它作为长期支持版本；我知道开发者不愿意看到依赖突然失效。
另一方面，如果每发布一个版本就永久保留，推理服务可能要同时运行大量不同模型，这也会给所有人带来负担。
Swyx： 更新快的话，可能很快就有上百个版本要维护。
Diogo Almeida： 正是如此。我们希望将来找到比简单保留某个长期支持版本更好的办法，团队正在研究。我认为那会对开发者很有帮助，但现在还不能把尚未实现的方案当成承诺。
可以确定的是，我们会继续推出能力更强的新模型。按我的观察，Jev 在相邻版本之间的行为差异，通常甚至小于一些生成文本的模型对同一个请求调用两次产生的差异。但如果我们解决了模型能力中某个明显不稳定的部分，新旧版本之间就可能出现很大的变化。
不追 Benchmark，追极致的“每美元智能”
Swyx：模型有了长期支持版本（LTS），还有一个好处：你们可以把同一个版本移植到其他芯片平台上运行。不知道你们有没有考虑过这件事。
Diogo Almeida： 暂时不评论。我更关心的是“每美元能获得多少智能”。
Swyx： 但速度也重要。
Diogo Almeida： 这要看后续情况。
Swyx： 过去一年，推理技术路线发展得很快。比如，把模型放到 Cerebras、Etched 这类芯片上运行，速度可能会有大幅提升。
Diogo Almeida： 对。“每秒能获得多少智能”是另一个衡量指标。我们内部甚至讨论过把成本和时间放在一起衡量，比如“每美元、每秒能获得多少智能”。
对于 Jev 系列模型，我在内部反复强调的一点是：模型变得更聪明当然好，但它必须处在帕累托前沿。也就是说，在同等成本下，它要尽可能强；达到同等能力，成本要尽可能低。这就是 Jev 的定位：把每美元获得的智能做到最好。
至于每秒能获得多少智能，还要继续看。这个方向很有意思，我也知道有不少行业高度依赖实时响应。对它们来说，速度的提升直接对应着很大的经济价值。我当然希望两个指标都能做好，也希望从市场和用户的反馈中判断，究竟该把重心放在哪里。
Swyx： 而且速度不只关系到实时场景，也关系到规模。到了足够大的调用量，哪怕每次只差几微秒，乘上数十亿、数万亿次，也会变得很可观。
Diogo Almeida： 如果是大型数据库 MapReduce 查询这类后台任务，延迟可能没有成本那么重要。这也是 Jev 的定位：尽可能提高每美元所能获得的智能。至于“每秒智能”，还要继续看。我很喜欢那些对速度要求极高的应用场景，也知道对一些高度依赖实时响应的行业来说，速度提升能带来很大的经济价值。这方面的需求正在增长，很有意思，但我不认为它会成为 Jev 的主要方向。
Swyx： 说到“更快、更便宜”，其他模型通常给出的取舍是速度更快，但价格也更高。我在想，Jev 之所以受到关注，一个原因是你们做到了更快、同时更便宜。这一块目前选择不多，前提当然是模型的智能水平大致保持不变。
Diogo Almeida： “智能水平保持不变”这句话很关键。难就难在这里。
Swyx： 但你似乎不太认可公开基准测试，或者至少不喜欢用现有的公开基准来证明这一点。你们内部总得有一套判断方法吧？
Diogo Almeida： 当然。我们有自己的内部评测。不过，要避免团队有意无意地针对评测做优化，需要很强的自律；这件事必须得到最高优先级的重视。
否则，我们凭什么说自己的模型处于“每美元智能”的帕累托前沿？我们不是凭感觉做决策。尝试不同方案时，成本和能力都会变，我们会测量、比较，把结果放在一起看，判断哪种方案对用户最好。
所以，我并不反对评测。我担心的是，一旦掺入其他激励，评测就可能变得很危险。在这件事上我管得很严。同事们也许会觉得我在很多事情上都管得严，但对我来说，不能在模型到底有多聪明这件事上自欺欺人，这一点尤其重要。我们得诚实地追求事实。
Swyx： 同意。接下来我想聊聊 API 设计上的一些具体选择。
别让 AI 一口气干完：把任务拆小，出错才好查
Swyx： 你们定义了三个基础概念：Choice、Score 和 Noul（又名 Noulli）。先说 Noul，这个词是从哪里来的？是文献里已有的术语吗？
Diogo Almeida： 现在算是了（笑）。我们为名字讨论了很久。它有点像布尔值（Bool）：涉及“真”或“假”，但它的取值是连续的。名字来自伯努利（Bernoulli），更准确地说，是取了 Bernoulli 的一部分，因为它表达的就是伯努利概率。
我们当时还考虑过 PBool、Pool 等名字。我甚至想把它叫作“pool party”，但没人同意。最后大家觉得 Noul 最合适。我们这群人起名多少有点不按常理出牌，Jev 也是这样。最初我们以为，对程序员来说，Jev 不过是代码里的一个字符串，没想到这个名字后来还衍生出不少双关梗。当时内部有很多人反对这个名字，现在除了一个人，其他人都向我道过歉了。
回到 Noul。我们需要为它创造一个新概念，因为如果直接叫 Bool，会让人误解。事实上，Choice、Score 和 Noul 都是我们有意单独定义的概念。它们与编程语言中的现有类型很接近，但并不完全相同。比如 Score 不是整数。如果通过 Instructor、Pydantic 之类的工具，直接把整数或浮点数映射成 Score，就可能出问题。我们更倾向于把含义说清楚，即使这会增加一些初次理解的成本。
Swyx： 但你们不担心集成问题吗？开发者通常希望它能直接接入自己已经在用的工具。你们有自己的 SDK；如果我是开发者关系负责人，我可能还会特别在意：怎样把 Jev 和 Instructor 一起用？怎样接入其他工具？
Diogo Almeida： 我们确实希望做好这些集成。相关示例也许已经有了，只是我现在跟不上所有更新。社区里也会有人做。支持社区这件事没有一个“完成”与“没完成”的二元状态，我们总还能做得更好。说实话，聊到文档我有点紧张，因为录制前没来得及重新看，而文档又一直在变。
至于这三个概念，Score 其实并不难理解。它接近用语言模型做评判（LM judging）时得到的评分，也可以把它叫作一种“判断结果”。Noul 也可以被看作概率，但在我们的体系里，模型输出本来就带有概率性质。Choice 则最接近函数调用，不过我对现有的函数调用设计有不少意见，这个话题我们可以稍后再展开。在代码中，Choice 更像是把 switch 或 match 语句要处理的选择，直接作为 API 输出。
Swyx： 也就是说，它可以很自然地对应枚举（enum）；如果需要，开发者再根据选中的项调用相应函数。
Diogo Almeida： 对。关键是先得到那个“选择”。这三个概念都可以对应到基本的程序控制方式：Choice 对应基于枚举的 switch 分支，Noul 对应 if 条件判断，Score 对应排序，或者通过“大于”“小于”的阈值来筛选。这一直是我们的设计方向。以后还会有更多类型，也会继续与程序中的基本操作对应起来。
Swyx： 对于准备深入使用 Jev 的开发者，还有什么 API 设计上的细节值得讲？比如这些概念具体怎么用，图例、置信度该怎么看，测试中又该注意什么。你是最了解它的人，我想多给他们一些实际建议。
Diogo Almeida： 谢谢，我很喜欢这个问题。没想到会聊得这么细。除了几个月前给我们的开发者关系同事做入职培训，已经很久没人这样问我了。
我们设计模型时，想的是让它将来能深入计算机程序内部工作。我们相信，这类用途的规模会远超今天人们的想象。模型现在也许还没准备好，但我们一直在朝这个方向推进。我们的目标不只是让它在相对浅层的任务上不断提高分数，而是让它进入程序的核心逻辑，因为这样才能让软件具备更强的能力。
刚才说的 Choice、Score 和 Noul 是输出形式。输入端同样可以有结构：状态（state）、指令（instructions）、判断标准（criteria），都可以是结构化的 JSON 对象。程序可以把这些信息准确地放到需要的位置，开发者不必先把它们塞进字符串模板。
很多人可能没注意到这一点，以为这些输入都只是字符串。用模板拼出一条系统消息，当然也能工作，但那延续的是过去处理模型输入的方式。既然信息本身有结构，就应该尽量保留这种结构，让计算机直接处理。写普通程序时，我们不会先把所有数字转成字符串，再传给程序内部的其他部分。转成字符串通常是为了展示给人看；程序内部传递的，应当是有明确含义的嵌套结构。
我们也在持续优化模型处理这类输入的能力。它现在已经能处理结构化信息，但嵌套每增加一层，推理难度也会提高，所以这仍是我们重点投入的方向。我也希望开发者更多地采用这种方式：代码会更清楚，也不必过度依赖底层实现细节。
可以把它想成调用一个 AI 函数：程序当前有一组状态，也就是可用的变量；你需要决定，哪些状态应该传给这个函数。相比之下，一条包罗万象的系统消息很像一个混乱的全局变量：把所有信息、所有指令都放进去，然后指望模型一次满足每项要求。很多问题其实可以拆开，并行地问。
我很建议大家多向模型提问，把问题拆小、拆细。我这么说不是为了增加调用量。无论当前模型能否一次完成复杂任务，把问题分解成简单决策，都会让 AI 应用的代码更好维护；而且每个小决策都更容易单独评估。
过去我们常常给模型一大段系统消息，等它返回一大段结果，再检查它有没有遵守其中的每条要求。现在回头看，这种做法挺不可思议的，只是大家已经习惯了。比如“不要读取这个子目录”“不要把 API 密钥传给 DeepSeek”，这类约束应该尽可能由程序保证。机器学习模型本身无法给你绝对保证，但把任务拆开之后，至少可以逐项测量、验证。
Swyx： 比如可以核查某个操作到底有没有执行。
Diogo Almeida： 对。我们的接口本身就很容易验证，这会让工程实现可靠得多。
Swyx： 我理解这个思路。不过，以前大家不这么做，也有现实原因：即使用小模型，把任务拆成很多次调用，仍然可能又慢又贵。我自己做过对比：一条流程把所有要求放进系统消息，只调用一次、拿到一个完整输出；另一条流程把任务拆成上百个问题。后者更慢、更贵，结果还不如前者。
Diogo Almeida： 确实会发生这种情况。拆分任务也很麻烦，调用之间可能还得重复传入一些信息，看起来不够高效。于是人很容易想：为什么不一次性把所有东西都放进去？但那样得到的系统往往很难依赖。我希望我们的模型能够支持大量在后台运行的程序调用；如果做不到，我会很失望。
Swyx： 那具体应该怎么拆？你们有没有发现什么有效的方法，或者发现哪些原以为可行的拆法其实不行？开发者听完之后可能会照着这个思路使用 Jev，但他们首先得知道从哪里下手。
Diogo Almeida： 我倾向于把问题拆到最小的语义单元：先找到其中最基础、能够独立判断的那件事。我可能是使用我们模型最多的人之一。提问时，我会尽量把输入写得结构化、明确；在问题里清楚指出所引用的内容，有时会用反引号把它标出来。我希望模型尽可能按字面准确理解要求。编程本来就要求指令得到准确执行，而 AI 扩大了程序所能执行的指令范围。
我自己偶尔也会图省事，把几个判断混在一个问题里。但如果是大型生产系统，我会不断增加独立的问题，并且让新增问题这件事足够容易。每个问题负责什么，要拆得清楚；最终的具体行为则由代码来控制。
举个小例子：拒绝回答。我不建议只问模型一句“这里要不要拒绝？”这个问题它或许也能答得不错，因为这是一个适合快速直觉判断的任务。但更好的办法是，针对不同的拒绝情形分别提出独立的问题。这样，你就能明确规定自己希望系统如何处理各种情况，而不是让模型自行猜测。
更妙的是，如果后来发现某种情况没有触发拒绝，原因是你漏写了一项条件，这其实是一个很好的工程问题：补上那个问题，设置阈值，再把这个案例留作测试。修正就留在程序里了，不会因为提示词变长、上下文中的早期信息失效而被“忘掉”；你也可以持续测量它。如果模型对某项判断还不够准，还能根据真实案例调整相应阈值。整个过程有点像在做机器学习系统，但你不需要为每种情况重新训练模型。
当然，有些任务可能仍超出了模型当前的能力。比如看到有人用模型做自动交易，我会有点担心。这件事看上去很酷，但任务本身复杂、风险也高，最好交给专业人士。即使把它拆成若干判断，你也可能通过评测发现：模型在某一步还不够可靠，那这一版就先不要部署，或者调整方案、选择更保守的处理方式。
客户服务也一样。假设模型还不能可靠识别“VIP 客户在说反话”这类特殊情形，你就可以规定：遇到这种情况，转交人工处理。置信度估计也是为这样的决策服务的。
Swyx： 你刚才提到，开发者可以通过设置阈值，决定什么情况下采用模型的判断。但如果模型的概率校准本身就有问题呢？一个校准良好的模型，至少应该让较低的分数对应较低的实际发生概率，较高的分数对应较高的概率。现实中，两者也可能对不上。这时我可能想微调模型，而你们目前没有提供这个功能。
Diogo Almeida： 我没有说模型的校准是完美的。微调当然是我们可以考虑的方向。
Swyx： 微调是一种可能，也可以是别的调节手段。现在听起来，如果模型判断错了，用户能做的就是改提示词、把问题拆得更细，或者调整置信度阈值。如果模型确实不擅长这件事，这些办法不一定让人满意。
Diogo Almeida： 没错。先说清楚，模型会在很多事情上犯错。我们有问题反馈按钮，大家也可以在 Discord 告诉我们哪里出了问题。我们希望持续改进模型，每个新版本都应该有明显提升；如果没有足够大的进步，我们就不会保持现在这样的发布速度。
承认 AI 在某些任务上还不够好，是务实的做法。同时，“足够好”也取决于具体用途。人也会把工作做错，但只要总体预期收益足够高，很多工作仍值得由人来做。模型也类似：通过合适的阈值和其他控制方式，即便它会出错，仍可能承担相当多的工作。
至于微调，我能想象我们以后会提供，但我有一些顾虑。用户想要的功能和真正对他们有益的功能，不一定完全相同。通用模型有一种很难说清的优势：它会处理大量其他任务，这种广泛的能力，可能也让它在某个特定任务的边缘案例上表现更好。如果只针对一个狭窄任务做微调，我会担心失去这部分能力。
所以我的回答是：有可能。我在这些事情上很务实，我们想做的东西还有很多。但我也不想推出一个看似有用、实际却很容易让用户把系统用坏的功能。
Swyx： OpenAI、Claude，可能还有 Gemini，都曾推出过微调功能，后来又撤回或收缩了相关服务。这也挺有意思：现在微调似乎更多发生在开源模型领域。
Diogo Almeida： 我知道这些情况。有些微调产品的效果确实不好，撤下来也许是对的。
Swyx： 所以，告诉用户“微调可能不是正确的解决办法”，也说得通。另一种回答是：你们的模型与通常的大语言模型差异很大，就像量化、输出 Token 这些概念未必适用于它，微调也可能不适用。
Diogo Almeida： 我对这种可能性也持开放态度。不过下面说的是我的设想，不是产品承诺。
随着“每美元智能”的成本继续下降，也许我们能用很小、成本很低的模型，完成一些过去要靠手写规则处理的判断。举个例子：会不会有一天，人们不再需要自己写正则表达式？因为用 AI 完成同一件事的成本，已经低于编写和维护正则表达式所带来的复杂度。我会很乐意看到那一天。对于其中一些狭窄用途，微调也许恰好能让模型的表现跨过可用的门槛，还得继续看。
我希望概率校准加上模型级联，也能解决一部分问题。比如，小模型对某个判断非常有把握，就直接采用它的结果；如果置信度落在中间地带，再交给更大的模型，必要时继续往上一级处理。我还不知道最终哪种方式效果最好。
还可以设想另一种用法：我们提供一系列处于帕累托前沿、规模各不相同的模型。熟悉技术的开发者也许愿意自己选择，但企业可能更需要动态调度：系统根据技术栈中不同环节所需的判断能力，自动选择合适的模型。考虑到我们的接口相对简单，这套机制甚至可能结合某种自动微调。
重申一下，刚才说的动态选模型、自动微调，都不是产品承诺。我只是在畅想一种有点像科幻的未来。
“决策模型早就有了”，Jev 到底想做什么？
Swyx： 但你们会考虑推出不同规模的 Jev 模型，让用户有得选？
Diogo Almeida： 当然。用户到底需要多强的智能，我怎么可能事先知道？
Swyx： 需求可能是无限的。
Diogo Almeida： 也有人劝我们，现在的产品已经够好了，不用急着发布新东西。但我不太喜欢“够用就停”的想法。有句话我很认同，大意是：市场不奖励你做一件事时，你仍然坚持去做，那才体现出你的文化。 我希望大家以后也拿这句话要求我，因为说出口之后，就很难反悔了。
也许有一天，我们坚持的东西会变得理所当然，公司会像 Visa 一样，成为人们平时不会特别留意的基础服务，到时候我可能连粉色西装都不穿了。但现在，我还想让更多人看到这条路的可能性。我们会继续做有意思的事，并不是因为当前产品非改不可，而是因为今天大家看到的才刚刚开始。第一次发布更像是一次低调的研究预览，远不是我们能做的全部。面向机器的智能（machine-native intelligence）还有很大的空间。
Swyx： 所以，将来可能不止一种模型规模，也不止目前这一款模型？
Diogo Almeida： 没错。我们希望尽可能满足不同需求。但我得加一个重要前提：我不想像一些产品团队那样，什么想法都往外推。我们做的东西应该服从一个统一的方向。回看我们的宣言，未来的尝试都应该落在其中三个方向之一。
Swyx： 我没准备好在这里逐条聊那份宣言。
Diogo Almeida： 抱歉，我说得像是在故意吊胃口。我的意思是，那三个方向不是一张待完成的清单，而是我们认为足以支撑下一轮技术变革的三条轴线。我们做的每一次尝试，都应该能在其中找到位置。模型方面，我们也会做一些看起来挺奇怪的东西。
既然是“面向机器”的智能，就不一定非得让人一眼看懂它的形式；关键是它有没有实际价值。
Swyx： 能透露一点吗？“奇怪”会是什么样？
Diogo Almeida： 给个提示吧。有人想把我们的模型叫作“决策模型”，因为目前的几个基础概念都与决策有关。但我不会这样命名：未来还可能出现其他面向机器的输出类型，它们未必是决策。
Swyx： 好，那就留给大家猜。
Diogo Almeida： 这个提示已经挺有意思了。
Swyx： 现在也有人说：“决策模型我一年前就做过了，Jev 没什么新鲜的。”但我觉得，一方面，你们展示了这类模型可以怎样成为一个独立的产品方向；另一方面，从我看到的数字和测试结果来看，Jev 目前的表现仍然超过了那些类似产品。
Diogo Almeida： 先说清楚，我不在乎基准测试上的输赢。无论领先还是落后，我都希望继续发布我们的进展。
Swyx： 你们至少让更多人开始认真看待这个方向。而且，“决策模型”和 System 1 模型之间的区别，似乎也是你一直想讲清楚的。
Diogo Almeida： 对，我想让软件工程师借助 AI，拥有更强的能力。让我难过的是，AI 已经这么强大，却远没有得到充分利用。如果事情继续这样发展，甚至会走向新一轮“AI 寒冬”，实在太可惜了。这件事会让我情绪激动。
我并不是认为所有技术进步天然都是好事，也不想一味宣扬技术乐观主义。但看到 AI 有这么多能力，软件却仍然没有真正用上它，我觉得很难接受。我想做的，就是帮大家打开这些可能性。先说到这里吧，这几天我已经哭了太多次，不想在录节目时再哭一次。
Swyx： 谢谢你愿意讲这些。光看“TypeSafe AI”这个名字，大家未必能感受到你对这件事的投入。但了解你们想推动的方向，以及你们已经迈出的第一步之后，就更容易理解你为什么希望大家一起往前走。
Diogo Almeida： 我不确定最难的部分是否已经过去。以后肯定还有很多难题。也许等到各种工作真正实现自动化、经济增长明显加快，每天都有值得庆祝的进展，我们才能说难关已经过去。而且，我觉得大家现在太关注速度和成本，对可靠性的关注还不够。可靠，才会让人用起来觉得好；可靠，才会让人敢于信任它。
Swyx： 你们还写过一个目标：五年内让全要素生产率（TFP）增长超过 3%。我很少见到一家 AI 实验室把 TFP 增长当成目标。
Diogo Almeida： 因为那才是经济变革该有的样子。这和 OpenAI 早期章程想表达的方向其实相当一致。章程本身也许没变，但关于什么算 AGI，后来的讨论似乎越来越倾向于用利润之类的指标来界定。
在我看来，一个值得追问的问题是：如果模型能解出数学上的千禧年难题，却几乎没有承担现实世界中有经济价值的工作，我们该怎样评价它的影响？如果按“承担世界上大部分有经济价值的工作”这个标准看，我觉得目前各家模型都还接近零。这个过程也许已经开始，但我猜占比还不到 1%。等它真正发生时，应该能从经济统计数据里看到变化。
我期待那一天。我不认为它会造成大规模失业，但它会带来很多积极的变化。另一方面，我也厌倦了 AI 总是站在产品最显眼的位置。软件和生活应该变得更好，而 AI 只需要在其中发挥作用。
Swyx： 让 AI 融入后台。
Diogo Almeida： 对。我在演讲里也常问：2019 年的软件和 SaaS 产品已经创造了很大价值。现在都到 2026 年了，AI 的能力进步这么多，为什么大多数软件看上去却几乎没变？很多产品只是侧边栏多了一个聊天框。它有时能帮上一点忙，但公司仍不敢让它处理那些需要承担后果的决策，因为还无法充分信任它。
这在我看来很不可思议。企业有很强的经济动力去改变现状。我觉得接下来可能出现的，恰恰是所谓“SaaS 末日”的反面：SaaS 会因为 AI 而得到增强。软件公司最清楚自己的业务里哪些工作值得自动化，因此也最有机会把 AI 真正用进去。
Swyx： 你们已经做出了一件很有意思的事。不过，我还想弄清一个边界：什么样的问题适合 System 1，什么样的问题需要 System 2？现在大家可能什么都想拿 Jev 试一遍，其中一些尝试恐怕会失败。
Diogo Almeida： “什么都拿 Jev 试一遍”这个说法挺好玩。说实话，边界要靠实验来找，就像缩放规律也来自经验观察。以机器人为例，投入了这么多钱，为什么它至今仍有很多事情做不好？问题未必能靠继续增加投入解决，还要看实验结果究竟能不能支持那条路线。
我的判断是，预训练模型把大量能力浓缩到了一起，而 System 1 最接近它们天然擅长的思考方式。可验证奖励强化学习（RLVR）在增强 System 2 式推理方面取得了惊人的进展，我很佩服这些成果。但这类能力也很脆弱。
回想 ChatGPT 刚出现时，人们常说：“它很通用，能做很多事”，接着又指出它不擅长数学，连 GSM8K 这类小学数学题也做不好。如今谈起经过 RLVR 训练的模型，大家又会说它的能力很不均匀：为什么它能解决某个特别难的问题，却会在另一个地方出错？数学能力也不是简单地在少数地方出现尖峰，它的差异可能细到不同问题层次。
如果看各种训练方法各自追求什么，就比较容易理解：基于人类反馈的强化学习（RLHF）希望模型的回答获得人的认可；RLVR 优化的是能通过程序验证的任务表现。这类任务之所以能用于 RLVR，本身就需要有可验证的结果。我们做的 RLCD，则是希望模型能可靠地供程序调用。
Swyx： 我说一个实际使用中的观察，你看看对不对。拿到 Jev 的访问权限后，我第一天就用它试了很多任务。单步推理的效果非常好，可以说是顶尖水平；但需要连续推好几步时，表现就开始下降，而且步数越多，问题越明显。
Diogo Almeida： 对。这又回到了实验问题：我们究竟能从模型中挖掘出哪些能力？我们希望尽可能多地释放它已有的能力，同时让能力分布更平滑、补上缺口，也增加新的能力。但归根结底，我们是在发掘这些高度浓缩的模型内核所具备的特性，再设法把不同特性组合起来。
目前有效的那部分能力，恰好可以用“System 1 式”来描述。这也是为什么我们没有选择让模型在字符串里写出很长的推理过程。我认为，模型很擅长在内部完成推理，尽管这种能力还不完整，也不是对所有问题都有效。
Swy 本文来源：InfoQ