Diogo Almeida谈Jev：Codex和Claude Code都没走对路

编译 | 林绮蓓、蔡芳芳

策划 | Tina

在 TypeSafe CEO、Jev 创始人 Diogo Almeida 的设想里，AI 最终会慢慢退到软件后台，就跟数据库、正则表达式这类基础设施差不多，变成开发者随手就能调用的普通能力。

可问题也跟着来了：怎么让开发者敢于把判断权交给 AI，而不是守在旁边一遍遍复核？这正是他想要回答的事——当智能真正融进软件，用户压根不需要察觉到它还存在着。

这位曾经参与 OpenAI InstructGPT 工作的研究者，几个月前在 AI Engineer 大会演讲时就说过，“下一个时代并不是 Claude Code”时代。他的判断是，Claude Code 和 Codex 说到底还处在同一个阶段，AI 扮演的主要还是围绕人做辅助的角色。他真正在意的是另一件事：AI 明明这么聪明，能啃下数学界的千禧年难题，怎么连最基础的活都没法实现自动化工作？

9 月 22 日，Diogo 做客 Latent Space 播客接受采访，又一次提起这份不满，话说得更直白：“在我看来，Jev 出现之前的 AI 世界，简直是个悲剧。”他觉得症结在于，强大的“智能引擎”早就有了，可把它接进实际业务流程的接口依然缺位。

这回他拿出了自己的答案——Jev。团队想借助面向校准决策的强化学习（RLCD），让模型输出能够被代码直接使用的选择、评分和概率，开发者则依据不确定性去设阈值，决定哪些时候执行、哪些时候交回给人处理。

从参与训练听得懂人类指令的模型，到试着让代码直接调用智能，Diogo 为何要重新挑一个训练目标？他又打算怎么让 AI 变成像数据库那样普通的软件能力？这场两小时的访谈里，他讲了自己的判断和尝试。

太长不看版：

Swyx：要是有人不太了解情况，或者只想听个确切答案——Jev 到底是什么？

Diogo Almeida：现在最准确的叫法是 System One 模型，它的能力范围远不止决策这一件事。这类模型想达到的目标，是让代码成为模型输出的直接使用者。

Swyx：你对 RLHF 有个核心观点：模型给出的回答会偏向用户想听的内容，而不是它内心对一件事真正的置信度。能展开讲讲吗？

Diogo Almeida：RLHF 的缺点几乎没人留意，尤其是“模式坍缩”（mode dropping）。它会让模型倾向于生成更安全、更常见的答案，代价是牺牲概率分布的真实校准。这既把长文本里的错误累积盖住了，也解释了文本模型为什么不擅长决策。

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的不少判断他是认同的，可Yann有一页幻灯片很有名，争议也大，核心意思就是“大语言模型这条路注定走不通”。

Swyx问，是不是那个拿“蛋糕”打比方的那页？

Diogo Almeida回答：不是，是讲序列长度的那一页。按照Yann的推理，生成每一步都带着出错概率，文本一长，至少错一次的概率自然就往上走。这个逻辑在数学上看着挺顺，可模型的实际表现并没有这么走。他特别喜欢拿这一点去追问：数学推导和实际观察之间，差在哪儿？

Swyx追问，那问题到底出在哪？

Diogo Almeida解释说，关键在于，假如模型要覆盖整个分布，或者说它的概率分布校准得足够好，那它不会因为偶尔冒出一个离群结果就被狠狠惩罚。它会时而生成落在常见分布里的内容，时而生成分布之外的东西，覆盖整个分布本来就会这样。可以回想一下生成对抗网络出现以前那些图像生成模型，它们吐出来的图往往糊成一片。

生成对抗网络则相反，会出现模式坍塌：占比小的类别直接丢掉，只生成最常见的那几类。也正因为这样，前面那个“序列一长，错误必然累积到没法用”的效应，并没有以最直接的方式兑现。要生成长文本又不容易露出明显破绽，模型就得极度保守，因为一旦出错，人一眼就能看出来；反过来，一个看着没问题、其实漏掉微妙之处的回答，却很难被抓住。为了让概率分布保持校准，这对文本序列的生成方式影响很大。这层关系相当微妙。在他看来，它既说明了那种直观的错误累积推论为什么没应验，也说明了文本模型为什么做不好决策：硬让一个本来用来生成文本的模型去扛太多决策任务，效果往往不理想。

Swyx接着问：既然聊到Yann，那你认不认同他的解法？也就是世界模型，比如JEPA这类嵌入模型的做法。问题的一部分似乎在于，我们让模型基于已经输出的词元继续往下推，再把输出送回去，如此循环，直到整句话生成完。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 不是聊天机器人，就会犯嘀咕：“我的下一个 ChatGPT 在哪里？”我没有精确算过，不过凭直觉：哪怕全世界每个人都来试几下，调用量可能还不如一个真正用它创造价值的开发者写下的一段循环程序。

我们起初以为，往候补名单里放多少人得非常谨慎。后来发现，更紧张的是速率限制：开发者一旦把 Jev 用进程序、拿到了实际价值，就会希望大幅提高调用额度。软件就是这么跑的——先花时间定义一个重复任务，然后让它一直执行；只要创造的价值超过最初投入，就可以把它丢到后台，再让其他功能依赖它。

Swyx：设置好，让它自己运行。

Diogo Almeida：对。之后开发者还能在这些能力之上搭更复杂的东西。早期互联网的许多创造，正是靠不同软件能力的组合才发生的。虽然你不喜欢“可组合”这个词，我仍想在宣言里强调它：我们希望 Jev 成为催化剂，让开发者做出连我们也没预料到的应用。为此，我愿意继续在 Discord、公开交流和播客里跟他们聊，哪怕要在直播里套个垃圾袋出镜。

Swyx：长访谈还有个好处，就是能跳过刚发布那阵子那些浮在表面的议论，直接让人看明白你们到底要做什么。要是有人认可这条路，说不定会来投奔团队，或者干脆“把你们买下来”——不好意思，我意思是变成你们的客户。

Diogo Almeida：哦，作为客户（笑）。

Swyx：对，作为客户。发布视频也确实很受关注，刚才看到是 3600 万次播放。

Diogo Almeida：现在到 3800 万了。

在Swyx看来，若只论2026年新兴AI实验室的发布热度，Diogo Almeida所在的团队大概能排到最前头。

对这个说法，Diogo Almeida并不太买账。他说自己不在意"新兴AI实验室"这类标签，团队周边还专门拿它开过玩笑，像是"你最爱的新兴实验室最爱的新兴实验室"，还有"有产品的那种新兴实验室"。

他真正想做的，是一个靠得住的开发者平台。发布时的热度总会退去，他希望之后开发者还能长期依赖它、信任它。

模型不能说变就变：Jev 如何兑现"可靠"？

Swyx提到，对方一直在讲可靠性。他原本以为这主要指RLCD里的概率校准，可看完之后发现，服务可用性、扩展能力，还有常说的"几个9"，似乎也都算在里面。

Diogo Almeida回应说，这些确实都属于可靠性的一部分。但模型本身的判断也得可靠——它能不能持续完成你希望它做的事？眼下的大型推理模型很聪明，可他觉得，还有不少任务看着够聪明、企业也有动力去自动化，真到落地却不敢交给模型，因为结果不够稳。距离理想状态，路还很长。

他的思路是先自动化容易的工作，再去啃难的部分。目标是有一天开发者需要一处智能判断时，能像写数据库查询那样，直接在程序里写一个类型安全的System 1调用，让程序准确走向对应分支，而不是每次都先试探模型行不行。这会是漫长的过程。

聊到可靠性，Swyx注意到API里并没有随机种子（seed）参数。同样的输入，每次输出都一样吗？要是不一样，原因又是什么？

Diogo Almeida觉得这是个好问题。"可靠性"其实是个总称。AI没法自动化某件事，可能出在输出不符合类型要求，可能出在结果不确定，也可能出在能力分布不均匀。Swyx问的确定性，指的是相同输入得到相同输出，这对单元测试之类的场景或许有价值，但他不认为这该被当成首要目标。

他更看重稳健性：语义相近的输入，判断也该相近。大语言模型在这点上有时很不可靠。他们的一种测试办法，是在提示词里塞进不同的UUID当随机标记。问题的实际含义没变，只是多了个无关的字符串，模型的判断本不该因此大幅波动。开发者让AI做决定时，常被这种细微变化带来的结果起伏坑到。

当然，确定性模型也能做。如果开发者能说清它在哪些场景确实重要，他们愿意考虑。但确定性可能要在成本和能力之间做取舍。他们一直想站在"每美元智能"的帕累托前沿，为此试了不少不太常规的模型组合和工程方法。

Swyx于是把话题拉回最初的问题：将来会不会提供随机种子或确定性模式？

Diogo Almeida答，有可能。只要需求足够明确，而且没被GPU资源严重卡住，就能做。只是按他们目前的判断，它可能拉低每美元能提供的有效智能。

Swyx说，从OpenAI和Anthropic的发展看，他猜开发者迟早会要这个功能。哪怕你告诉他们稳健性更重要，他们可能还是想要确定性。

Diogo Almeida说那就看后面怎么走。有人讲他们品牌的一部分是"立场坚定"，其实就是委婉地说他固执。

Swyx接话说，自己以前和他争论过，证据充分时，他也会改掉原先的判断。

Diogo Almeida承认，在开发者需求这件事上，Swyx说对过很多次。不过他也怀疑，团队在很长一段时间里都会受GPU供给限制。如果一种方案能提供同等智能却更费GPU，就更难让更多人用上它。他们当然想服务企业，但眼下更想让尽可能多的开发者拿到Jev，去实验、去做那些出乎意料的东西，让这个方向真正热闹起来。

Swyx说这种探索已经开始了。不过他想提醒一个开发者可能会担心的问题：既然说会尽一切办法提高"每美元智能"，又面临GPU限制，大家难免会猜，你们会不会在发布后进一步量化模型，省显存或带宽，却让同一个模型的质量下降？

他补充说，现在不一定非要作承诺，但至少该考虑明确告诉开发者：已经发布的模型，质量和行为会不会保持稳定。过去有些API虽然模型名字没变，背后的模型却换了。现在有版本号是好事，还可以再说明，同一个版本上线后是否保持不变。

Diogo Almeida表示，那些已经上线的模型，他们不会在用户不知情的情况下动手脚，这么做对开发者来说实在说不过去。换成直接面向用户的产品，背后的模型可以一直调，只要体验能往好的方向走就没问题；可API不一样，它嵌在别人的程序里当依赖，处理方式不能跟前者一样。

不过，他们更新模型的速度可能会比大家习惯的快得多。新版本会不断发，也暂时不能承诺每个旧版本都有长期支持，因为要改的地方还有很多。眼下不少人在用Jev 1.13.0，他们可能会暂时把它当作长期支持版本；他清楚开发者不愿意看到依赖突然失效。

反过来讲，如果每发一个版本就永久保留，推理服务可能得同时跑大量不同模型，这也会给所有人带来负担。

Swyx说，更新快的话，可能很快就有上百个版本要维护。

Diogo Almeida说是这样。他们希望将来能找到比简单保留某个长期支持版本更好的办法，团队正在研究。他觉得那会对开发者很有帮助，但现在还不能把没实现的方案当成承诺。

有一点可以确定，能力更强的模型我们还会接着推。照我观察，相邻版本之间的行为差距，往往比某些生成文本的模型拿同一个请求跑两遍的差别还小。可要是模型能力里某个明显不稳的地方被我们修掉了，新老版本之间就可能差出一大截。

不盯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 抛出的疑问是集成层面的：开发者一般盼着手里的工具能直接连上，Jev 有自己的 SDK，站在开发者关系负责人的角度，他要操心的是怎么把 Jev 和 Instructor 搭在一起用，又怎么接到别的工具上去。

Diogo Almeida 承认这些集成本来就该做好。他说示例说不定早就有了，只是更新太多，他自己都跟不全，社区里也会有人补上。在他看来，支持社区没有“做完”和“没做完”这种二分状态，永远有改进余地。聊到文档他直言有点紧张，录节目之前没顾上再看一遍，而文档本身一直在变。这三个概念里，Score 理解起来不算难，它接近用语言模型做评判时拿到的评分，也可以叫它一种“判断结果”。Noul 同样能看作概率，只不过在他们的体系里，模型输出天生就带概率性质。Choice 和函数调用最接近，但他对眼下函数调用的设计意见不小，这个话题留到后面再说。落到代码里，Choice 更像把 switch 或 match 语句要处理的选择，直接当成 API 输出来用。

Swyx 接着问，那它是不是可以很自然地对应枚举，开发者需要的时候再按选中的那一项去调对应的函数。

Diogo Almeida 给了肯定的回答。他说关键就在于先把那个“选择”拿到手。这三个概念都能对上基本的程序控制方式：Choice 对应基于枚举的 switch 分支，Noul 对应 if 条件判断，Score 对应排序，或者拿“大于”“小于”的阈值去筛。这是他们一直以来的设计方向，往后还会加更多类型，也会继续和程序里的基本操作一一对应。

Swyx 想知道，对准备深入用 Jev 的开发者来说，API 设计上还有哪些细节值得讲，比如这些概念具体怎么使，图例和置信度怎么看，测试的时候又该留意什么。他说 Diogo Almeida 是最了解它的人，想多给开发者一些实际建议。

Diogo Almeida 先道了谢，说很喜欢这个问题，没想到会聊得这么细。除了几个月前给公司做开发者关系的同事做过入职培训，已经很久没人这样问过他。

他讲起设计模型时的想法：要让它将来能钻进计算机程序内部干活。他们相信这类用途的规模会远远超过今天人们的想象。模型现在可能还没准备好，但方向一直没变。目标不是在相对浅层的任务上把分数越刷越高，而是让它进入程序的核心逻辑，软件的能力才能因此变强。

Choice、Score 和 Noul 说的是输出形式，输入端一样可以有结构：状态、指令、判断标准，都能做成结构化的 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% 以上。拿 TFP 增长当目标的 AI 实验室，他见得不多。

Diogo Almeida：因为那才是经济变革该有的样子。这跟 OpenAI 早期章程想说的方向其实挺一致。章程本身也许没动，但后来聊到什么算 AGI，讨论越来越倾向于拿利润这类指标来划线。

在我看来，有个问题值得追问：假如模型能解开数学上的千禧年难题，却几乎没干现实世界里那些有经济价值的活，我们该怎么评价它的影响？要是按“承担世界上大部分有经济价值的工作”这个标准看，我觉得眼下各家模型都还差不多是零。这个过程也许已经起步，但我猜占比还不到 1%。等它真发生时，经济统计数据里应该能看出变化。

我盼着那一天。我不觉得它会造成大规模失业，但它会带来很多好的变化。另一头，我也烦了 AI 总是占着产品最显眼的位置。软件和生活该变得更好，AI 只要在其中起作用就行。

Swyx：让 AI 融进后台。

Diogo Almeida：对。我在演讲里也常问：2019 年的软件和 SaaS 产品已经造出了很大的价值。现在都 2026 年了，AI 的能力进步这么多，为什么大多数软件看上去几乎没变？很多产品不过是侧边栏多了个聊天框。它有时能帮上点忙，可公司还是不敢让它去处理那些要担后果的决策，因为还没法充分信任它。

这事在我看来实在说不通。企业改现状的动力明明很强。我认为接下来很可能出现的情形，正好跟所谓“SaaS 末日”倒过来：AI 反而会把 SaaS 抬高一层。哪块活儿该自动化，软件公司自己最门儿清，所以它们也最有条件把 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 式”来形容。这也是我们没让模型在字符串里写出长长推理过程的原因。我认为，模型在内部做推理很在行，虽然这能力还不完整，也不是什么题都灵。

Swyx： 打住，你说的“潜在推理”（latent reasoning）是在字符串里推？我理解的是模型内部在推。术语我得对一下。

Diogo Almeida： 我印象里，模型内部那种形式以前叫“连续推理”（continuous reasoning），不过我也拿不太准。过去有人把另一种情况叫“潜在推理”，是因为推理轨迹没公开：对只看见答案的人来说，它就相当于一个隐藏变量。所以“隐藏”的到底是哪一块，大家用法也在变。至少 OpenAI 和 Anthropic 的推理轨迹，现在仍有一部分不向用户完整展示。

Swyx： 那 Jev 以后也不做推理模型？毕竟显式推理好像跟你们强调的 System 1 路线拧着。

Diogo Almeida： 我的承诺是，为了做好面向机器的智能，该用什么方法就用什么方法。我能想象有些推理方式没那么慢、没那么低效、也没那么脆；真要是这样，我们完全可能用。我不会承诺永远只吃一种技术路线。我守的是最终要优化什么、给用户造出什么价值。产品是发了，可我们仍觉得还有不少事要干。

Swyx： 视觉能力也是眼下缺的一大块。不过，它适合塞进 System 1 模型吗？

Diogo Almeida： 在我看来，什么能力都可能加进来。我们内部也在争一个更大的问题：是先给用户我们判断他们真需要的东西，还是更快给到他们明说自己想要的功能？过去两年没公开产品时，我们主要走前一条路，因为确信这个方向有价值。产品发布后，这两者得找平衡。

上下文长度就是一例。据我观察，我们的模型在长上下文里保持能力方面表现很好。可行业里也常见另一种打法：用户想要更长的上下文，就接着把数字往上堆。反过来说，要是我们太坚持“我们知道用户需要什么”，又可能变成替开发者做太多决定，那对开发者同样没好处。

我们不想把判断模型能力边界的全部担子都甩给开发者，也希望他们作为有判断力的成年人，自己做出知情的取舍。接下来要解决的是：功能以多快的速度发布，才能既顾上产品的可信度，又顾上开发者的自主权。Swyx： 这个权衡说得通。

Diogo Almeida： 老实讲，我们还没答案，只能边做边找。接下来几天，这恐怕就是我最需要反复聊的问题之一。我们手里还攥着不少东西。这次发布反响这么大，之前真没想到，我们原本还打算之后陆续放一些后续成果。

发布前没人看懂，发布后用户开始教他们怎么用

Swyx： 我不太信你们完全没料到发布后的反响。过去两个月，我从没见过你这么全力扑在一件事上。Diogo Almeida： 那也得谢我的幕僚长，是他逼着我必须全力扑上去。我以前以为自己已经够拼了，这回才发现还能更拼。

Swyx：我们办写作工作坊你居然也来了，那会儿我还纳闷：他怎么也跑来了？看得出来，你们为这次发布做足了准备，而且是有意识地在铺路。效果摆在那儿，恭喜。

Diogo Almeida：多谢。但愿接下来这股劲头能续上。技术圈的好几道关我们已经过了，后面还有不少坎要迈，我挺想接着干下去。

Swyx：在聊TypeSafe之外的事之前，这次发布还有哪些地方你觉得被低估了，或者被大家理解偏了？比方说产品的用法、模型能力参差不齐这些。

Diogo Almeida：每个点我都能扯上半天，还是收着点。有一点想单独拎出来说，就是我们的示例手册（cookbooks）。团队在这上面下了大功夫，内容也挺顶用。本来我们想把不少例子塞进发布博客，可那样文章就太长了，也显得只照顾深度用户。

说真的，发布前我们心里没底：这东西听着像外星来的，别人凭什么要用？我们判断，让大家搞懂这个新方向，可能会是最大的坎，所以在说明和示例上砸了很多精力。现在看，用户做出来的东西远超我们预想，这道坎也许没那么高了。

Swyx：等于用户反过来教你们怎么用自己的模型。

Diogo Almeida：是这个理。有些用户的玩法比我们的演示还带劲。我看到一些计算机操作方面的案例时就想：发布时要是拿这个出来演示该多好。示例手册那边，我们是实打实做的，不是随便生成一堆东西凑数。每个例子都有用，不少是从帮客户解决真实问题里来的。

Swyx：发布之前，你们做了多少用户验证？当时具体是个什么状况？那会儿能接触到的人可比现在少多了。

Diogo Almeida：老实讲，发布前的反馈不怎么样。团队里非技术岗的同事尤其犯嘀咕：不少人既没看明白，也不觉得自己用得上。大家会问，我们卖的到底是“维生素”，还是能止眼前痛的“止痛药”？是不是还得配上前沿部署工程师（FDE），替客户把周边软件都写好，产品才转得起来？

发布前我们基本没什么收入。技术团队信它，是因为能看到它在多个维度上的计算特性，也相信它潜力够大。可我自己怕得要命，这也是那阵子我拼了命投入的原因。

让一半以上的试用者搞懂它在干嘛都费劲。少数看明白的人会说：“这挺酷，可我们怎么走采购流程？”整个过程不轻松。后来我们拍板，先面向开发者发布。开发者自己会找到用法，其他人看到实际效果，自然也想用。

那些后来改主意的人，我不想笑话他们，情况确实变了。但这段经历让我重新琢磨“产品市场匹配”这个词。发布前，我们拿着产品去问潜在用户：“你们会用吗？”他们说：“不知道能不能解决我们的问题。”发布后，需求一下就炸了，大家开始问：“能把我们的速率限制再提一提吗？你们算力不够，我们甚至能给你们供GPU。”

营销当然起了点作用，但我觉得更要紧的是，一群真喜欢这个方向的开发者先用了起来，他们做出来的东西又带动了更多人。

Swyx：不少公司也是从开发者起步，最后转向大企业客户。

Diogo Almeida：没错。但我希望我们一直记得最早支持我们的那批开发者，别只把他们当成进企业市场的跳板。我甚至在琢磨，能不能推出一些对开发者比对大企业更有利的东西，让他们拿到更多能力。我脑子里已经有些想法了，虽然这么干可能很不寻常。

我也不知道还能怎么表达谢意。昨天我去染头发，也是想借机继续和他们聊聊。公司正处在一个要紧阶段，这时候反倒不跟开发者说话了，我会觉得不对劲。

Swyx：所以你的头发是这么来的。

Diogo Almeida：对。请大家以后拿这些话来要求我。我希望自己能守住原则；哪天我变了，尽管指出来。

从暗数据到智能软件：Jev 瞄准四类核心场景

Swyx：我想给大公司的开发者指几个具体方向。哪怕他们眼下没做这类项目，也能知道有哪些用法值得去看。

Diogo Almeida：我本来想先聊编程 Agent，不过还是先把主要的几类用法讲完。这些方向是发布前我们就从基本能力出发梳理出来的。

我们管第一类叫“暗数据”（dark data）。不少公司手里囤了大量数据，却迟迟没能好好利用，原因就在于拿大语言模型去分析，成本压不下来。这类活儿对大型企业特别有吸引力——它们有的是等着被分析的数据。数据科学家同样对这件事很感兴趣。在我看来，暗数据分析和编程 Agent，大概率是调用量最猛、赚钱空间也最大的两个方向。

第二类是实时场景，得在处理流程里迅速拿到模型的判断。这类公司的 CEO，或者至少 CTO，大概都门儿清：响应时间每少 10 毫秒，产品体验能好多少。

Swyx：电商尤其明显。

Diogo Almeida：没错，各种AI助手同样需要这种能力。我从团队那边得到的反馈是，这些用户对Jev很认可；不过我现在不直接管客户沟通这块。我自己特别想看到它用在游戏场景里，比如玩家下指令指挥队伍作战的那种自动或半自动对战游戏。那会挺好玩，只是趁我还有工作的时候，先别把它做得太强（笑）。

第三类我们称作“验证一切”：拿它去检查其他大语言模型的调用和输出，有点像给AI系统加上可观测性。这里有个实用的做法：假如你手头有一大段状态信息，想并行核查其中很多内容，那就给每条消息编上ID，然后按各个ID分别提问。这样一来，较长的状态信息只用传一次，就能围绕里面的消息问出很多问题，成本能压下来一些。

Swyx：按System 1和System 2的分工来想，这好像意味着：每调用一次推理模型，就能配上一次、十次，乃至上百次Jev调用。

Diogo Almeida：也许吧，不过我更希望用户少花点。比如说，把本来要做的推理模型调用砍掉一半，再给每次调用搭上几次Jev判断。具体怎么搭，得看它能不能解决原来解决不了的问题。

第四类是“智能软件”：把智能判断变成软件自身的一部分，让程序能组合出过去做不到的行为。有人试着把Jev塞进编程语言里，做出来的东西挺有意思。我们现在的基建还处于早期；要是发放使用额度能更方便，我很愿意支持这类项目。

这四类是我们提前梳理出来的主要方向。计算机操作是后来才冒出来的用法，可以归进实时场景里。要是它能稳定跑起来，我会非常兴奋。这个方向多多少少出乎我们的预料，我也觉得模型在这块还有很大的提升余地。

Diogo Almeida：编程Agent这块眼下有件事让我挺意外。据我所知，Claude Code和Codex大概是目前最领先的两个产品，不过我没有一直盯着排名看。它们基本上是照着“单模型”的思路做的，这很合理：以前开发者挑编程Agent，主要是在功能差不多、能力高低不同的模型里面选。

现在，开放式的编程Agent项目都在兴头上试着接入Jev。我相信他们也在试别的各种搭配。眼下这些Agent的能力大体接近，毕竟只靠一个循环调用模型的框架，能做出的差异有限。一旦有人找到某个只有自家Agent才能做好的关键用例，用户就会涌过去；可其他开放式项目也能很快学过去。Claude Code和Codex则是围绕单模型搭起来的，我挺好奇它们打算怎么接招。

我个人很希望跟它们集成，也希望Jev能接进各种产品。它们将来也许会推出跟我们竞争的能力，这我说不准。但作为一家基础设施公司，我的职责不是替行业提前决定大家该用谁，而是让更多人能用上我们的能力。这会让编程Agent市场变得很有意思。

我还写了份内部文档，梳理了一些可能适用于编程Agent的设计模式，正在让团队审。希望能很快分享出来。这个领域有太多东西值得摸索了。要不是我正忙着做Jev，现在也很想亲手去做编程Agent的实验。

Swyx：编程Agent公司应该也乐意跟你们一起探索。我觉得Claude Code和Codex仍然有接入Jev的空间。接下来先跳出TypeSafe，聊聊你对AI研究方向、尤其是安全与对齐的看法。

“放慢前沿进展”之外，还有别的研究路线吗？

Swyx：我最近参加了一场研究者聚会，大家确实在担心技术发展的速度。有一种说法是，公众还没准备好，所以前沿实验室应该放慢脚步。你怎么看？

Diogo Almeida：这话题容易引起争议，不过我愿意聊。我还想专门写一篇更完整的回应，这里先讲个简短版本。

在我看来，“要不要放慢前沿进展”的讨论，往往默认了一件事：所有人都得接着做RLVR，而且力度要不断加大。可我不这么看。就Jev这类模型想完成的任务来说，我认为最合适的RLVR用量甚至可能是零。

RLVR也不能只从“奖励可验证”这个角度去理解。推理模型兴起之前，人们就试过用可验证结果做强化学习，并没有因此自然而然地得到今天的效果。训练任务的整体形态同样关键。我想起一段经历：RLHF刚开始受关注的时候，有几条后来被统称为“后训练”的研究路线在同时推进。指令遵循当时并不被所有人看重，因为评估它太麻烦。我曾跟预训练团队说，这里面有关键价值；他们的顾虑是，模型实验做得那么频繁，难道每次都要等人工评测结果出来才能决定选哪个模型？

那会儿，代码生成也拿到了很多资源。团队试过用单元测试的结果给模型做强化学习，取得过一些成果，但光有可验证的测试结果，并不能自动带来今天这种推理能力。所以RLVR的效果不只是奖励函数带来的，还跟模型被允许经历怎样的推理、采取怎样的中间步骤有关。为了让模型解出最难的问题，研究者会给它很大的行动空间。

所以我对那套“把前沿进展压下来”的说法一直存疑。当然，有人会反驳：也许是沙箱隔离做得不到位。这确实可能是个原因，而且也能修。可实验室为什么愿意给模型更大的行动空间？因为那样它做任务可能更出色；一旦把约束收紧，又可能折损一部分性能。在我看来，这里面有不少设计取舍，本该是研究者自己去扛的，现在却被讲成推进AI绕不开的前提。

Swyx：如果先接受“必须沿着这条路线继续加大投入”这个前提，再推出风险会增长，逻辑上是说得通。但前提本身还有别的选法。

Diogo Almeida：对，就是这样。真正去重新定义任务或者研究目标的做法并不多，大家更容易顺着原来的路往下走。对别的可能性，眼下想得还是不够开。

公众不该为这种局面负责。他们不是研究这件事的专家，通常只能相信OpenAI、Anthropic等实验室已经在尽最大努力；更清楚技术上还有哪些选择的，是研究者自己。

Swyx：你们做的事，也是在让大家看到另一条路。

Diogo Almeida：我尽量吧。不过我没打算去说服别的实验室改方向，我真正想做的是让做软件的人重新有信心，动手把他们早就想自动化的那些活儿给自动化掉。

以前我写过一篇文章，讲的是我心目中AI未来该是什么样，结果团队没同意发。那里面有挺多设想，单看都很小，但体验会因此不一样。刚才语音操控电脑那个演示就是一个例子：以前的计算机太死板，你说什么它就照字面执行；要是它能更懂人的意图，很多事做起来会顺得多。

我不想承诺这些很快就会实现。但我们会尽力推动，让智能逐渐进入软件的各个角落。

Swyx： 回到训练方法。你深入参与过后训练，怎么看“中训练”（mid-training）？我们好像还没聊过这个。

Diogo Almeida： 训练的不同阶段更像是一条连续的谱系，没有那么清楚的分界。

Swyx： 可以理解成一种更复杂的课程学习？

Diogo Almeida： 可以这么说。中训练也有成本上的考虑：你不必为了增加某些能力，从头再做一遍预训练。

在我看来，智能在训练的每个环节都有点说不清道不明，很难拿几条简单规则去概括。去看数据、去搞清楚能力到底是怎么进到模型里的，这事儿挺有意思。我们的数据团队在这方面很拿手，我不如他们。我更偏向从整体结构去想问题，也很乐意听他们讲从数据里看出了什么。

打个比方，短时间里靠微调就能让模型很快表现出某种倾向；可要是相关的训练一直做下去，有些能力就会一点点扎进模型里，变得越来越稳。我想找的就是那些能稳定发挥出来的能力。前面提到的System 1式能力，也算在里面。所以我对中训练有兴趣，也愿意支持把各种训练方式都试一遍，看还能从模型里挖出什么。只不过这些方法烧钱，我不可能每种都自己上手做。

有件事我以前只私下讲过。我觉得既然能对投资人说，那也能公开跟大家说：哪怕给我10亿美元，我也不会自己去搞预训练。我现在还是这个想法。预训练实在太贵了。作为AI工程师，你可以把现成的模型拆开、把不同的能力拼到一起，各种路子都试试。像“弗兰肯斯坦”那样把模型缝起来，可能不够漂亮，但管用。反正，我会去试预训练以外的办法。

Swyx：顺着这个说，有个问题值得聊聊：以后是把所有能力都塞进一个“超级模型”，还是继续把不同能力分到不同模型上去？OpenAI以前是往全能模型（omni model）那个方向走的，GPT-4o就是例子。可有一阵子，也能看到聊天优化的模型和编程优化的模型各走各的路。

Diogo Almeida：这其实是两个差得很远的问题，得分开讲。多模态是一码事：多加上别的模态，有时候对模型有帮助，有时候反而拖后腿。比如我看到有些团队好像在收缩对语音（speech）的投入。这里说的语音，跟更宽泛的音频（audio）不是一回事；语音这块能力眼下好像不太容易迁移到别的任务上。这问题以后说不定能解决，但还得看实验结果。

各种形式的智能我都支持去探索，但不能觉得只要照着缩放规律往里砸投入，问题就一定没了。缩放规律说到底要回答的是：投入加上去之后，能力到底涨了多少？有些任务就算规模继续扩大，也未必能达到能用的水平。就我了解，计算机操作现在还没解决。我希望我们能在里头出份力，但也可能不管收多少数据都不够，得把方法改一改。

所以，问我支不支持全能模型，我的回答是：各种能力我都支持去探索。不过你刚提的另一个问题更值得细说——后训练会怎么影响模型本来就有的能力。我特别不喜欢把智能训练得七零八落。

以聊天优化为优先的训练，往往很依赖RLHF，也容易带出大家常抱怨的那些毛病：顺着用户说、过度自信、幻觉。甚至像LM Arena这类评测里那种讨喜的回答风格，也可能是训练目标给塑出来的：一堆加粗、斜体、表情符号；不正面回答问题，先写一大段，再反过来问用户一句，让对话显得更像真人。

我认为，这跟让模型更准确地发挥已有能力，是两码事。让模型写一段自由文本，本来不确定性就大；训练当中，模型可能学会用一种非常笃定的口气去维持某种回答模式，好避免明显跑偏、被奖励模型罚。这会改掉它的概率分布，也会跟推理能力互相影响。模型可能学会一些取巧的路子，把目标给完成了，可判断能力未必就因此更稳。弄明白这些细枝末节的变化，是研究智能很重要的一块。至少我还在OpenAI的时候，我觉得这方面研究得还不够，大家更多是在优化“聊天”这个目标。

Swyx： 一旦确定目标，团队就会集中优化它。

Diogo Almeida：对。有人会说，那就两个目标一起优化。但在我看来，把模型分别往不同目标上拽，本身就可能把能力扯裂。

Swyx： 可是，你把能力分成 System 1 和 System 2，某种程度上不也是在拆分智能吗？只不过你不认同别人拆分的方式。

Diogo Almeida：我觉得这俩不一样。我们并没有把System 2任务丢掉。开发者可以拿Jev去试这类任务，而碰到模型没把握的问题，一个合理的结果就是说出“不确定”。它应该给出比较低的置信度，把不确定性明明白白摆出来；某些启发式方法说不定还能让表现好一点。这些任务我们同样上心，只是我认为，长链条的System 2式推理并不是这个模型最自然、最稳的能力形态。

我也不想为了塑造产品身份去改模型的回答。比如有人问它是谁，我不会专门训练它答“我是TypeSafe的Jev”。那等于把一个品牌要求写进模型的判断里。我更愿意它根据学到的东西给出正确回答，让能力保持平滑、可预测。

Swyx： 模型身份对直接面向用户的产品来说，可能是个特殊问题。

Diogo Almeida：对，第一方产品是得考虑身份。但如果提供的是API，那就不一样了。开发者拿模型做自己的聊天产品，一般希望它呈现的是自家产品的身份，而不是开口就说“我是ChatGPT”。

Swyx： 为了让开发者更容易把 Jev 用进产品，你们也提供了 Jev Skill，让编程 Agent 知道该怎么与 Jev 配合。

对。

从 InstructGPT 走到 TypeSafe AI 创业

最后几个问题。回头看，你做这事有两年多了吧？

按公司成立来算，两年多。但对我个人来说，它其实是一段四年的经历。

我记得有一年感恩节，你把别的安排都推了，说大家正好放假，空出来的 Edge GPU 可以拿来做一次集中实验。那会儿 TypeSafe 还没成立吧？

没错，那阵子挺有意思。是不是刚好撞上 OpenAI 那次管理层风波？我记不太清了。

对，时间差不多。

那就对上了。那场风波很让人烦，不过今天没空细说。

你说烦的是风波，还是实验？

是风波。也许下回聊的时候我再讲当时的事。但 Jev 要解决的问题，早在 ChatGPT 发布之前就在我脑子里转。那时我看 ChatGPT 团队做的事，觉得任务选对了。他们干了件很多 AI 研究者不拿手、可优秀产品团队特别看重的事：把用户体验一点点磨好。当时的 OpenAI 里这种人不多，ChatGPT 团队这块做得确实好。

你说的这段，能追到 GPT-3 往 GPT-3.5 走的那个阶段。那会儿还有 AI Dungeon 这类应用，也是你们事先没料到的用例。

对。我当时也很用力地推 InstructGPT 上线。早期有些版本用了我自己设计、后来没公开的训练算法，因为清理 PPO 数据实在太慢。我那时候想：效果都这么好了，得赶紧让用户用上。

上线之后，它很快在当时的大语言模型使用市场上占了一大块，我们估算大概 50%。我还花了很多力气，保证发布视频里的演示都是真的。那时我甚至认真琢磨过：一个模型能这样理解和执行指令，算不算 AGI？现在看显然不算。但我觉得每个人都该想想，为什么它看着这么聪明，却仍不是 AGI。

再后来，我发现它主要被拿去写营销文案，比如 Jasper AI、Copy.ai，还有大量往网页里填的文字。我们一度担心，是不是把互联网搞得更糟了。于是我重新想：模型明明显得很聪明，为什么没造出我们期待的价值？还差什么？

我试着从一场 AI 推动的经济变革倒推：如果 AI 以 API 形式存在，未来主要是谁在调它——人还是代码？我的判断是，绝大多数调用会来自代码。可当时的优化几乎都冲着人与模型的对话去。那一刻我意识到，该把“让程序能可靠地调用智能”当成目标。

我写了份文档，也跟 Sam 聊过。他觉得这方向很好，建议我去做。我当时回他：“可我还有本职工作啊。”

Sam 都让你去做了，那就去做啊。

我当时还觉得，这方向太显而易见了，Anthropic 肯定已经在做，我们可能已经晚了。我那时的看法是，OpenAI 往往更擅长追已有方向。比如我认为 ChatGPT 与 Anthropic 此前内部做过的聊天产品有相似之处，只是后者当时没发布。

对，之前还有在 Slack 里用的 Claude。不过推理模型这条线上，OpenAI 算是较早推出产品的。

研究成果很出色。至于它是否对应用户当时最迫切的产品需求，我不太确定。编程 Agent 这边，Claude 也做出了重要的产品。

跟 Sam 聊完，我先回去干原来的活。后来指令遵循团队觉得这块进展已经很大，我也开始想下一步做什么，于是试着研究那个面向程序调用的方向。我本以为训模型、验证想法一周就够，结果花了好几年。

中途有一次，我看到了初步有效的迹象。它当时显然还不能直接部署，否则我们早就发了。但我很想知道，如果在研究上全力投入，这条路最后能走到哪。我也想过：要是 AI 最后进入新一轮低谷，而我明明看到了这个问题却没认真试过，我会觉得自己有责任。

我和其他公司聊过，提出想建一个研究这个方向的实验室，也得到了一些兴趣。可当我问他们，加入现有公司和自己创业，哪种推进得更快，他们的回答是“创业”。于是我决定自己做。

然后你联系了 Eric 和 Sasha？

我先找的是 Eric（译者注：Erik Gafni，现任 TypeSafe AI 首席技术官）。去找 Sasha（译者注：Sasha Sheng，现任 TypeSafe AI 首席运营官）的时候，我其实没打算拉她入伙。我就是想问问她：“会不会是我想偏了？是不是在 OpenAI 待太久了，外面的解法我根本没看见？”

她的回答是“我加入”。我跟她说，你手上那家创业公司还在做呢。她说快收尾了。我让她再仔细想想，她想了，然后还是决定来。

两周之内钱到账了，也有人搬进我的公寓一起干活。我这人有点洁癖，那阵子过得挺难受。研究继续往下推，后来终于跑出了一些结果，说明这条路初步能走通。

别再复制前沿实验室：先找到你的 North Star

背景说了这么多，我真正想问的是：假如现在有位前沿实验室的研究者，处境跟当年的你差不多，觉得自己的方向拿不到资金、资源，也没人重视，你会劝他也出来创业吗？

这问题挺有意思。我得琢磨一下怎么说，才不至于一下子得罪太多人。

说句实在话，除非这些新兴实验室背后有什么我还没搞懂的经济逻辑，否则大多数我都不太看好。我在意的不是研究者简历好不好看，而是他们有没有认真挑一个值得解决的问题。研究者当然需要，但他们得真的在乎自己做的这件事。对我来说，第一步是找到一个值得长期押注的 North Star（核心目标），再围着它做真正有用的东西。光有一份漂亮的研究背景，一般不会自动变成价值。

我信的是目标得清楚，做的事得有用。一家新实验室方向明确，我举双手支持；可要是从头把别人做过的事再做一遍，拿了钱跑一堆实验，真正把前沿往前推的机会又很小，那我看不出它造出了多少价值。跟一些新兴实验室聊下来，有的团队确实还没想明白自己要去哪。

所以建议得看你为什么走。如果只是想更自由地试各种研究题目，那现有实验室可能还是最合适的地方。我更希望你是带着一个要解决的问题出来的。这个问题可以是探索性的，但最好有你自己认的原则和方向。要是你确定自己找到了一个值得投入的新任务，那我非常支持你去干。研究圈里的思路越来越趋同，总得有人出来打破。

像一种“蜂群思维”。

对。“放慢前沿进展”那套说法，有一部分也来自对 AI 的某种特定想象：模型聪明得吓人，能力却极不均衡，于是带来特殊的风险。可这只是发展 AI 的一条路线，不能当成唯一的可能。去试不同的技术方向，这件事本身就有价值。

公平地说，我想准确转述一下之前跟我聊过的 OpenAI、Anthropic 还有 SpaceX 人士的意思：他们讲放慢进展，考虑的不只是灾难性风险，也有政治层面的东西。

政治层面的事，就超出我的专业范围了。

我当时听完，也意识到他们讨论的时点可能跟 2028 年选举有关。

我真希望没听到这一层。感觉很糟。

先说明一下，这只是当时那场讨论里部分人的说法，代表不了整家公司。

明白。也许我是个天真的技术人员，但听到这些，我多少有点失望。

随着技术发展，谁来执政、监管规则怎么定，确实会越来越重要。实验室也得认真对待这些问题。

这点我完全同意。我担心的是，为了达到某个自认为正确的目标，公开沟通时把话说得太满，或者让公众产生误解。政治我不想在这儿展开谈。我的原则是，就算出发点被认为是为了公共利益，也该尽量把事实和不确定性说准确。

就我听到的讨论而言，我不觉得他们是在误导公众。他们更多是在解释，为什么现在要提放慢进展。

我理解。但如果公开强调的风险理由，跟实际推动这件事的目标并不完全对得上，我还是觉得其中有该说清楚的地方。希望以后我们尽量别卷进这种事。公司变大之后，也许很难完全置身事外，但我还是想守住自己作为技术人员的出发点。

那我开个玩笑：让 Jev 去竞选总统吧，我说不定比信任自己的决定更信任它。玩笑先放一边。你们已经定下了自己的 North Star：让 AI 可靠、可编程、可组合，还要便宜。要是把机会让给别人，你最希望他们去解决什么问题？

这问题太好了。我先说一个好玩的，再说一个我觉得很有研究价值的。

第一个是游戏。游戏里的角色和世界要是能更智能，会非常有意思。我看过 Ali 做的《Doom》演示，玩家能让 NPC 去做一些操作。那还只是概念验证，却已经让我想到很多可能。我很喜欢《星露谷物语》；它的世界相对静态，照样很吸引人。要是角色能对游戏状态作出更多反应，就能长出很多新故事。

每一帧游戏画面都调用Jev也没必要，成本恐怕吃不消。哪怕只在NPC的状态机中掺入一点智能判断，游戏世界也有可能鲜活不少。眼下没法亲手做这些项目，我觉得挺可惜。

Swyx：可以交给别人做，你来给反馈就行。

Diogo Almeida：没错。另一个我很想看到有人去趟的方向，是让编程Agent的设计不再受KV Cache束缚。我写过一篇《KV Cache Rules Everything Around Me》，专门讲现在的编程Agent跟KV Cache之间是怎么互相牵制的。不少现象都能由此得到解释：模型路由为什么难做，子Agent为什么常常达不到预期，上下文压缩为什么同样扎手。

另外我还写了一份新设计模式的文档，交给团队审阅，希望之后能发出来。我想把想法摆到大家面前，请各位动手试试：假如不再受现有KV Cache用法限制，编程Agent还能怎么设计？

Swyx：你说的“绑住”，指的是它卡住了模型选择？

Diogo Almeida：这是一头。要高效利用KV Cache，系统通常得不断往已有上下文后面追加内容，也就容易锁死在同一个模型上。久而久之，设计就会偏离软件工程里那些熟悉的做法，比如显式管理状态、做抽象、拆任务。

打个比方，简单任务为什么不能丢给更便宜的子Agent？难点之一在状态交接：父任务攒下的一大堆上下文要是全传过去，子Agent光读这些信息就可能烧掉不少成本。那能不能更聪明地判断，它究竟需要哪一块状态？

这里头可研究的编程模式不少。可以给状态标上明确含义，把任务组织成有层级的子任务。编程Agent本来就是一个接一个处理子任务；某个子任务做完，为什么非得把它碰过的所有状态都塞回父任务？真需要信息时，为什么不能在子任务树里检索相关上下文？

只要访问上下文的成本足够低，回看历史记录也能更方便。现在的Agent常常像每次都从零干起，然后我们又单独去啃“持续学习”这块硬骨头。其中一部分其实是记忆管理：信息并不是压根不存在，而是系统不知道怎么有效地把它找出来。

并行干活的子Agent也是同理。它们的状态既然存在计算机内存里，为什么不能有选择地读取彼此的进展？哪些内容正在写入、哪些允许读取，都可以管得更清楚。多个Agent协作时，协调方式说不定也能比简单加锁更灵活：“你这会儿在改什么？我改的是哪块？谁该先写？”

Swyx：让Jev来判断谁先拿到锁？

Diogo Almeida：多Agent协作里确实可能出现这种用法。还有些Agent只管读状态，比如向用户汇报其他Agent的进展。它不用看完所有探索过程，只要能找到已写入的结果、相关子任务和当前状态就够。

要是有人肯花足够多的时间，重新琢磨编程Agent该怎么保存、查找和共享状态，我觉得能做出挺有意思的东西。这是我特别想看到的方向。

Swyx：你可以去看PrimeAgent。它跟递归语言模型（RLM）那边的工作有结合。我们刚和参与这方面研究的Alex聊过。这条路已经有人在走，只是眼下还不算热。

Diogo Almeida：那挺好。我希望更多人尝试各种不寻常的想法。我没法保证它们一定管用，但从技术角度看很值得探索。等我们把发放使用额度的机制建起来，也希望能支持做这类实验的人。

Swyx：将来你们说不定还能直接资助相关研究。也恭喜你和整个团队走到今天，从我头一回认识你到现在，你和团队都走得很远。

Diogo Almeida：我希望自己还是原来那个人。

Swyx：我同意。但你身上这股劲儿，我以前真没见过，原因是你清楚了自己要干什么。之前那么多年，你总在挑毛病，可始终没拿出一个真能落地的方案；再往后方向算是有了，你又花了很久才把它真正做出来。

Diogo Almeida：还有一点，我打心底觉得自己压根没有创业者的性格。创业这事我不喜欢，CEO这个位子也从没想要过。干一回就够呛了，实在想不通怎么会有人乐意来第二回。最早融资那阵，有个投资人问我最佩服哪位CEO，我脱口而出的念头是：“我干嘛要佩服他们？”

没有针对谁的意思。我碰到过很多很不错的人，只是有些名气最大的人，身上好像也藏着不少不愿让人看到的东西。在OpenAI的时候，我确实感到想推动的事情推不动。如今好歹有了一点证据，能说明我们这条路也许走得通，当时那些想法我也更容易讲明白了。

当时身边聊得最多的是“怎样让ChatGPT进入更多产品”“怎样让ChatGPT对开发者更友好”。可我琢磨的却是另一件事：函数调用接口现在这套设计，凭什么非得是这样？开发者拿它怎么才能稳稳当当地操控程序？

Swyx：像是在已有的变通办法上，再叠加一层变通办法。

Diogo Almeida：这还不算完。我那阵子老讲：要是函数调用做不到给每个函数配上对应的logit bias，让开发者能知道、也能调整模型挑中它的概率，那这项目就别拉我进来。我提的条件真不算多。

Swyx：你想要的是某种与置信度接近、但未必经过校准的信号。

在 Diogo Almeida 看来，能不能让开发者选择某个函数的概率，至少得给出这么个口子。模型在不同场景下该做什么、该放行还是该拦住，这些都得由开发者来拿主意。同样是拒绝，迪士尼和 AI Dungeon 想设的门槛差得远。问题是接口如果只允许开发者靠提示词一遍遍请求模型“这种时候请拒绝”，那它凭什么叫好的程序接口？可大家已经这么用了好多年。

现在的 Skill 也差不多。现有编程 Agent 对自家运行框架适应得不错，能力却参差不齐，用外部工具和 MCP 的时候经常不太靠谱。某个工具要是对业务很关键，开发者凭什么不能明确把模型调用它的倾向调高？眼下多半还是得在系统消息里翻来覆去地要求。他觉得这很不合理。

Swyx 表示理解了，也很高兴能在节目里聊这些，并期待对方接下来要发布的东西。

Diogo Almeida 道了谢，说接下来可能比 Swyx 想的还快。

Swyx 问，你们现在还在招数据、基础设施、市场和社区方面的人？

都在招，Diogo Almeida 回答。他自认为还能胜任创始营销负责人，但团队会让他别再抢这份活，好好当 CEO。事情一下子多起来之后，人很快就会学会授权。

负责模型能力的人也在招，这部分工作很大一块跟数据有关。他说自己希望团队充分认可这类工作的价值，让直接改进模型能力的人得到应有的重视，同时又不在团队里搞出奇怪的等级。

聊到文化，他挺高兴同事们不会因为他是 CEO 就事事顺着他。他们会开他的玩笑，也会当面反驳他。他觉得这是个好信号。

另外还得招平台工程师，把 Jev 部署到更多地方去。服务器位置对他们来说格外要紧，网络传输时间会直接拖累延迟。现在欧洲还没有他们的服务器，欧洲用户拿到的速度提升可能只有约三倍，而不是本来有机会达到的约一百倍，这让他挺遗憾。

Swyx 打趣说没关系，欧洲的生活节奏也慢一点。

Diogo Almeida 笑着回了一句，这话可是 Swyx 说的，不是他说的。总之他们希望把服务铺到更多地区。如果“每秒能获得多少智能”对用户重要，他们就会把服务部署到更多地区。开发者在他们的能力之上做产品，他很在意这些人的使用体验。

招人还在继续，Jev 之外的能力也要接着开发。这家公司的目标不是只做 Jev 这一款模型，更不想只靠一种简单模型走到黑。以后可能需要一个像 AWS 那样的平台，提供形态各异的智能能力。他希望公司朝这个方向走。

Swyx 追问，那个平台会是你们吗？

Diogo Almeida 说，现在就咬定一定是他们，太自大了。但他会尽一切努力去做。他觉得这事会很有意思：现在探索的只是 System 1 式智能中的一层。拿 TCP 类比的话，上面还能搭很多层能力。

Swyx 接话说，对，还有很多层，他甚至提过 Temporal，也许它能算传统七层模型之外的“第八层”。不过这话题又能聊很久。他让对方回去工作，或者好好睡一觉，并道了谢。

Diogo Almeida 谢了邀请，说聊得很开心，也很期待接下来要做的事。