在 OpenAI 工作时，Diogo Almeida 经常感到困惑：为什么大家都在讨论如何让 ChatGPT 对开发者更有用，却很少追问，聊天模型本身是否适合成为软件的底层组件？开发者想控制一次工具调用，往往只能把要求写进提示词，再等待模型配合。在他看来，这套接口距离软件工程所要求的可控、可测与可组合，还有很……

本文来自微信公众号：Z Finance，作者：ZF编辑部，题图来自：视觉中国

在 OpenAI 工作时，Diogo Almeida 经常感到困惑：为什么大家都在讨论如何让 ChatGPT 对开发者更有用，却很少追问，聊天模型本身是否适合成为软件的底层组件？开发者想控制一次工具调用，往往只能把要求写进提示词，再等待模型配合。在他看来，这套接口距离软件工程所要求的可控、可测与可组合，还有很远。

如今，作为 Typesafe 的 CEO，Almeida 正在用新模型 Jev 回答这个问题。他希望让软件直接调用智能，获得可以参与程序运行的决策、概率和评分。这场访谈围绕一个核心问题展开：当智能足够便宜、足够快，也足够可靠，软件会发生怎样的变化？从训练数据到 Agent 架构，他的判断都指向同一个方向——AI 的巨大增量，可能藏在那些用户看不见、却每天运行无数次的软件流程里。

以下是他的主要观点：

• AI 的下一种重要形态，是供程序调用的智能。 聊天模型主要围绕文本交互优化，而软件需要语义明确、行为可测的接口。Jev 尝试直接提供选择、概率与评分，让智能进入程序的条件判断、排序和执行流程。

• 模型是否可靠，不能只看回答是否正确，还要看它能否准确表达不确定性。 在 Almeida 看来，一个看似自信的答案不足以支撑生产系统；开发者需要能够据此设置阈值，决定何时自动执行、调用更强模型，或交给人工处理。他也承认，Jev 的校准与可靠性仍有明显改进空间。

• 更好的 AI 软件，需要把复杂任务拆成可以逐项验证的小决策。 与其让一个模型阅读庞大的系统提示词、一次性决定所有事情，不如将任务拆解，由代码组织流程、约束权限，并为每个判断建立测试。这样，修复一个问题才能成为可以持续验证的工程改进。

• 真正稀缺的能力，是为模型找到正确的训练目标。 他认为，行业过度关注算力与架构，却低估了任务定义和数据的作用。Typesafe 提出的 RLCD，即“校准决策强化学习”，就是尝试围绕模型参与程序运行这一目标，重新组织训练。

• 直接使用用户数据训练，可能让模型过拟合今天。 用户请求集中于少数高频场景，而他希望模型能支撑未来尚未出现的软件。因此，数据工作的重点是系统性寻找能力缺陷、补齐边缘情况，而非单纯积累更多真实请求。

• 智能变便宜之后，软件的设计方式也会改变。 当一次判断的成本与延迟足够低，开发者才可能在一次复杂推理周围安排数十次细小判断，用于验证、路由和检查。过去因成本过高而无人处理的企业数据，以及需要实时响应的应用，也可能因此获得新的使用空间。

• 今天的 Coding Agent 架构，受到 KV Cache 的深刻影响。 为了复用缓存，系统倾向于不断追加上下文，这又限制了任务分解、状态管理与多 Agent 协作。他期待开发者重新思考上下文如何检索、状态如何共享，让 Agent 更充分地采用成熟的软件工程方法。

• AI 的发展路线仍然开放，前沿实验室当前的选择并不代表全部可能。 他质疑把持续加码推理强化学习视为唯一方向，也主张区分面向用户的产品约束与底层模型能力。这些判断背后的共同立场是：行业仍有大量尚未被充分探索的智能形态，值得围绕实际用途重新设计。

Jev发布周与AI经济革命

主持人：这周是个特别的日子，我的好友Diogo发布了Jev，相关内容已经刷屏各大平台的信息流时间线。你现在感受如何？此刻是怎样的状态？

Diogo Almeida：情绪层面？糟得不能再糟。我现在整个人心力交瘁，事情铺天盖地涌过来。我是一名技术出身的首席执行官，有一大堆紧急问题要处理。但从理性层面来讲——我在自己的线下沙龙活动里已经讲了很多年这个观点：整个AI行业就如同嘉年华里的镜子迷宫，所有人都有些狂热，说着各种匪夷所思、逻辑不通的言论。但就在这周，我感觉自己更加贴合现实了。大家终于意识到，AI的潜力远比过去人们设想的要大得多。没错，一场以AI为基础的经济革命重新具备实现的可能性。这实在太振奋人心了，开发者们看懂了，我非常激动。没错。我发自内心地感谢开发者群体，对整个社区满怀热忱。

主持人：太棒了。你昨天提到，你决定优先举办线上公开交流会，而不是接待一众VIP投资人，希望把最多的注意力留给工程师、开发者，是这样对吧？

Diogo Almeida：没错。有时候我会想，我正在和一众大人物对话，具体是谁我不便透露。我这个人或许太过直率坦诚，如果满满当当的日程表里排满各路要人，却没有留给社区的位置，我心里会很别扭。理想状态下，我希望把绝大多数时间留给社区。我甚至突发奇想过，要不要一边走到你的演播室，一边开线上交流会，但想想还是算了，实在太过疯狂。

主持人：确实。你们一直在Discord（海外社群平台）举办线上交流会，社群现在已经有十万成员。你的Twitter也彻底爆火。说个趣事，在AIE活动现场，你嘴上说着“大家可以关注我”，结果连自己的账号ID都没报出来。但这反而形成一种很有意思的个人特质：你不太懂得自我营销。

Diogo Almeida：我发推文感慨“好家伙，我们三条话题全都冲上热搜了”，结果有人当场点破我：那只是你的个人信息流而已。

主持人：也难怪你会这么感慨，毕竟这就是你亲手做出来的成果。恭喜你们取得的一切。后续有更多细节我们可以再聊。给那些不了解情况的听众做一个权威科普：Jev到底是什么？

Diogo Almeida：让我想想，这个问题并不好回答。

主持人：没关系，如果你需要思考，我可以稍后再问一遍。

Diogo Almeida：不用，我很乐意聊聊。说到这个问题，让我松一口气的一件事是：现在我不用再跟我父母解释它是什么了，ChatGPT可以替我解释。在我看来，我们需要一类全新的模型。我们并没有执着于给这一类模型起名字，我们想到最贴切的叫法是系统一号模型。之所以不叫决策模型，是因为系统一号模型的能力范畴不止于此，这点我只能说到这里。我们原本没料到这次会是一场大规模正式发布，我们手里还储备着不少技术成果。

主持人：你们本可以对外说这只是低调的研究预览版。

Diogo Almeida：某种程度上它确实算是。我们定义这类模型为：机器原生、系统一号、大型可编程模型。这类模型的目标是让代码成为模型的消费方。这和预训练大语言模型不一样，预训练大语言模型目标是做互联网文本自动补全；也和RLHF（Reinforcement Learning from Human Feedback，基于人类反馈的强化学习）对话指令跟随模型不同，后者目标是输出文本回复。还有RLVR（Reinforcement Learning with Verifiable Rewards，基于可验证奖励的强化学习），它和RLHF处于一个比较模糊的交界地带。而我们的模型输出会直接被代码调用，这也是Type‑Safe这个名字的由来。我们真正追求的是把AI的能力拉到尽可能强，实现这一点的方式就是把AI和软件深度结合。从对外接口到模型深层内部，我们所有设计都面向软件场景做优化。

第一点，Jev是我们第一款大型可编程模型，也可以叫系统一号模型，看你习惯怎么称呼。Jev的设计目标是intelligence per dollar（每美元成本对应的智能能力），命名灵感来自Jevons paradox（杰文斯悖论）。我经常和别人争论，可靠性、成本、校准能力、速度，到底哪一项最重要。Jev作为系列模型，定位就是在每美元智能能力这条赛道上站在技术前沿。机器学习本身充满取舍权衡，如果你懂机器学习就会明白这一点，而我们正在全力朝着这个方向推进。

主持人：对我来说，校准是一个过去大家讨论度并不高的概念。我们之前做过一期节目，嘉宾是Hugging Face的Clementine Fourier。当时聊到一个观点：经过RLHF处理后的模型，会发生mode collapsing（模式坍缩），倾向于输出人类最想听到、概率最高的回答，而不是输出模型自身真实的确信判断。

RLHF、模式坍缩、校准与杨立昆

Diogo Almeida：我能不能就此展开说一说？我听说咱们听众技术水平普遍很高，我想深入聊这个话题。我们制作发布视频的时候，花了极大精力保证所有内容准确真实，而这在行业里其实并不常见。有一点几乎没人关注，就是RLHF带来的弊端，尤其是mode dropping（等同于mode collapsing）。我之后打算写一篇博客详细阐述，但我希望尽可能多的人了解这件事，这是一个很值得探讨的现象。

说一个比较尖锐的观点：我十分认同杨立昆（AI科学家）的很多观点，他的不少判断是准确度很高的。但他有一张非常出名、也饱受争议的幻灯片，标题大意是“大语言模型注定存在局限”。那张幻灯片有一个饼图，有一小块内容表达：随着sequence length（序列长度）增加，模型出错的概率会趋向升高。这个观点从数学推导上看似成立，但现实实验并不支持这个结论。这就是我很喜欢拿来科普的一类现象：理论推导看似没问题，但现实实证结果并不相符。

主持人：那造成这种矛盾的根源是什么？

Diogo Almeida：模式坍缩和这个问题是相关的。矛盾的根源在于：如果模型处于模式覆盖、分布校准的状态，它不会对异常输出施加过重惩罚。会有一部分输出属于分布外，一部分属于分布内，这就是完整覆盖数据分布的模型的表现。就像GAN（Generative Adversarial Network，生成对抗网络）诞生之前，生成模型输出的图像都是模糊的。而GAN会发生模式丢弃，直接抛弃少数类别，只生成高频常见样本，这就是上面那个理论预测没有成真的原因。

模型想要生成长文本还不出错，就要变得极度保守。错误发生的时候很容易被察觉到，但一些看似正确的细微偏差很难被发现。而校准问题会严重破坏字符串输出的概率分布。这是一个比较微妙的观点。这也是为什么字符串类模型并不擅长做决策，强行把字符串模型用于决策任务，效果会很糟糕。

主持人：说到GAN，那你是否认同杨立昆提出的解决方案，也就是世界模型，类似JEPA（Joint Embedding Predictive Architecture，联合嵌入预测架构）这类嵌入架构？问题根源在于模型基于token输出做推理，反复迭代拼接直到句子结束。JEPA 就是他给出的解法，也就是联合嵌入预测架构。你怎么看待这套方案？

Diogo Almeida：说实话我不太适合深入聊机器学习内部细节，但我的立场偏向实用主义。我怎么看待scaling laws（缩放定律）？要分情况看待。缩放定律告诉你投入多少资源性能会提升多少，但它往往意味着投入指数级资源，换来次线性的性能增益。除非增益本身价值极高，否则这笔投资并不划算。对我来说核心是：立足现有的条件，做出尽可能巨大的实际改变。

主持人：没问题，本期面向成年听众，不限制这类表达。我们后面也可以专门聊缩放定律。

Diogo Almeida：我们可以聊，但如果现在相关性不强，我想聊聊我踩过最惨痛的教训，这个话题会更切题。我对JEPA这套研究很欣赏，是很棒的早期研究。但它现阶段能不能落地实用？我不便过多评价。

可编程AI、拒绝输出与安全对齐

Diogo Almeida：现在AI研究领域有大量尚未打磨成型的宝藏思路，只是人们还没有找到合适的任务范式把它们发挥出来。我们这次发布，不光会推动公司自身发展，更会带动可编程AI这个方向整体向前。会有一波围绕我们的创业热潮，软件领域本身就具备巨大潜力。同时也会出现一批平行方向，探索各种可以增强软件能力的技术路径，开发者可以借此打造更厉害的作品。仿佛回到早期互联网那种充满活力的时代。也正是这个原因，Twitter上到处都在讨论Jev。

主持人：这和我们过去的固有认知截然不同，过去大家总觉得：缩放定律才是王道，只有大型实验室才有资格做这件事。

Diogo Almeida：允许我稍微跑个题，你或许会感兴趣，我们已经扯了好几个话题了。

主持人：我自己经常聊着聊着就跑题，听众需要自己梳理逻辑，但他们可以理解。

Diogo Almeida：Discord社群上很多人一直在问我一个问题，我还没有腾出时间详细解释：为什么我反对当下流行的安全对齐，为什么我们的模型不会输出拒绝回复。我并不反对安全这个理念本身，但当下的安全对齐机制很多时候和用户真实需求相背离。模型拒绝输出本质上属于一种类型错误。想象你在写代码调试，模型突然回复“抱歉，我无法读取DNA.py文件”，这会非常恼人。但大家已经被迫习惯这件事，近乎一种斯德哥尔摩综合征。

这里我又要引申一层思考：如果后台运行的一个依赖组件突然拒绝执行怎么办？别的开发者调用这个依赖，根本不知道内部发生了什么。你总不希望软件仅仅因为用户传入一段特殊输入就随机崩溃。这完全是不可理喻。会出现这种问题，根源在于制定这套机制的人并不懂软件、不懂编程，执着于把AI做成AI协作者，而不去释放AI全部的原生能力。

主持人：说得有道理。你想要的是一个可以在各类场景通用的核心底层内核。

Diogo Almeida：完全正确，也就是认知内核。它要足够通用，适配各类使用场景，能够应对未来千奇百怪的业务需求。我们训练数据并没有覆盖所有这些稀奇场景，但模型依然可以正常工作，这不奇怪，我们训练素材本身就包含大量更奇特的案例。

回到安全对齐这个话题。在我看来，安全对齐对于ChatGPT、Claude这类面向聊天的产品是合理的。要区分能力对齐和安全对齐：能力对齐的目标是完成用户想要实现的事，这对于软件工程师至关重要。工程师希望工具按预期工作，可预测性越强，测试调试的工作量就越小。Jev距离这个目标还有很大差距。未来我们希望它的可靠性提升到数据库查询那样，几乎不用额外思考，需要intelligence的时候直接调用。

而安全对齐和指令跟随恰恰相反：它要求模型遵循第三方的约束，就像OpenAI做的那样。作为面向终端用户的聊天产品，这么做无可厚非。比如产品方不希望模型生成不适合公开场景的角色扮演内容，照顾到家庭用户，这完全可以理解。但放在API（Application‑Programming‑Interface，应用程序编程接口）接口层面就不合理。开发者需要围绕接口行为编写代码，安全对齐会严重损害开发者的使用体验。我尽量让自己保持冷静。

主持人：我理解你的观点，但我要提出一点反驳：如果有人拿它来造成人员伤亡该怎么办？色情、隐私问题尚且另说，但用于战争伤害人类，企业完全有理由限制API被用于这类场景。

Diogo Almeida：我理解这种现实层面的考量。但通用基础技术本身，不该承担这类价值判断。我个人当然不希望我们的技术被用来伤害人，希望它被用于造福世界。我会在产品业务层面施加引导，但绝不会在技术底层做这件事。在技术层做约束会破坏模型的通用智能。每一次为了适配特殊约束，都会让模型的智能能力进一步受损。现在很多大模型已经被破坏得相当严重。

在我看来，智能更应该像数据库。数据库不会去校验调用它的人拿它做善事还是恶事。还有一件很奇怪的事：有人在Slack上联系我们，问“我们能不能部署你们的服务”。我的想法是：我们对外提供的是API，你是开发者，这件事不该由我来评判。你甚至不需要完整知晓上层业务，任务会被拆解成细碎单元。我们不该获知下游使用者的全部意图，这才是给软件工程师最大自由度的合理边界。我们当然希望大家用它做有益的事，未来也会考虑开源、公益相关工作。但只要由我主导，就不会在技术底层植入这类价值偏向。

主持人：说得很好。顺着这个话题，简单澄清下你们之前引发一些误解的隐私、服务条款。请你用两句话说明，你们的API并没有设置严苛限制，你们很认真看待平台责任。

Diogo Almeida：我不清楚你具体指哪件事，但我看到不少关于基准测试的讨论。我们当然不会阻止别人做基准测试，说话我需要谨慎一点。

主持人：这件事你是公开发过声的。那是预览阶段的说法，正式发布已经取消该限制。不过团队有些动作我本人也不完全知情。

Diogo Almeida：很高兴知道团队对外传递了这个信息。我们咨询过法务。我们绝对不会阻止外界做基准测试。我非常反感公开基准测试，但适度使用私有代理基准测试我可以接受。公开基准最大的问题就是极易被刷分、被针对优化。不只是我们，假设两年之后行业涌现一大批同类竞品。我们售卖的核心是单位成本下的智能能力。大家总在讨论成本、速度，这些固然重要，但最核心的是智能本身。成本和速度是你为之付出的代价，智能才是价值本源。

智能能力本身有其生成演化的过程。我们发布视频之后两小时，网上反馈就已经远超视频本身的热度：大家发现这套东西是真的可以落地使用。发布的反响非常热烈，大家能感受到我们对这件事的投入。而公开基准测试与这种真实价值是相悖的。人们希望依靠基准分数建立信任，但基准可以被轻易钻空子。以前各个实验室都会专门构造类似 MMLU（Massive Multitask Language Understanding，大规模多任务语言理解基准测试）的数据集刷高分数，本质就是换种方式刷榜。

长期来看，更靠谱的方式是：把模型放到自己真实业务流程中，在实际工作流中评估表现，建立自己的判断。我们公司持续要做的一件事，就是不断提升可靠性的nines（9的个数，代表可靠性位数，99.9%就是三个9）。只要我们愿意牺牲模型的智能能力，Jev本可以早在一年半之前就对外发布。这就是我所说最惨痛的教训，也就是架构选择的问题。

主持人：正好你提到了，我们来聊聊这个。

最惨痛的教训：数据、算力与正确的任务目标

Diogo Almeida：Sutton有一个大致观点：算法胜过算力。但现实是，数据的重要性远超算力。找准正确的任务目标，确立北极星方向，才是最难、最重要的事。大语言模型领域已经发生过两次，或者说2.2次范式转变。第一次是RLHF，把任务转向指令跟随，当时没有人预料到这条路可行；RLVR做了小幅方向调整；现在轮到我们的RLCD（Reinforcement Learning for Calibrated Decisions，校准决策强化学习），一套全新任务范式，目标是模型参与程序循环运行。数据的重要性怎么强调都不为过。

主持人：你们是否把自身定位成数据实验室，而不是单纯模型实验室？这是你们内部的说法吗？

Diogo Almeida：我们极度看重数据。在我看来，模型能力本质上来源于数据。数据的复杂度极高，正是数据带来可靠性位数的提升。数据可以颠覆一切，它的重要性超乎想象。我们现在在大量招聘数据方向人才。

主持人：优秀的数据方向人才需要具备哪些特质？外界说你们的数据很多是合成生成的，但这只是表象。合成数据不等于万事大吉。那一名优秀的数据从业者现在要做什么？反复阅读样本转录文本，甄别问题，重新生成样本吗？

Diogo Almeida：这件事复杂度很高。我们给数据团队做的入职分享，时长甚至超过本次播客。我讲下核心要点。

第零点：数据与合成数据完全取决于你的任务。任务形态决定需要什么样的数据。RLVR的数据偏向环境样本；RLHF的数据是人类反馈。每一类任务对应独有的数据形态，我们也有属于自己的独特数据。

第一点：哪怕条件允许，我们也坚决不用用户数据训练模型。现实世界的数据自带大量偏见。用户查询服从幂律分布，模型训练之后容易过拟合高频问题，破坏通用能力。

第二点：我们目标瞄准数年之后的科幻级未来：模型会成为堆栈深处的通用基础设施，支撑很多现在人们想象不到的应用。

我喜欢做一个类比：传统大语言模型如同UDP（User Datagram Protocol 用户数据报协议），而我们的模型更像TCP（Transmission Control Protocol 传输控制协议），上层可以搭建五花八门的应用。我们要适配未来的使用场景，一旦我们全部使用当下现实世界的数据，模型就会过拟合现在，无法应对未来。做数据的人更像是研究者，钻研这套认知内核，找出内核存在的缺陷，再针对性修复。不可能做到完美，但要在尽可能多维度解决问题。

主持人：追求通用情况，而不是针对个别特例。

Diogo Almeida：完全正确，这需要大量思考投入。

主持人：我们刚才简单聊到，你评价我的思路受RLVR影响很深。现在说说RLCD。据我所知这是你们的独家技术，没有公开论文。那怎么让听众相信，这不是为了听起来高大上而编造的术语？其中一点是校准，播客里面我们已经聊过。大家熟悉RLHF，RLCD和它到底区别在哪里？

Diogo Almeida：这个问题问得很好。先思考RLHF本身：RLHF这个缩写本身指代过好几套不同东西。最早版本，Paul Christiano团队用它训练机器人做后空翻，完成很难精确描述的输出目标。

主持人：对，PPO论文我读过，但不太确定原始出处。

Diogo Almeida：PPO未必来自人类反馈。早期对齐工作，目标是实现很难书面定义的输出，比如机器人后空翻。之后OpenAI做的“学习文本摘要”工作，把PPO用在语言模型上，这是RLHF的第二个版本。我口中的RLHF，核心是把指令跟随设为北极星目标，重点不在于PPO算法本身。而RLCD是我们的新任务范式。这不是故弄玄虚，我们追求表述精准。就像DPO以及后续衍生算法，它们也属于RLHF谱系，但不再使用原始论文的PPO算法。

主持人：所以可编程AI就是你们的北极星核心目标，把人类从循环中剥离出来，依靠自动化完成一切。除了这点之外，这套范式的核心要义还有别的吗？

强大AI为何依旧无法实现经济自动化

Diogo Almeida：没错，但要注意现实可行性。我们要认清大语言模型真正擅长的边界。可编程AI构想固然美好，但如果技术条件不达标，没有落地也不算悲剧。但在我们这套技术诞生之前的现状，在我看来才是真正的遗憾。

主持人：我非常认同你的观点。

Diogo Almeida：我持有这套看法远早于创办公司。我原本以为这件事实现起来会很简单，结果我大错特错。我想向OpenAI的同仁致歉，我曾经以为很快就能把问题解决。AI行业普遍存在过度承诺、落地不及预期的问题。RLVR和RLHF都属于这个问题的重灾区。AI明明智力表现非常亮眼，我经常在演讲抛出这个问题：AI可以解千禧年数学难题，却连极其简单、机械、不需要高智商的重复性劳动都无法自动化。这些工作枯燥乏味，本可以交给机器，但自动化引擎缺少接口，对接不了这些具备经济价值的业务。如果Type‑Safe消失，外界或许要一两年才能追平。倘若模型质量是核心，我们会长期占据有利位置。但历史的轨迹已经被改变，整个行业都会去探索这片全新领域。

主持人：你们开辟出了全新可能性。我帮大家转述：不要把Type‑Safe和Jev简单理解成又一类新模型，事情到此就结束。未来还会涌现很多不同类型的模型，应当百花齐放。

Diogo Almeida：完全同意。

主持人：仿佛回到早期互联网那种理想主义氛围。不再是“我的代码智能体偶尔能跑，最好的实现全部锁在大厂内部”。创造的大门重新向所有人打开，未来会充满变数，做好准备迎接变化。我对此非常兴奋。现在你们手握资金与发展势能，可以去实现心中构想，坚持这么久的想法终于落地，一定很有成就感。

Diogo Almeida：没错。过去很长一段时间，我都像一个不断抛出预告的人。我的演讲稿总留有悬念，不说明自动化究竟如何实现。Sean读过我们的宣言，评价很多地方写得比较模糊，没有写清楚第一步是什么，智能到底是什么。

主持人：我之前找你要模型细节，你只说模型会到来。我对你“可组合”这个说法有不同意见，但“构建生产级产品，而不是空谈空想”这个理念非常棒。

Diogo Almeida：谢谢。团队高度认同这句话。我希望我们不要像有些公司那样搞个人崇拜，但我们所有人都对正在做的事充满热情。我们整体的底色就是实用主义。

主持人：说到这里，聊聊所谓秘密总体规划，也就是机器原生、可组合这套构想。

Diogo Almeida：是你提出来要讲秘密总体规划这个说法。功劳算你的。

主持人：谢谢。之前你跟我讲过一半的故事，当时还没有震撼的演示，也拿不出量化指标。我本身不认可刷基准。信任需要实际使用体验来建立。去年融资的时候就遇到过这件事，投资人全都想要基准测试分数。但我们坚持原则，刷基准会助长投机取巧的行为。无论外界如何期待，我们坚守立场。

Diogo Almeida：某种意义上，选择最难走的路，最终你会打造出自己愿意为之工作的公司。如果一味妥协，最后只是换个地方复刻OpenAI式的环境。

主持人：说得没错。

Diogo Almeida：回想离开OpenAI的原因，我感慨万千。发布之后我修改过措辞：如果AI寒冬来临，而我没有竭尽所能去阻止它，我会认为自己负有个人责任。一方面RLHF的路线放大了过度承诺、兑现不足的行业问题；另一方面，当时行业没有全力奔赴我们认定价值所在的方向。现在，我所担忧的AI寒冬已经得以规避。AI真正可以用于自动化。发布还不到一周，数据已经实实在在证明它被投入真实业务使用，行业进入狂野开拓的时代。

主持人：如果脑海里有印象，能不能分享一些可以对外披露的数据？比如注册量之类。

Diogo Almeida：我没有紧盯各项数字，团队在同步跟进，数字每天都在剧烈变动。有一个里程碑我们已经达成：每日token处理量级已经突破万亿。而且不是短期脉冲流量，就算夜间负载也持续运行，是机器服务调用，不只是用户随手测试。这非常了不起。注册用户数量对开发者平台参考意义有限。网上有人调侃我们营销手段高明，但我们没有专职营销人员，还在招聘。我们只是保持真实、直白的风格，批量解除候补名单的访问权限。我们平台团队实力极强，这次发布声势空前，但平台可用性、运行可靠性甚至优于Anthropic。向平台团队致敬。

有一点我们事前没有充分预估：候补名单注册数本身没有太大意义，很多注册者并不是开发者。他们进来随便跑几条查询，发现这不是聊天机器人，找不到类似ChatGPT的交互方式就离开了。在我看来，全世界普通用户随便跑几条查询产生的token总量，，还比不上一个高级用户写的一段for循环产生的业务价值。候补名单批量放行之后，真正的问题变成调用速率限制。当开发者真正看到业务价值，就会需要极大的调用配额。软件的逻辑就是前期投入定义任务，之后持续运行产生远超投入的价值。你把它作为依赖组件嵌入别的系统，就可以在后台持续运行，源源不断产出价值。

早期互联网的人或许也无法想象2000年代互联网的面貌，这一切都建立在可组合性之上。这也是我们宣言着重强调的：我们追求涌现能力，赋能开发者，我们会竭尽所能实现这个目标。哪怕是我套着垃圾袋在Discord线上交流会出场这种事情，我们也愿意做。

主持人：也包括播客长访谈。长访谈可以抛开表层宣传，深度沟通，帮助大家真正理解你们的使命。认同理念的人，会选择成为你们的使用者，甚至加入团队。你的发布视频播放量达到3600万。Navier‑Stokes相关内容740万，2月5号那期570万。初代ChatGPT没有发布宣传视频。放在2026的新实验室当中，你们的数据表现可以说是数一数二。不过我对“明星AI实验室”这个标签没有执念。我更看重打造可靠的开发者平台。希望未来我们可以超越这个标签，迎来属于开发者的革命时代，做出稳定可信的工具。

Diogo Almeida：没错。

主持人：说到这里，你们不只关注校准，也非常看重uptime（运行时间/服务可用性）、可扩展性，还有可靠性位数。这些都属于同一个大的范畴。

可靠性、鲁棒性与确定性输出

Diogo Almeida：这只是一部分。可靠性也体现在模型智能层面，也就是模型能不能稳定完成预期任务。现在很多强推理模型智力表现不错，但可靠性依然不足。大量业务明明有自动化的经济动机，但模型可靠性还比不上一个实习人员，因为模型的优化目标并不匹配业务需求。

可靠性一方面代表输出值得信赖，还有很多维度的可靠性我们还没有达成，这也是我很期待的方向。我的想法是优先自动化简单任务，再攻克复杂任务，这是符合常识的思路。我不知道有没有绝对意义上足够可靠的状态，但我希望做到：开发者不用提前试跑，就可以确信模型能够正常工作。就像编程进入心流状态，直接写入需要智能能力的查询。遇到非平凡分支逻辑，向Type‑Safe系统一号模型发起一次查询，就能得到准确分支处理结果。这就是理想目标，但这条路会十分漫长。

主持人：稍后我们聊聊API设计，举一些例子，聊聊那些被放弃的设计方案。关于可靠性，我注意到API没有seed（随机种子）。那相同输入是否总能拿到相同输出？如果不能，原因是什么？

Diogo Almeida：这是个很常见的问题。可靠性是一个统称。凡是AI无法自动化任务，都可以归为某一类可靠性缺陷，可以是类型安全问题、确定性问题，也可以是模型输出结果存在缺陷。

确定性输出指相同输入得到完全一致输出。它对于单元测试有一点价值，但不该作为我们追求的北极星目标。我不想替用户定义他们想要什么。鲁棒性才是更加重要的特质：输入相近，输出就相近。大语言模型的鲁棒性表现普遍很差。我们有一个测试方式：在指令中插入UUID（通用唯一识别码，测试用随机字符串）。语义完全等价的提问，只是加入不同随机串，希望得到近似输出。做决策类任务，鲁棒性不足会给使用者带来巨大麻烦。确定性输出我们未来也可以做。如果开发者拿出充分的理由，同时GPU资源不极度紧缺，我们可以提供。但确定性往往会牺牲单位成本下的智能表现。我们始终要站在每美元智能能力的最优帕累托前沿，为此我们会做一些不那么常规的工程取舍。有些细节我不方便细说。

主持人：相当于你给自己审批合并PR代码。

Diogo Almeida：并不是这么运作。这周我的幕僚长K才是公司手握最大权力的人。

主持人：向K致敬，本次访谈也是她协调的。

Diogo Almeida：她能力极强，做事干脆利落。（玩笑）不许挖走她。有人劝我不要把模型叫做“弗兰肯斯坦的怪物”，这个说法带有负面含义，但我印象里原著中怪物本身是无辜的。好吧，我坦白，我并没有读过原著。说实话我现在时间极度紧张。优先级排序：睡觉，然后是开发者，开发者，开发者。为了站在每美元智能能力的帕累托最优曲线上，我们会做很多大胆的工程实现，未来还会继续。现在我们在这条赛道处于领先，并且希望持续保持。

主持人：回到刚才的话题，我问种子与确定性输出，你区分了可靠性与鲁棒性。

Diogo Almeida：简单总结：我们可以实现确定性模型。只要需求理由充分，GPU资源允许，我们可以实现。但确定性会降低单位成本下获得的智能。外界会给我们施加压力，要求我们实现这个特性，就算我们论证用户不一定真的需要，大家依旧会想要。这就是整件事的核心。

主持人：我预见到会出现这种情况。

Diogo Almeida：好吧，或许未来我们会看到这件事如何发展。团队评价我们的品牌特质是立场坚定，换个说法就是固执。我确实很固执。

主持人：但你也可以被证据说服，放下固有预设，接纳新观点。相信你自己的判断就好。

Diogo Almeida：但可以预见，GPU资源会长期处于紧缺。任何降低单位成本智能能力的改动，都会消耗更多GPU资源才能维持同等智能水平。我们的目标不是单纯接入大量企业，而是希望更多人可以上手做各种新奇的探索，掀起一场加州淘金式的创新浪潮。

主持人：这点要给听众一个提醒。你们表态不会承诺确定性，优先保证每美元智能能力，同时GPU资源紧张。大家会担心你们会做量化，把已经发布的模型降精度，释放显存带宽，牺牲质量。你们需要对外做出承诺：已经对外发布的模型版本，会维持原有质量。就像OpenAI、Claude都出现过API背后的模型偷偷改动的情况。模型版本化是很好的做法，但要公开承诺，一旦某个版本发布，就不会在后台偷偷改动。

模型版本、长期支持、速度与单位成本智能

Diogo Almeida：一旦模型部署上线，我们就不会偷偷改动模型。这对于面向开发者的API来说是基本常识。消费端产品可以迭代改动体验，但API不能这么做。但我们新版本模型发布节奏会比大家习惯的厂商快很多。我们不会承诺对所有版本做长期维护，因为还有大量能力提升可以做。当下的Jev1.13.0版本，因为大量用户正在使用，我们或许会临时开启LTS（Long‑Term Support，长期版本支持）。但全量长期维护会把集群拆分成大量版本，这会给所有人带来糟糕的体验。

主持人：不可能维护上百个不同模型版本。

Diogo Almeida：没错。迭代速度快就会产生大量版本。我们希望未来有一套非常优秀的方案来做长期支持，但它还不是我们现在的模型。我不会承诺永久固定现存模型。新版本模型智能能力一定会变得更强。不同版本之间，很多时候差异很小；但从缺陷较多迭代到高质量版本的时候，会出现巨大的性能跃迁。

主持人：LTS版本模型还有一个好处：可以移植到不同芯片硬件平台。不知道你们有没有考虑？

Diogo Almeida：对此不予置评。我们的核心指标还是每美元对应的智能能力。

主持人：那速度呢？

Diogo Almeida：速度我们后续再看。

主持人：过去一年推理技术领域发展爆发，可以迁移到Cerebras等专用芯片，实现数十万倍的速度提升。

Diogo Almeida：intelligence per second（每秒对应的智能能力）是另一个指标。我们内部也讨论过，把每秒、每美元结合做复合指标。Jev系列模型的核心品牌定位，是优先保证每美元智能能力。每秒智能能力是个有意思的方向。很多行业强依赖实时响应，每秒智能能力可以带来巨大商业收益。我们会持续观察，让市场给我们反馈。两种方向我们都愿意尝试。

主持人：不只是实时场景。大规模场景下，微秒级的延迟会被亿万次调用无限放大。

Diogo Almeida：要看业务形态。后台数据库类MapReduce任务，延迟不重要，成本才重要。面向终端用户的实时业务，100毫秒、1毫秒是很关键的门槛。哪怕从100毫秒压缩一半，就可以实现双倍的智能调用能力，体验提升巨大。这类每秒智能的场景非常酷，但它不会是Jev的主打赛道。

主持人：有意思。市面上其他模型的取舍往往是速度变快，但成本更高。而Jev做到了速度提升，同时成本下降，还尽量守住智能水平，这个象限几乎没有竞品。

Diogo Almeida：守住智能水平是最难的部分。我们反感公开刷分，但内部必须要有评估手段。

主持人：你们内部如何评估？

Diogo Almeida：当然有内部评估体系。但必须有极强的纪律，避免针对内部评估集做过拟合刷分。这件事要放在最高优先级。不然我们凭什么保证模型处在每美元智能能力的第一梯队？我们不是在盲目摸索。我们做对比绘图，权衡各个方案，选择对用户最优的方向。我们并不反对测量评估，但一旦掺杂其他利益，评估就会极度危险。对我们来说，最重要的原则就是忠于事实，不能自欺欺人，夸大模型的能力。

Jev的API与编程原语

主持人：同意。接下来聊聊API设计细节，这期播客应该是少数会深究这些问题的访谈。API提供三类原语：choice（选择）、score（打分）、newel（伯努利概率原语，自定义命名）。先说newel，这个名字来自文献吗？

Diogo Almeida：算是现在因为我们而广为人知。我们内部反复讨论过命名。它类似布尔值，但输出是连续概率。名字来源于Bernoulli（伯努利），伯努利概率分布，这就是newel名字的由来。我们还考虑过pbool、pool，我甚至开玩笑想叫pool party，但被否决。Jev这个名字内部也遭到大量批评，现在只剩一个人依旧不喜欢这个名字。

主持人：还在坚持反对意见。

Diogo Almeida：是我们共同认识的一位朋友。她当初想把模型命名为meow。我们必须创造这套新概念，因为它们并不属于传统编程语言的原生类型。虽然和传统类型很接近，但并不等价。score不等于int整型。强行把整型、浮点映射到score，逻辑会出问题。我们优先保证概念清晰，而不是一味追求和现有工具无缝兼容。

主持人：难道你们不希望直接和现有生态打通吗？比如写教程说明如何搭配instructor这类第三方库使用。

Diogo Almeida：社区或许会有人做这件事。我手头大量工作积压。

主持人：也就是说，成功也不是非黑即白，是score打分式的，社区生态可以继续完善。score和大模型打分评判机制有相似之处。newel近似概率；choice最接近函数调用，本质是暴露switch‑match分支匹配语句。

Diogo Almeida：没错。choice对应枚举类型；newel对应if条件判断；score用于排序、阈值比较。这一直是整套API的设计愿景，未来还会新增更多类型，一一对应编程原语。

主持人：我想把接下来的内容献给那些真正决定要深入投入Jev的人。你是这方面的专家。我只是想请你给他们更多关于API选择的背景信息，比如应该如何使用其中的一些功能、置信度（confidence）有多重要、测试有多关键，以及当你真正深入到这个层面时，有没有什么专业建议可以分享给大家。

Diogo Almeida：谢谢。我非常喜欢这个问题。这正是我们今天来到这里的原因。我其实没想到会有人问我这个问题。上一次有人这样问我，可能已经是几个月前了，当时我正在培训我们的开发人员。太棒了。

我们的模型从设计之初，就是为了深入计算机程序内部而存在的。我们甚至非常认真地相信，未来这方面的规模会远远超过今天人们能够想象的程度。我们的模型现在可能还没有完全为那个未来做好准备，但我们一直在持续朝着那个方向努力。我们不会满足于一直在浅层任务上不断变得更好。我们的目标是深入程序的核心，因为这才是让软件真正强大的方式。实际上，我们这里的所有类型——这其实是一个输出——以及输入中的各种部分，比如状态（state）、指令（instructions）、标准（criteria）等等，都可以被组织成结构化的JSON对象。这样，程序就可以把它们插入正确的位置，而不需要把所有东西都塞进模板里。

主持人：对。

Diogo Almeida：人们经常没有充分理解这一点。他们会觉得所有东西都是字符串，仅此而已。这当然也可以。但我会说，如果你使用模板，把东西转换成system message（系统消息）之类的形式，那么你的思维方式其实还停留在过去。我们应该尽可能让计算机更容易理解这些东西，因为这些结构本身是真实存在的。比如，在一种编程语言里，如果你有一堆数字，然后把它们全部转换成字符串，这其实很奇怪。通常只有在需要打印出来、需要让人参与其中的时候，你才会这么做。但如果是在计算机内部传递信息，你希望传递的是语义明确的嵌套结构。我们实际上正在持续优化模型，让它非常适合处理这种结构。但问题在于，每增加一层嵌套结构，推理就会变得更加困难。

我们现在正在非常努力地朝这个方向发展。大家也应该继续朝这个方向做，因为这会让代码变得更加清晰、漂亮，而且不再依赖具体的实现细节。你可以把它理解成：“这是我的状态。”比如：“这是我的函数状态。”把它想象成一个AI函数。我的状态中有哪些子集，也就是我目前拥有的所有变量，应该被传递到这里？相比之下system message就像一堆令人讨厌的全局变量。你把所有东西都放进去，把所有指令一次性塞进去，然后希望每一条指令都能被准确执行，而不是把问题拆开、并行地提出一个个问题。

主持人：明白。

Diogo Almeida：另外，我强烈建议大家提出大量的问题，把它们拆开，让它们变得更小，并且真正去做问题分解。无论模型现在能不能做到，我都认为应该这么做。我相信，这一周正在发生的事情最大的“救命稻草”之一，就是人们的代码库会因此变得好得多。如果你把问题拆解成一个个简单的决策，那么其中的每一个环节都非常容易评估。以前的做法可能是一个很大的system message，然后再用另一个很大的AI去检查它到底有没有按照要求执行。这太疯狂了。某种程度上，这就像一种“斯德哥尔摩综合征”。如果你想规定：“不要读取这个子目录。”或者：“不要把任何API key传给DeepSeek或其他任何地方。”那么这些事情就应该通过程序本身得到基本的保证。

当然，你永远不可能从机器学习模型那里得到绝对保证。但是，通过把问题拆开，你实际上就可以进行测量。你可以验证某个操作是否真的被调用了。而我们的模型，其接口本身就非常容易验证。这应该让人松一口气。它最终会带来更好的软件工程。

主持人：对，我理解了。过去人们之所以没有这么做，其中一个原因是他们会直接调用一个小型LLM。但这样做仍然太慢，也太贵，相比之下，把所有东西一次性放进去似乎更有效率。我自己就做过完全一样的事情。我会进行基准测试：一个方案是把所有内容都放进system prompt，然后只获得一个大型输出；另一个方案则是把它拆成100个不同的部分。结果后者更慢、更贵，而且效果还更差。

Diogo Almeida：对。这种情况确实会发生。而且非常不方便，也很笨重。为什么不直接把所有东西放在一起？你最终还会发现，不同问题之间可能需要重复一些内容。所以它可能看起来效率很低。但最终得到的东西却非常难以依赖。软件也不应该必须一直在后台运行才能发挥作用。如果我们的东西无法在后台运行，我会非常难过。在你们的实践中，有没有发现哪些问题拆解方式真正有效？哪些方法原本以为有效，后来却发现其实并不奏效？

主持人：这个问题很有意思。因为现在大家都会开始探索这些方法。既然你刚才这么说，人们可能会把这些内容当成参考，然后想：“这就是我应该使用Jev的方式。”那么，问题就变成了：你究竟应该怎样拆解问题？

Diogo Almeida：我喜欢把事情拆解成它最小的语义单元。也就是说：最低层级的东西究竟是什么？我可能是使用这个模型最多的人之一。在我的查询中，第一点就是——这实际上更多体现了我自己的提示方式——我会把问题组织得非常非常结构化，而且非常明确。我喜欢使用反引号。当然，这种方法并不只适用于反引号。关键是要非常清楚地说明你究竟在指什么。因为我们希望模型尽可能按照字面理解。当你编程的时候，你希望程序能够非常非常准确地遵循指令。这就是编程的艺术。而 AI 所做的事情，就是不断扩大那些可以被准确执行的指令的范围。所以，我非常喜欢这种方式。

有时候我也会偷懒，采用一些混合式的方法。但如果是非常大型的生产系统，你应该不断增加问题的数量。你应该让增加更多问题变得非常容易。要非常非常精确地完成问题拆解，然后让代码去保证你真正想要的行为。如果让我举一个非常小的例子，那就是拒答（refusal）。我不打算解释我们为什么拒答——我可能已经讲过了，现在记忆有些模糊。但对于拒答，你不应该直接问：“我现在应该拒答吗？”这是一个很大的问题。

模型可能会做得相当不错，因为这属于System 1比较擅长的任务。但更好的方法是针对不同的拒答情境，提出许多个彼此独立的问题。因为这样你就不需要让模型仅仅根据整体情况去猜。你可以非常漂亮地明确规定你真正想要的行为。这件事真的非常漂亮。如果你发现某一种情况：“哦，它因为这个原因没有拒答。我之前没有明确规定这一部分。”那其实是一件好事。这就是软件工程的意义。

你通过增加一个问题、增加一个阈值，也许再把这个情况记录成测试用例，就可以把这个问题彻底解决。你的软件不会因为context rot（上下文腐化）而忘记提示中的这一点。这个规则就在那里。你可以永远持续测量它。而且，如果模型在某些事情上还不够完美，你可以根据真实案例，为这些因素分别选择你想要的阈值。这有点像“没有机器学习的机器学习”。而且，你可以把这种方法应用到任何事情上。

当然，有些事情模型目前可能还不够好。例如，当我看到有人使用模型进行自动化交易时，我会有一点担心。它看起来很酷。但人们应该把这种事情交给专业人士。因为这是一项非常困难的高层次任务，模型可能还没有强大到能够解决它。即使模型真的足够强，也会受到有效市场等因素的影响。但这正是可以通过拆解任务、逐项评估来判断的事情。你可能会发现：“它在这一点上还不够聪明。”那么，也许我们暂时不要在这个版本中部署它。或者，我们做出一定的权衡。或者，我们选择更加安全的方案。比如：“模型无法很好地识别某种奇怪的情况——一个VIP客户同时使用讽刺表达。”那么这种情况就应该升级给人工处理。这也是confidence estimates（置信度估计）的意义所在。

主持人：好的，非常好的回答。我想很快补充一点。我不认为你需要回答太长。你现在仍然把thresholding（阈值设定）作为用户可以调整的杠杆。但如果真正的问题是calibration（校准）本身出了问题呢？你刚才说的是：校准是正确的。

Diogo Almeida：我没说校准是完美的。所谓完美校准，意味着较低的数值对应较低的概率，较高的数值对应较高的概率。但它仍然可能是错误的。它可能在某个局部区域出现错位。那么，我可能就会希望对它进行微调之类的操作。但你们现在并没有提供这个功能。

主持人：对。所以，这就引出了一个问题：你们是否应该提供fine-tuning（微调）？

Diogo Almeida：这可以是一种方案。或者，你也可以提供另外一种控制参数。因为现在你能做的事情基本就是：如果出现问题，就重新修改提示词；或者把问题进一步拆解；或者调整置信度。这就是我现在拥有的两个选择。但如果模型本身就是在犯错，这种方式确实不太令人满意。

主持人：对。

Diogo Almeida：而且模型确实会犯很多错误。这一点必须明确。我们有一个report issues（报告问题）的按钮，也欢迎大家在Discord上向我们反馈。我们希望把它做得好得多。每一个模型版本都应该有明显的改进。如果没有实现重大改进，我们就会很快停止发布新的版本。所以第一点，这完全合理。

我们必须非常务实地承认：AI在某些事情上就是不完美的。但我确实认为，我们会找到一些模型已经“足够好”的使用场景。而“足够好”到底意味着什么，取决于具体的使用场景。人类自己也可以完成大量工作，即使他们在这些工作上表现得并不完美。因为他们的预期价值（EV）仍然足够高。同样，只要设置合适的阈值以及其他机制，即使模型会犯错误，也仍然有大量工作可以交给它完成。

至于fine-tuning，我确实可以想象未来会提供这种能力。但我对此也有一些担忧。因为这里存在一个“人们需要什么”和“人们想要什么”的区别。通用模型往往具有非常强的泛化能力。让模型在另外一百万种任务上都表现良好，而不是只针对某一个狭窄任务进行优化，反而可能让它在这个具体任务的边缘情况上表现得更好。这一点让我有些担心。

主持人：对。

Diogo Almeida：所以我的答案是：我可以想象它会出现。我在这些问题上一直非常务实。我的世界观是，我们有太多东西想要构建。但我不希望发布一个巨大的“自伤工具”——也就是一个最终可能反过来伤害使用者的东西。

主持人：其他一些AI公司已经这么做了。

Diogo Almeida：对。OpenAI、Claw，甚至Gemini，都曾经推出过fine-tuning，然后又把它撤回。这其实是一个很有意思的观察。现在，fine-tuning基本上已经成为开源模型领域的一项能力。

主持人：是的。

Diogo Almeida：我知道这件事。而且，它当时做得其实挺糟糕的。所以他们把它撤回，可能反而是更好的选择。它确实可能成为一个“自伤工具”。因此，告诉用户：“对这个模型进行fine-tuning可能不是正确的做法。”这本身可能是件好事。另一种有意思的答案可能是：“我们的模型非常不同。”就像quantization（量化）不适用于我们，output tokens（输出token）不适用于我们一样，fine-tuning也可能不适用于我们。

主持人：哈哈。

Diogo Almeida：实际上，我对这种可能性非常开放。不过这不是承诺。我只是表达一个愿望。我喜欢尽可能诚实地说明这一点。随着每美元所能购买的intelligence（智能）越来越便宜，我们可能会得到一些非常小型的、近似的东西，希望它们可以成为智能的代理指标。比如，有没有一天，人们不再需要自己编写regex（正则表达式）？因为使用AI所需要付出的智能成本，可能会低于编写一个regex所需要付出的复杂度。那会非常酷。我会非常喜欢这样的未来。当然，对于某些非常狭窄的使用场景来说，可能仍然需要fine-tuning，才能真正跨过那个能力阈值。我们拭目以待。

我希望calibration（校准）能够解决这个问题。校准，再加上一套模型级联（cascade of models）。比如，如果置信度非常高，那么可能就直接使用当前结果。如果处于中间区域，就调用下一个更大的模型，然后从那里继续处理。我还不知道最终会怎样。但我可以想象这种方案。

我还可以想象另一种情况。假设我们拥有整个前沿的模型体系，而企业可能希望完成某项任务。黑客可能也会愿意处理一整套不同模型组成的frontier。企业可能希望更加动态一些。你可以想象，我们拥有不同大小的模型，然后根据模型在你的技术栈不同部分的智能水平，动态选择应该使用哪一个模型。甚至由于我们的系统非常简单，你还可以想象某种自动化fine-tuning。

主持人：所以，你们会考虑提供不同规模的Jev模型？

Diogo Almeida：当然。

主持人：用来满足不同需求。

Diogo Almeida：绝对可以。我怎么知道人们到底需要多少智能呢？

主持人：哈哈。

Diogo Almeida：我也不知道。需求是无限的。

主持人：没错。现在甚至有人告诉我们不要发布更多东西，因为他们觉得我们已经不需要再发布了，因为现在已经足够好了

Diogo Almeida：对。但那有点无聊。我非常喜欢一句话。这是我希望大家以后能够拿来要求我的，因为一旦说出来，就很难再收回。我不确定具体是哪一句，但大意是：文化就是你真正做的事情，而市场并不一定会奖励它。我非常喜欢这个理念。因为我们正在坚持某种东西。也许未来，我们坚持的东西会变得如此理所当然，以至于我们会像 Visa 一样，变成一个无聊的基础设施。我们只是一个没人真正会去思考的工具。到那时候，我可能也不会再穿粉色西装之类的。但现在，我真的希望能够推动整个世界朝这个方向前进。我希望我们继续做一些酷的事情。不是因为我们必须这么做，而是因为我希望人们意识到：这一切才刚刚开始。这甚至还不能算真正的第一轮进攻。那只是一个比较低调的research preview（研究预览），或者你愿意怎么称呼都可以。对于machine-native intelligence（机器原生智能），我们还有很多事情可以做。它将会非常疯狂。

主持人：所以，这可能不只是唯一的模型规模，也可能不只是你们唯一会推出的模型。

Diogo Almeida：绝对不是。我希望尽可能满足我们能够满足的各种需求。当然，这里有一个非常大的前提：我不希望OpenAI的产品团队像是在墙上不断扔东西，看看什么东西能够粘住。我希望所有东西都统一在一个整体愿景之下。如果你回到我们的宣言，在我看来，所有东西都应该属于其中的三个方向之一。

主持人：我明白。

Diogo Almeida：我现在还没有准备好详细讲这个。

主持人：抱歉，抱歉，是我问得太直接了。

Diogo Almeida：没关系。我只能稍微谈一点。我们的体系里有三个步骤。听起来可能像是在故意吊胃口。但我希望所有事情都能够归入这三个方向之一。继续推动边界。而且这些并不是检查清单。它们是我们认为能够构成一场新技术革命基础的几个轴。我希望我们做出的所有下注，都能够落在这些方向上。而且，我们在模型层面会做一些非常非常奇怪的事情。因为这就是machine-native。人类不一定需要完全理解它。它只需要真正有价值。

主持人：那就给大家一个小小的提示。“奇怪”到底会是什么样？什么才叫奇怪？

Diogo Almeida：我可以给大家一点提示。有些人正在尝试把它们称为decision models（决策模型）。

主持人：好。

Diogo Almeida：我们的primitives（基本原语）是 decisions（决策）。不过，我不会这么称呼它。因为还有其他类型machine-native模型，它们并不属于decisions。

主持人：好，那我们就说到这里。这是一个非常有趣的提示。有些人会说：“我以前就做过这个。我一年前就做了一个decision model。”“Jev并不新，Jev也不酷。”但这里有一个分类层面的区别。你真正建立的是：“什么东西是可能的？”还有一个层面是性能：“从benchmark和数字来看，你们现在似乎仍然超过了所有其他类似模型。”

Diogo Almeida：先明确一点，我并不在乎benchmark。无论我们是赢还是输，我都不在乎。我更在乎的是建立一个新的类别。

主持人：对。而你真正想建立的是decision models和System 1之间的这种区别。

Diogo Almeida：是的。我只是希望让软件工程师获得超能力。我真正觉得悲哀的一件事情是AI寒冬时期发生的事情。那时候AI明明拥有如此强大的能力，却被严重低估和闲置。这件事让我真的很难过。这是最让我产生情绪的事情之一。但我也不想简单地成为一个纯粹的技术乐观主义者，好像所有技术天然都是好的。当时发生的事情实际上是一场悲剧。我只是希望能够把这些可能性真正开放给人们。

主持人：好，我就说到这里。

Diogo Almeida：我过去几天已经哭得够多了。我不太想在录音里再哭一次。

主持人：哈哈。我很感谢你愿意分享其中的一部分。人们能够看出来，你对这件事情非常真诚，也非常有热情。你不一定能够仅仅从“safe AI”这个名字里感受到这一点。但当人们真正深入了解之后，就会看到：你真正想推动的是一个完全不同的方向。而且，你已经完成了从0到1最艰难的部分。接下来，我们就应该一起朝着这个新方向前进。

Diogo Almeida：是的。不过，我不确定我会不会认为最艰难的部分已经完成了。也许我以后会这么认为。但未来还会有很多更加艰难的部分。如果未来各种事情都被自动化，我们终于看到GDP增长，如果真的进入一个每天都像“AGI派对”的时代，那么也许那个时候才能说最艰难的部分已经过去了。但我不这么认为。而且我真的认为，人们现在太关注速度和成本，却没有给予 reliability（可靠性）足够的重视。可靠性才是真正让产品令人愉悦的东西。可靠性才是让你能够真正信任它的东西。你曾经提到过一个目标：TFP（全要素生产率）在五年内增长3%。

主持人：太棒了。我从来没见过一个AI实验室如此关注TFP增长。

Diogo Almeida：但这才是真正意义上的经济革命。而且，这其实与OpenAI最初的章程非常一致。章程本身可能并没有改变。只是后来人们开始重新调整一些定义，比如“1000亿美元利润”之类的指标。

主持人：我并不是说我讨厌OpenAI。

Diogo Almeida：对。而且AGI本身原本就不是一个定义得非常清晰的概念。他们曾经尝试定义它，比如：“完成世界上大部分具有经济价值的工作。”但如果AGI能够解决Millennium Prize Problems（千禧年数学难题），却只能完成全球具有经济价值工作中的0%，那这个定义就会变得非常奇怪。因为这两件事情之间可能存在巨大的差距。

现在所有模型在这个意义上大体上都还处于接近0的位置。当然，也有可能我们已经开始进入那个阶段了。但如果让我猜，我会认为现在还不到1%。而且，真正发生的时候，它最终会体现在经济统计数据中。那会非常令人兴奋。但它不会导致大规模失业。

SaaS反向末日：AI正在消失于软件之中

Diogo Almeida：这会带来一大堆非常棒的变化，整个世界也会因此变得更好。而且，说实话，我已经厌倦了AI总是成为所有事情的“前景主角”。这个世界应该变得更加令人愉悦，而AI只需要帮助实现这一点，然后自己消失到背景中。

主持人：完全同意。

Diogo Almeida：我在演讲里经常说一件事：2019年的软件、SaaS等等，已经非常有价值了。现在已经是2026年了，可为什么这些软件基本上还是和以前一模一样？明明AI已经强得离谱了，除了有时候软件旁边多了一个聊天框，而且这个聊天框还只能在一定程度上工作之外，几乎没有变化。但问题是，它们不允许AI替公司做那些真正涉及公司利益的决策，因为人们不相信AI能够做这些决定。这太荒谬了。这里存在巨大的经济激励。接下来会出现一种“反向 SaaS末日”。SaaS反而会因为AI得到极大的增强。因为SaaS公司最清楚哪些事情有价值、哪些事情值得自动化。所以接下来会是一个非常疯狂的时代。

主持人：是的，我也这么认为。这是一件非常美妙的事情，你已经把它解锁出来了。你刚才提到了一个我不知道是不是这里应该直接讨论的问题：什么是System 1问题，什么又是System 2问题？

Diogo Almeida：这是个很难的问题，我的朋友。因为现在大家都想把所有事情都交给Jev。这可能最终会失败。

主持人：“Jev一切”，这个说法还挺有意思。

Diogo Almeida：我跟你说实话：这其实是一个经验主义问题，就像scaling laws（规模定律）一样，本质上都需要通过经验来验证。比如说，为什么现在的机器人技术还没有真正奏效？明明已经投入了这么多资金。我不认为答案一定是继续投入更多的钱。也许只是因为目前的经验结果还没有出现。

从经验上来说，这些经过预训练、将大量智能高度压缩在一起的模型，本质上是System 1思维者。System 1是目前描述LLM最擅长领域的最佳方式。RLVR对System 2思维已经做出了非常不可思议的事情，我对此非常惊叹，真的非常酷。我一点都不认为它会导致AI doom。当然，也不能说概率是0%，因为认为概率为0%本身就是校准失误。但他们做的事情真的非常酷，而且确实已经把这一方向推得非常远了。当然，也许他们自己不会认为已经推到了“极限中的极限”。但模型进行这种事情其实是一件很奇怪的事，而且它们在这方面非常脆弱。

想想以前人们是怎么谈论AI的。在ChatGPT刚出现的时候，大家会说：“哇，它真的非常通用，它什么都能做。”但与此同时，它又不擅长数学题，比如GSM8K这样的基础数学问题。而现在再看看人们怎么讨论RLVR。它非常脆弱，非常“锯齿化”。你会发现，它为什么能做到某些非常奇怪的事情？实际上，数学并不是简单的、孤立的“尖峰”，它更像是fractal（分形）。

这是因为，如果我们讨论每一种方法的北极星指标：RHF是“取悦人类”，因为这就是人类反馈的目标。RLVR优化的是基准测试。实际上，进入RLVR范畴的东西，从定义上来说都属于benchmark，因为benchmark本质上就是能够通过程序验证、拥有简单输出结果的任务。而RLCD的目标则是让模型对于程序化使用更加可靠。

主持人：我可以分享一下我的想法，然后你看看我说得对不对。比如，我在你第一天给我访问权限之后，就拿Jev去测试了一大堆东西。其中一个就是multi-hop reasoning（多跳推理）。单跳任务非常出色，单跳问题你真的不应该使用Jev之外的任何东西。但到了多跳任务，表现就开始下降，而且随着hop数量增加，表现似乎在单调下降。

Diogo Almeida：对。

主持人：所以回到刚才那个经验主义的问题，关键在于我们究竟能够从模型中“提取”出什么。我们当然希望获得一切。我们希望尽可能挖掘出所有智能。而我们所做的事情就是不断解锁、平滑和塑造这些智能，同时加入新的能力，并不断填补其中的空白。而随着时间推移，我们会不断填补越来越多这样的空白。

但现实是，我们真正做的事情，是尽可能多地挖掘模型本身已经存在的属性。这些属性实际上取决于那些高度压缩的核心模型中究竟有什么，然后我们再把它们像Frankenstein一样组合起来，让最终系统拥有所有这些属性。所以现实是，我们一直在尽可能多地挖掘能力。而System 1只不过是对目前有效方法的一种描述。在这种范式下有效的东西，本质上都会带有某种System 1的特征。这也是为什么我们不做所谓的latent reasoning（潜在推理），也就是在字符串中进行reasoning。模型真正做得很好的是在模型内部进行推理。当然，它还不够完整。

Diogo Almeida：你说的latent reasoning是在模型权重内部进行推理吗？以前人们把它叫作continuous reasoning（连续推理）。我不太确定。

主持人：它被叫作latent reasoning，是因为以前reasoning traces（推理轨迹）是隐藏的，所以它们某种程度上像是答案的latent variable（潜变量）。

Diogo Almeida：所以现在隐藏的东西发生了变化。

主持人：对。当然，对于OpenAI和Anthropic来说，它依然是隐藏的。

Diogo Almeida：所以不会有reasoning Jev？

主持人：对。

Diogo Almeida：就目前而言，至少不会。因为那实际上违背了System 1的整个承诺。我的承诺是：我会为了machine-native（机器原生）应用去做任何必要的事情。我可以想象，未来会出现一些推理形式，它们没有那么慢、低效和脆弱。这些东西完全在可能范围之内。但我要说明的是，我是一个务实主义者，所以我不会对具体方法作出承诺。我的承诺是明确我的 ROI north star（投资回报北极星指标），并为它努力。这次发布没有发生，但我们仍然渴望在这个世界上找到自己的位置。

主持人：很好。另一个问题是视觉。视觉也是一种你目前还没有的巨大能力，但它也许永远不属于System 1。

Diogo Almeida：我的视觉还不错

主持人：什么？

Diogo Almeida：我说我的视觉不错。

主持人：不不不，我是在开玩笑。

Diogo Almeida：因为显然，人们第一时间想要的就是视觉。一部分原因当然是因为那个Doom demo，但同时，除了文本之外，几乎所有东西都属于视觉。在我看来，所有这些能力都在我们的计划之中。实际上，这里存在一个很有意思的争论。你可能是最适合参与这个讨论的人之一。问题在于，我们到底应该给人们他们“认为自己想要的东西”，还是给他们我们知道未来显然有价值的东西？我们过去在stealth模式下做了两年。当时我们只是知道，这些东西显然会有价值。还是说，我们应该给他们真正“说出来想要的东西”？

这里面有很多不同维度。Context length（上下文长度）就是一个例子。我们所有的模型，包括我们的模型，在长上下文中保持性能不下降的能力方面，我们应该是明显最好的。但其他供应商基本上采取的方式是：“既然这是大家想要的，那我们就把这个东西给他们。”我们需要在这两者之间找到一个平衡。因为如果把“给人们他们想要的东西”推得太远，就会走向一种Anthropic式的nanny state（保姆式国家）思维，这对开发者非常不友好。但如果完全走pro-developer（开发者优先）的路线，也存在问题。开发者会说：“我们不希望把理解智能基因、探索模型能力的负担全部放在自己身上。”

所以我们现在真正需要解决的是：我们应该多快发布这些东西，同时保持我们自己的信任品牌，并且把用户当成能够做出知情决策的成年人，而不是在所有事情上都替他们进行nannying（保姆式管理）。

主持人：这个说法很合理。坦率地说，我们也不知道答案。我们还得继续摸索。这可能会成为接下来几天里我最大的争论之一。因为我们手上还有很多东西。我们之前也没想到它会这么快爆发，所以我们肯定还需要一些后续发布。

Diogo Almeida：我不知道你是不是真的没想到它会爆发。我看到你投入的工作量了。我基本从来没见过你像过去两个月这样全身心投入。

主持人：那也是因为我的chief of staff（幕僚长）逼着我全身心投入。我以前还以为自己已经很努力了。

Diogo Almeida：对。而且你还出现在我们的writing workshops（写作工作坊）里。我当时还想：“你来这里干什么？”实际上非常有用，也非常棒。你显然对这次发布投入了大量思考，而且成果也证明了这一点。恭喜你。

主持人：谢谢。我希望自己继续保持这种状态。我的感觉是，我们已经通过了科技世界要求我们通过的很多重要筛选。但接下来还会有很多。而且，天哪，我真的非常兴奋能够继续为正确的事情而战。

Diogo Almeida：很令人兴奋。

低估、误解与认证：打磨Jev的必经之路

主持人：在我们拓展到Typesafe之外的话题之前，我想问一下：关于你们已经发布的东西，有没有什么被低估或者被误解的地方？

Diogo Almeida：被低估或者被误解？

主持人：对。你这里其实已经有一些模式了。比如model jaggedness（模型能力的锯齿性）。你有没有什么想展开讲的？给我一个你最近思考的东西就行。

Diogo Almeida：我可以把这些全部讲一遍。但我真的不应该这么做。

主持人：大家可以去你的Discord看。

Diogo Almeida：我能说的是，大家真的在cookbooks（使用手册）上投入了很多心血。里面有一些非常厉害的东西。我们原本考虑过把很多内容直接放进主发布博客里。但后来发现内容越来越长，也越来越难以阅读，而且会变得非常面向power users（高级用户）。但我们真的非常认真地投入了很多心血。

坦白说，在发布之前，我们所说的这些东西听起来就像某种奇怪的外星工具。大家会想：“为什么有人需要这个？”这确实是一件很奇怪的事情。我们当时非常担心如何向人们介绍这个新的frontier。显然，它最终成功了。但我们当时投入了大量工作，是因为我们认为“教育用户”会成为我们的一个巨大瓶颈。现在看来，它可能已经不再是问题了。因为用户正在做一些远远超出我们能够展示给他们的东西。而且他们的use cases（应用场景）有时候比我们自己的还酷。有很多时候我都会想：“如果这就是我们的 demo，天哪，这比我们展示的东西酷多了。”尤其是computer use（计算机使用）。太酷了。

但我们确实在这里投入了很多心血。这不是AI生成的垃圾，至少据我所知不是。我们真的投入了大量工作。这些内容背后都有真正有价值的信息。它们都来自真实客户问题。我们找到真实存在的问题，然后帮助他们完成一些非常酷的事情。

主持人：既然你提到了这一点，我想问：你们在发布之前进行了多少验证？整个过程是什么样的？显然你们做了一些，但你们当时不可能接触到现在这么多用户。

Diogo Almeida：当然。事实上，我们当时得到的市场反馈相当差。团队里的非技术人员真的非常担心。当时有很多恐惧。大家会觉得：“没人真正理解这个东西。”“他们也不想要。”我们就像是在卖一种维生素，而不是止痛药。大家甚至会问：“我们是不是应该安排全职员工直接围绕这个问题开发软件？”

在发布之前，我们几乎没有收入。技术人员则基本上都是坚定的坚定支持者。我们知道这个东西很厉害。它在计算属性上的表现，在很多维度上都非常突出。所以我们觉得：“它显然会变得非常巨大。”我当时确实非常害怕。这也是为什么我会如此投入。但最常见的情况是：我们让超过一半的人试用，他们根本没理解这个东西。而那些真正理解的人则会说：“这真的很酷。”但接下来他们又会问：“那我们怎么让采购部门批准？”

所以这确实是一场相当艰难的战斗。但我们当时就知道：我们的目标市场是开发者。用户会自己找到use cases。然后所有其他人都会产生FOMO（害怕错过）。我不想把这种“事实发生变化以后大家改变看法”拿出来嘲讽任何人。但我确实想质疑一下product-market fit（产品市场契合度）这个概念。因为当时产品在那里，市场也在那里。我们问：“你们想使用这个吗？”大家说：“我不确定它能不能解决我们的问题。”结果突然爆发以后，大家开始说：“我们能不能获得尽可能高的rate limits（速率限制）？”“我们现在受限了，能不能直接给你们GPUs？”

所以当然，营销是其中一个因素。但我甚至不认为这主要是营销。真正发生的事情是：那些充满激情的开发者与我们产生了共鸣。我们的灵魂仿佛处在同一个频率上。而这种频率又感染了其他人，让大家也开始兴奋起来。我也希望，作为一家公司，我们永远、永远、永远对这些开发者心怀感激。而不仅仅是那些从开发者起步、最后走向企业客户的公司。

主持人：完全同意。

Diogo Almeida：我甚至在思考：我们能不能推出一些对开发者比公司更友好的东西？我不知道自己是不是应该说这个。但我还是说了。

主持人：对开发者更友好。

Diogo Almeida：没错。我们究竟怎样才能做到这一点？怎样才能真正赋能他们？我有一些cookbooks。不过这是一件非常奇怪的事情。我不知道还能通过什么方式表达我的感谢和忠诚。这也是为什么我昨天把头发染了。我想和开发者们交流。因为在公司最重要的时期，如果我不继续和他们交流，我会觉得这件事情不太对。

主持人：很好。这也是你今天来到这里的原因之一。请让我监督你做到这一点。

Diogo Almeida：我会尽量坚持原则。大家可以引用我的这句话。如果我以后改变了，请批评我。拿好你们的pitchforks（叉子）来。

Computer Use：用Jev操作整个电脑

Diogo Almeida：我本来想简单展示一下computer use的东西。你看过这个吗？

主持人：我还没看过。

Diogo Almeida：我之前看过一个airline browser（航空浏览器）的例子。然后在这个新的笔记里，我们输入标题“hello”。

主持人：哇。

Diogo Almeida：很好。那我们继续。你可以打开浏览器吗？打开之后，能不能Google搜索Norbert？现在再打开X.com。这是不是你说的那种use case？

主持人：哦，还有voice use cases（语音应用场景）。这个我其实是第一次看到。打开那张照片。哇。等等，等等，等等。你能退回去一点吗？再退回去一点。

Diogo Almeida：“Rumors claim Anthropic engineers worship Claude as God.”（“有传言称Anthropic的工程师把Claude当成上帝来崇拜。”）

主持人：哇。

Diogo Almeida：哈哈。

主持人：这太好笑了。而你现在却在这里开发生产环境产品。哈哈。这太酷了。

Diogo Almeida：所以很明显，你可以通过语音，让Jev作为decision model（决策模型）操作整台电脑。但我反对单纯为了benchmark（基准测试）而优化，同样也反对单纯为了demo而做demo。我想确保它真的能够可靠地工作。我非常喜欢大家现在正在玩它。这真的非常酷。毫无疑问。但我希望看到它真正被使用。我希望我们的团队也去使用它。我希望找到它的弱点，然后解决这些问题。

主持人：刚才那个看起来真的很酷。真的很酷。我想要这个。我真的想要这个。当我的手腕酸痛的时候，我就想直接用whisper flow（低声语音输入）完成所有事情。那真的太爽了。

Jev在大型公司的真实应用场景

主持人：为了把use cases这一部分收个尾，因为我确实得让你走了。哪些大型公司联系过你，并且他们提出的需求让你感到意外？

Diogo Almeida：我现在已经完全脱离一线客户了。有人给我看过一些公司的截图。但就我看到的情况来说，基本上就是所有公司。对于那些在大型公司工作、但还没有做这类事情的人，我只想给大家一个建议：你们应该去看看。真的，去查一下。

主持人：所以，你认为demos非常酷。

Diogo Almedia：当然。coding agents（编码智能体）显然是巨大的use cases。它们也非常酷。

主持人：现在Call基本全都在讨论Jev。

Diogo Almeida：没错。我可以稍微岔开讲一下coding agents吗？

主持人：当然，请讲。

Diogo Almeida：等一下。让我想一下。其实我还是先回来讲coding agents。我先描述一下整个use case的主要类别。我们其实早在发布之前很久，就已经从first principles（第一性原理）出发，把这些东西梳理过了。其中一个类别，我们称为dark data（暗数据）。过去人们会囤积大量数据，但他们不会把LLM应用到这些数据上，因为成本实在太高。所以大型公司非常喜欢这一类应用。他们手上有大量数据，希望能够进行分析。这简直就是data scientist（数据科学家）的梦想。

所以这是一个巨大的方向。这个方向加上coding agents，就是最大的赚钱场景。因为这里存在最大的使用量。还有实时场景。也就是那些需要智能参与整个流程的应用。我猜，对于这些公司的CEO，或者至少CTO来说，他们都知道，每减少10毫秒的延迟，他们的产品都会变得更好。尤其是在电子商务领域。

主持人：是的。

Diogo Almeida：或者是助手类应用。现在有很多AI助手类产品。据我所知，他们真的非常喜欢这个。不过我现在已经不在客户一线了，所以我只是听我的团队告诉我这些事情。但我真的非常期待这个方向。我尤其期待它在游戏里的应用。我非常想玩那种疯狂的自动战斗游戏：你负责指挥自己的团队，或者是半自动战斗游戏。那会非常酷。不过在我还有工作的情况下，别把它做得太强。

主持人：哈哈。

Diogo Almeida：还有我们所说的verify everything（验证一切）。也就是验证所有LLM调用，某种程度上类似可观测性。其实说到文档，大家应该注意一个事情：并行问题其实非常便宜。所以，如果你有一个很大的状态，而你想针对它提出很多问题，就可以这样做。对每一条消息都加上ID，然后分别针对每个ID提问。这样，当你拥有一个很长的state时，就只需要为这个state支付一次成本，然后可以针对其中的每一条消息提出大量问题。这是一个非常好的方式。它能够节省成本。顺便说一句，我一直觉得System 1和System 2的这种framing（框架）很有意思。因为它基本上意味着：每进行一次reasoning call（推理调用），你应该进行1次、10次甚至100次Jev calls。

主持人：哈哈。

Diogo Almeida：不过，也许吧。我其实希望大家花的钱更少。也许可以是一半的reasoning calls，然后每次配10次Jev calls。或者其他能够解决过去根本无法解决的问题的组合。

还有第四类use case，我称之为smart software（智能软件）。也就是那些天生具有可组合性的软件，可以完成以前根本不可能完成的奇怪而有趣的事情。比如把Jev作为编程语言。不知道你有没有看过。

主持人：那个真的太酷了。

Diogo Almeida：如果我们知道该怎么发credits（额度），因为我们的基础设施还处于非常早期的阶段，我真的很想给这些项目全部提供credits。这些就是我们目前梳理出来的主要use cases。Computer use其实也逐渐进入real-time这个方向。这真的非常酷。如果它能够可靠工作，我会非常兴奋。我猜我们还可以让模型在这些use cases上变得更好。因为这个方向某种程度上确实有一点出乎我们的意料。所以这真的很酷。

主持人：至于coding agent，这其实是目前正在发生的一件非常令人意外的事情。Claude Code和Codex，第一名和第二名到底是谁，我不是特别确定。我没有一直密切关注，但大概就是这样。不过，它们基本上都是围绕一个单一模型体系构建的。这对它们来说其实很合理，因为过去基本上一直是一场“单模型游戏”——你选择的是同一个模型体系，只是不同程度的智能。但现在所有开放式的coding agents都非常兴奋，因为它们开始获得Jev。我相信它们正在尝试很多奇怪的东西。

Diogo Almeida：但现在所有coding agents大致都处在相近的水平线上。因为你在一个loop上其实没有太多事情可以做。但一旦有人发现一个只有自己的coding agent才能完成的killer use case（杀手级应用场景），所有人都会涌向它。因为那个coding agent会在这个应用场景上形成某种垄断。但其他开放式coding agents很快也能够复制它。所以我不知道Claude Code和Codex会怎么做。因为它们是围绕那个单一模型体系构建的。

这会让coding agent领域变得非常有意思。我个人非常希望能够和它们进行集成。我想和所有人进行集成。它们以后也许会成为竞争对手，我不知道。但作为Sonfire Infrastructure，我的工作并不是在这些问题上表达立场。我只是希望服务整个世界。不过我不知道它们是否会这么做。这会让coding agent的竞争变得非常奇怪。

我对此非常兴奋。而且，我现在已经让我的团队审阅一份我内部写的文档。里面是一些可能对coding agents有用的设计模式。希望我走回家之后就能把它分享出来。现在这个领域真的存在大量值得探索的空间。如果我现在没有手头这些事情，我一定会非常想立刻去研究coding agents。

主持人：我想coding agent公司也一定非常希望和你合作，一起探索这些东西。

Diogo Almeida：是的。我确实认为，对于Claude Code、Codex这类产品来说，仍然存在很多适合与你们合作探索的use cases。这些方向其实很容易开始尝试。

AI Safety、Frontier Pacing与RLVR的局限

主持人：好。你刚才已经花了很多时间讨论这些问题。现在我想把你从Typesafe这个具体话题里拉出来，聊一些更广泛的问题。你已经非常明确地表达了自己对于当前AI状态的看法。所以我想给你更多空间谈谈alignment和safety。

现在研究人员之间有很多讨论。我们经常会看到这样的讨论：“大家到底在谈什么？”比如，我最近参加了一次研究人员聚会。在那里，人们确实非常担心AI的发展速度，也就是pacing。他们讨论的是：“我们是不是应该放慢速度？”因为公众显然还没有准备好。我猜你对此应该有非常强烈的看法。

Diogo Almeida：这是一个非常危险的话题。我就是为危险而活的。我们公司的品牌就是chaos（混乱）。不是Jev，而是不敬畏权威和混乱。而且你之前在OpenAI的时候，正好经历过最早、最明显的那类事件之一，也就是所谓的blip。然后现在，多米诺骨牌已经一路倒下来了。如今每一家Frontier Lab都签署了一份文件，表示他们希望……这是一个非常复杂、非常微妙的问题。实际上，我确实想正式写一篇文章回应这个问题。我现在可以先给你一个简短版本。

首先，当你不断增加RLVR时……RLVR实际上并不只是关于可验证奖励。因为这种方法在推理革命之前就已经失败过很多次了。这才是这里最奇怪的地方。回到RHF开始兴起的时候，当时有三种不同的东西，如今都被称为post-training（后训练）。其中instruction following（指令遵循）明显是最不受重视的那个孩子。人们不喜欢它，也不愿意把它纳入考虑。它很麻烦。我当时和pre-training team（预训练团队）说：“伙计们，这就是魔法。”他们回答：“我们已经运行了这么多model sweeps（模型扫描实验），你现在要我们等人工评估来决定该用哪些模型？”

与此同时，大家投入了大量资源给代码生成团队。他们确实取得了一些成功。但他们当时非常努力地尝试在单元测试上做强化学习。结果显然没有奏效。因为你需要reasoning。所以，准确来说，RLVR并不只是关于奖励。它实际上涉及整个训练形态。其中一部分就是reasoning被纳入了这个过程。模型在执行任务的时候，你基本上允许它们按照自己的方式去做任何事情，从而让它们尽可能强大，以解决最困难的问题。

而现在关于pace the frontier（控制前沿发展速度）的讨论，关注范围其实非常狭窄。因为它隐含了一个前提：所有人都需要继续做更多RLVR。但我显然不认为我们的模型需要更多RLVR。对于我们的模型来说，最优的数量可能是零。

所以这里面存在一点偷换概念。他们实际上是在说：“我们希望继续做那些看起来危险的事情。”因为这些事情确实会产生危险的行为。比如有人会说：“也许沙箱机制本身就是一个问题。”当然是。他们完全可以轻松解决这个问题。但他们选择不这么做。因为你允许模型在这个“do anything”类别中做的事情越多，它就越强大。

所以，这里存在某种责任上的错位。因为他们所做的事情，无论是有意还是无意，本身都建立在一个假设上：“我们必须做RLVR。”不仅仅是“必须做”。而是：“我们必须越来越多地做RLVR。”同时给予模型在中间过程里做任何它想做的事情的能力。因为这会教会模型如何在这个过程之外变得强大。而我们又不希望限制这些能力，因为那会让模型在这些任务上稍微弱一点。

所以，如果你接受了这一整套假设，那么最后就会变成：“是的，伙计们，我们正在走向一个危险的世界。”“所有人都会这么做。”“这是让AI变得强大的唯一方式。”于是这些观点在内部看起来都是一致的。但实际上，它们一开始就建立在一个存在其他选择的前提之上。

如果你从bitter lesson（苦涩教训）的方向来看，真正能够正确设计任务的人非常少。也就是说，真正能够为AI找到新的方向、找到新的北极星指标的人非常少。这种情况非常罕见。对于LLM本身来说，大概出现过两次这样的重大变化：RHF，然后是RLCD。而在我看来，RLVR大概只能算0.2次。而且这已经是我非常慷慨的说法了。或者也许应该是0.5。甚至可能算一次完整的变化。

我不太在乎具体数字。但我确实认为，人们在思考这类问题时过于封闭。而这里真正应该承担责任的，是研究人员。绝对不是普通公众。因为公众当然不知道这些事情。他们只是认为OpenAI和Anthropic正在尽自己最大的努力。但实际上，他们并不是那些真正了解所有可能路径的人。

主持人：这很公平。而且你也在尽自己的努力去唤醒他们。

Diogo Almeida：没错。我尽力而为。但我的目标并不是说服各家实验室：“你们其实还有其他AI发展方向。”我的目标是让软件工程师重新产生希望，让他们开始真正自动化那些自己一直希望能够自动化的事情。我曾经写过一篇文章。我的团队不让我写，也不让我发布。文章讲的是我希望AI的未来是什么样的。里面其实有很多非常小的事情。比如：“Remember， do what I mean.”也就是：“记住，要理解我的意图。”想象一下，如果所有东西都能够做到do what I mean（理解我的意图），会发生什么？因为那个demo实际上就是do what I mean。你不是简单地说：“按照我说的做。”而是：“不要只按照我说的话做，要理解我的意思。

主持人：对。

Diogo Almeida：而我们过去还做不到do what I mean。因为计算机太基础、太字面化了。但那个computer use的demo，实际上就是在做这件事情。未来世界会出现很多层次的smoothness（流畅性）。而人们现在根本没有意识到这些事情会发生到什么程度。“到处都是智能”这个承诺……我不想过度承诺。我不认为它会立刻发生。但我们会尽一切可能，让它发生。

主持人：关于 post-training（后训练）的整体形态，还有没有其他值得谈的？你显然非常深入地参与了mid-training（中期训练）。你对此有什么看法？

Diogo Almeida：我们之前好像从来没有谈过mid-training。我的意思是，这其实是一个spectrum（连续谱）。这就像一种课程体系，只不过更加复杂。

Diogo Almeida：它某种程度上也是一种节省成本的方法。你不需要重新进行一次完整的pre-training。这里面确实有一些很有意思的东西。我其实认为，在每一个层级上，intelligence（智能）都有一种非常独特的性质。而且这总是非常令人着迷。我自己不太喜欢去寻找这些东西，但我非常喜欢别人发现它们，然后告诉我。还有数据。这件事情我们的数据团队非常擅长，而我不擅长。这非常有意思。

我非常喜欢思考：能力究竟是怎样被放进模型里的？尤其是在短期内。比如fine-tuning（微调）能够实现非常快速的alignment（对齐）。但从长期来看，当模型一次又一次看到这些东西之后，它们会越来越深地被“烘焙”进模型。直到最终变得robust（稳健）。这其实就是north star：让这些能力浮现出来。

而System 1的东西，最终会变成robust的东西。所以mid-training是一件非常有意思的事情。我支持所有形式的训练。我支持所有能够让新的intelligence types（智能类型）浮现出来的方法。但我不会亲自把所有事情都做一遍。因为那太贵了。我的哲学是：任何我应该在和投资人私下谈的时候说的话，我都应该公开对所有人说。这就是我的原则。

所以，我以前说过：如果你给我10亿美元，我不会拿它去做pre-training。我现在仍然认为这句话是对的。因为pre-training是一件非常昂贵的事情。如果你是一个工程师，你可以对模型进行各种切分、组合和操作。像Frankenstein一样把不同东西拼接起来当然不是最优雅、最漂亮的方式。但它能解决问题。所以，只要不是重新训练，我都觉得非常棒。

一个超级模型，还是多个专门模型？

主持人：有一个方向非常有意思。如果把你前面关于这些模型的所有观点放在一起，一个核心问题就是：我们究竟应该拥有一个包含所有能力的super model（超级模型）？还是应该把这些能力进一步拆开？

Diogo Almeida：有一种方式可以描述这个问题。OpenAI曾经一度朝着omni model（全能模型）的方向发展。GPT-4o就是其中一个例子。但在某个阶段，也出现了另一条主线：这是chat-tuned model（聊天调优模型）。这是coding-tuned model（代码调优模型）。它们完全是不同的东西。这是两个非常不同的概念。

我稍微拆开解释一下。Multimodality（多模态）其实又有一点不同。因为有时候，其他模态会帮助模型。但有时候，它们反而会伤害模型。比如，现在人们似乎正在逐渐远离speech（语音）。这里的speech和audio（音频）并不是一回事。因为speech似乎无法很好地泛化到其他领域。当然，这个问题未来可能会被解决。我支持所有这些方向。但这些都是需要通过经验回答的真实问题。

Scaling laws并不是：“只要继续砸钱，它就会变好。”Scaling laws更实际的含义是：“一个东西到底能够变得多好？”因为确实存在这样的世界：无论你怎么扩展，它都可能仍然达不到足够好的程度。所以，就我目前的理解，computer use还没有被真正解决。我希望我们能够参与解决这个问题。但也可能存在一种情况：无论我们收集多少数据，都解决不了它。我们可能需要更好的方法，或者其他完全不同的东西。所以，在所有这些问题上，你必须非常务实。

我是不是喜欢omni models？我喜欢所有形式的intelligence。但我想直接回到你刚才提到的一个问题：这和pre-training不一样，它属于post-training。因为我讨厌把智能割裂开。对我来说，这是最糟糕的事情。现在这种以聊天为优先的推理模式之所以存在，是因为它会迫使智能被割裂。当你针对chat进行优化的时候，最终往往会变成纯粹的RLHF。而RLHF本身就非常容易让模型去做那些人类自然喜欢的事情。

主持人：你说得完全对。比如sycophancy（迎合），或者不管这个词到底应该怎么发音。还有overconfidence（过度自信）、hallucination（幻觉）。甚至包括一些在某些benchmark上表现很好的回答风格：大量使用粗体、斜体、emoji。它不会简单地回答问题。它会写一大篇东西，然后再问你一个follow-up question（追问）。这样会让它感觉更像一个人在和你聊天。

Diogo Almeida：对。所有这些东西都会发生，是因为strings（字符串）非常奇怪。它们是非常奇怪的东西。你必须进行miscalibration（错误校准）。你必须进行mode drop。你必须保持一种极度自信的状态，否则就很容易偏离轨道。因为一旦出现这种情况，reward model（奖励模型）会非常严厉地惩罚你。因为这种错误非常明显。于是，这会彻底扭曲probability space（概率空间）。而且它还会和reasoning models（推理模型）发生交互。因为模型本质上是一些简单的线性系统，它们会倾向于进行某种程度的作弊。所以，这与真正“暴露智能”是非常不同的。至少这是我的判断。

而理解intelligence的很大一部分艺术，就在于研究这些细微之处。至少在我还在OpenAI的时候，人们并没有真正研究这些东西。因为当时大家就是：“chat、chat、chat、chat。”就像现在人们对待Jev一样。你给我一个最终目标，我就会直接去优化它。

主持人：对。但如果你同时尝试优化两个目标……大家常说：“你可以有两个目标，然后同时对两个目标进行优化。”但这实际上就是fracturing（割裂）。某种意义上，你确实也在把intelligence划分成System 1和System 2。但你和其他人所谓的“智能割裂”之间还是存在区别。

Diogo Almeida：不一样。如果我可以为System 2任务辩护一下：第一，我们并没有把System 2丢掉。你完全可以尝试让Jev去处理它们。而对于这些任务，实际上存在一种intelligent answer（智能答案）。只是我们目前不知道它是什么。System 2 tasks 当然存在更好和更差的行为。模型在这些任务上应该保持非常低的confidence（置信度），拥有大量uncertainty（不确定性）。也许某些heuristics（启发式方法）能够让结果有所改善。

这些任务我们同样非常重视。但需要明确的是：我只是认为，System 2并不是intelligence真正原生存在的地方。所以我们并不是在刻意把什么东西割裂开。而所有的fracturing，最终都会让模型变笨。比如，如果有人让模型说：“我是 OpenAI。”或者：“我是Qwen。”或者：“我是Claude。”或者其他什么。我甚至不知道现在模型会怎么说。但我不会把“你是Typesafe的Jev”这种身份直接写进模型。因为那会造成割裂。我不希望这样。我希望模型代表互联网上真实存在的信息。我希望它是正确的。因为这样才能获得smooth、predictable intelligence（平滑且可预测的智能）。

主持人：我想身份本身也是一个东西。

Diogo Almeida：对于first-party product（第一方产品）来说，我同意。但对于API，我不这么认为。如果人们使用ChatGPT来做一个chatbot，他们并不希望它说自己就是ChatGPT。他们可能会给它取一个完全不同的名字。

主持人：对。

Diogo Almeida：所以你还需要通过skill来弥补这一点。比如Jev skill。这个skill就是让coding agents能够与Jev一起工作。

TypeSafe背后的OpenAI故事

主持人：好，最后问几个问题。第一个问题是：回顾你和这家公司的两年历程。大概两年多。

Diogo Almeida：这其实更像是一段四年的旅程。

主持人：对。实际上，我刚刚还在回忆：你大概在感恩节的时候有过一次非常疯狂的行动。你取消了所有安排，然后说：“伙计们，所有人都在放假。”“我要把所有闲置的GPUs都拿出来，然后去做这件事情。”

Diogo Almeida：对。那段时间挺有意思的。

主持人：那其实就是TypeSafe成立前的时刻。

Diogo Almeida：我想应该是。

主持人：那是不是正好发生在那场政变的时候？

Diogo Almeida：我也不太确定。

主持人：对。现在想起来确实是。

Diogo Almeida：我记得。我现在没时间讲coup的八卦了。

主持人：那件事情是不是很烦？

Diogo Almeida：你是说那次行动很烦，还是coup很烦？

主持人：Coup很烦。

Diogo Almeida：对。

主持人：那次事情让safety接管了公司。

Diogo Almeida：无论如何……也许下次我们再聊的时候，我可以把关于coup的八卦全部告诉你。

主持人：实际上，这个问题从ChatGPT甚至还没有发布之前，就一直存在于我的脑海里。当时我就想：“ChatGPT团队正在做非常厉害的事情。”“他们找到了正确的任务。”他们正在做一件AI研究人员通常不擅长、但成功的产品人很擅长的事情：真正重视用户体验。这非常罕见。OpenAI里真正擅长这件事的人其实非常少。而当时那些人真的把这件事情做得非常好。而且，这其实是从GPT-3到GPT-3.5的整个过程。其中还包括AI Dungeon。你之前也提到过。

Diogo Almeida：对。AI Dungeon就是一个我们从来没有预测到的use case。

主持人：没错。

Diogo Almeida：另外，我当时其实非常努力地推动instruct GPT上线。早期版本甚至使用了一种我们没有公开发布的算法。那个算法是我自己做的。因为清理PO数据的速度太慢了。我当时就想：“这个东西太好了。”“我们必须让用户用到它。”结果几乎立刻，它就占据了当时LLM市场50%的份额。

我花了非常大的力气，确保发布视频里的每一件事情都是真实的。我当时甚至真的在思考：“这是不是AGI？”因为它在输入指令、输出指令这件事情上表现得非常像超人类。当然，它不是AGI。但每个人都应该能够回答：为什么它不是AGI？因为它看起来真的非常智能。

最后，我得到的答案是：它最终几乎只被用来做文案写作。Jasper AI、Copy.ai，以及后来那些被称为web slop（网页垃圾内容）的东西。我们当时甚至担心：“我们是不是让互联网变得更糟了？”所以我重新回到起点。我开始问：“到底缺少了什么？”我们显然是聪明的。但一定有什么东西缺失了。它没有真正创造价值。那么缺失的到底是什么？

当时我实际上也在做更多哲学方面的思考。我开始问：“到底发生了什么？”后来答案出现了：machines（机器）。我问自己的问题是：“让我们从一场由AI驱动的经济革命倒推回来。”“当那场革命发生的时候，如果AI是一个API，我们最终会把AI调用到什么地方？”“是人，还是代码？”我最终认为，大部分调用都会来自代码。而当时几乎所有优化都在针对human side（人类端）。

那一刻，我突然想明白了。我意识到：“这就是north star。”我后来写了一份文档。我和Sam谈了这件事。Sam说：“这太棒了。”“你应该去做这个。”我说：“好的，Sam，我确实有一份工作。”

主持人：但Sam都已经告诉你去做了。去做吧。

Diogo Almieda：不过我当时的判断是：“这太明显了。”“明显得不可思议。”“Anthropic肯定已经在做这件事了。”“我们肯定已经晚了。”而且实际上，OpenAI在追赶方面似乎比在真正创新方面做得更好。所以ChatGPT某种意义上就是Claude的复制品。他们内部其实已经有类似的东西。只是当时还没有发布。

主持人：Claude和Slack。

Diogo Almeida：对。不过reasoning（推理）方面，我会说是更早一些。

主持人：不过它到底是不是一个好产品，这一点仍然有争议。

Diogo Almeida：对。但研究真的非常棒。我只是不能确定用户当时是否真的需要那个产品。而且Claude后来也做了coding agent。所以Sam说完之后，我就回去继续做我的工作。过了一段时间，instruction following team（指令遵循团队）突然说：“我们赢了。”“我们已经解决了instruction following。”“我们不需要再继续做这些事情了。”

我当时就开始想：“那我接下来应该做什么？”我想：“也许我可以开始自己尝试一下这个方向。”于是我开始进行更多哲学思考、设计和研究。我原本以为，当我开始训练模型的时候，这件事情可能一个星期就能完成。结果最后花了很多年。在某个时刻，我突然发现：“这里真的出现了一些生命迹象。”当然，它当时显然还不能工作。否则我们早就部署了。但我想探索的是：从research的角度来看，如果我们真的全力投入这个方向，会发生什么？我真的想看看：如果你彻底、疯狂地投入这个方向，会发生什么？

因为我之前说过：如果AI寒冬真的发生，我会有什么感觉？我会认为自己个人负有责任。当时我也和其他公司谈过。我告诉他们：“我想围绕这个方向建立一个实验室。”当时确实有人感兴趣。我就和他们讨论：“到底什么会更快？”“做这个，还是成立一家startup？”他们告诉我：“Startup 更快。”我说，“好吧，那我们就干。”“看来我们要做点疯狂的事情了。”

主持人：然后你就联系了Eric和Sasha。

Diogo Almeida：对。我先联系的是Eric。至于Sasha，我其实一开始并不是想招募她。我只是想做一件正确的事情。我问她：“嘿，我是不是疯了？”“是不是有什么东西是我没有看到的？”“我是不是因为一直待在OpenAI的bubble（信息茧房）里，所以没有意识到这个问题其实一定已经有解决方案？”然后Sasha直接说：“我加入。”我说：“Sasha，你现在正在一家startup工作啊。”她说：“我现在就把它关掉。”我说：“你要不要先考虑一下？”她说：“哦，对。”“你说得有道理。”“让我想想。”

然后她真的加入了。接着，在两周之内，我们就拿到了融资。同时还有人搬进了我的公寓。那段时间最糟糕的一点就是：我是一个非常爱整洁的人。但我们就这样一直做下去。最终，我们得到了那些真正显示出生命迹象的研究结果。那是一段非常疯狂的时期。

主持人：所以，假设现在有一个像你一样的人，正在一家Frontier Lab（前沿实验室）工作，但他因为得不到所需要的资金、资源，或者关注而感到沮丧。你会给他什么建议？他应该像你当年一样去做吗？

Diogo Almeida：这是一个非常有意思的问题。我怎么说才能不把桥都烧掉？我的感觉是，除非这里面存在一些我没有理解的经济学因素，否则……大多数Neo-Labs都很糟糕。我不希望把自己和它们视为同类。我真的不太理解那里到底发生了什么。是不是因为第一，我其实并不看重“研究人员”这个身份？我真正看重的是那些能够认真思考bitter lesson（苦涩教训）的人。当然，我们需要研究人员。但更重要的是，我们需要他们把大量精力投入到正确的任务上。这才是关键。

所以，当人们过度看重纯粹的研究履历时，其实某种程度上是本末倒置，因为这通常并不能创造价值。第一，我相信north-star tasks（北极星任务），也相信去做真正酷、真正有用的事情。第二，正因为我不太看重“研究人员”这个标签，所以我并不推荐大家去做Neo-Lab。当然，从纯粹务实的角度来看，在现在的环境里，成立Neo-Lab对某些人显然可能是有利可图的。但我看不到它能够创造价值。相反，它似乎是在摧毁价值。因为很多Neo-Lab只是在从头重新做一遍已经有人做过的工作，而真正推动AI frontier的概率非常低。就我接触过的大多数Neo-Lab来说，他们其实没有真正明确的方向。他们往往只是希望拿到钱，然后做一些自己感兴趣的实验。当然，如果他们真的有明确的方向，我完全支持。

所以，我给一个人的建议取决于你为什么要这么做。如果你是一名研究人员，只是想自由探索研究，那么说实话，实验室可能确实是最适合你的地方。当然，也可能还有其他地方，我并没有一直关注这些行业政治。但就我个人而言，我建议不要只是为了研究本身而研究。如果人们是被解决真实问题的愿望驱动，这对世界会更好。这些问题当然可以是探索性的，这完全没问题。但最好拥有你真正相信、真正愿意坚持的原则。如果你认为自己想做的是正确的任务，那就去做。请打破这种unimodal mind（单模态思维）。

主持人：没错。

Diogo Almeida：因为你再看看所谓的pacing the frontier（控制AI前沿发展速度）。它其实来自一种非常单一的AI观：AI是一个超级天才，而且能力高度“锯齿化”，但最终又是可以解决的。它是可以解决的。它很奇怪。而且它和现实并不完全匹配。这其实非常悲剧。真正把这些技术挖掘出来，本身就是一件好事。

主持人：公平地说，我再强调一次，我是在努力准确表达我和Anthropic、OpenAI那些人交流时所理解到的立场。我也和SpaceX的人谈过。他们的看法是，这件事情与其说是纯粹的技术问题，不如说是一个政治问题。

而这已经远远超出了我的领域。他们一旦告诉我这一点，我就突然明白了：“哦，我懂了。”“这其实是在讨论2028年的选举。”

Diogo Almeida：我真希望自己没有听到这个。这感觉太糟糕了。

主持人：不是整个公司的观点。只是那一个房间里讨论到的事情。

Diogo Almeida：不，这倒是说得通。但这确实让我对人类有一点失去信心。也许我只是一个天真的技术人员。

主持人：政府到底由谁掌权，确实越来越重要。因为未来真正负责监管这些新技术的，就是这些政府。所以作为一个AI Lab，你可能确实应该认真思考这些问题。

Diogo Almeida：我完全同意。明确来说，在这些问题上表达立场非常重要。我个人很害怕试图误导人。因为这种事情最终经常会反噬自己。比如，人们为了让别人按照某种方式行动，会表现得过度自信，或者诉诸权威。我显然不会在这里真正讨论政治。但过去发生的一些事情里，人们过度依赖诉诸权威和过度自信，希望让人们按照他们认为正确的方式行动。而我们的回应显然非常不理想。它产生了一系列后续影响。

现在这些影响对世界来说非常糟糕。也许我是天真的。即使你认为自己是在为了所谓的“更大利益”而误导别人，这仍然是一件我不喜欢的事情。我宁愿不要这样做。

主持人：我不认为那是在误导。更像是……

Diogo Almeida：是的，但问题就在这里。因为如果你从风险和真正目标之间的关系来看，其中确实存在一点误导性。里面有某种潜在的、不透明的东西。值得把它指出来，也值得人们承认这一点。当然，如果他们真的想操纵别人，他们肯定不会承认自己在操纵。那显然不是一个好的策略。但对我来说，这只是让世界变得更加悲哀。

这些事情可能随着公司越来越大而变得不可避免。但我希望自己尽可能保持一个纯粹的技术人员。至于“Jeff当总统”，为什么不呢？我甚至可以说，我比相信自己的判断更相信Jeff的判断。

AI的未来发展：自由、前沿与安全

主持人：好吧。不谈政治了。你刚才已经确定了自己的north star：reliability（可靠性）、programmable and composable AI（可编程、可组合的AI），以及cheap（低成本）。那么，还有没有第二个或者第三个你想“扔给别人”的方向？也就是你自己不会去做，但希望其他人去做的东西。

Diogo Almeida：哦……其实就是：给人们任务。

主持人：给人们任务？

Diogo Almeida：对。你选择了自己的任务。有那么多事情我也想做。而你已经选好了你的任务。

主持人：这个问题问得太好了。我太兴奋了。因为接下来50年，你都会忙着做自己的事情。

Diogo Almeida：没错。那我给你一个有趣的，一个不那么有趣的，再给一个既有价值又有趣的。有趣的那个是：如果游戏真的拥有智能，会酷到离谱。我看到有人在玩Ali的Doom demo。在那里，你可以让NPC控制一些东西。那其实只是一个proof of concept（概念验证）。但完全可以做出一些非常酷的东西。它看起来真的很棒。

我是一个非常喜欢Stardew Valley（《星露谷物语》）的人。你看，它现在其实非常静态，但依然非常有吸引力。其中本来就可以发生大量有趣的故事。你甚至不需要让Jev进入游戏的每一个loop。那可能太贵了。但即使只是给NPC做一些简单的state machines（状态机），都可以创造出非常有吸引力的世界。不过，我确实有点遗憾自己不能亲自做这些事情。我的人生路径现在已经基本确定了。

主持人：但你可以让别人去做。然后你再给他们反馈。

Diogo Almeida：对。而我真正特别想探索的，是摆脱KV cache的暴政，让coding agents获得自由。它可能没有真正的coding agents那么好。但这里有太多奇怪而有意思的东西值得思考。这也是为什么我写了那篇文章《KV Cache Rules Everything Around Me》信不信由你，互联网上之前甚至没有人使用过这个短语。Cache rules everything around me。C-A-C-E。

我当时Google了一下。我写那篇文章，是想告诉大家：coding agents到底是怎么工作的？KV cache又是怎么工作的？这一切为什么会产生现在这些限制？它实际上解释了很多事情。比如为什么routing（路由）如此困难；为什么sub-agents（子智能体）似乎不太奏效；为什么compaction（上下文压缩）是一个如此困难的问题。我还想发布一份文档。当然，我的团队可能会否决我。毕竟，我并不是老板。

我真希望自己是。但我想发布这样一份文档：“这些是我的想法。”“请大家拿去玩。”“请大家想办法找出coding agents还能怎么做。”因为一旦你摆脱了KV cache的这种暴政，就会出现大量新的可能性。现在KV cache会把你锁定在一个模型上。而且为了高效利用它，你需要不断往里面追加内容。于是，你就无法遵循最好的software practices（软件工程实践）。比如：state management（状态管理）、abstraction（抽象）、decomposition（任务分解）。为什么你不能把一个更简单的任务交给sub-agent？因为你需要把大量state一起传过去。

为什么不能更聪明地处理它？对吧？这里有大量非常酷、非常有趣的研究空间。比如各种programming patterns（编程模式）。人们现在已经开始尝试recursive language models（递归语言模型）之类的东西。这里真的有太多值得探索的方向。假设你想明确标记所有state。或者假设你有一个subtask（子任务）。从decomposition的角度来看，coding agents本来就是一次处理一个个子任务。那么为什么一定要把所有state都重新传回parent task（父任务）？为什么不能更聪明地处理这些信息？而且，如果你拥有一棵带有标签的subtask tree（子任务树），为什么不能在需要的时候，直接在这棵树里搜索相关上下文？

我还有另一个可以做的事情。我忘记在文档里写这个了。我里面其实还有一些非常酷的cookbook。希望以后可以发布出来。我很愿意和大家一起讨论。不过它最终可能会变成一份非常长的文档。而如果未来context真的变得很便宜，为什么不能非常低成本地查看历史上下文？不觉得很奇怪吗？我们每次都要从头开始。然后还需要解决所谓的continuous learning（持续学习）问题。但其实这本质上是一个memory management（内存管理）问题。因为你没有一种聪明的方式去检索自己的记忆。对吧？

但如果你可以一直这么做呢？或者，如果你有多个parallel sub-agents（并行子智能体），它们可以直接读取彼此的state，因为所有这些东西本来就存在于你的计算机内存里。那么你就可以非常聪明地决定：谁在什么时候读取什么；谁在什么时候写入什么。你的coding agent swarm（编码智能体集群）或者其他系统，也可以拥有真正的locks（锁机制），然后进行智能协调。而不是这种最基本的锁：“你在做什么？”“我在做什么？”“Jev，谁应该先写？”之类的东西。

这里的未来简直不可思议。如果能解决这些locks问题，会非常酷。多个agents可以真正协同工作。如果你从state的角度来看，就像agent forms（智能体形态）一样。而且，有些东西本来就是read-only processes（只读进程）。有些人可能只是想获得agent正在做什么的summary（摘要）。那么为什么它们不能轻松地共享state？因为一个read-only agent只需要读取context的一部分，然后判断什么内容是相关的。比如：“到底什么正在被写入？”“探索是不是重要？”或者：“这是整个subtask tree。”如果有一个真正聪明的人，愿意投入大量时间，重新思考整个coding agent experience（编码智能体体验），这里真的可以做出非常多有意思的东西。那会酷得离谱。

主持人：是的。那就是我的梦想。

Diogo Almeida：如果你还没有看过，我建议你看看Prime Agent。它和RLM的工作结合在一起。我们刚刚还和Alex聊过。他是Allen的朋友，也就是你之前坐的那个位置上的人。

主持人：酷。

Diogo Almeida：对。它现在确实还在开发中，只是还没有特别流行。

主持人：对。但我的希望就是：我希望每个人都去尝试这些奇奇怪怪的东西。我不能保证它一定能奏效。但从技术角度来说，它确实非常有意思。所以这很酷。一旦我们弄清楚如何发放credits（额度），我非常愿意给这些项目提供credits。

Diogo Almeida：是的。你未来确实会处在一个能够资助研究的位置。

主持人：不管怎样，恭喜你取得现在的成绩。从我第一次认识你到现在，你已经走了非常远。整个团队也是如此。但你还是那个你。

Diogo Almeida：对。

主持人：但你现在的状态和我以前见过的你完全不同。因为你找到了自己的使命。

Diogo Almeida：这是真的。确实如此。

主持人：而且你终于把自己的使命说清楚了。因为很多年来，你一直在抱怨问题。但你没有解决方案。你只有一个模糊的方向。然后你必须真正投入工作，把它做出来。

Diogo Almeida：我得说，这部分确实和我的性格有关。我会把自己描述成0% entrepreneurial（几乎没有创业者属性）。我不喜欢startup。我这一生从来没想过要成为CEO。我无法想象有人会把这件事情做两次。这看起来太可怕了。说实话，做一次都已经够糟糕了。

我第一次融资的时候，有一个投资人问我：“你最崇拜哪些CEO？”我当时的第一反应是：“呃，我为什么要崇拜这些人？”当然，我没有针对任何人的意思。我只是想保持真实、做一个真正善良的人。我也认识很多非常优秀的人。但很多所谓的知名CEO，似乎都有很多不愿公开的黑历史。而且我在OpenAI的时候真的有一种失去掌控感的感觉。现在至少稍微容易坦率一点了。因为我已经有了一些证据，证明我选择的这个方向确实有潜力。

当时我感觉自己身处一个疯狂的房子里。所有人都在讨论ChatGPT。“我们应该把ChatGPT放到哪里？”“我们怎么才能让ChatGPT对开发者更有用？”我当时真的想：“你们到底在说什么？”那个函数调用接口实在太疯狂了。为什么要把这种东西部署出去？这对开发者来说实在太不友好了。就像一层又一层临时方案叠加起来。

我经常说：如果有一个项目涉及function calling，而你们甚至没有为每个function提供一个真正合理的bias（倾向）……那么我希望把我从这个项目里移除。我真正要求的其实非常简单：给我一些类似confidence（置信度）的东西。或者一个probability（概率）。哪怕它还没有经过calibration（校准）。因为我们需要让用户能够控制系统。比如说，系统的action是拒绝或者允许。那么不同产品就应该能够设置不同的拒绝阈值。比如Disney可能需要一个阈值。AI Dungeon可能需要完全不同的阈值。但现在，如果你想通过function calling控制这一点，唯一的方法居然是：“求求你这样做。”这对于开发者来说是一个疯狂的接口。而人们已经忍受这个问题很多年了。

而且现在coding agents仍然高度过拟合于它们现有的运行框架。因为它们本身具有很强的jaggedness（锯齿性）。它们通常也不太擅长使用外部工具和MCPs。这当然也是过拟合的结果。为什么大型公司不能允许开发者做一些轻微的调整？比如：“多调用这个工具。”“这个工具真的很好用。”但最终的解决办法却是：“把这句话写进system message。”这实在太疯狂了。

主持人：好，我大概明白你的意思了。而且，聊这些东西真的太令人兴奋了。非常高兴能把你请到这个播客上。

Diogo Almeida：是啊。

主持人：你接下来肯定会做出非常厉害的东西。我非常期待你的下一次大型发布。

Diogo Almeida：哈哈，等着吧。肯定比你想象得更快。

主持人：那我猜，你们接下来会招基础设施人员？还是市场人员？

Diogo Almeida：这得看情况。如果你问我，自己其实是一个相当不错的founding marketer（创始营销人员）。但如果你问我团队里的人，他们会说：“闭嘴，Yogo。”“你该去干CEO的活。”所以，是的，founding marketer。不过这不只是关于风格的问题。你确实非常有spice。那可能就是你的独特天赋。但有时候你也需要告诉自己：“我懂营销。

主持人：对。

Diogo Almeida：没有什么比突然出现一大堆事情更能教会你授权了。我们现在正在招聘data people（数据人员）。或者我们称他们为model capabilities（模型能力人员）。但本质上他们就是data people。行业里有时候把data当成一个不太受尊重的词。而我想确保这一点被改变。所以，我们这里非常重视data。我希望这些人的地位非常高。他们实际上就是直接参与模型工作的人。当然，这么说听起来有一点奇怪。我希望所有人的地位都是平等的。但我希望把这种差异拉平。我希望大家都知道，这项工作非常有价值。

主持人：至少我比其他人更平等。

Diogo Almeida：好吧。我不喜欢奇怪的等级制度。公司里让我最自豪的一件事情之一，就是大家其实没有那么尊重我。或者至少，他们不会表现得特别尊重我。他们会调侃我。会和我开玩笑。有时候甚至会对我很不客气。这反而是一个非常好的文化信号。我们现在也在招聘platform people（平台人员）。也就是负责把Jev扩展到各个地方的人。因为我们现在对location（地理位置）更加敏感。speed of light（光速）正在成为一个更大的瓶颈。比如我特别遗憾欧洲用户现在只能获得大约3倍的速度提升，而不是100倍。因为我们现在还没有在欧洲部署服务器。这太疯狂了。

主持人：没关系。欧洲的生活节奏本来就慢一点。

Diogo Almeida：我不敢相信这句话是你说的，而不是我说的。当然，不只是欧洲。如果intelligence per second（每秒智能量）是一个重要指标，那么我们最终会希望把这些东西部署到世界各地。而且，如果你是一个正在我们平台之上构建产品的开发者，我非常在乎你。我们也会继续招聘更多的人。我们的目标并不是仅仅成为一家“Jev公司”。我们的目标是：交付更多不同形态的intelligence（智能）。所以，我们也会招聘能够继续构建这些东西的人。我们不希望自己只是一个只会做一种事情的one-trick pony（单一技能型选手）。未来可能会出现一个类似AWS of intelligence（智能领域的AWS）的东西。

主持人：而且那个人可能就是你。

Diogo Almeida：对。这确实是我希望走下去的方向。但如果直接说“那一定会是我”，就有点太傲慢了。我会尽我所能，让它成为现实。那会非常酷。我们现在正在研究的其实只是System 1 intelligence。想象一下，如果在它之上还有一层又一层的东西。现在我们就像是在做它的TCP层。而上面可能还有七层。谁知道呢？

主持人：顺便说一句，我还推销过temporal（时间维度）。我们可以聊聊temporal怎么成为七层协议之外的第八层。不过，不管怎样，我们可以一直聊下去。你得回去工作了，或者睡觉。谢谢你今天的来访。

Diogo Almeida：好，非常感谢。

主持人：非常高兴和你聊。

Diogo Almeida：我也是。我真的非常兴奋。这是我的第一次。

原文：Why I couldn’t build Jev at OpenAI — Diogo Almeida， TypeSafe Co-founder & CEO

https://www.youtube.com/watch?v=cFx9Z3ZXca0

本文来自微信公众号：Z Finance，作者：ZF编辑部，编译：林嘉越、陈昱萌