“当年在OpenAI像在疯人院！”Jev作者完整访谈：全人类陪AI聊天的价值，不如程序员一个for循环

　　绝大多数新兴 AI 实验室全在毁灭价值。

　　整理 | 王启隆

　　出品丨奇点折射（ID：rgznai100）

　　过去这两年，大家对大模型的认知几乎被框死在了一个固定的形态里：屏幕前放一个对话框，你给它一段 Prompt，它回你一大段自然语言。

　　但最近海外技术圈被一个叫Jev的新模型彻底刷了屏。奇怪的是，它完全不写一句话、不陪人聊天，甚至连最基础的文本生成能力都被切掉了，只专门向程序输出带有精确概率和置信度的决策判断。推出这个模型的团队叫 TypeSafe AI，其创始人Diogo Almeida大有来头——他曾是 OpenAI 的核心研究员，也是早年把 InstructGPT 和 RLHF（人类反馈强化学习）做出来、亲手拉开 ChatGPT 时代序幕的关键技术作者之一。

　　就在 Jev 发布后的几天，Diogo 做客了硅谷知名 AI 播客Latent Space，与主持人 Swyx 聊了整整两个多小时，第一次完整剖析了自己为什么要反叛老东家的路线，去做一个“闭嘴干活”的 AI。

　　对谈中最直击痛点的一个问题，扯下了大模型落地时心照不宣的遮羞布：为什么 AI 明明聪明到能去挑战千禧年数学难题，但在企业里做最基础的自动化工作时却总是掉链子？Diogo 的反思很尖锐——过去全行业把算力全砸在教模型“怎么像人一样客套聊天”上，结果训练出了一堆满嘴漂亮话、却会在底层逻辑上严重幻觉的聊天机器。而真实的软件工程根本不需要一个坐在屏幕对面唠嗑的“数字同事”，工程师需要的是像数据库一样确定、令行禁止、可以直接喂给程序if或switch语句的底层决策。

　　核心要点速览

　　System Message 就像恶臭的全局变量：“把所有上下文和规则不管三七二十一全塞进一个大 Prompt，然后求神拜佛希望模型一次性全执行到位，这纯粹是被驯化的恶习。正确的工程做法是拆成上百个微小判定，让每个决策都可度量、可 Debug。”

　　都 2026 年了，SaaS 居然只多了一个聊天框：“2019 年现代企业软件就已经极具商业价值了。到了今天，除了在界面硬塞一个谁也不敢全信的对话框，软件形态毫无质的飞跃。底层的智能强悍得不可思议，上层却原地踏步，这简直荒唐。”

　　盲目微调（Fine-tuning）是个巨大的深坑：“通用模型之所以厉害，是因为它在其他一百万个任务上学到了泛化能力。很多人自以为需要微调，结果只是亲手毁掉了模型的泛化质感，各厂商以前力推的微调大多沦为了给开发者挖坑的玩具。”

　　侮辱性的 Function Calling：“在现有的架构下，开发者想控制模型调用某个接口，唯一的手段居然是在 Prompt 里像孙子一样求它‘请务必调用这个函数’。这种设计简直是对程序员的侮辱。”

　　“放慢前沿演进”背后是肮脏的政治算计：“那些大实验室天天宣扬 AI 毁灭论、呼吁放慢研发节奏，背后根本不是什么人类生存危机。他们试图在推理环节绑架公众认知，很大程度上只是冲着 2028 年美国大选做的监管套利与政治站位。”

　　以下是本次采访的完整中文整理：

　　别把 AI 当聊天同事，把它做成令行禁止的基础设施。

　　从表面调包走向深层工程重构——

　　2026 奇点智能技术大会将于 11 月 20—21 日在北京举行，18 大前沿专题、70+ 一线技术嘉宾，拆解 AI Coding、Agent、Infra、多模态等真实落地路径。

　　扫码免费领取大会 PPT 与 Agent 实战资料

　　走出哈哈镜迷宫：代码才是 AI 真正的唯一消费者

　　主持人：欢迎来到录音室。本周十分特别，我的朋友 Diogo 刚刚发布了 Jev，瞬间引爆了社交网络。

　　你现在感觉如何？处在舆论的风暴中心是一种什么样的体验？

　　Diogo Almeida：从状态上来说，坦白讲非常疲惫。事情接踵而至，而我作为一名偏向技术型的 CEO，眼下有太多突发问题需要处理。

　　但在认知层面上，过去几年里我也常在 Over/Under 聚会上表达过类似的观点：整个 AI 领域此前就像一座游乐园里的哈哈镜迷宫，充斥着各种极度扭曲、离谱的论调。

　　到了这一周，我终于感觉事情回归到了现实轨道，大家开始意识到：“原来这才是正确的方向。”

　　AI 能够实现的价值远超人们此前的预期。可以说，基于 AI 推动真正经济变革的可能性终于重现曙光。这种感觉非常振奋，看到开发者们能够完全理解我们的初衷，我也深感欣慰。

　　我非常感激开发者社区，大家展现出的热情超乎想象。

　　主持人：你昨天提到，自己宁愿推掉许多重要投资人的会面，也要优先参加社区的 Town Hall，因为你希望将核心精力集中在最重要的人群身上——也就是工程师和开发者。

　　Diogo Almeida：确实有这种体会。虽然即将接触一些极具影响力的人物——具体名字我不便透露——但对我而言，如果把日程全部排满外部会面而忽视了社区，会让我觉得有悖初衷。

　　我在这方面可能有些偏执。如果可以，我更愿意全心投入到社区中。来这里的路上我甚至考虑过边走边开一场社区直播，但仔细想想，那样确实有些过火了。

　　主持人：你们在 Discord 上持续举行的 Town Hall 已经积累了 10 万名成员，你的社交账号关注度也迎来了爆发式增长。

　　Diogo Almeida：我平时不太关注这些数据，竟然已经达到这个规模了吗？

　　主持人：粉丝量增长非常惊人。有趣的是，上次在 AIE 大会上你让台下观众关注你，结果根本没有留自己的账号。

　　Diogo Almeida：在这方面我确实毫无经验。

　　主持人：这种不擅长自我营销的特质，反而显得很真诚。

　　Diogo Almeida：我之前发动态说我们同时登上了三个热门趋势，结果有人指出那只是算法根据我的偏好推送的个性化页面（For You）。当时确实觉得有些尴尬。

　　主持人：毕竟你一直关注这些内容，算法自然会推荐给你。

　　无论如何，祝贺你们。具体的细节我们稍后深入探讨。首先，对于那些还不了解背景、或者想听官方定义的朋友来说：Jev 究竟是什么？

　　Diogo Almeida：这个问题并不容易三言两语说清。

　　主持人：没关系，如果你需要先理清思路，我们可以稍后再聊这个话题。

　　Diogo Almeida：不用，我们按自然的节奏聊就好。

　　值得庆幸的是，我现在不必再费力向父母解释我的工作内容，直接让他们去问 ChatGPT 就行了。

　　在我看来，行业需要一种全新形态的模型。我们并不纠结于具体的命名，目前认为最贴切的表述是“系统 1 模型（System 1 models）”。之所以没有称其为“决策模型（decision models）”，是因为“系统 1”涵盖的范畴远比单纯的决策更为宽泛。目前我只能透露这么多，坦白讲我们没料到这次发布会引发如此大的反响，后续还有更多成果尚未公布。

　　主持人：你当时或许应该保守一点，称其为一个“内部研究预览版”。

　　Diogo Almeida：但从本质上讲，它确实只是一个早期预览版本。

　　我们将这类模型定义为：机器原生（machine-native）、具备“系统 1”特性的高可编程模型。其核心设计原则是：以代码作为唯一的消费者。

　　这与现有的模型有着本质差异：预训练大语言模型本质上是全网文本的“自动续写工具”；基于 RLHF 的模型（如对话系统或指令微调模型）主要用于生成自然语言文本；而 RLVR 则处于这两者之间的过渡地带。

　　相比之下，我们模型的输出直接由代码调用与消费——这也是我们将公司命名为“TypeSafe”的原因。

　　我们的终极目标是释放 AI 最大的潜能，而我们坚信，实现这一目标的唯一途径在于使其与现代软件架构深度整合。从外部接口到底层模型结构，我们所有的设计都完全面向软件系统进行了深度优化。

　　首先，Jev 是我们推出的首个大型可编程模型，或称系统 1 模型。其核心定位是追求极致的“单位成本智能（intelligence per dollar）”——Jev 这一命名正来源于“杰文斯悖论（Jevons paradox）”。

　　这一模型完全聚焦于单位成本下的智能产出。业内经常探讨可靠性、成本、概率校准与运行速度之间孰优孰劣，而 Jev 系列的目标，就是始终在单位成本智能这一维度上保持领先。机器学习的本质就是权衡与取舍，而我们正是在这一特定维度上做出了最极致的权衡。

　　杨立昆的观点并没错：自回归长文本的“对齐”存在根本性缺陷

　　主持人：“校准（calibration）”此前很少被深入探讨。我们在采访 Hugging Face 的 Clémentine Fourrier 时，他们也曾提及这一点……

　　这也正是你对 RLHF 的核心质疑：当前模型存在严重的模式坍塌（mode collapse），倾向于生成最迎合用户或概率上最平庸的内容，而非其内部对事实的真实置信度。

　　Diogo Almeida：关于这一点，我可以多展开谈谈吗？

　　主持人：请畅所欲言。

　　Diogo Almeida：既然这个播客的听众群体非常专业，那我就深入讲讲。

　　为了保证我们发布的视频内容严谨可信，我投入了大量精力核实细节，这种做法在业内似乎并不多见。但大家此前普遍忽视了 RLHF 的一个关键缺陷：模式丢弃（mode dropping）。

　　主持人：是模式丢弃（mode dropping）还是模式坍塌（mode collapse）？

　　Diogo Almeida：两者本质上是一致的。我之后会专门撰文详述，但眼下我想尽可能向大家阐释清楚，因为这个现象至关重要。

　　说一个可能会引发争议的观点：我其实非常赞同 Yann LeCun。在许多核心问题上，Yann LeCun 的看法反而最接近事实真相……

　　主持人：那么关于他那张幻灯片呢？

　　Diogo Almeida：我们是先探讨幻灯片，还是稍后再回到模式丢弃的话题？

　　主持人：先谈谈 Yann LeCun 的那张幻灯片吧。

　　Diogo Almeida：我认为 Yann LeCun 的许多判断非常准确。不过他有一张人尽皆知甚至颇具争议的幻灯片，主题是“自回归 LLM 注定失败”。图上包含一个饼图，指出随着生成序列长度的增加，整体出错的概率会无限趋近于 1。就是那一页。

　　我很关注这张图，因为它在数学逻辑上看似无懈可击，但在工程实践中却显然与事实相悖。它在理论上完全成立，在现实经验中却并未发生。我一直希望能帮大家厘清，这种理论与现实之间的脱节究竟出在哪里。

　　主持人：那么，这种脱节的原因是什么？

　　Diogo Almeida：脱节的核心在于：如果一个概率分布能够覆盖完整模式（mode-covering）或经过了良好校准，那么离群值（outlier）并不会受到过度惩罚。系统本就应当预期部分概率落在特定分布区间之外。完整覆盖真实分布通常会导致模糊性——正如 GAN 出现之前的生成模型那样，生成的图像往往偏模糊。

　　但 GAN 采取的是模式丢弃（mode dropping）策略。它们直接舍弃了长尾的少数类，只输出最常见、最稳妥的核心模式。这也解释了为什么 Yann LeCun 所预测的错误累积效应在实际中并未发生。

　　为了生成足够长的文本且不出现明显错误，模型必须变得极度保守。一段文本如果包含明显的硬伤，很容易被识破；但如果是看似合理、挑不出毛病的中庸表述，人往往难以察觉。

　　然而，这种所谓的“对齐”手段，对文本背后的概率分布具有破坏性影响。

　　这是一个十分微妙的权衡。我认为这恰好解释了自回归长文本生成为何没有崩溃，同时也揭示了为什么文本生成模型在用于决策时表现极差。强行将文本生成模型直接应用于底层决策系统，本身就是一个根本性的错误。

　　在底层 API 中设置安全拒答在工程上完全无法成立

　　主持人：顺着 Yann LeCun 的观点来看，你认同他的解决方案吗？也就是类似 JEPA（联合嵌入预测架构）的世界模型。自回归模型容易出现问题的一个核心原因，在于它是在 Token 层面进行推理，并通过不断自循环生成直至句末。你认为 JEPA 是正确的方向，还是有不同的看法？

　　Diogo Almeida：关于机器学习内部架构的细节，我恐怕不能透露太多。

　　但我必须说明，抛开表达风格不谈，我最核心的特质其实是务实，在这个问题上的态度也是如此。至于我是否认同 Scaling Law（缩放定律），这要视具体情况而定。

　　Scaling Law 确实揭示了资源投入与性能提升之间的关系。但它同时也意味着你需要投入指数级的资源，去换取往往只有亚线性的收益回报。除非那些细微的边际提升本身具备极高的商业价值，否则从投资回报的角度来看，这并不是一笔划算的买卖。

　　对我而言，核心问题始终是：我们如何利用手头现有的资源，去创造最大的实际影响。

　　主持人：关于 Scaling Law，我们稍后也可以深入探讨。

　　Diogo Almeida：如果有必要可以展开，不过那不是眼下最紧迫的。探讨我所总结的“最苦涩的教训（bitterest lesson）”或许更有价值。

　　我衡量技术的标准始终是实际效果。JEPA 确实是非常前沿且出色的早期研究，我也很欣赏高水平的基础科研。但它现阶段是否具备实用价值，目前还很难下定论。

　　事实上，当前科研界并不缺乏有潜力的成果，许多突破只是因为尚未找到恰当的任务目标而被暂时搁置。我们这次的发布不仅推动了 TypeSafe 自身的发展，对公司而言是一大步，但更深远的意义在于：它真正开辟了“可编程 AI（programmatic AI）”这个全新方向。

　　接下来会有大量开发者涌入这套体系，因为软件正在被赋予前所未有的强大能力；与此同时，整个生态也将迎来新的探索浪潮——大家会尝试以各种方式暴露并封装 AI 的能力，增强软件功能，构建更具创新性的产品。

　　这种氛围就像重回早期互联网的开拓时代。我想这正是为什么在社交平台上大家对 Jev 的反响如此热烈。

　　主持人：这种局面确实令人振奋。过去大家反复听到的一种论调是：“普通团队做不了这个，只有顶尖实验室依靠庞大的算力堆砌 Scaling Law 才能搞定。”

　　Diogo Almeida：顺便提一句，我能否延伸探讨一个话题？我认为这个内容非常值得讨论。

　　主持人：没问题，请继续讲。

　　Diogo Almeida：在 Discord 上，经常有人问我一个之前未能公开说明的问题：为什么我反对安全对齐（safety alignment）？为什么我们的模型坚持不做“拒绝回答（Refusal）”？

　　我并非在原则上反对系统安全性，而是认为当前所谓的“安全对齐”，本质上与实际需求脱节。而在程序逻辑层面，“拒绝执行”本质上就是一个显而易见的类型错误（Type Error）。

　　设想一下，如果是普通用户在进行日常对话，或者使用 Claude 辅助编写代码，模型突然抛出拒答：“抱歉，我无法读取dna.py这个文件。”这种体验固然令人困扰，但在交互界面下，用户或许还能被动适应并绕过这个问题。

　　但如果将模型作为底层依赖库部署在后台系统中，一旦它毫无征兆地拒绝执行，后果是什么？当下游服务调用该依赖时，调用方甚至不知道底层接入了该模型。整个软件系统难道要因为终端用户输入了一句略带敏感词汇的内容，就毫无预警地抛出异常甚至崩溃吗？

　　这种设计在工程实践中完全不可理喻。提出这类方案的人缺乏对现代软件工程和编程逻辑的理解。他们仍局限在将 AI 视作“数字同事”的“无马马车”式旧思维中，未能真正释放 AI 作为基础设施的潜力。

　　主持人：理解了，你追求的是一个放之四海皆准的底层“认知内核（cognitive core）”。

　　Diogo Almeida：正是如此。这个核心必须具备高度的通用性，同时针对具体的落地场景做到极致优化。系统需要能够承受各种极端边界场景，稳定处理各类非常规的输入。

　　我们在训练时并未依赖现实中琐碎混乱的数据。它之所以能够运行顺畅，是因为我们使用了更底层、更本质的训练逻辑。

　　在我看来，安全对齐属于应用产品层面的职责，例如面向终端消费者的 ChatGPT 或 Claude。安全对齐与“能力对齐（capability alignment）”的关键区别在于：能力对齐追求的是绝对服从并准确执行用户的指令。

　　对于软件工程师而言，系统必须做到确定、可靠且严格执行指令。行为的确定性越高，开发者所需编写的容错与异常处理就越少。

　　Jev 目前距离完美还有差距，但我们的目标是实现工业级的高可用性（达到几个“9”的指标）——就像执行常规的数据库查询一样，无需担忧不确定性，只要发出请求，系统就能稳定可靠地返回结果。

　　然而，现行的安全对齐机制往往站在了指令遵循的对立面：它实质上是在强制模型遵循第三方的规则，例如 OpenAI 或 Anthropic 设定的约束，而非当前用户的指令。

　　在具体的终端应用中，这种限制具备合理性——例如 ChatGPT 限制某些敏感或成人角色扮演内容，这是出于面向大众用户群体（包括未成年人和老年人）的产品定位考虑，无可厚非。

　　但在底层 API 中推行这种机制是完全错误的，在工程上根本无法接受。开发者依赖 API 构建生产级应用，这种设计无异于直接站在开发者的对立面。抱歉，提到这点我有些激动。

　　AI 是数据库而非同事：划清底层与业务的边界

　　主持人：大家都能理解你的热情。但我必须代表外界提出一个现实的质疑：如果有人用这项技术去危害生命呢？我指的不是擦边或色情内容这类隐私问题，而是战争场景。企业完全有合理的理由，不希望自己的 API 被用于军事武器。

　　Diogo Almeida：我可以理解这种担忧，在实际业务操作层面，这种立场是讲得通的。但就我个人而言，通用技术的最底层绝不应该成为施加这类限制的地方。

　　我希望自己的技术被用于杀戮吗？显然不希望。我希望它被用来推动世界上一切美好的事物吗？当然希望，而且我也会为此全力以赴。

　　但我绝不会在底层技术上做人为干预。因为一旦在底层技术上设限，智能本身就会遭到破坏。每一次为了迎合某些特殊案例而进行的过度拟合，实际上都是在削弱它的通用智能。而现有的模型已经在这种干预下受到了极大的损害。

　　在我看来，未来的智能更像是一个数据库，而不是坐在你身旁的同事。你会要求数据库在底层做拦截，去审查自己是否被用于不良用途吗？比如中情局（CIA）的某些行动——虽然我并不清楚他们的具体行动细节，但这类行动难免会存在误伤无辜等伦理争议。

　　但这难道是数据库应该承担的责任吗？此外，经常有人在 Slack 上问我们：“我们准备把你们的模型部署到生产环境，请问这个场景能用吗？”这种思维方式本身就不符合技术逻辑。

　　在我们看来，平台只负责提供 API，技术具体用来做什么，应当由开发者自行掌控与负责。开发者甚至不应该把一整套业务流程全盘扔给底层模型，而是应当将其拆解为若干细分的决策环节。

　　作为底层基础设施，我们根本不该、也无需知晓下游用户具体的业务逻辑。只有划清这个边界，软件工程师才能拥有最充分的掌控权。

　　在理想状态下，我们自然希望技术能被用于正向的领域，并且会为此提供支持。我们探讨过开源和公益支持等方向，尽管目前业务非常繁忙，但只要我仍在负责，就绝不允许主观偏见干预并污染底层的技术架构。

　　告别虚假基准测试：数据才是决定可靠性能达到几个“9”的关键

　　主持人：顺便聊聊你们的服务条款（Terms of Use）和隐私政策，社区此前对此有些误解。你用两句话就能讲清楚吧：你们对 API 的限制并不苛刻，在理念层面上，你们非常明确地将自身定位为一个开放平台。

　　Diogo Almeida：我不太确定你具体指的是哪件事，但我看到有人在讨论与 Benchmark（基准测试）相关的条款。我们从来没有限制别人去做测试，我想我发言需要更谨慎一些。

　　主持人：你公开澄清过，那是内测期的遗留条款，正式发布时漏删了，目前已经在走流程准备移除。

　　Diogo Almeida：团队推进的具体细节很多我也未必全知晓，很高兴看到他们已经与外界沟通了。我已安排他们联系法务处理。

　　我们绝不会阻止大家进行评测。但我个人十分反对公开的基准测试（Benchmark）。至于作为替代指标的私有基准测试，我的态度相对中立。

　　公开榜单不仅极易被操纵，而且从行业本质来看，假设两年后整个行业都在提供类似的服务，我们售卖的核心产品，本质上是某种维度的智能性价比——即单位成本的智能，或是单位时间的智能。

　　业界目前极力追求低成本和低延迟。这固然很有价值，但最核心的始终是智能本身。成本和延迟只是付出的代价——通过付费与等待响应，最终兑换的是智能。

　　但智能最棘手的地方在于，它带有一种“难以言表的特质（je ne sais quoi）”，也就是业内常说的“优秀模型的感觉（good model smell）”。

　　产品发布约两小时后，社区里的真实反响远超官方宣传视频的热度。大家的反馈是：“它居然真的能在生产环境中稳定运行。”这才是最有价值的认可。用户能切实感受到我们对实际落地效果的重视，而这正是长期的核心壁垒。

　　公开基准测试的作用却恰恰相反。由于智能难以量化，设立基准的初衷本是建立信任。但公开榜单太容易被刷分了，即使开发者主观上没有作弊意图，模型在训练时也会被动地产生过拟合。

　　当年在 OpenAI 时，各大模型实验室都会专门组建团队，清洗并抓取与 MMLU 结构类似的数据来训练模型，纯粹为了提升榜单分数——这本质上是一种变相的“刷榜套利（bench-maxing）”。

　　长远来看，用户最终只能依赖直觉与信任，直到将其接入具体的实际工作流中，用自己的业务数据进行测试和评估，才能对模型在具体任务上的表现建立起真实的认知。

　　作为一家基础设施公司，我们的职责是不断提升系统可靠性背后的那串“9”（即高可用性指标）。这是我们需要长期专注投入的方向。如果真想投机取巧，我们早在一年半前就可以发布一个极不成熟的 Jev 版本。这也引出了那个著名的“最苦涩的教训（The Bitter Lesson）”……

　　Diogo Almeida：Sutton 的核心论点在于：算力的提升终将胜过算法层面的优化。但在算力之上，数据显然起着比算力更为关键的作用。如何确立正确的目标导向（North Star），才是最困难、最核心的课题。

　　在大语言模型（LLM）的发展史上，这种范式转移大概发生过两次，或者说 2.2 次。第一次是 RLHF（基于人类反馈的强化学习），将核心任务彻底转向了“指令遵循”，在此之前业界尚未意识到这种路径的可行性；另一次是 RLVR（基于可验证奖励的强化学习），在方向上进行了微调；

　　如今轮到了我们所推动的 RLCD。我们定义了一个全新的任务范式：让程序在闭环中调用并整合 AI（programs in the loop）。

　　数据的重要性无论怎样强调都不为过。

　　主持人：所以相比于“模型实验室”，你更倾向于将团队定义为一家“数据实验室”？

　　Diogo Almeida：毫无疑问，我们始终将数据置于最高优先级。

　　在我看来，模型能力的上限完全由数据决定。数据本身极其复杂，它是决定系统可靠性能否达到多个“9”的核心要素。数据对模型表现的重塑程度超乎想象。

　　因此，如果有正在寻求工作机会的朋友，我们目前正大力招募数据领域的优秀人才，招聘名额不设上限。

　　未来的 TCP 协议：为什么我们不采用人类的粗糙数据进行训练

　　主持人：在您看来，怎样才算优秀的数据人才？是那些愿意深入处理原始转录文本的人吗？您之前提到过团队完全依赖合成数据，但这应该只是表象。即便是合成数据，也需要具备极高审美水准和敏锐洞察力的人员进行审核，找出问题并重新迭代生成。在当下，“优秀的数据人才”是否就是这样定义的？

　　Diogo Almeida：这个问题涉及的层面很广。平时我对数据团队新成员所做的入职培训，时长甚至会超过我们今天录制这期播客的时间。我尽量简明扼要地概括一下。

　　首先，数据（包括合成数据）的组织形式完全取决于任务的定义。任务的形式直接决定了数据的形式。例如，RLVR（基于可验证奖励的强化学习）所需的数据本质上是各种交互环境，而 RLHF（基于人类反馈的强化学习）所需的数据则是人类的偏好排序。每种任务都对应着独特的数据范式，我们自然也有针对自身技术路线的特定数据。

　　其次，关于为什么即便能够获取，我们也避免使用用户的真实数据进行训练。我们对这种方式持审慎态度，因为无论如何清洗或处理，现实世界的数据都不可避免地带有显著的偏见与偏差。

　　用户的提问模式普遍遵循幂律分布，绝大多数人都在反复询问高度相似的问题。如果直接使用这些数据进行训练，模型最终只会对当下的高频场景产生过度拟合，从而损害其通用的泛化能力。

　　更核心的原因在于，我们的目标是面向数年后更具前瞻性的未来场景——届时模型将作为通用的底层基础设施，深植于整个软件技术栈的最底层，去支撑如今尚无法预见的各类应用场景。

　　打个比方，如果说传统大语言模型类似于不可靠的 UDP 协议，那么我们的目标则是打造如同 TCP 协议般具备高确定性的可靠底层，所有现代应用程序都可以稳固地构建于其上。我们必须提前解决未来可能出现的各种极端边界情况，软件开发者才能无后顾之忧地开发下一代软件架构。

　　为了实现这一目标，即便汇集当今全人类产生的所有现实数据，也只会让模型对当下的使用场景产生过拟合，在应对未来的未知场景时依然无能为力。

　　因此，我们所需要的数据专家更接近于工匠或艺术家：他们必须深入理解模型的认知核心——与主流模型相比，我们的认知边界更加平滑，缺陷（jaggedness）显著更少——他们的核心职责是精准定位那些参差不齐的能力边界，并在所有潜在的逻辑维度上将其彻底修补平整。

　　主持人：也就是说，重点在于提炼出通用的解决范式，而非孤立地修补单一特例。

　　Diogo Almeida：这一过程中的每一个环节，都需要极高的智力投入和专业素养。

　　消除人工干预：RLCD 与真正的经济自动化

　　主持人：明白。刚才你提到我的思维定式受 RLVR 影响太深，这个提醒很中肯。那我们来深入聊聊 RLCD 吧。你们显然掌握了某种独特的技术路径，但据我所知，目前还没有公开发表过相关论文，对吗？

　　Diogo Almeida：还没有。

　　主持人：那行业该如何客观理解它？你能否向大家证明，这并非为了博取关注而生造的新概念？比如“对齐”，大家在各类播客中耳熟能详，但多数人并不清楚你所说的 RLCD 与现有技术究竟有何本质区别。

　　Diogo Almeida：问得好。在回答之前，我想先探讨一个问题：究竟什么是 RLHF？

　　RLHF 在不同语境下的含义截然不同。最初的 RLHF，如果我没记错，应当源于 Paul Christiano 当年训练虚拟机器人完成后空翻的研究。

　　主持人：是那项研究吗？我记得涉及 PPO 的论文，但不确定是不是这篇。

　　Diogo Almeida：那就是最初的 RLHF。如果我没记错，PPO 本身并不必然依赖人类反馈。那是 OpenAI 早期的对齐探索，主要用来优化那些难以用明确规则形式化定义的目标，例如后空翻动作。具体细节我记不太全了。

　　后来有了《Learning to Summarize》那篇关于摘要生成的研究，由指令遵循团队的多位成员主导，核心是利用 PPO 在语言模型上处理目标相对模糊的任务。这也是大多数人所理解的 RLHF。我并未在那篇论文上署名。顺便提一句，Dario 和 Raffel 都在作者名单中……

　　主持人：那是 2017 年的工作了。

　　Diogo Almeida：是的，如果论文里有机器人做后空翻的实验，那就是它。看来我没记错。

　　所以最初的核心思想是：能否利用强化学习去解决那些无法被明确形式化定义的目标？这是第一阶段。第二阶段则是 OpenAI 的文本摘要研究，即将 PPO 应用于语言模型来处理模糊任务。

　　但对我而言，真正意义上的 RLHF，本质上是指“指令遵循（instruction following）”这一核心任务目标。关键从来不在于 PPO 算法本身，具体算法如何实现并不重要；重要的是它确立了一座指引方向的北极星——明确了这个技术路径具有巨大的实用价值。这就像《苦涩的教训》（The Bitter Lesson）中所阐述的方向指引。

　　对我们而言，RLCD 确立的是一个全新的任务目标。这绝非凭空创造术语，我向来追求技术概念的严谨。它代表着另一个维度的北极星——正如同 DPO 及其衍生变体，即使完全脱离了最初论文中的 PPO 算法，业内仍会将其归入广义的 RLHF 范畴一样。

　　主持人：明白了，所以这个核心目标就是“可编程 AI”，彻底消除人在回路（removing human-in-the-loop）。传统 RLHF 的本质在于拟合人类偏好，而你的目标是实现全流程的自动化。

　　Diogo Almeida：完全正确，实现真正的全自动化。

　　主持人：我对这一核心目标的理解还有什么遗漏吗？

　　Diogo Almeida：理解得非常准确。我表达时习惯加上各种限定条件。这里唯一需要补充的是：我们必须保持务实，清醒地认识到当前大语言模型与 AI 究竟擅长什么。

　　某些程序结构在理论上或许极其精妙，但如果底层技术尚不足以支撑，暂时无法实现也完全可以接受。但在我看来，在 Jev 出现之前，整个技术生态的现状令人遗憾……这么说或许显得有些自负。

　　主持人：不算自负，我完全理解你的意思。

　　Diogo Almeida：听起来可能有些激进，但在创办这家公司之前，我就已经是这种想法了。

　　主持人：这点我可以作证，你在 Over/Under 聚会上阐述这套理念已有近三年时间。

　　Diogo Almeida：是的，我谈论这个构想很久了。之所以一直公开表达，是因为我起初误以为实现它并不困难。正如那句格言所言：“人们之所以着手做某些事，并非因为其简单，而是因为当初误以为它很简单。”

　　我起初以为整个系统只要一周就能搭建完成，结果事实证明我严重低估了难度。当时在 OpenAI 我甚至信心满满地对同事宣称：“我很快就能把这个问题彻底解决！”在此我也想向当年的同事们致以歉意。

　　但真正令人担忧的是——过度承诺却无法兑现本身就是一种损耗，而当下的 AI 行业在这种倾向中走得有些偏激。我认为 RLVR 和 RLHF 在一定程度上都推动了这种趋势。

　　AI 展现出的智能水平毋庸置疑。我在演讲中最常向听众提出一个问题：为什么 AI 一方面已经足以挑战数学界的千禧年大奖难题，另一方面却连现实中最基础的重复性工作都无法实现自动化？

　　现实中有大量机械、繁琐的任务，根本不需要顶尖智力来承担，从事这类工作也难以产生价值感；这些从业者本应参与更具创造性的工作，但现实中我们却不得不持续投入人力兜底，仅仅是因为现有技术无法将其自动化。

　　我们手中掌握着性能极为强大的自动化引擎，却缺乏与之匹配的架构接口，无法将其真正嵌入具有直接经济价值的实际工作流中。

　　退一步讲，哪怕 TypeSafe 这家公司明天不复存在，行业大概也需要一到两年的时间才能真正赶上现有进展。具体需要多久我无法断言。如果基础模型的质量是决定性因素，那么我们将在相当长的一段时间内保持领先。

　　但最关键的是，这扇大门已经被彻底推开。技术演进的路径已经改变，整个行业都将在这个全新的空间中持续探索下去。

　　专注生产力，而非造神：日均万亿 Token 背后的淘金热

　　主持人：我非常赞同，你开启了全新的可能性。

　　如果做个概括，我认为大家绝不能把 TypeSafe 和 Jev 的成功仅仅看作“多了一种新模型，我们可以沿用老套路继续做下去”。事实绝非如此。目前至少还有五六种全新的模型路线有待开拓，行业应当呈现百花齐放的态势。

　　Diogo Almeida：确实如此。这种状态让人重温早期互联网的极客精神，科技乌托邦的时代正在回归。

　　大家不再需要抱怨：“我的 coding agents 只是偶尔能跑通，而最好用的工具都被头部大公司垄断了。”如今，创造的权力重新回归到每一个人手中。未来的变化将极其深刻，这令人倍感振奋。

　　主持人：而且你们目前资金充裕、势头强劲，完全有能力去实现这一构想。你多年来倡导的理念终于向全世界证明了其可行性，这非常令人欣慰。

　　Diogo Almeida：过去一直保持悬念的过程确实不容易。我早期的演讲往往点到即止，并未具体说明该如何实现自动化。Shawn 此前在审阅我们的宣言时曾指出：“这几个部分写得过于模糊，第一步究竟是什么？单位成本的智能又该如何衡量？”

　　主持人：当时我向你询问模型进展，你只说“正在路上”。

　　尽管我个人对“可组合（composable）”这个词不太推崇，但“专注生产力，而非造神（Build Prod, Not God）”这句话概括得非常精辟。

　　Diogo Almeida：谢谢。整个团队都对这句话高度认同。我们并不像某些公司那样带有极端狂热的色彩，但所有人对自己所专注的事业抱有极高的热情。我个人的风格始终坚持务实，全团队也高度崇尚实干，这种协作氛围非常契合。

　　主持人：你们的逻辑非常清晰：第一步，交付在单位成本下具备最高智能水准、原生面向机器的可组合 AI；第二步，让 AI 达到极高可靠性，以真正的自动化重塑经济；第三步，以更高维度的智能抽象赋能全球……这很有 Elon Musk 当年在特斯拉的风格。

　　但你当时确实应该提前透露关于发布模型的消息；你当时只说明了一部分内容，并没有提及关于《毁灭战士》（Doom）的演示，也没有提供任何具体数据。

　　Diogo Almeida：因为我并不盲信所谓的基准跑分（benchmark）。很多工具的实际价值，只有亲自上手才能体会。即便这种坚持让我们付出了不小的代价，但我始终认为这是建立长期信任的唯一途径。

　　去年融资时，外界对我们充满怀疑。投资人只关注基准跑分，而我们的态度非常明确：“我们不会迎合这种机制。我们有自己的底线，绝不向只会催生投机行为的风气妥协，也不会为了迎合要求去虚构指标。这就是我们的原则，无法接受可以不参与。”因此，我们只能拒绝妥协。

　　主持人：你选择了一条最艰难的道路，但也正因如此，你最终建立起了一家自己真正愿意为之奋斗的公司。否则一旦妥协，无非是在另一家类似 OpenAI 的机构里重复原有的工作模式。

　　Diogo Almeida：对此我毫无悔意，最终的成果甚至超出了最初的设想。昨晚谈及离开 OpenAI 的初衷时我有些激动，在发布会之后，我也修正了自己原先的部分看法。

　　我此前一直认为，如果 AI 寒冬不可避免地到来，而我未曾全力以赴去阻止它，我将负有不可推卸的责任。原因之一在于我曾参与推动 RLHF，而这项技术在很大程度上拉大了“过度承诺”与“实际交付能力”之间的落差；

　　另一方面，也是因为我未能在更早的时候全力投入到当前的方向——而唯有这个方向，才能真正实现规模化商业变现、创造实在的经济价值。

　　如今的情况令人宽慰，因为我所担忧的 AI 寒冬正被扭转。AI 正在转化为切实可行的生产力，被深度应用于现实场景的自动化流程中。产品发布尚不足一周，多项核心指标已经充分证明，它已被广泛嵌入真实的业务生产环境。技术淘金时代已经拉开序幕。

　　主持人：能否分享一些具体的数据？比如注册用户规模，或是其他可以公开的业务指标？

　　Diogo Almeida：我日常并不特别关注这类细节数字，通常是由团队同步给我。

　　不过有一个关键的里程碑可以公布：我们日均处理的 Token 规模已经突破一万亿（1 trillion tokens per day）。更重要的是，这并非尝鲜式体验带来的短暂峰值——即便利于深夜，系统请求量依然保持高负荷运转。这表明流量主要源自机器程序的自动化调用，而非人类用户的偶发性测试。日均一万亿 Token 确实是一个极为显著的规模。

　　突破这一量级非常令人振奋。至于注册用户数，我并不刻意追求。坦率地说，我们在这方面甚至走过弯路。社交媒体上有人将我们称为“营销奇才”，但事实上我们甚至尚未设立专门的市场岗位——目前也正在招聘相关人员。我们只是在社交媒体上展现了团队最真实、随性且不拘一格的一面。

　　此前我们曾全力消化候补名单（Waitlist）中的用户。平台工程团队展现出了极高的工程水准，在面对如此爆发式的发布流量下，我们系统的可用性指标（uptime）甚至比 Anthropic 还要高出几个 9。工程团队在此次保障中功不可没。

　　但就面向开发者的基础设施平台而言，候补名单的绝对数量参考价值有限。其中很大一部分注册者可能并非开发者，他们在注册并尝试几次调用后便感到困惑，因为缺乏编程背景的用户会意识到，这并非面向日常对话的聊天工具，无法像 ChatGPT 那样直接交互。

　　直觉告诉我，即便全球每人完成数次偶发查询，其累计价值也远不及一位核心开发者在后台部署一个持续运行的for循环。

　　我们起初并未完全意识到候补名单背后的实际挑战：扩充准入人数本身并不困难，真正的压力在于速率限制（Rate Limits）。开发者一旦验证了其效用，便会迅速产生对高并发配额的极大需求。

　　软件的本质正在于此：前期投入精力用代码将重复性任务定义清晰，其产生的杠杆效应远超开发成本，随后即可实现“部署后自主运行（set it and forget it）”。让程序在后台持续运转，成为上层架构的基础依赖，去支撑更高维度的业务逻辑，进而在现实世界中源源不断地创造价值。

　　早期互联网的开拓者可能也未曾预料到 2000 年代初网络生态所催生出的技术突破。尽管你对这个概念持保留态度，但正是依托这种“可组合性”，各类突破性创新才得以生根发芽。

　　我们追求的是技术涌现，致力于成为推动整体生态发展的催化剂。无论是在 Discord 上以随性的方式举办全员会（Town Hall），还是参与播客对谈，我们都会全力投入。我始终倾向于长音频对话的形式，因为唯有深入、完整的沟通，才能让外界真正理解并认同你的使命。

　　开发者需要的不是绝对的确定性，而是高度的鲁棒性

　　主持人：稍后我们会深入探讨你们的 API 设计，分享一些具体的应用场景和权衡考量。

　　但在此之前，我想先问一个关于可靠性的核心问题：我注意到你们的 API 没有提供seed（随机种子）。这意味着如果输入相同的 Prompt，是否无法保证每次都获得完全一致的输出？如果确实无法保证，原因是什么？

　　Diogo Almeida：这是我们最常收到的提问之一。

　　“可靠性”其实是一个概括性概念。只要 AI 无法顺利完成自动化任务，本质上都是某种可靠性不足导致的——可能是类型安全缺陷、确定性缺失，或是能力表现不稳定。我们将解决这些问题统称为在可靠性上的北极星指标。

　　“确定性（Determinism）”意味着相同的输入必须产生完全一致的输出。在单元测试中这确实有一定价值，但我认为它不应被当作核心目标。鲁棒性（Robustness）才是开发者真正需要的特质。

　　我并不想替用户下定义，但我坚信鲁棒性更为关键：当输入相似时，模型能够稳定给出语义一致的输出。而在当前的主流 LLM 中，这一维度的稳定性非常欠缺。

　　我们的测试方法是在 Prompt 中引入不同的 UUID 或随机数（nonce）。在语义完全等价的前提下，我们期望所有变体的输出高度一致。缺乏鲁棒性，正是目前开发者在利用 AI 辅助决策时最容易产生故障的环节。

　　因此，鲁棒性具有极高的优先级。技术上我们完全能够支持确定性。从开发者的思维模式来看，确定性在特定场景下确有需求，如果大家持不同意见，欢迎进一步指正；但在多数情况下，确定性完全可以通过其他成本更低的方式来替代或权衡。

　　我们的核心目标是始终保持在“单位成本智能”的帕累托前沿。为了实现这一点，我们在底层架构上采取了一些极其激进、甚至非常规的工程手段。这或许不适合过多对外透露，但确实是我们的做法。

　　主持人：反正你能自己合并 PR，没人能阻止你。

　　Diogo Almeida：我们内部并不是这样的运作模式。至少在这周，我们的幕僚长 Kay 才是真正掌握决策节奏的人。

　　主持人：也感谢 Kay 协助安排了这次对谈。

　　Diogo Almeida：她的执行力极其出色。曾有人提醒我，不要把我们的架构称为“弗兰肯斯坦的怪物（Frankenstein's monster）”，因为这个词带有贬义。但我认为在原著故事里这个角色其实是无辜的——不过坦白讲，我并没有读过原著。

　　主持人：Jacob Elordi 出演过一部相关的改编作品，有空不妨看一看。

　　Diogo Almeida：我目前的时间非常紧张。我的优先级排序很简单：除了必要的休息，剩下的全部重心都是开发者、开发者，始终是开发者。

　　为了在单位成本智能的帕累托前沿上保持领先，我们尝试了所有可能的优化方式，未来也会延续这种策略。这需要打破很多传统思维定势。

　　至少在目前阶段，我们在该维度的表现处于前列，并且希望继续保持这种优势。

　　主持人：你刚才区分了可靠性与鲁棒性，但换个角度看，技术上其实完全可以直接提供确定性输出。

　　Diogo Almeida：我们确实有能力提供确定性。如果开发者能证明这具备显著价值，且算力资源不受限，我们很愿意支持。我们的目标始终是服务用户，并促进行业的改变。

　　确定性确实在考量之中，只是它不可避免地会折损一部分单位成本下的智能水平。

　　主持人：参考 OpenAI 和 Anthropic 的发展路径，市场和行业的压力最终很可能会迫使你们做出妥协。即使你向开发者反复解释并不需要这项特性，他们往往依然会坚持要求提供。

　　Diogo Almeida：这需要时间来验证。外界常评价我们的品牌风格是“坚定不移”，有人认为这只是顽固的委婉说法，我也承认自己在某些技术路线上确实非常坚持。

　　主持人：我们之前交流过，我认为你虽然有坚持的原则，但只要有充分的事实和证据，你也能够迅速修正观点并认可对方的逻辑。因此在这个问题上，按照你目前的判断走即可。

　　Diogo Almeida：但我预计在相当长的一段时间内，算力瓶颈都会客观存在。任何降低单位成本智能的方案，都意味着在消耗同等 GPU 资源的前提下，最终交付的智能表现会大打折扣。

　　我们的首要目标并非一味迎合大型企业客户——企业客户固然重要，但我们真正的核心是赋能广大的独立开发者，让他们能动手实验、探索更多创新的可能。我们希望把工具交付到尽可能多的人手中，推动整个生态的爆发。

　　主持人：这里需要提醒一点：当你公开表示“不承诺提供确定性模型、为了极致性价比采取非常规手段，同时算力受限”时，开发者的第一直觉往往是你们会采用模型量化（Quantization）。大家会担忧你们是否会在模型上线后暗中量化降级，通过牺牲输出质量来节省显存与带宽。

　　因此，你们可能需要向社区给出明确承诺，哪怕不在现阶段，比如声明“保证模型质量与发布时一致”。

　　在 OpenAI 和 Claude 的 API 早期阶段，后端模型权重确实曾频繁在后台变动。你们在 API 中引入了版本号控制，这是很好的做法，但最好能公开保证：特定版本一旦发布，后端绝对不会暗中变动。

　　Diogo Almeida：已上线的特定版本我们绝不会擅自变动，这种做法对开发者极不负责，而我们始终把开发者放在首位。

　　暗中修改线上模型，恰恰体现了 C 端产品与底层 API 基础设施之间的本质差异。在面向普通消费者的产品中，只要能优化交互体验，你可以频繁调整；但在底层 API 领域，擅自修改稳定接口和模型无异于自毁信誉。

　　我们的迭代节奏会明显快于传统的模型厂商，推出新模型的频率可能会远超外界预期。并且鉴于技术迭代空间巨大，我们目前无法对所有历史模型都提供长期支持（LTS）。

　　不过作为例外，我们正在评估是否为当前的 Jev 1.13.0 版本提供短期的 LTS 支持。考虑到该版本目前的调用规模极其庞大，且我们深知开发者对下游依赖被破坏的顾虑，这一考量是合理的。但如果完全不淘汰旧版本，集群算力就会被严重碎片化，这在长期来看对任何人都不可持续。

　　主持人：确实，服务商不可能长期维护数百个并存的模型版本。

　　Diogo Almeida：是的，高速迭代必然带来严重的版本堆积问题。因此，我们不仅计划在未来建立完善的 LTS 机制，而且在技术研究上正在探索一种全新的实现路径，力求找到对开发者最为友好的平衡方案。不过这项技术目前尚未落地在现有模型中，所以我目前无法承诺永久保留完全相同的旧模型。

　　但可以明确的是：每一次迭代的新模型都会具备更强的能力。从实际观察来看，即使在快速迭代的不同版本之间，对于模型已经掌握的能力，跨版本的输出漂移幅度，甚至低于传统大语言模型连续调用两次自身的波动。

　　真正的质变，正是从能力参差不齐（jagged）跨越到高度稳定可用（wow）的那一刻。

　　单位成本还是单位时间？切入“更快且更具性价比”的市场空白

　　主持人：长期支持版本（LTS）模型还有一个优势，就是可以迁移到其他专用芯片上。你们考虑过这个方向吗？

　　Diogo Almeida：目前无可奉告。

　　主持人：明白。

　　Diogo Almeida：我更关注的是单位成本所能获得的智能水平。

　　主持人：那运行速度呢？这也是需要衡量的因素。

　　Diogo Almeida：这个可以后续再看。

　　主持人：过去一年推理芯片的技术发展非常迅猛。如果迁移到 Cerebras 或 Etched 这样的专用芯片上，运行速度甚至能提升数万倍。

　　Diogo Almeida：“单位时间智能（intelligence per second）”属于完全不同的评估维度。我们内部曾讨论过类似“单位成本与时间乘积的智能（intelligence per dollar-second）”这种复合指标。

　　关于杰文斯悖论是否成立，以及 Jev 系列模型的长期定位，我一直在向团队强调：无论新模型的能力多强，它都必须位于帕累托最优前沿上。这也是 Jev 品牌的核心立足点——在给定的单位成本下，提供最高的智能水平。

　　至于单位时间智能，我们会持续观察。这个方向确实很有潜力。很多行业对实时低延迟有极高要求，每秒能获取的智能直接关系到核心业务收益。

　　我们会观察市场的反馈，也希望能兼顾这两个维度，让市场的实际需求来进行检验，并持续听取一线的真实需求。

　　主持人：这不仅涉及实时交互，更关系到规模效应。当推理规模达到亿万级 Token 时，哪怕单次节省几微秒，累计起来都是非常庞大的数字。

　　Diogo Almeida：这取决于任务属于后台异步处理还是前台实时响应。如果是类似 MapReduce 这类大数据的后台批处理分析，系统对延迟并不敏感，关键在于以最低成本获得足够的智能。

　　但如果是面向终端用户的实时交互，在 100 毫秒乃至 1 毫秒的窗口内所能调动的计算预算，往往会带来质的差异。即便原本的延迟已经控制在 100 毫秒内，如果能进一步缩短一半，就意味着在同一时间窗口内可以调用两倍的推理能力，或是串联执行多次决策，从而显著优化用户体验。

　　业内目前已经有团队在进行这类探索，成果非常亮眼。虽然我很看好高频实时的应用场景，但这并非目前 Jev 最核心的定位。

　　主持人：市场上其他方案通常需要在速度与成本之间权衡，往往是“速度更快，但成本更高”。Jev 之所以受到广泛关注，在于你们切入了“速度更快且成本更低”这一相对空白的区间，同时还保持了模型的基本智能水平。

　　Diogo Almeida：在大幅降本提速的同时维持住智能水平，这正是最具挑战性的地方。

　　主持人：这引出了一个问题：如果你们不采用公开的基准测试（Benchmark），内部又该如何客观评估模型的能力是否得到了提升？

　　Diogo Almeida：我们内部有一整套专有的评估体系（evals）。但这需要极高的自律性，团队必须杜绝任何形式的数据粉饰，将客观诚实作为最高原则。如果不进行严密的内部评测，就无法确保模型在单位成本智能上始终处于帕累托最优前沿。

　　内部评测绝非盲目摸索。在尝试各种非常规架构和不同的成本配比时，我们需要科学的对比依据。我们会将每个方案的数据点绘制在坐标图上，精确测算哪一种配置能为终端用户带来最大价值。

　　因此，我们高度重视评估工作。我并不排斥度量本身，但一旦引入容易变形的外部激励机制，事情就会走向歧途。在这一点上，我对团队的要求极为严苛。在日常管理中我可能显得非常强硬，但在评估模型的真实能力时，绝不自欺欺人是我们必须坚守的基本底线，务必做到求真务实。

　　Noul、Choice 与 Score：将智能精准映射到底层编程原语

　　主持人：我想深入探讨一下你们 API 设计的具体细节，很少有访谈会涉及这么底层的技术问题。

　　你们定义了三大基础原语：Choice、Score 和 Noul。首先，Noul 这个命名是怎么来的？它是学术界的既有术语，还是你们自创的？

　　Diogo Almeida：现在它已经成为一个正式术语了。我们内部曾对这个命名有过激烈讨论。它在语义上类似于布尔值（Boolean），即 True/False。

　　主持人：但它输出的是连续概率值。

　　Diogo Almeida：它的命名其实源自数学家伯努利（Bernoulli）。

　　主持人：原来是这样。

　　Diogo Almeida：这也是为什么它的拼写看起来很特殊（Noul）。它是从“Bernoulli”中截取出来的字母组合，代表伯努利概率分布，这正是它的数学本质。

　　这就是它的由来。当时我们权衡了很久，备选方案有pbool、pool，我甚至提议过叫“pool party”，但被全员否决了。经过反复讨论，我们最终敲定了 Noul。

　　我们的思考逻辑是——这与 Jev 的命名过程类似——团队成员大都具有硬核的技术文化，而真正的开发者通常并不介意这种独特的命名。对他们而言，Jev 只是一个模型标识符字符串，我们最初完全没有预料到这个名字会受到广泛关注，甚至衍生出许多网络梗。

　　其实这个名字最初在公司内部也遭遇了不少反对。后来大家基本都认同了，除了一位——也就是我们的共同好友兼联合创始人，她当时坚持想把 Jev 命名为“Meow”。

　　主持人：这很符合她的个人风格。

　　Diogo Almeida：确实是她的风格。

　　我们之所以创造新词，是因为如果直接使用 bool 会给开发者带来很大误解。这三个原语全都是全新的概念，在现有的传统编程语言中并没有直接对应的原始类型。这是我们刻意做出的设计，因为它们虽然与传统类型相似，但在本质上存在差异。

　　Score 并不是传统的整数（int）。如果使用 Instructor 或 Pydantic 等库强行将 int 或 float 映射为 score，在工程实践中很快就会遇到瓶颈。在“准确传达本质”与“降低初期理解门槛”之间，我们坚决选择了前者。

　　主持人：你是否担心这会带来认知门槛？难道不想让它更顺畅地融入开发者现有的工具生态中吗？

　　Diogo Almeida：我们当然希望融入现有的生态，其实我认为……

　　主持人：你们有自己的 SDK，但从开发者关系（DevRel）的角度来看，通常会非常积极地去编写教程，比如“如何在 Instructor 中使用 Jev”。

　　Diogo Almeida：类似的内容我们在部分文档里应该已经提过了，不过我现在可能没有掌握所有具体细节。

　　主持人：社区自然会协助完善生态。只要产品本身足够优秀，大家就会认可它的价值。

　　Diogo Almeida：而且，我也从不把“成功”看作一个非黑即白的布尔值，它更像是一个 Score。在服务社区的过程中，永远有更高的目标需要达成。

　　谈到这部分我其实有些顾虑，因为最近文档更新很频繁，我还没来得及逐一核对。

　　Score 类似于大家常说的模型评估打分（LLM as a Judge），也可以称之为裁决打分，这是目前行业普遍的使用方式。Noul 则可以被视为一个置信概率，而在我们的体系中，万事万物本质上都是概率。

　　Choice 则最接近传统大语言模型中的函数调用（Function Calling）。但现有的函数调用在工程实现上不够简洁——这一点我们稍后可以展开讨论。Choice 才是将代码中类似switch或match的分支语义暴露出来的更规范、更合理的方式。

　　主持人：所以它能够直接映射为枚举类型（enum），需要的话，还可以在代码中将其进一步实例化为具体函数。

　　Diogo Almeida：枚举化的 Choice 正是核心所在。这三个原语实际上分别映射了编程中最基础的控制流：Choice 映射到针对枚举的switch语句，Noul 映射到布尔类型的if条件分支，Score 则映射到基于大小阈值的排序与过滤逻辑。

　　这一直是我们的核心愿景：未来会出现更多机器原生的新型数据类型，而它们都将精准地映射到底层的编程原语之上。

　　告别全局变量式的 System Message：将任务拆解为原子化决策

　　Diogo Almeida：可以看一下我们系统支持的数据格式——这里展示的是输出结构，但实际上在输入端，无论是系统状态（state）、执行指令（instructions），还是评判标准（criteria），都可以组织为结构化的 JSON 对象。

　　这样一来，程序可以直接将对象传入对应的字段中，无需再去手动拼接繁琐的字符串模板。

　　许多人尚未完全理解这种设计的用意，依然习惯传入普通的文本字符串。当然传入字符串依然可行，但从设计初衷来看：如果依然依靠字符串拼接来构建庞杂的 System Message，说明开发模式尚未转变过来。

　　我们应当以计算机最易于解析的方式来组织数据，因为实际业务场景中的数据本质上就是高度结构化的。在现代编程实践中，如果把数字或状态拼接成字符串在各层之间传递，显然违背了工程规范——通常只有在最后需要向用户展示结果时，才会将其转为字符串。

　　在系统内部流转时，始终应当传递具有明确语义的嵌套结构。我们的模型专门针对这类结构化输入进行了深度优化。当然，嵌套层级越深，推理难度就越高，我们目前也正集中投入工程资源在此方向上进行持续攻关。

　　建议大家采用这种思路，它能让代码更加清晰简洁，同时也能彻底解耦应用层逻辑与底层大模型的具体实现。

　　开发时的逻辑应当是：确定当前的系统状态与函数状态，将其视为一个标准的“AI 函数”，进而思考应该向其传入状态数据的哪一个子集。

　　传统的 System Message 往往被当作一个庞大的全局变量来使用：开发者将所有上下文和业务规则一股脑堆叠进去，期望模型能够一次性完美遵循所有指令。但更合理的做法，是将它拆解为多个并行的、结构化的子任务。

　　此外，建议将任务充分拆解为一系列细粒度的子任务。这并非为了增加 API 调用量，而是强调应当将复杂问题细分化、轻量化，做到彻底的解耦与细化。

　　无论现阶段模型的综合能力达到何种水平，我认为本次发布最重要的价值在于：它将推动 AI 应用开发的工程质量得到显著提升。

　　当把宏观任务拆解为具体的原子化决策后，每一个环节都具备了高度的可评测性（eval-able）。以往在开发 AI 应用时，常见的做法是先编写极其冗长的 System Message，随后再引入另一个庞大的模型去审核输出是否违背了约束。这种做法本质上是低效且本末倒置的工程妥协。

　　例如限制系统“禁止访问特定子目录”或“严禁向外部接口泄露 API Key”，这类硬性约束在工程体系中本就应当通过确定性的代码逻辑来提供可靠保障。

　　通过细粒度的原子化拆解，系统内的每一次决策都变得可观测、可度量，且输入输出均具备确定性的接口规范。这不仅能大幅降低工程维护成本，也必然会构建出更健壮、更可靠的软件系统架构。

　　主持人：我理解这种思路。过去之所以很少有人采用这种方案，是因为受限于早期模型的响应延迟与高昂成本，将所有业务逻辑打包放入一个统一的 Prompt 中反而是性价比更高的选择。我之前也构建过类似的架构：通过一条链路将所有信息灌入 System Prompt，一次性生成完整结果；在当时如果拆分为上百个微小决策，不仅延迟与开销不可接受，最终的综合效果也未必更好。

　　Diogo Almeida：过去由于工程手段受限，实现方式非常繁琐且沉重，强行将逻辑揉杂在一起不仅效率低下，而且系统的最终输出稳定性也难以保障。

　　更关键的是，那种架构根本无法在后台稳定、静默地执行。如果模型无法作为可靠的基础设施在后台平稳运行，那便失去了我们这项系统设计的核心意义。

　　像 Debug 传统代码一样修复 AI 缺陷：置信度与模型级联

　　主持人：既然提到了任务拆解，你们团队摸索出的最佳实践是什么？哪些方法切实可行，哪些设想在实际中行不通？既然你公开推荐这种模式，大家往往会将其视为准则。具体应该如何拆解？

　　Diogo Almeida：这是个很好的问题。我的做法是将业务拆解为最小的语义单元：最底层、最原子的逻辑到底是什么。

　　我大概是调用我们模型次数最多的人。在我的实践中，首要原则是：在构建请求时，必须保持高度的结构化与显式定义。在提问时，我习惯用反引号标注变量，但这同样适用于所有字段。

　　必须让模型完全明确你的指代对象。我们需要模型具备极其精确的字面理解能力。在编程领域，核心是对指令的确定性执行，这是编程的本质，而 AI 只是拓展了可程序化执行的指令边界。

　　因此我极力推荐这种方式。虽然有时我也会图省事混写逻辑，但在严肃的生产环境中，正确的做法是不断拆分出独立的问题，并尽可能降低追加调用的成本。将每个维度拆解至足够精确，再由上层业务逻辑去实现预期的行为。

　　以安全拒答为例。处理拒答场景时，不应直接询问模型：“遇到这种情况是否应当拒答？”虽然直接提问的效果尚可，毕竟这类任务符合“系统 1”的直觉认知特征。

　　但更有效的方式是：针对触发拒答的各个独立维度，分别发起多次独立的提问。

　　这样模型无需自行推测全局意图，每条规则的边界都能明确定义。这种方式的优势在于，它完全契合传统的软件工程逻辑：如果在生产环境中发现模型在某类场景下未能正常拒答，排查后会发现只是遗漏了特定维度的判定。

　　这便是典型的调试（Debug）过程。

　　修复这类问题的方式非常简单：在工作流中增加一个针对性的判定问题，设定好置信度阈值，并将其纳入单元测试用例，该问题便得到了确定性解决。系统不会因为上下文退化（context rot）而在长 Prompt 中遗忘这条规则。它成为了一道可被持续监控的明确防线。

　　即使模型在某些边缘维度上的表现不够完善，也可以基于实际业务样本，为每个维度单独设定阈值。这相当于无需从头训练机器学习模型，便能获得相应的能力，并无缝集成到业务逻辑中。

　　显然，目前仍有一些复杂任务是模型无法胜任的。例如，看到有人尝试用我们的模型进行全自动量化交易时，我通常持保留态度。尽管这类尝试很有吸引力，但面对高度宏观、高维度的任务，当前模型的能力尚不足以胜任，更适合交给专业系统。

　　但如果将任务拆解并独立验证，就可以清晰地评估：“模型在这一环节的能力尚不成熟，当前版本可以先不上线该子模块”，或者采取更保守的回退策略；

　　再比如，“模型在识别‘针对特定客户的隐晦讽刺’等微妙语境时可能不够稳定，那么当置信度处于模糊区间时，系统可以直接将工单转交人工客服处理。”这正是输出概率与置信度校准的核心价值。

　　主持人：这解释得很清楚。顺着这个思路，我想提一个很现实的问题，或许涉及一些敏感细节……

　　Diogo Almeida：你认为我会有所保留？

　　主持人：倒不是这个意思。核心问题在于，用户目前唯一的调优手段就是调整阈值。但如果模型本身的校准存在偏差呢？虽然你们强调校准效果很好，但是……

　　Diogo Almeida：我从未声称它是完美的，确实没有。

　　主持人：良好的校准意味着数值能准确反映概率高低。但模型在特定局部仍可能出现失真或对齐偏差。在这些情况下，开发者自然会倾向于使用微调（Fine-tuning），但你们目前并不支持该功能。

　　当前的局限在于：一旦模型在某个具体问题上持续判断错误，责任往往会被归咎于开发者的使用方式不当（skill issue），迫使他们不断修改 Prompt、进一步拆解任务或调整阈值。如果模型始终无法给出正确结果，这种排障体验会令人受挫。

　　Diogo Almeida：坦白讲，模型目前在很多场景下确实会出现错误。我们有专门的反馈渠道，用户也可以在 Discord 中直接提出批评，我们的目标始终是持续优化模型。每个新版本的发布都伴随着显著的性能改进；如果无法实现有实质意义的提升，我们也不会维持目前的高频迭代。

　　首先，这个质疑非常合理，正视 AI 当前的局限本身就是一种务实的态度。但我坚信，在许多实际场景中，模型已经具备了足够的胜任力，而这种胜任力取决于具体的业务定义。

　　人类在工作中同样会犯错，但依然能承担大量现实工作，原因在于整体决策的期望收益（EV）是正向且充足的。配合合理的阈值控制与架构设计，即使模型偶尔出错，也足以支持大规模业务流程的自动化。

　　关于是否支持微调，从长期来看是有可能的。但我对此确实存在深层疑虑：在“用户以为需要的”和“业务实际需要的”之间存在差距。通用模型具备一种独特的通用泛化特性。

　　正是在海量异构任务上的预训练赋予了它极强的泛化水平，使其能够在特定垂直场景的边缘特例中依然游刃有余。盲目微调极有可能破坏这种基础泛化能力，这是我非常审慎对待的一点。

　　因此，微调可能会列入未来的规划路线中。在工程实践上我追求实用，只要切实有效的功能都会考虑；但另一方面，我们绝不希望仓促推出一个容易给开发者带来隐患（footgun）的特性。

　　主持人：OpenAI、Anthropic 以及 Google（Gemini）此前都曾大力推广过微调服务，但后来相关功能要么逐渐边缘化，要么停止维护。目前微调在很大程度上已经成为开源模型生态的主要领域。

　　Diogo Almeida：当时那些微调服务的使用体验并不理想，下线对开发者而言反而是件好事。

　　主持人：那些功能确实容易产生反效果。明确告知用户微调在很多场景下并非最优解，其实是一种负责任的做法。另一种观点认为，或许你们的模型机制本身就足够特殊——正如量化和基于 Token 的生成机制不完全适用于你们一样，微调在你们的体系中可能也不是必要路径。

　　Diogo Almeida：对于这种可能性我持开放态度。这并非承诺，而是一种构想，我也倾向于提前明确边界。

　　随着单位算力与智能成本的持续下降，我们能够构建体量极小但判定精确的专用 Agent。未来可能会出现这样的场景：工程师不再需要手动编写复杂的正则表达式（regex），因为调用一次底层 AI 模型的成本，已经低于维护复杂正则的心智负担。若能实现这一点，将是工程效率的巨大飞跃。

　　不过，要彻底解决极端垂直的长尾场景，未来或许依然需要某种形式的微调来跨越可用性门槛，这需要时间验证。

　　就目前而言，我更倾向于依赖精准的概率校准以及模型级联（Model Cascading）机制：当轻量模型输出极高置信度时直接采纳其结果；当置信度处于模糊区间时，动态路由至更大型的模型处理，形成分层的级联调用链。这条技术路线值得期待。

　　我还设想过更长远的架构：假设拥有一系列覆盖完整帕累托最优前沿的不同尺寸模型。部分开发者可能倾向于手动权衡模型选型，但企业级场景通常更需要动态、自适应的调度系统。在技术架构的不同层级，系统可根据任务复杂度自动分发给相应规模的模型；甚至依托纯粹的底层原语，在系统后台对这些工作流自动执行隐式的自适应微调。

　　当然，这仅代表一种前瞻性的技术设想，并非确定的产品规划。

　　所谓的文化，就是在得不到市场即时反馈时依然坚持

　　主持人：但你们确实在考虑推出不同参数规模的 Jev 模型，以满足不同层次的需求？

　　Diogo Almeida：当然。我不可能预先替所有人框定他们究竟需要多高水平的智能。

　　主持人：人们对算力的需求是无止境的。

　　Diogo Almeida：目前有人建议我们放缓发布节奏，认为“现有的成果已经足够好，可以先歇一歇”。我认为这种想法过于保守了。

　　我很认同这样一句话，也希望大家未来能用它来监督我，避免我偏离初衷：“所谓文化，就是在市场尚未给予回报时，你依然选择坚持的事。”

　　这个定义触及了本质，因为我们有自己的原则和信念。也许很久以后，我们所坚持的理念会变得司空见惯，而我们也可能演变成像 Visa 那样普通却不可或缺的基础设施，不再引人热议，我也换上了普通的西装，不再穿亮粉色。

　　但在现阶段，我希望能激发更多人的想象。我们坚持去做那些真正有突破性的事，不仅是因为自身使命，更是想让大家意识到：眼前的一切不过刚刚开篇。

　　这次发布甚至谈不上正式发力，充其量只是一个初步的研究预览版，未来还有巨大的探索空间。机器原生智能所蕴含的潜力，必将超出所有人的预期。

　　主持人：也就是说，不仅模型尺寸会有多种选择，未来的形态也不拘一格。你们试图打破现有的思维定势。

　　Diogo Almeida：远不止于此。我们的核心是尽可能契合真实的工程落地需求。

　　但必须明确一个前提：我们绝不会像某些团队那样，毫无方向地推出各种试验品去碰运气。我们的一切行动都必须服务于统一而清晰的愿景。如果查阅我们的发展路线，你会发现所有的探索都严格依托于我们设立的三大核心支柱。

　　我们的规划分为三个阶段。虽然听起来像在描绘远景，但我们所有的研发都在围绕这三个方向推进，不断拓展边界。这不是为了完成任务清单而做表面工作，而是我们坚信能够奠定下一代技术基石的核心框架。

　　我们未来的每一次核心投入都会契合这张蓝图。在模型架构层面，我们会尝试一些极其前沿甚至反常规的设计——因为它是机器原生的。人类终端用户是否能够直观理解并不重要，关键在于它能否为软件系统带来不可替代的核心价值。

　　主持人：能稍微透露一点，你所说的“反常规”具体指什么吗？

　　Diogo Almeida：可以提供一点思路。目前外界倾向于将我们归类为“决策模型”，尽管我们当前的底层原语确实涉及决策逻辑，但我绝不认同用“决策模型”来概括我们的全部潜力，因为许多更纯粹的机器原生形态，其核心定位完全不在于“决策”。

　　主持人：这个悬念就先留给听众自己思考。

　　Diogo Almeida：保持这样的期待感很有意义。

　　主持人：业内确实有一些质疑声，认为这种方案并不新鲜，无非就是某种分类决策机制。但我认为核心在于，你们建立了一种全新的范式；退一步讲，单从基准评测和实际运行数据来看，你们在效率和表现上也显著拉开了与同类模仿者的差距。

　　Diogo Almeida：我想再次重申，我从不在意那些公开评测榜单。无论最终评分领先与否，我都并不认可这些评测本身的指导意义。

　　主持人：你们开拓了这一领域。但我认为，将传统的“决策模型”与更底层的“系统 1”思维区分开来，才是你真正希望向业界阐明的核心观点。

　　Diogo Almeida：正是如此。我的终极目标，是通过 AI 为软件工程师提供前所未有的强大赋能。

　　最令人遗憾的，正如我之前谈到的潜在行业危机：AI 蕴含着如此庞大的潜能，却往往被局限在一些无足轻重的边缘场景中消耗殆尽。这确实让我感到非常遗憾。

　　我并非盲目的技术乐观主义者，不会认为只要贴上技术标签就一定是好事。我认为过去几年整个行业的发展路径存在很大偏差。我真正想做的，是打破这种局限，为开发者开辟出具有广阔应用潜力的全新路径。

　　这个话题先聊到这里吧，这几天我为此倾注了太多的情感，可不想在录音机前显得过于激动。

　　让 AI 退居软件幕后：五年内拉动 3% 的全要素生产率

　　主持人：感谢你的分享，能感受到你对此充满激情。

　　坦白说，仅看“TypeSafe AI”这个严谨的名字，外界很难联想到背后的愿景是如此宏大。但只要深入了解你们对未来的构想，并看到你们确实完成了从 0 到 1 最艰难的突破，大家就会愿意认同并追随这个方向。

　　Diogo Almeida：我目前还不敢断言最困难的阶段已经过去，未来的挑战只多不少。

　　只有当各行各业的核心业务真正实现顺畅自动化、切实拉动全球 GDP 增长，乃至引发全行业的 Jevons 效应（反弹效应）时，或许才能说跨过了难关。但目前为时尚早。

　　我认为业内目前过度关注速度和成本，却严重忽略了可靠性。坚如磐石的可靠性不仅能带来卓越的用户体验，更是让企业放手托付业务的核心前提。

　　主持人：你们在宣言中明确提出：“要在五年内推动全要素生产率（TFP）增长 3%。”在 AI 实验室中，几乎没人会把这类宏观经济指标直接作为目标。

　　Diogo Almeida：这是理所应当的，因为这才是真正意义上的经济变革。

　　这与当年《OpenAI 宪章》（OpenAI Charter）的初衷高度一致。宪章最初也表达过类似的宏愿——尽管字面表述或许未变，但如今其目标似乎已被悄然置换为“实现 1000 亿美元利润”这类商业诉求。我并非刻意批评 OpenAI……

　　主持人：当时对于 AGI，确实缺乏精确的量化标准。

　　Diogo Almeida：他们曾尝试给出过定义，即“能够将绝大多数具有经济价值的工作实现自动化”。

　　既然如此，就必须直面一个问题：既然模型已经有能力尝试千禧年数学大奖级别的难题，为什么在人类最具经济价值的实际业务中，自动化率依然无限接近于零，甚至达不到统计学上的有效值？

　　客观来看，目前全行业所有大模型在真正创造经济价值的自动化任务上，实际产出基本为零。我们或许迈出了一小步，但即便算上我们，整体渗透率也难以企及 1%。但我确信这一指标终将迎来突破。而一旦发生质变，它必然会直观地体现在宏观经济数据中。

　　这不会导致大规模失业，反而会推动产业范式的深层升级，使整个社会的生产力大幅提升。

　　此外，我不赞同让 AI 始终在前端占据视觉中心。更理想的软件体验应当是自然顺畅的，AI 理应隐入幕后，提供底层支撑。

　　主持人：就像水和电一样，作为基础设施彻底融入软件的底层。

　　Diogo Almeida：回想 2019 年，当时的现代软件与 SaaS 服务本身就已具备巨大的商业价值。

　　如今已是 2026 年，除了在界面旁附加一个对话框之外，整体软件形态与数年前相比几乎没有本质变化。底层的 AI 能力已极其强大，但上层应用却停滞不前。

　　对话框固然有其用途，但企业绝不敢让它参与任何涉及核心利益的关键决策，因为目前的模型尚不足以承担这种严肃的信任。这种脱节是不合理的。

　　这里蕴藏着巨大的商业潜力。我认为传统 SaaS 行业将通过这次变革迎来重塑。SaaS 厂商最清楚自身业务中哪些环节具备自动化的最高价值，整个行业也必将因此迎来新一轮的增长周期。

　　系统 1 的直觉与系统 2 的局限：慢推理并非万能解法

　　主持人：这是一个非常深刻的切入点。

　　你刚才提到了一个核心划分：究竟什么是“系统 1”问题，什么是“系统 2”问题？现在的行业趋势是试图将所有业务都交给 Jev 处理（即所谓的“Jev everything”）。盲目套用在很多场景下难免受挫，但在特定场景中它的表现又极其出色。

　　Diogo Almeida：“把一切都 Jev 化”这个说法很有意思。

　　从本质上讲，这完全是一个经验工程问题，就像 Scaling Law 本身也是一种经验法则一样。投入了如此巨大的资金，当下的机器人领域为何仍未迎来根本性的质变？这并非单纯依靠持续增加资金投入就能解决，很可能是我们尚未找到关键的技术突破口。

　　从经验来看，经过海量预训练、高度凝聚了人类知识的智能模型底座，在底层机制上天然契合“系统 1”的快速直觉模式。用“系统 1”来界定当前大语言模型（LLM）最具优势的能力范畴，是最准确的表述。

　　RLVR（强化学习形式验证）在系统 2 的慢推理层面取得了显著进展，这一成果确实令人赞叹。我并不认为这会引发所谓的 AI 灭绝危机——当然概率并非绝对为零，断言 0% 本身就不符合科学的概率校准——但他们在学术前沿取得的进展确实令人瞩目，将能力边界推向了极高的水平，尽管他们自身可能认为这尚未触及极限。

　　然而，迫使模型采用这种慢推理模式，在机制上并不自然，模型在这一范式下的表现也展现出极高的脆弱性。

　　回顾 ChatGPT 最初问世时外界的反馈：“它的通用性很强，能够应对各类宽泛对话，但在面对复杂数学题或 GSM8K 这类基准测试时却表现不佳。”

　　反观如今人们对强化推理模型（RLVR）的评价：表现过于脆弱，能力边界极不均衡（jagged）。为何它能解决难度极高的高阶数学竞赛题，却会在基础常识逻辑上出错？因为数学逻辑不仅认知门槛高，还具有类似分形结构的自相似复杂性。

　　若对这几种训练范式的核心目标进行拆解：

　　RLHF（人类反馈强化学习）的核心在于“迎合人类偏好”，这是其反馈机制的设计初衷；

　　RLVR 的核心在于“针对基准测试进行最大化提升”，因为能够纳入 RLVR 框架的任务，在定义上都属于可形式化验证的基准测试；

　　而 RLCD 的核心目标始终只有一个：为程序调用提供极高可靠性的确定性。

　　主持人：分享一下我的观察，若有偏颇请指正。我一直在关注多跳推理（Multi-hop Reasoning）的表现。在单跳（Single-hop）决策场景中，Jev 的表现极其出色，几乎是目前行业的最优解，在类似场景下很难找到替代方案。然而，一旦进入多跳逻辑链路，随着推理步骤的增加，模型的准确率似乎呈现出持续递减的趋势？

　　Diogo Almeida：这再次回到了工程经验的问题：关键在于我们能在多大程度上挖掘模型内部的潜能。我们的目标，是在不引入负面效应的前提下，最大化释放其固有的智能。

　　可以将我们的角色理解为：对原始的智能内核进行解耦、平滑处理与精细优化，同时弥补其短板并赋予新能力。随着技术演进，我们会逐步消除这些能力盲区。

　　但客观事实是，我们所做的是“发掘既有特性”的工作。这些特性的上限，完全取决于这些高度压缩的内核本身蕴含了什么，我们的工作是将它们梳理重构成一个更完善的整体。

　　我们致力于最大化释放模型的能力，而“系统 1”恰好是对当前有效规律最精准的概括。在这一范式下行之有效的所有机制，都具有鲜明的系统 1 特征。

　　这也是我们没有选择所谓“隐式推理（latent reasoning）”路径的原因——即在文本序列中生成冗长的思维链（CoT）。模型真正擅长的，是在权重表征层面内部完成并行推理，尽管这项能力目前仍有提升空间……

　　主持人：稍等，你将文本序列中生成思维链称为隐式推理？我通常理解的隐式推理是指在模型隐藏层权重内部进行的推理。

　　Diogo Almeida：业界过去常将后者称为连续推理（continuous reasoning），各方对术语的界定不尽相同。此前之所以称之为“latent（隐式/潜在）”，是因为早先各家机构将思考过程（reasoning traces）对用户完全隐藏，对最终输出而言，它就像一个隐变量（latent variable）。

　　如今对隐藏的定义有所调整，不过对 OpenAI 和 Anthropic 而言，核心的推理轨迹依然未向外界公开。

　　主持人：这意味着你们不会考虑推出具备深度推理链的 Jev？因为这与系统 1 的定位相违背。

　　Diogo Almeida：我们的宗旨是：为机器原生场景提供极致的交互体验。未来我们完全有可能考虑引入更快速、更高效且鲁棒性更强的轻量推理形态。

　　在工程上我始终保持务实：不会在具体的算法路径上自我受限；我们唯一坚守的指标是投资回报率（ROI），并以此为基准持续推进。在这个技术周期中，我们依然在全力争取确立自身的行业生态位。

　　保姆式干预还是生产力工具：在用户预期与底层技术规律之间寻找平衡

　　主持人：另一个关键领域是计算机视觉（Vision）。这项能力非常强大，但你们目前尚未接入。视觉能力在未来有可能属于系统 1（System 1）的范畴吗？

　　Diogo Almeida：我认为我的视力还算正常。

　　主持人：我是指计算机视觉技术。

　　Diogo Almeida：在我看来，一切皆有可能。

　　实际上，我们内部一直在深入探讨一个问题：我们究竟该在多大程度上坚持打造我们坚信具备长期价值的产品（正如我们在过去两年封闭研发时所做的那样），还是直接顺应用户当下表达的需求？

　　这背后涉及诸多维度的权衡。上下文长度（Context Length）就是一个典型案例。对于市面上的所有模型，包括我们自己的产品而言——尽管测试表明，我们的模型在长上下文场景下的性能保持能力显著领先于行业——但其他厂商的做法往往是：既然市场有超长上下文的需求，那就盲目堆砌这项参数直接推给用户。

　　我们需要在两者之间找到最佳平衡。如果走向“由我们替用户做主”的极端，产品就会滑向类似 Anthropic 那种典型的“保姆式（nanny-state）”干预风格，这违背了开发者的实际诉求；

　　真正面向开发者的路径应当是：为他们提供顺手、可靠的工具，而不是将理解底层技术复杂机制的心智负担转嫁给开发者。

　　因此，我们在版本发布节奏上始终保持克制与审慎，既要维护开发者对我们专业性的信任，也要把用户视为具备独立决策能力的成熟个体，避免在技术之上附加主观的过度干预。

　　主持人：这个观点很中肯。

　　Diogo Almeida：坦白讲，我们目前也没有定论，仍在摸索。这大概会是未来几天内部讨论最密集的议题。这次发布引发的关注远超预期，我们必须紧锣密鼓地筹备后续迭代。

　　主持人：我见证了你的投入。认识你这么久，我从未见过你在过去两个月里展现出如此高度集中的专注状态（locked in）。

　　Diogo Almeida：这也得益于我的幕僚长一直在推着我往前走。

　　我原以为自己工作已经足够拼命，但事实证明还有提升的空间。

　　主持人：你当时甚至抽空参加了我们的写作训练营，我那时还在想你怎么可能有时间过来。看得出你对这次发布经过了深思熟虑，每一步都执行得极为坚定，事实也证明成效显著，由衷恭喜你。

　　Diogo Almeida：非常感谢。我们会一直保持这种全力以赴的状态。我们已经攻克了技术演进中的几个关键节点，但前方仍有更具挑战性的目标。能够为真正有价值的方向倾注心血，确实令人感到振奋。

　　告别概念 Demo：四大应用支柱与“暗数据”金矿

　　主持人：在转向更宏观的讨论之前，我想最后问一个关于 TypeSafe 的问题：在这次发布的内容中，你认为有哪些地方被外界严重低估或误读了？例如你们在文档中提到的一系列架构范式：投机式扇出（speculative fan-out）、置信度门控路由（confidence-gated routing）、复合评分机制（composite scoring）、模型锯齿效应……

　　Diogo Almeida：关于被低估或误读的地方……让我想想。其实每一项我都能展开聊很久，但这里还是聚焦重点。

　　我想强调的是：我们在实战手册（Cookbooks）中投入了大量心血，里面的内容非常扎实。我们曾考虑过直接将这些内容放进发布博客中，但那样会让文章显得过于冗长和技术化，更偏向核心极客受众。

　　在正式发布前，我们所介绍的方案在外界看来可能非常小众，甚至让人费解：“为什么会有人需要这种方案？”我们当时非常担心市场教育会成为主要阻碍。

　　但从目前的反馈来看，这已经不再是问题。社区展现出的创造力完全超出了我们的预期，开发者构建的用例甚至比我们内部设想的更为出色。比如一系列基于电脑操作（Computer Use）的项目就非常亮眼。

　　我们在实战代码库上倾注了大量精力。据我所知，里面没有任何粗制滥造的 AI 生成代码，每个案例都源自我们协助真实客户解决生产环境复杂问题的积累，凝聚了扎实的工程实践，旨在帮助他们构建可靠的生产级能力。

　　主持人：你们在正式发布前做了多少验证？整个内测过程是怎样的？最初收到的反馈如何？

　　Diogo Almeida：最初的情况如何？坦白讲，最早的外部反馈并不理想。

　　团队中非技术背景的成员一度非常担忧：“似乎没人理解这个产品，市场真的需要它吗？我们做的到底是一个可有可无的辅助工具，还是不可或缺的刚需方案？我们是否需要招聘大量前线部署工程师（FDE）来为客户定制配套软件以解决问题？”

　　在正式发布前，我们几乎没有商业收入。技术团队对此深信不疑，我们清楚这套架构在计算效率和工程表现上具有压倒性的优势，坚信它一定会获得市场认可。

　　但我个人当时确实承受了巨大压力。最常见的情况是：早期试用者中有一半以上完全摸不着头脑；而少数真正理解其价值的人，第一反应则是：“这套架构非常出色，但我们该如何走完内部的法务和采购流程来引入它？”

　　那段时期确实充满挑战，但我们始终坚持一个判断：核心受众是一线开发者，只要开发者发掘出真正的应用场景，行业就会迅速跟进。

　　我并不想事后去评判那些态度转变的人，也不想重新定义所谓的“产品市场匹配（PMF）”。在发布前，同样的产品摆在那里，当我们询问“是否愿意使用”时，对方的反应多半是“不确定这能否解决当前的问题”。

　　然而一旦公开发布并引发关注，同一批客户的态度迅速转变为：“能否为我们提供更高的调用额度？我们的算力需求已经饱和，甚至可以直接提供闲置的 GPU 资源。”

　　市场推广确实起到了催化作用，但我认为更深层的原因在于：它在广大一线开发者群体中引发了强烈的共鸣，进而带动了整个外围市场的认知转变。

　　我由衷希望公司能始终对一线开发者保持感恩，绝不走那种“靠开发者生态起家，壮大后便转向只迎合企业采购流程，逐渐忽视独立开发者”的老路。

　　我甚至在思考：我们能否推出一些专门针对独立开发者、甚至在某些方面优于企业版的功能？如何才能真正为他们提供助力？

　　我有一些在商业常规看来有些反直觉的想法，但这正是我向社区表达谢意的方式。这也是为什么我昨天去染了头发——在公司发展的重要节点上，如果不深入社区与开发者站在一起，我会觉得有违初衷。

　　主持人：请大家以此为证，共同监督。

　　Diogo Almeida：请大家随时监督。我始终坚持这一原则。欢迎记录下这番话，如果未来我违背了承诺，随时欢迎大家来追责。

　　主持人：别人在宏大叙事，而你们在专注于具体的生产力工具。

　　Diogo Almeida：与我对追求基准刷榜持保留态度类似，我本质上对各类概念演示也比较谨慎。我更关注方案能否在生产环境中稳定可靠地运行。不过看到社区做出这样的探索，依然令人印象深刻，其创意毋庸置疑。

　　我期待看到它真正落地，也希望团队能深入测试，找出其脆弱环节并彻底解决。刚才的演示确实很有吸引力，我也很想使用这样的工具——比如在写代码手腕疲劳时，能够完全通过语音高效完成操作，体验会非常理想。

　　主持人：有哪些主动接洽的大型企业？他们提出的应用需求中，有哪些出乎你的意料？

　　Diogo Almeida：商务合作这块我没有直接参与。不过同事同步给我的客户信息显示，主流的大型科技企业基本都已经在接触我们了。

　　主持人：这有助于为大型企业受众提供一些具体的对标参考。

　　Diogo Almeida：概念演示确实引人注目，但从实际落地来看，代码智能体（coding agents）显然是当前最主要的方向，这一场景的需求非常旺盛。

　　主持人：例如 Cognition（Devin 母公司）目前就在高频调用 Jev。

　　Diogo Almeida：关于代码智能体，我可以稍微展开谈谈吗？

　　主持人：请讲。

　　Diogo Almeida：我来梳理一下我们在发布前基于第一性原理推导出的几大核心应用场景方向：

　　第一类是我们所说的暗数据（Dark Data）：许多大型企业沉淀了海量的数据资产，但在以往很难用传统大语言模型进行全面处理，因为推理成本过高。企业对这类能力的需求非常迫切，面对庞大却难以有效分析的数据资源，Jev 的成本效益能够很好地满足数据科学家的需求。暗数据处理与代码智能体结合，是目前体量最大、商业价值最集中的领域。

　　第二类是高频实时场景（Real-time）：即将模型推理深度嵌入系统核心循环的业务。相关企业的管理层和技术负责人普遍非常清楚，每降低 10 毫秒的延迟，都能为终端产品体验带来显著的改善。

　　主持人：尤其是在电商领域。

　　Diogo Almeida：以及各类助理型产品，相关开发团队给出的反馈都很积极。

　　我个人也非常期待它在游戏领域的应用，例如策略类自动对战游戏或半自动化战棋游戏，玩家能够用自然语言策略直接指挥 NPC 军团。这种体验如果做出来会非常有深度，当然，也希望开发者们留给人类一些操作空间。

　　第三类是我们称之为全面验证（Verify Everything）的场景：对传统大模型的生成结果进行毫秒级的质量校验，类似于深度的系统可观测性。

　　这里可以补充一个文档中提到的成本优化技巧：在我们的架构下，并发查询的成本极低。如果你需要对一段庞大的上下文状态进行多维度质检，最佳实践是为每条消息标注 ID，随后针对各个 ID 并行发起独立的判定请求。这样只需为该上下文状态支付一次计算成本，即可同时完成数十甚至上百次细粒度检查。这是一个非常高效且节省成本的实践方案。

　　主持人：这让人联想到系统 1 与系统 2 的协同机制：按照这个逻辑，未来每进行一次重量级的慢思考推理，其背后或许都需要搭配 1 次、10 次甚至上百次类似 Jev 这样的快速决策调用。

　　Diogo Almeida：确实如此，甚至可以进一步优化成本：如果将慢思考模型的调用频率降低一半，转而搭配 10 次 Jev 进行快速验证与决策，就能以更低的综合成本解决以往难以落地的工程问题。

　　第四类应用则是我所定义的智能软件（Smart Software）：这类新型软件原生具备极高的可组合性，能够实现过去难以想象的特性。例如，有开发者直接将 Jev 作为某种编程语言的控制原语——那个项目的构思非常精妙。如果未来我们的底层基础设施容量足够充裕，我非常乐意为这些充满探索精神的开源项目提供充足的算力支持。

　　摆脱单一模型与 KV Cache 的束缚

　　Diogo Almeida：coding agents 的爆发完全出乎我们的预料，其演进速度非常惊人。在这个领域，目前正在发生一件非常值得关注的事情：

　　Claude Code 和 Codex 普遍被视为处于行业前两位的代表，我没有密切跟进所有进展，但大体是这个格局。然而，它们的底层架构完全是围绕“单一模型的世界（single-model world）”构建的。

　　在过去这很合理，因为此前整个行业的主流范式就是单一模型，大家无非是在同一家厂商的不同能力档位之间进行权衡。

　　但现在，开源 coding agents 团队都非常兴奋，因为他们终于可以把 Jev 接入进去了。目前市面上所有 coding agents 的架构在本质上大同小异，一个while循环里能做的事情其实很有限。但只要有团队率先利用 Jev 的组合能力打造出极致的体验，整个行业的关注度和用户就会迅速向他们聚集，从而形成显著的竞争壁垒。

　　开源生态内部可以迅速相互借鉴并复现这套方案。我很想看看 Claude Code 和 Codex 会如何应对，因为他们目前仍局限于单一模型的范式中。这必然会演变成一场非常精彩的博弈。

　　就我个人而言，我非常希望能与他们展开深度整合，与所有人合作。作为底层软件基础设施的提供方，我们不应该在生态上带有任何倾向或偏见，我们的目标是为整个行业提供服务。

　　这会让 coding agents 的竞争格局变得格外有趣。目前团队正在评审我写的一份内部技术备忘录，里面总结了我推导出的、可能适用于 coding agents 的全新设计模式，希望今天晚些时候就能公开发布。如果不是因为管理这家公司脱不开身，我非常希望能亲自下场去研发 coding agents。

　　主持人：我相信各大 coding agent 团队同样很想和你交流。而且我也认为，Claude Code 和 Codex 完全有空间接入你们的技术。

　　感谢你分享了这么多细节，确实非常坦诚。我们暂时跳出 TypeSafe 本身，来谈谈更宏观的行业议题——你在安全与对齐上的立场已经表达得非常明确了。

　　Diogo Almeida：我刚才谈到安全对齐了吗？我好像还没详细展开过。

　　主持人：你之前提过。而且每次像 NeurIPS 这样的顶级学术会议，你都会和大量前沿学者深入交流。目前业内核心研究人员重点讨论的到底是什么？

　　例如我最近参加了一场头部研究员的小范围聚会，大家对当前技术的演进速度表现出普遍的担忧，甚至在严肃讨论“是否应该放缓研发节奏，因为公众和监管显然还没做好准备”。我很想听听你对这种“放慢前沿演进步伐（pace the frontier）”的论调怎么看。

　　Diogo Almeida：这个话题在业内算是敏感议题吗？我很愿意探讨，我并不避讳这类有争议的讨论。

　　我们公司的核心基调本来就是接纳混乱（Chaos），而不是固步自封；我们的特质就是不拘泥于既定规则，敢于打破常规。

　　主持人：当年在 OpenAI 经历那场管理层变动（blip）的风波时你就在现场。后续引发了一连串连锁反应，以至于今天几乎所有头部前沿实验室都联名签署了关于控制研发节奏的承诺文件。

　　Diogo Almeida：这很有意思。这是一个非常复杂且充满各方权衡的议题，我其实一直想写一篇严谨的长文来深入阐述。

　　我可以先简要说明我的核心观点：当前大家在 RLVR（基于可验证奖励的强化学习）方向上投入越来越大，但 RLVR 的本质从来不仅是“可验证奖励”本身。事实上，早在这一轮推理大模型爆发之前，这一路径就已经多次遇到瓶颈了。

　　回顾一下行业早期的技术历程：在 RLHF 刚起步时，后来被称为“后训练（Post-training）”的技术路线内部其实分为三个截然不同的方向。而当时，“指令遵循（Instruction Following）”绝对是其中最不被看好的边缘方向（bastard child）。当时大家并不重视它，不愿意投入精力，认为它繁琐且缺乏技术美感。

　　我当时和预训练团队沟通，告诉他们这个方向蕴含着巨大的潜力。但他们的反馈是：“我们每次做超参数扫描需要测试成百上千个模型，难道每筛选一个模型都要等待人工评估（human evals）的结果吗？”

　　当时顶尖的算力资源全部倾斜给了代码生成（CoGen）团队。他们确实取得了一定成果，但当时尝试将单元测试作为强化学习的奖励函数直接训练代码模型，结果证明是行不通的。因为缺乏底层的深层推理能力作为支撑，那条技术路线最终陷入了停滞。

　　因此，RLVR 绝不仅仅是一个简单的奖励机制，它决定了整个技术栈的架构形态。其核心在于将推理过程作为隐变量全部纳入考量。为了让模型在解决极其复杂的难题时发挥最大性能，研究人员选择在中间思考过程中给予模型极高的自由度，几乎不作任何约束。

　　目前业内流行的“放缓前沿研发步伐”的论调，在我看来视角非常狭隘。因为这种论调建立在一个假设之上：整个行业唯一的出路就是继续沿着 RLVR 的路径死磕。

　　但我们的模型显然完全不需要依赖更多的 RLVR。对于我们所定义的目标任务，RLVR 的最优配比应当是零。这种一概而论的观点根本站不住脚。

　　这很大程度上是一种偷换概念的话术（sleight of hand）：头部实验室在向公众传递这样一种叙事——“我们之所以顶着巨大风险向前推进，是因为这项技术本身蕴藏着巨大的颠覆性力量”。

　　有人辩解称，问题在于“沙盒隔离不到位”或“执行环境存在漏洞”。这种说法并不成立，在工程层面，构建严格的沙盒隔离并不是难题。

　　他们之所以选择不作严格限制，是因为在允许模型任意探索的框架下，赋予模型的自主权限越高，它所展现出的极限能力往往就越强。

　　这背后其实存在回避关键责任的问题。他们有意无意地引导舆论，将公众认知锚定在一个预设之上：“我们必须推进激进的 RLVR，必须在中间推理环节给予模型极大的自由度，因为只有这样它才能展现出突破性能力；绝不能在中间环节施加约束，否则就会削弱其极限表现。”

　　如果完全接受这一整套前提假设，得出的结论自然就是：“我们正在将技术推向高度危险的未知领域，而未来所有人别无选择，只能走这条唯一通往通用人工智能的道路。”

　　主持人：也就是说，他们的逻辑在自身体系内能够自圆其说，但关键在于，这套逻辑所依赖的底层假设本身并不是唯一解，完全存在其他替代路径。

　　Diogo Almeida：确实如此。回到“苦涩的教训（The Bitter Lesson）”这一核心思想：纵观整个计算技术历史，真正能够跳出固有范式、重新定义正确任务方向并指明新目标的人，始终屈指可数，这是极其罕见的。

　　在大语言模型发展史上，称得上范式级创新的其实只有两次：一次是 RLHF，另一次是现在的 RLCD。至于 RLVR，在我看来最多只能算 0.2 次迭代，这甚至已经算比较宽容的评价了。至于别人非要算作 0.5 次还是一次完整的范式突破，我也不打算过多争论。

　　我认为目前很多研究人员在这个问题上的思维方式过于受限。而这种认知的局限性，主要责任在于核心研究群体本身。普通公众对此并不知情，他们自然会认为 OpenAI 和 Anthropic 目前展示的技术形态就代表了行业的极限。公众不是领域专家，并不知道在既有路径之外，其实存在广阔得多的技术路线选择。

　　主持人：这个观点很深刻，你也在通过自己的方式推动行业重新审视这些问题。

　　Diogo Almeida：我确实在全力以赴。但我最终的目的并不是去说服那些头部大实验室改变方向。我的目标是让广大软件工程师看到新的可能性，激励他们亲自动手，去真正自动化并接管那些一直想解决的现实业务。

　　我之前写过一篇关于“我所期待的 AI 未来”的长文，不过团队出于各方面考虑建议我暂时不要公开发布。大家可能还记得早期计算机领域著名的“理解用户意图（Do What I Mean, DWIM）”理念吧？

　　试想一下，如果现实中所有的软件系统都能真正做到“领会意图”，那将带来巨大的生产力变革。刚才展示的那个用语音操作计算机的 Demo，核心逻辑正是为了实现“理解用户意图”。

　　它不再机械地局限于字面指令，而是去执行用户真正希望达成的目标。过去计算机很难做到这点，因为传统程序只能僵化地响应精确语法；但刚才那个 Computer Use 的案例，已经让人看到了这种转变的曙光。

　　整个世界的交互逻辑正在变得极其顺畅与高度自动化，这种顺畅程度甚至超出了许多人目前的认知。由泛在的轻量智能构建起的图景令人向往。我不想做出不切实际的承诺，这一切显然不会在一夜之间实现，但只要能加速这一天的到来，我们必将全力以赴。

　　即使给我十亿美元，我也不会从头预训练一个基础大模型

　　主持人：谈到后训练（Post-training）的整体流程，对于“中间训练（Mid-training）”，你有什么见解？我们之前似乎没有深入探讨过这个概念。

　　Diogo Almeida：中间训练……其实所有的训练过程本质上都是一个连续的光谱。

　　主持人：类似于课程学习（Curriculum Learning），只是换了一种更前沿的表述方式。

　　Diogo Almeida：本质上是为了控制成本，避免每次都从头做一次完整的预训练。

　　这其中包含一些非常值得推敲的技术细节。我认为在模型训练的各个层级上，智能都呈现出某种微妙的特质，这始终很吸引人。我更偏向于从宏观结构和空间关系（shape rotator）去理解系统，并不擅长捕捉那些极其细微的直觉体验，但我非常敬佩那些能在数据细节中敏锐捕捉规律、并将其转化为方法论的人。

　　深入到数据内部做精细化挖掘——这是我们数据团队非常擅长、而我自愧不如的能力——我认为这极具价值。

　　我一直在思考各项能力是如何融入模型的：短期内，通过微调可以快速实现表层对齐；但从长期来看，只有让模型在充分的数据与任务中反复迭代，这些能力模式才能真正沉淀到更深层网络中，进而形成真正的鲁棒性。这才是我们应当追求的核心目标，系统 1 的能力最终也是依靠这种深层沉淀变得稳固可靠。

　　中间训练是一个很有前景的方向。我并不排斥任何训练方法，也乐见各种探索催生出新的智能形式。只是就我个人而言，不会亲力亲为去重跑整个流程，因为研发成本过于高昂。

　　我之前曾公开表示：即使现在给我十亿美元，我也绝不会拿去从头做基础模型的预训练。直到今天我依然坚持这个观点。

　　作为一名合格的 AI 工程师，完全可以通过对现有顶尖模型进行切片、重组、蒸馏与组合优化，探索出极多的可能性；相比之下，从头预训练既昂贵又缺乏效率。将各种现有模块进行组合重构，听起来或许不够优雅纯粹，但它能切实有效地解决实际工程问题。除了从头做预训练，其他技术路径我都愿意尝试。

　　主持人：综合你刚才对技术路线的阐述，引出了一个值得探讨的问题：未来的终局究竟是集成所有能力的“全能全模态模型（Omni-model）”，还是会走向进一步的解耦与分化？

　　换句话说，OpenAI 显然在全力推进全能模型的方向（例如 GPT-4o）；但在更早的时期，他们的技术路线中也长期并存过专门针对对话调优的模型，以及专门针对代码调优的模型。

　　Diogo Almeida：这是两个完全不同的技术概念。

　　多模态（Multimodality）的机制不太一样，引入其他模态有时能提升模型的综合表现，有时反而会产生负面干扰。例如，目前行业似乎在逐渐远离纯端到端的语音训练（这与通用的音频处理有所区别），因为端到端语音训练出的表征，很难很好地泛化到其他复杂的推理任务中。未来这个问题或许能得到解决，我也支持相关的探索，但这完全属于需要实证支持的工程问题。

　　Scaling Law 的核心内涵绝不是“单纯堆算力就能解决一切”，它的实际指导意义在于评估一项技术路线究竟能在多大程度上走得通。在许多实际场景中，不论投入多少计算资源，性能瓶颈可能依然难以突破。

　　据我了解，目前的 Computer Use（让模型自主操作电脑）在底层技术上远未得到真正解决。我非常希望我们能成为攻克这一难题的参与者，但现实可能是：无论收集多少数据，现有的范式都可能存在上限，我们必须引入全新的方法论。

　　在这些问题上需要保持客观与理性。我是否支持全能大一统模型？我期待看到任何形式的智能探索。但针对你提到的在后训练阶段进行人为切分，我认为这种割裂智能的做法非常不可取。

　　目前这种将“对话交互”置于最高优先级的范式，本质上就是在强行拆解模型的通用智能。如果所有的优化都完全围绕对话体验展开，模型往往会过度偏向极端的 RLHF（基于人类反馈的强化学习）。

　　在这一机制下，许多被广泛诟病的问题几乎是必然出现的：严重的迎合倾向（sycophancy）、盲目自负，以及貌似合理的幻觉。

　　甚至观察 LMSYS Chatbot Arena 榜单上最容易获得高分的生成风格就能发现：通篇大量使用加粗、斜体以及表情符号。面对问题不直接给出答案，而是堆砌冗长的总结，并在结尾客套地询问“请问这是否对您有所帮助？”，其目的仅仅是为了刻意迎合人类对“真人对话感”的偏好。

　　这些现象的根源在于文本生成的随机性极难把控。为了防止生成内容偏离正轨，模型往往以牺牲概率校准为代价，主动舍弃多样性分布（mode drop），并表现出非理性的过度自信——因为一旦输出出现明显瑕疵，背后的奖励模型就会施加严厉的惩罚。

　　这种机制扭曲了底层的真实概率分布，进而破坏了其与深层推理模块的协同。由于深度神经网络在本质上倾向于平滑拟合，在面对这种硬性扭曲时，模型只能学会各种投机取巧的捷径。

　　这与我们所追求的“无损暴露纯粹的智能原语”，是两条截然相反的路径。

　　研究智能的关键，很大程度上在于理解并顺应这些微妙的底层规律。当初我在 OpenAI 时，很少有人专注于这些细节，多数人的关注点几乎完全集中在对话体验的打磨上，类似于当前行业对 Jev 的狂热跟风。

　　主持人：一旦确立了某个指标，研发人员往往就会不顾一切去刷满这个指标。

　　Diogo Almeida：如果试图同时优化两个相互冲突的目标，底层智能就会产生撕裂。

　　主持人：从某种意义上说，你将智能划分为系统 1 和系统 2，也是一种切分，只是你不认同别人的切分方式。

　　Diogo Almeida：这两者并不相同。客观来说，我们并没有放弃系统 2 类的任务，你依然可以用系统 2 的复杂问题来测试 Jev。在这类任务中，模型的表现确实存在优劣之分：面对超出其深思能力的慢思考任务，理想的模型应当表现出较低的置信度，明确承认自身的不确定性，或是借助某些启发式规则（heuristics）给出部分合理的参考。

　　需要澄清的是，我们同样重视系统 2，只是认为当前的架构天生并不完全适合这类任务。

　　我们不希望对智能进行人为的割裂，任何不自然的限制都会削弱模型的通用能力。例如，如果用户通过提示词诱导模型说出“我是 OpenAI 的模型”，或者称自己是通义千问（Qwen）、Claude，我绝不会出于品牌宣传的考虑，强行在模型中注入一条“你是来自 TypeSafe 的 Jev”。

　　强行设定此类人设是对智能表征的扭曲。模型应当依据训练数据中的客观事实作出正确判定。这才是合理的路径，唯有如此才能构建出表现平稳、可预测的工业级智能。

　　主持人：自我身份认同在很多应用场景中确实具有其特殊性……

　　Diogo Almeida：对于面向普通用户的 C 端产品而言确实如此，但对于底层的 API 服务来说完全不同。如果开发者基于你的 API 构建自己的产品，他们绝不希望模型向最终用户自称是 ChatGPT，而是希望它表现为“Chipotle 专属助手”或其他定制化品牌。

　　狂热中的清醒：当全行业都在押注对话框时，我看到了属于机器的未来

　　主持人：你们满足这类定制化需求的方式是提供 Skill，也就是专供编程智能体（coding agents）与 Jev 协同工作的 Jev Skill。

　　在结束之前，还有最后几个收尾问题。首先是回顾你的创业历程：从正式成立公司到现在，大概有两年，还是两年出头？

　　Diogo Almeida：如果仅从公司注册时间来看是这样；但对我个人而言，这更像是一场长达四年的漫长探索。

　　主持人：我一直记得你当年感恩节前后的那次“单兵突击（hero run）”：你推掉了所有私人安排，趁着全公司休假，把 OpenAI 所有闲置的算力资源全调集起来集中攻坚。

　　Diogo Almeida：那段经历非常痛快。

　　主持人：那应该算是创立 TypeSafe 之前的转折点，对吧？

　　Diogo Almeida：那大概……是不是高层人事动荡那阵子？我都有些记不清了。

　　主持人：时间点刚好吻合。

　　Diogo Almeida：看来确实是对得上。现在时间有限，没法细聊当年的内幕，但当时那场风波的过程确实令人非常不适。

　　主持人：是因为人事动荡本身，还是繁重的实验？

　　Diogo Almeida：当然是那场动荡本身。

　　主持人：当时所谓的“安全派”一度掌控了局势，先略过这个话题……

　　Diogo Almeida：下次有机会再来录播客，我可以详细讲讲那段经历。

　　不过那个核心问题，在 ChatGPT 正式发布前就一直在困扰我。我当时觉得 ChatGPT 团队做得很漂亮，他们找到了准确的任务定义。他们在做一件传统 AI 研究员往往不屑一顾、但优秀产品经理却极其擅长的事——把用户体验放在首位，并做到极致。这种思维在当时非常罕见，在当年的 OpenAI 内部也是屈指可数。负责那个项目的团队确实完成了极其出色的工作。

　　主持人：交代一下背景：这是从 GPT-3 迭代到 3.5 的完整过程，期间还包括了谁也没预料到的热门应用《AI 地牢》（AI Dungeon），你之前常拿它作为范例。

　　Diogo Almeida：没错。此外，我当时在内部竭力推动 InstructGPT 的上线部署。那个模型最初的版本甚至是用我自己写的一套算法训练出来的，因为当时整理适配 PPO 算法的数据流程效率太低。

　　我当时认为这个模型的效果足够惊艳，必须尽快推向真实用户。结果上线后，它迅速占据了当时整个大语言模型市场约 50% 的调用份额。

　　我们当时甚至开始思考：这是否就是通用人工智能（AGI）的雏形？因为在“遵循指令并输出结果”这一点上，它已经超越了普通人类的平均水平。现在看来显然还不是。但我认为行业内的每个人都需要回答一个问题：为什么一个当时看起来如此强大的模型，却根本算不上 AGI？

　　我的思考结论是：它最终被广泛落地的场景，大部分只是生成营销文案——比如 Jasper AI、Copy.ai，在互联网上大批量生产如今被称为“垃圾内容（slop）”的文本。我们当时甚至感到担忧，害怕自己亲手恶化了互联网的内容生态。

　　于是我重新在白板前复盘：这里面到底缺失了什么？模型本身确实很聪明，但若要产生实质的经济价值，关键的断层在哪里？

　　那段时间我做了很多底层逻辑上的推演，试图探寻背后的本质。最终得出的答案是：核心在于机器。

　　我反推了真正由 AI 引发的经济变革：假设未来的 AI 依然以 API 的形式存在，那么最核心的调用方会是谁？是人类，还是代码？答案显然绝大多数都将是代码。

　　然而，当时全行业几乎把所有的资源与算力，都倾斜在服务人类终端这一极小比例的需求上。意识到这一点后，我感到豁然开朗，这才是真正值得追求的方向。

　　我为此写了一份备忘录去找 Sam Altman 讨论。Sam 看完后非常认可，并鼓励我：“这个想法很好，你应该立刻去做。”我当时回应他：“Sam，我手头还有本职工作要完成……”

　　主持人：Sam 居然直接建议你去做。

　　Diogo Almeida：我当时的直觉是：这个逻辑太直观了，Anthropic 大概率已经在着手推进，我们可能已经落后了。坦白说，OpenAI 在历史上更擅长作为追赶者后来居上，而不是从 0 到 1 开辟全新的方向。当年 ChatGPT 本质上也是跟进 Claude，Anthropic 内部早已有了成型版本，只是没有对外公开。

　　主持人：当时是运行在 Slack 里的 Claude 机器人。不过在推理模型领域，OpenAI 确实走在最前列。

　　Diogo Almeida：确实，但作为产品形态而言，效果如何仍有待验证。那无疑是顶级的科研突破，但我并不确定市场端是否有足够明确的实际产品需求。此外，Claude 在编程智能体（coding agents）方向上的布局也相对更早。

　　在与 Sam 沟通后，我继续处理日常研发工作。直到后来指令遵循团队宣布该方向的核心问题已经基本解决，无需再投入过多精力时，我才开始规划下一步，决定着手验证之前的设想。

　　我投入了更多精力进行底层推演、系统设计与架构搭建。最初训练模型时，我以为一周左右就能看到结论，结果这一投入就是几年。直到某个时刻，模型终于展现出了可行的信号。

　　当时这项技术显然还不成熟，否则早已投入生产环境。但我非常渴望在科研层面探明究竟：如果我们倾尽全力投入这个方向，究竟能走多远？

　　我想知道全力以赴的结果是什么。正如我之前提到的：如果未来真的出现 AI 产业低谷，而我没有做这件事，我很难原谅自己。

　　我当时与其他几家机构交流过，提出想围绕这个方向成立专门的实验室。对方表达了兴趣，但我直接问他们：“哪种推进方式更快？是在你们内部孵化，还是独立创业？”他们的建议是独立创业。于是我下定决心，无论面临多大的不确定性，都要把这件事做出来。

　　主持人：所以你联系了 Eric 和 Sasha……

　　Diogo Almeida：我先联系了 Eric。找 Sasha 时，我起初并没有挖她的打算，只是想找同行做个客观评估：“我的推论是否存在认知盲区？我是不是在 OpenAI 待得太久，以至于忽略了外部已经存在的成熟方案？”

　　没想到 Sasha 听完后直接表示要加入。我当时很意外，提醒她说：“你现在的初创项目进展很顺利。”她说可以结束现有项目。我建议她再深思熟虑一下，她表示会再考虑，但随后依然决定加入。

　　在两周之内，我们完成了早期融资，全员搬进我的公寓开始办公。虽然对有洁癖的我来说环境有些局促，但我们高强度推进研发，最终在技术可行性上取得了关键突破。回想起来，那确实是一段极具挑战且纯粹的经历。

　　绝大多数新兴实验室本质上都在折损价值

　　主持人：我想问的是：如果现在顶级实验室里有人面临和你当年一样的困境，因为缺乏足够的算力、资金或重视而感到受限，你会给他们什么建议？他们应该效仿你的做法出来创业吗？

　　Diogo Almeida：这个问题很犀利。我得想想怎么回答才不至于把同行得罪光。

　　我的真实看法是：除非背后有某种我没看透的深层经济学逻辑，否则我认为目前市面上绝大多数所谓的新兴实验室（neo-labs）都没有实际意义。我不认同他们的做法，也看不出他们能做成什么。

　　首先，我并不盲目崇拜所谓的“研究人员”。回顾《苦涩的教训》（The Bitter Lesson），行业确实需要科研人才，但关键在于，这些人必须愿意将全部精力倾注在真正正确的目标上，这才是核心所在。

　　当前行业过度追捧学术背景和研究履历，但这种光环很多时候并不能转化为实际价值。我始终认为，必须有明确的核心目标作为指引，专注于攻克真正有用、有突破性的事物。

　　其次，基于同样的理由，我并不建议大家盲目跟风。虽然在当下的资本环境下，创办新实验室或许能让一部分人获利，但从工程实践的角度来看，大量建立这种新兴实验室并不能创造价值，反而是在耗费资源——因为他们大概率只是在低水平重复造轮子，对推进技术前沿没有任何实质帮助。

　　据我观察，大多数新兴实验室并没有清晰的技术路线，更多只是借助资本热度来满足做实验的诉求。当然，如果确实有目标明确、方向笃定的团队，我是完全支持的。

　　所以我的建议取决于你的初衷。如果你只想单纯做研究、做实验，那么留在顶级大实验室里显然是更好的选择，也无需卷入其他纷争。但我个人并不推崇这种状态。世界需要的是那些以解决实际工程问题为导向，并始终坚守自身原则的人。

　　如果你坚信自己找到了真正正确的技术路径，我非常鼓励你独立出来，去打破当前局限于单一模态或固定范式的从众思维（hive-mind）。

　　我想强调的是，那种主张“放慢技术前沿步伐”的论调，本质上源于一种狭隘的假设——他们把 AI 预设成了一个能力畸形但智力超常的个体。这种脱离实际的执念并不可取。将真正有价值的技术开发出来并应用到现实世界中，始终是一件利大于弊的事。

　　主持人：客观来说，就我与 Anthropic 和 OpenAI 相关人员的交流来看，他们关注的重点其实更多是政治层面的博弈，而非单纯的人类生存风险（x-risk）。本质上是一种政治层面的布局。

　　Diogo Almeida：这已经超出我关注的技术范畴了。

　　主持人：当他们讲明逻辑后就很清楚了，这背后的核心目标其实直指 2028 年的美国大选。

　　Diogo Almeida：这确实让人有些难以接受。

　　主持人：需要说明的是，这并不代表整个公司的官方立场，只是闭门会议中的内部讨论。

　　Diogo Almeida：这种逻辑能够自洽，但也挺令人失望的。或许是我把事情想得太纯粹了，只关注技术本身。

　　主持人：随着技术爆发，未来由谁来主导政府监管政策变得至关重要，作为顶尖实验室，他们确实需要提前布局。

　　Diogo Almeida：我能理解这一点，在关键议题上有明确的主张固然重要。

　　但我非常反对误导公众，因为失信最终会带来反噬。盲目自信是很危险的——就像在新冠疫情期间，一些机构出于自负，试图通过武断的定论来引导公众行为，结果不仅应对失当，还引发了一系列严重的次生后果，至今仍在产生负面影响。

　　也许我有些理想主义。但无论打着多么崇高、多么顾全大局的旗号，只要涉及刻意误导公众，我都难以认同，也不会去参与。

　　主持人：他们可能不认为这是误导，而是在论证“为何迫在眉睫”——解释为什么监管必须在当下这个节点介入。

　　Diogo Almeida：这种所谓的“迫在眉睫”，其实混淆了真实风险与背后的战略意图。这其中存在一种心照不宣的算计，这种现象应当被公开且坦诚地探讨。

　　当然，如果意图本身就是政治游说，他们自然不可能公开承认，否则就失去了运作空间。但我依然感到遗憾。

　　我希望我们团队永远不要卷入这种策略博弈中。或许机构规模扩大后妥协在所难免，但我会尽最大努力守住作为工程技术人员的初衷。

　　摆脱 KV Cache 的限制：重构多 Agent 协作与动态状态机

　　主持人：你已经确立了自己的核心目标：高可靠性、可编程性、可组合性以及极致的性价比。如果让你挑选两到三个极具潜力的方向分享给行业，有哪些是你目前分身乏术，但非常希望看到其他人去深入探索的？相当于给大家提供一些研究课题。

　　Diogo Almeida：值得探索的方向确实很多，这个提议很棒。

　　我可以分享两个：一个偏向趣味性，另一个则兼具巨大的商业价值与研究深度。

　　有趣的方向在于：如果为游戏引入真正的微型智能（Micro-intelligence），能带来的体验会非常独特。大家之前看到 Ali 制作的《毁灭战士》Demo，让 NPC 自主控制游戏行为，大家玩得很有兴致；但那其实只是非常初步的概念验证（PoC），未来的空间远不止于此。

　　我个人非常喜欢《星露谷物语》（Stardew Valley）。即便游戏本身的剧情逻辑完全是预设好的，它依然极具吸引力。试想一下，如果在此类游戏中加入动态生成的微型智能，将会演变出多少生动的剧情展开。

　　你并不需要在游戏的主渲染循环中高频调用 Jev，因为那样成本难以承受；但只要为 NPC 配备结合了智能的离散状态机，就能构建出一个极具沉浸感的动态世界。可惜我精力有限，未来几年的工作重心已经基本固定，无法亲自去做这些了。

　　主持人：确实，不过你可以呼吁社区去探索，并为他们提供技术层面的反馈。

　　Diogo Almeida：我真正关注且非常希望深入探索的另一个课题是：彻底摆脱 KV Cache 束缚的 Coding Agents。

　　这种方向的上限未必能完全超越当前范式，但其内部包含大量值得深思的全新架构。这也是我之前撰写《KV Cache 主宰一切》（KV Cache Rules Everything Around Me，致敬 Wu-Tang Clan 的《C.R.E.A.M.》）的原因。我当时在 Google 上搜索过，此前全网似乎还没有人用过这个谐音梗。

　　我写那篇文章的目的，是希望向行业解释清楚 Coding Agents 的底层运行机制，以及底层的 KV Cache 是如何影响整个系统的。它能够解答许多核心难题：例如为什么跨模型路由如此困难？为什么多层级 Sub-agents 的表现总是不尽如人意？为什么上下文压缩会成为一个极难逾越的瓶颈？

　　我正打算整理并发布一份白皮书。团队内部可能会持保留意见，毕竟公司的决策并非由我一人主导。

　　但我很希望公开这份研究备忘录，把我的推演思路分享出来，供大家去动手验证：去探索一旦摆脱了 KV Cache 的限制，Coding Agents 能够展现出怎样的潜能。

　　主持人：当前的架构确实将系统与单一模型牢牢绑定了。

　　Diogo Almeida：系统被绑定在单一模型上，为了维持推理效率，只能不断地在同一个上下文中进行内容追加（append）。这就导致传统软件工程中的核心最佳实践被完全忽视：状态管理、分层抽象以及模块解耦，在当前架构下几乎都不复存在。

　　为什么无法把相对简单的子任务分发给轻量级的 Sub-agent？因为两者之间需要传递的状态过于庞大。为了传递这些冗余的状态，所消耗的推理成本甚至超过了处理任务本身所需的算力。我们完全可以用更合理的方式来解决这个问题。

　　在全新的编程设计范式方面，有许多极具突破性的研究课题。比如目前大家在探索的递归语言模型（Recursive Language Models, RLM）。试想一下，如果我们显式地为每一个系统状态赋予语义标签，系统会呈现怎样的形态？

　　在子任务分解方面，目前的 Coding Agents 普遍是一次只攻坚一个子任务。从解耦的原则来看，根本没有必要将子任务执行过程中的所有冗余状态完整同步回父级任务，完全可以对其进行智能筛选与剪枝。

　　此外，如果系统维护着一棵带有清晰语义标签的层级化子任务树，当需要补充上下文时，完全可以直接沿着这棵树进行精准的剪枝与检索。

　　我还有一个构想，后续希望能整理发布：如果上下文处理的成本大幅降低，我们为什么不能采用更高级的架构，例如以极低代价随时回溯并审查历史上下文？

　　当前的 Coding Agents 每次初始化时都缺乏上下文延续性，学界为此专门投入精力去研究所谓的“持续学习（continuous learning）”。但从本质上看，这其实是一个内存管理问题，症结在于缺乏高效的内存索引机制。如果能够随时以极低成本调用这种检索能力，情况就会截然不同。

　　另外，当多个并发运行的 Sub-agents 协同工作时，如果所有系统状态均保存在宿主机内存中，它们便可以互通状态。系统还可以智能仲裁并发读写冲突，使 Coding Agent 集群不再依赖传统刚性的文件互斥锁，而是通过智能调度实现协调：例如明确各自正在修改的模块，并由 Jev 这类机制裁决写入顺序。这个方向的发展空间极其广阔。

　　主持人：让 Jev 来充当分布式锁的智能仲裁节点。

　　Diogo Almeida：在多 Agent 协同场景下，这非常具备实用性。从状态属性来看，许多工作流本质上是纯只读的。有些开发者希望实时获取 Agent 的进度摘要，它们之间完全可以无缝共享状态。

　　只读 Agent 仅需扫描指定切片的上下文，提取核心变更并汇报代码修改即可，无需理会中间探索过程中的试错信息，或者可以直接呈现子任务树的状态。

　　只要有优秀的工程师愿意从第一性原理出发，彻底重构 Coding Agents 的整体交互范式，能够创造出的系统必将极具颠覆性。这也正是我始终追求的目标。

　　体验欠缺的 Function Calling：告别在 System Prompt 里妥协与被动祈求的时代

　　主持人：如果你还没关注过，我建议看一下 PrimeAgent。它与 RLM 的工作结合得很深。目前已经有人在朝这个方向探索，只是在社区里还没有完全普及开来。

　　Diogo Almeida：我非常希望看到更多开发者大胆尝试各种前沿方案。虽然不敢保证这些路线一定都能走通，但纯粹从工程角度来看，这些探索极具吸引力。

　　等我们理顺算力额度的赞助机制后，我很乐意为这类早期探索者提供充足的 API 额度支持。

　　主持人：以你们目前的发展势头，未来资助前沿研究完全不成问题。再次祝贺你取得的成绩。从我最初认识你到现在，你和团队经历了一段漫长且出色的历程。

　　Diogo Almeida：其实我觉得自己和当年相比并没有太大变化。

　　主持人：但你现在展现出的专注与状态确实是以往没有的，你显然找到了自己真正认同并全身心投入的使命。

　　Diogo Almeida：这一点毫无疑问。

　　主持人：而且你现在能把这个使命清晰地表达出来。过去几年你一直在指出行业的种种缺陷，只是当时还没有成熟的解决方案，脑子里只有一个模糊的轮廓；而随后你花了几年的时间，把它真正做成了现实。

　　Diogo Almeida：部分原因在于，我始终认为自己在创业方面几乎没有任何天赋（处于第 0 百分位）。我本能上并不喜欢初创公司，也从未设想过自己会去当 CEO。我很难理解为什么有人会选择连续创业，这极其消耗精力，经历一次就足以让人精疲力竭了。

　　当年启动融资时，有投资人问我：“你平时最推崇哪位科技公司的 CEO？”我当时的反应很排斥，反问为什么要去盲目崇拜这些人。这并非有意冒犯同行，我结识过很多优秀的创始人，只想保持真诚；但不少声名在外的所谓明星 CEO，背后往往都存在很多难以摆上台面的问题。

　　回想当初在 OpenAI 的经历，我曾体会到强烈的无力感与挫败感。既然现在已经拿出了成果、证明了路线的可行性，我也就可以坦率地讲出这些感受。

　　当时我感觉周围的环境极度狂热，所有人都在盲目跟风：“ChatGPT 太不可思议了！我们该怎么把 ChatGPT 接入所有产品？怎样让开发者更多地使用它？”

　　但我内心的想法完全相反：“大家究竟在盲目乐观什么？Function Calling（函数调用）的接口设计极其糟糕，这种水平的实现怎么能直接推向生产环境？这给开发者带来了巨大的负担。”

　　主持人：本质上就是在原本粗糙的临时方案（hacks）之上不断叠加补丁。

　　Diogo Almeida：不仅如此。我当时的立场非常强硬——虽然细节暂且不提，但我态度明确：如果不为每个函数调用提供独立的 logit bias（概率偏置），就不要让我参与任何与 Function Calling 相关的项目。对我而言，这本该是最基本的底线设计。

　　主持人：这类似于置信度控制，只是缺少了精确的概率校准。

　　Diogo Almeida：核心在于赋予它明确的触发概率。开发者必须拥有精确的控制权——比如面对“拒绝”或“放行”两个分支时，迪士尼业务需要的拦截阈值，怎么可能和《AI 地牢》这类游戏相提并论？

　　但在现有的 Function Calling 架构下，开发者若想控制模型调用某个函数的倾向，唯一的手段竟然是在 Prompt 里迁就并恳求模型：“请务必调用这个接口”。

　　这种设计极其不合理，对开发者而言是一种非常糟糕的交互体验，而整个行业竟然默默接受了这种现状多年。甚至如今所谓的 Skills 机制，依然在延续这套充满缺陷的逻辑。

　　市面上的 Coding Agents 严重过拟合于自身特定的测试基准（harness）。正因为能力分布极不均衡（jagged），一旦接入外部扩展工具或 MCP 协议，往往就会失效崩溃——其核心根源显然是过拟合。

　　为什么企业级客户无法对模型进行细微的倾向微调，比如指定“优先调用这个在生产环境中已被验证有效的接口”？目前的解决方案竟然依然是回到 System Message 中反复尝试说服模型。这种架构设计显然脱离了实际工程需求。

　　我们才刚刚写好智能时代的 TCP 协议，面向机器的 AWS 正在成型

　　主持人：我完全理解你的想法。非常高兴能请你来到录音室。相信你们未来会做出非常扎实的成果，我也十分期待看到你们后续的正式发布。

　　Diogo Almeida：下一次发布可能会比大家的预期来得快得多。

　　主持人：顺便帮你们做个招聘宣传：你们目前正在招聘数据专家、底层基础设施（Infra）工程师，我猜应该还包括市场营销负责人？

　　Diogo Almeida：这取决于你问谁。如果问我，我觉得自己是个挺合格的初创期营销负责人。但如果去问团队里的其他人，他们大概会让我少说两句，专心履行 CEO 的本职工作。所以，我们确实正在招募一位创始营销负责人。

　　主持人：市场营销不只是发表激进观点。你很擅长制造话题和关注度，这是你的特质；但团队确实需要有人以更规范、严谨的方式来做官方公关和信息传递。

　　Diogo Almeida：确实如此。面对纷至沓来的繁杂事务，学会适度放权是必然的选择。

　　我们目前正在全力招募数据专家——内部称之为“模型能力工程师”，但本质上就是顶尖的数据专家。在当下的算法圈里，“数据”这个词甚至带有一丝贬义色彩，但我希望在我们公司，深耕数据的人能够享有极高的技术声誉。

　　我倡导团队平等，但更希望打破行业对数据的偏见，让大家认识到高质量数据的核心价值。

　　主持人：“有些动物比其他动物更平等。”

　　Diogo Almeida：我非常排斥等级森严的官僚体系。在公司里最让我欣慰的是，大家并不会因为我是 CEO 就区别对待——平时经常拿我开玩笑，我认为这种包容、平等的氛围才是健康的团队文化。

　　此外，我们也在积极组建平台工程团队，目标是将 Jev 部署到全球各地。我们对机房的物理位置极为敏感，因为对于低延迟模型而言，光信号在光纤中的物理延迟才是真正的瓶颈。

　　对于欧洲用户，我感到有些遗憾：由于目前尚未在欧洲部署边缘节点，当地的调用速度大约仅是传统 LLM 的 3 倍，未能达到美国本土约 100 倍的提速表现，这是我们需要尽快改进的地方。

　　主持人：没关系，欧洲整体生活节奏偏慢，这也算符合当地特色。

　　Diogo Almeida：这话是你说的，我可没有这么表达。

　　我们需要在世界各地建设基础设施。如果“单位时间内的智能密度”是一项核心指标，我们就必须将服务部署在离用户最近的物理位置。对于选择基于我们底层基座进行构建的开发者，我们始终保持高度重视。

　　同时，我们也在招募人才探索全新的智能形态——公司的长期愿景远不止 Jev 这一款产品；我们的目标是向行业交付全新维度的智能形式。

　　因此，我们非常需要优秀的工程师加入。我们不会局限于单一产品，我相信未来必然会出现面向机器智能时代的 AWS。

　　主持人：而你们大概率会成为这家公司，对吗？

　　Diogo Almeida：这是我们努力的方向。如果现在断言一定是我们，未免过于自大；但我会竭尽全力促成这个愿景的实现。

　　未来的发展空间非常广阔。目前我们仅触及了 System 1 智能的基础部分；如果放眼未来的完整技术栈，现在的成果大概只相当于搭建好了智能时代的 TCP 协议层。

　　主持人：后面还有类似 OSI 模型中更多的协议层级，未来能演化出怎样的形态非常值得期待。今天能聊的内容很多，不过时间有限，你也需要回去投入工作或休息了。非常感谢你参与今天的交流。

　　Diogo Almeida：非常感谢，今天的交流很深入，也很让人振奋。