Jev创始人访谈：Jev是面向智能的SQL，软件设计需回到工作流为中心

智猩猩AI整理

编辑：六六

近日，TypeSafe 联合创始人兼 CEO、Jev 创始人 Diogo Almeida做客 TWIML AI 播客，与主持人 Sam Charrington 围绕 AI 的自动化能力展开讨论。

AI 聪明得不可思议，却又在很多本该发挥作用的地方无用得不可思议：为什么 Transformer 能解决数学领域的千年难题，却连自动化会计这样的工作都难以胜任？

Diogo 给出的答案是：你得到什么，取决于你优化什么。

在他看来，当前 LLM 的关键局限在于，模型主要围绕生成文本进行优化；而软件自动化真正需要的，往往不是一段看似合理的回答，而是明确、可执行、可信赖的判断。

因此，AI 能力与实际应用之间的鸿沟，不仅仅是模型不够强，还有优化目标与真实任务之间存在错位。要弥合这道鸿沟，需要更强的模型，也需要让模型从生成供人阅读的内容，转向输出软件能够直接使用的结果。

这正是 Diogo 提出“机器原生智能”（Machine-native Intelligence）的出发点，也是 TypeSafe 开发 Jev 的核心思路。

通过围绕经过校准的决策进行优化，即 RLCD（强化学习校准决策），Jev 尝试让模型输出判断及其对应的概率，再由开发者根据具体业务需求决定如何执行。

但改变模型的训练目标只是第一步。Diogo 借用 Sutton 的“苦涩的教训”进一步指出，算力和规模固然重要，但找到正确的任务、构建与之匹配的数据，同样是推动 AI 能力跃迁的关键。换句话说，优化目标决定了模型往哪里走，而正确的任务和数据决定了它能否真正走到那里。

在此基础上，要让 AI 实现大规模自动化，还需要明确的代码、可组合的工作流和可维护的工程系统。与其让一个端到端模型包办所有任务，不如将机器学习放在真正擅长的环节，让智能成为软件可以直接使用和控制的基础能力。这也意味着，AI 的可靠性不能只靠 demo 证明，而要在工程系统中被持续验证。

Diogo在访谈中表示“我们希望把 AI 做得可靠到理所当然，就像 SQL 一样。”但可靠性是个长期过程：每多一个"9"（比如 99.9% 到 99.99%），就可能解锁一批新的应用场景。

从优化目标、训练数据到 RLCD 与软件工程，Diogo 试图回答一个更实际的问题：当 AI 已经足够聪明，下一步该如何让它真正可靠地完成工作？

以下是访谈回顾：

01

你得到什么，取决于你优化什么

Sam：这里是 TWIML AI 播客，我是 Sam Charrington。Diogo Almeida 是 TypeSafe 联合创始人兼 CEO，此前在 OpenAI 工作四年半，参与了 InstructGPT 和 RLHF 相关工作。如今他致力于探索“机器原生智能”（Machine-native Intelligence），让模型不再只生成供人阅读的文本，而是直接做出软件可执行、值得信赖的决策。

下面请 Diogo 讲他想要弥合的那道鸿沟。

Diogo：我对 Jev 的一句话介绍是：自动化到底在哪儿？AI 聪明得不可思议，却又在很多本该发挥作用的地方无用得不可思议。ChatGPT 的深度研究和 Claude Code 已经展现出很强能力，可如果你只想做一件更简单的事，比如简单业务决策，它就完全派不上用场。

我很好奇你有没有答案：为什么一边是聪明得离谱，另一边却是无用到离谱？

Sam：我认为部分原因在于，我们现在似乎只有一把锤子：以预测下一个 Token 的 Transformer 为核心，再通过各种机制让它更擅长生成文本。我们试图把它用到所有地方，但它并不总是最优方案。

Diogo：这里还有更深层的原因。为什么 Transformer 能解决数学领域的千年难题，却没法自动化会计？业界还没有准备好诚实地回答这个问题。但要真正证明这一点，就是把那份工作自动化掉。我希望 Jev 是朝这个方向迈出的第一步。

我的答案是：你得到什么，取决于你优化什么。

几乎所有基于字符串的 LLM，都是围绕生成字符串进行优化的，这些内容供人类或其他 LLM 阅读。但会计工作需要的是计算机能够直接处理的结果——明确的字段、表单和离散决策。

为生成字符串而优化与为离散决策而优化，是两件截然不同的事。这是 AI 能力与实际应用之间存在巨大鸿沟的重要原因。

Sam：我并不认为"AI 擅长一些事、不擅长另一些事"是一个一维的"文本 vs 决策"问题，它是一道锯齿状前沿（jagged frontier）。要不断拓展这个边界，可能需要多方面的改进，而不只是区分文本生成和决策。

Diogo：我认为锯齿性并不完全是 LLM 或 AI 的内在属性，也与我们的优化方式有关。如果你朝某个方向施加很强的优化压力，就会获得相应的可靠性，却可能忽略其他方面。这就是优化的不对称性。以客服为例，该退款时没有退款，从准确率角度看，和胡乱敲击键盘一样都是错误结果。但模型不会真的用脸砸键盘，因为训练过程已经压制了这类行为。

RLHF 也是如此：通过奖励模型明确哪些行为应该受到惩罚，从而让模型在这些方面变得可靠。尽管预训练模型原本可能生成毫无意义的内容，后训练仍然能够显著改变它的行为。AI 从业者在决定向模型注入哪些目标时，其实拥有很大的主动权。

02

数据比算力更重要，

而比数据更重要的是找到正确的任务

Sam：机器学习本来就是围绕优化展开的，我们每天都在讨论损失函数。为什么你认为机器学习从业者反而没有真正理解“你得到什么，取决于你优化什么”？

Diogo：我想从 Sutton 的“苦涩的教训”（Bitter Lesson）谈起。它的一个核心观点是，算力和规模往往比人工设计的算法更重要。机器学习从业者通常热衷于算法创新，却不一定愿意投入那些更困难的系统工作，尤其是在学术界，计算系统和 GPU 相关工作并不容易开展。

但我认为，数据比算力更重要，而比数据更重要的是找到正确的任务。预训练损失就是一个例子，今天看来降低预训练损失能够带来强大的 AI 似乎顺理成章；但在早期相信这条路能够成功其实是一次很大的信念飞跃。找到正确的任务，才是关键。

在游戏中，这一点相对容易，因为游戏规则已经明确了目标。模型还可以通过同策略（on-policy）强化学习不断进行 rollout，利用算力生成训练数据。因此，在游戏场景下，Sutton 所说的“苦涩的教训”与我强调的优化目标，本质上是相通的。

Sam：那么在现实世界的应用中，数据是不是比算力更稀缺的资源？

Diogo：关键不仅是数据，还要找到正确的数据方向。RLHF 定义了一个重要任务：让模型能够进行对话、遵循指令。在这类 RLHF 出现之前，互联网上根本没有我们需要的那种数据。没有人会自发地持续比较两个语言模型的输出，并标注自己更喜欢哪一个。因此，研究人员必须意识到这种数据值得专门构建，并从零开始收集。

在最初的时候我们无法确定自己选择的方向一定正确，只能相信它值得投入。随后我们需要收集数据、投入算力并不断改进算法，最终才能验证这条路是否可行。机器学习领域那些巨大的跃迁，往往就来自这样的过程。Jev 至少从目前引发的关注度来看，也展现出了类似的潜力。

03

机器学习应该被放在它真正擅长的部分，

而不是被要求包办一切

Sam：我们上次对话已经是十年前了，当时聊的还是广义深度学习。这些年你都在做什么？

Diogo：我先去了 Google，后来离开休息了一段时间，玩竞技电子游戏、做即兴喜剧。最终我意识到 AI 比这些更有意思，于是加入了 OpenAI，当时语言模型还远没有今天这样的影响力。但一直有一个问题困扰着我：为什么 AI 厉害得不可思议，却在一些简单工作上如此无用？这也促使我创办 TypeSafe、开发 Jev。

Sam：这里面有太多我想追问的了。比如"软件在做科幻之事"，推特上就有个很好的例子：有人在自己车里跟 Grok 对话，让 Agent 去做一个视频。但你也指出，很多看似简单的工作一直没有解决，这是为什么。

Diogo：我每天都在使用编码智能体和聊天机器人。没有聊天机器人，我经营公司会困难得多。但我认为 LLM 是一种极其特殊的存在，它似乎是"对智能的最大程度压缩，同时效用却最低"。

自动驾驶就是一个很好的对照。Waymo 的系统通过大量软件和工程设计，将任务拆分成不同模块，明确每个部件的职责，再把它们组合成一个可靠的系统。这是一场非常出色的工程胜利。相比之下，当前很多 AI 产品的路径是：先做一个令人惊艳的 demo，获得融资，然后开始讨论如何提高可靠性，最终却依赖“人在环路”来兜底，而不是真正实现自动化。我并不是贬低这些团队。在当下的 AI 环境中，这可能是合理的选择，因为模型确实还不够可靠。

但我们也应该用同样的标准审视 LLM 的 demo 和 Jev 的 demo。真正重要的不是演示有多惊艳，而是系统能否在后台可靠运行，真正完成工作。

Sam：这也让人想到 Waymo 和特斯拉的不同路线：前者更强调模块化工程，后者更接近端到端的大规模数据训练。

Diogo：我想强调的是，机器学习只是整个系统的一部分，不应该成为系统的全部。我非常支持软件工程，要提高可靠性，就需要把系统拆开来看：研究每个部件的性质，理解每个机器学习组件的能力和局限，并且在出现问题时，能够定位原因、修复问题。

如果一开始就让一个端到端模型统治整个系统，这会非常困难。在当下，要交付真正有用、可靠、安全的软件，我认为工程化仍然不可或缺。机器学习应该被放在它真正擅长的部分，而不是被要求包办一切。

04

让 AI 像 SQL 一样可靠到理所当然

Sam：Jev 的想法是怎么来的？你们一开始就确定了这个方向，还是经历了几次转型？

Diogo：多年来我一直在讲同一件事，现在把它称为“机器原生智能”：为自动化、为机器而优化，而不是为字符串、为人而优化。去年讲同样的理念时，几乎没人听懂；而今年随着产品与市场的契合度逐渐显现，投资人开始认为这个方向很有吸引力。

我当初并不知道它最终会以 Jev 的形式出现，我们也经历了几次关键突破。但我们的目标始终没变：如果 AI 真正以“对软件有用”为目标进行优化，它会是什么样？

Sam：Jev 发布后，外界的反应很两极：一些人认为它不过是分类器或逻辑回归；另一些人则认为它可以更快、更便宜地完成过去一直想用 LLM 做的事情。你是怎么看呢？

Diogo：分类器本身没有问题，它是一种接口，并且分类器也不是什么新的机器学习创新，真正重要的是把它用于有价值的任务。如果有人把 Jev 描述为“面向任意任务的 zero-shot 通用分类器”，我会认为这是对它非常高的评价。

但我认为很多人误解了 Jev 的价值。他们关注的是接口、速度和成本，却忽略了真正重要的东西：智能本身。在理想情况下，速度应该是即时的，成本应该趋近于零，没有人希望在代码里增加成本和延迟。

人们真正愿意付费的是智能。Jev 的目标，就是让模型能够在各种任务上做出更好的判断。但到目前为止，我仍然认为真正把智能本身作为核心优化目标的团队并不多。

Sam：但 Jev 发布后不久，就有多个开源项目跟进，OpenAI 也推出了决策小模型。

Diogo：这些工作可能在接口、速度和成本上取得进展，但这和真正提高智能不是一回事。在理论上如果智能足够强，分类问题可以成为解决各种任务的基础。决定我们能自动化什么、能构建什么的，最终还是智能。

我们希望把 AI 做得可靠到理所当然，就像 SQL 一样。你写好查询，不应该每次都需要重新验证结果是否正确。我喜欢 Jev 速度快、成本低，但真正让人愿意为它付费的，是可靠性。要把智能放进应用，就必须拥有足够可靠的智能。

05

让智能以更适合软件使用的方式发挥作用

Sam：你之前说，原本以为一周就能做出 Jev。实际情况为什么比预想困难得多？

Diogo：我曾认为，只要投入相当于一次 RLHF 工作的资源，用一年时间就有可能构建这种为机器而生的新模型。但后来发现，RLCD 要难得多。要让 AI 做出经过校准、稳健的决策，则需要解决更多问题。

我们的目标是构建一个认知内核，理解它的能力与弱点，再找到最有效的方式，让它在真正具备的智能水平上表现得更加稳定。例如，模型可能无法准确数清一个单词里有几个字母，但现实世界中有大量任务并不需要这种能力，而是依赖语义判断。

Sam：语义判断可以拆分成分类问题。

Diogo：是可以，但不能无限拆分。工程系统需要合适的抽象层级，让工程师能够理解、维护，而不是针对每个具体问题过度定制。比如，要判断一个客户是否应该获得退款，你当然可以把问题拆成上百种具体场景，但这会让系统变得非常复杂。我们真正想做的是，让开发者能够在符合自己思考方式的语义层面编程，而不必把每件事都拆成大量细碎规则。

Sam：从开发者的角度看，Jev 是不是可以理解为一种“智能 API”：开发者提供输入和可选决策，模型负责判断，并给出相应概率？

Diogo：我很喜欢这个说法。我们也可以把它理解为“面向智能的 SQL”，或者构建智能应用的积木。我们希望把智能标准化为一组通用原语，让开发者能够直接在软件中使用它们。也有人把这一类产品称为“决策模型”，我们并不反对，但它们能做的事情不一定只有决策。关键在于，让智能以更适合软件使用的方式发挥作用。

06

RLCD 才是对软件真正有用的东西

Sam：Jev 的核心模型是通过 RLCD 后训练得到的吗？

Diogo：这里需要区分任务和算法。RLHF 并不只是某种特定训练流程，更重要的是它定义了什么任务：利用人类反馈，让模型学会遵循指令。我所说的 RLCD 则是一大类围绕“经过校准的决策”进行优化的方法，这才是对软件真正有用的东西。我们尝试了多种算法，但核心目标始终是相同的：让模型输出可靠、经过校准的判断。

Sam：能否进一步解释 RLCD 的任务设定？

Diogo：RLCD 的目标，就是向开发者提供正确的控制接口，让他们能够根据自己的业务需求调整模型行为。在客服场景中，是否转人工可以取决于客户价值、人工客服的忙碌程度，以及其他业务因素。这些因素都可能改变最终决策，但传统语言模型并没有为开发者提供足够直接的控制手段。

我们不仅需要准确率，还需要经过校准的概率。因为不同的行动具有不同的成本和收益，开发者需要根据自己的应用决定如何使用这些概率，而不是一味采用模型认为最好的选项。

Sam：也就是说，Jev 将决策控制权交给了应用开发者，而不是试图替所有应用决定统一的行为方式。

Diogo：正是如此。可以把它想象成：API 不只是返回一个最终答案，而是向开发者提供模型对不同选项的判断，让软件能够根据自身需要做出选择。概率只有进入应用、触发实际行动，最终为用户创造价值时，才真正有意义。

07

Jev 如何实现可靠的概率输出与泛化能力？

Sam：在过去模型校准一直很难，那你们如何确保 Jev 输出的概率有意义，而不是模型随意生成一个 0 到 1 之间的数字？

Diogo：据我们的观测，Jev 的校准表现不错，虽然没有达到完美，但比一些经过 RLHF 训练的模型好得多。我们认为可以通过合适的训练目标，从初始模型和种子数据出发，逐步提高校准能力、可靠性和智能水平，就像 RLVR 能够通过强化学习提升模型的推理能力一样。

Sam：那么 Jev 如何泛化到没有见过的商业决策和工作流？这些任务可能与训练数据存在很大差异。

Diogo：泛化并不是 AI 天生缺失的属性，我们也能通过投入更多工作，让模型在更多任务上变得可靠。今天 LLM 的很多脆弱性与锯齿状能力边界其实是和 RLVR 的训练方式有关。RLVR 通过可验证的奖励优化特定任务，模型因此能够在这些任务上取得很好的成绩，却不一定能同样稳定地处理其他问题。相比之下，RLHF 更容易泛化，因为它优化的是让人满意的文本，而人类偏好本身具有一定的主观性。

如果按照任务的泛化潜力来看，我认为 RLHF 最容易泛化，其次是 RLCD，再其次是 RLVR。这并不意味着 Jev 今天已经全面超过其他模型，它是我们第一个公开发布的模型，可以视为一个早期版本。但随着投入增加，我预计它在商业和企业工作流上的表现会大幅提升。可靠性是个长期过程：每多一个"9"（比如 99.9% 到 99.99%），就可能解锁一批新的应用场景。

08

Jev 负责提供智能，

其他逻辑和数据仍然由开发者掌握

Sam：对于 Jev，模型与 Harness 如何分工？它是主要依赖模型本身提供智能，还是依赖外部代码和编排系统来完成工作流与业务逻辑？

Diogo：我更愿意把 Harness 直接称为“编码”（Code），而且我不认同只要给 LLM 加上一个循环和工具调用，就能让它变得可靠的观点。以 Claude Code 为例，我认为它的能力跃迁可能不仅来自接口设计，也来自模型训练的进步。

接口和编排当然重要，但不能把所有问题都归咎于 Harness，因为智能本身也在不断演化。对 Jev 来说，模型应该成为用户自己编写的软件的一部分，而不是由我们控制一个统一的智能体框架。如果业务逻辑全部写在 system message 里，却运行在别人的服务器上，这其实很奇怪。

传统 API 通常只负责完成特定工作，而不是要求开发者把所有业务逻辑都交给它。我希望有一天，智能能够像数据库一样：软件在需要智能时直接调用它。Jev 不是主要用来编写代码的，而是用来增强代码本身的能力。

Sam：也就是说，开发者把 Jev 嵌入自己的程序，由自己决定如何编排工作流、管理数据和控制行为。

Diogo：没错。我们不需要所有应用都使用同一套 Harness，而是需要让开发者能够把自己的逻辑放进去。可以把 Jev 想象成 n8n 或无代码编辑器中的一个节点，负责提供智能，其他逻辑和数据仍然由开发者掌握。我们想扩展的是软件工程师能够使用的“逻辑词汇表”，让他们可以把智能融入现有系统，而不是被迫把整个系统改造成一个智能体。

09

明确的工作流和可靠的决策机制，

让系统承担更复杂更有价值的任务

Sam：这是否意味着开发者需要回到更传统的、以工作流为中心的软件设计方式？

Diogo：是的。如果我们想把一项工作规模化，让它在后台长期运行，或者成为一个可以反复调用的依赖，那么可靠的工作流就非常重要。软件工程师需要的是能够组合、分层、长期维护的基础能力。明确的工作流和可靠的决策机制，能够让系统承担更复杂、更有价值的任务。

Sam：所以使用不可靠的模型做自动化，可能永远无法真正到达可靠自动化的终点；而 Jev 希望通过更明确的代码和工作流解决这个问题。

Diogo：这对自动化来说是一个优势，但对一次性的即时任务来说就未必值得。介于两者之间还有很多可能：可以让 LLM 理解任务并生成工作流，再用 Jev 处理其中需要大量判断的步骤。假设你要处理公司知识库里的大量文档，就不一定需要让一个大型模型对所有文档进行复杂推理，我们可以把工作拆开，在适当的环节调用更高效的决策模型。未来会出现很多这样的组合方式，创造空间非常大。

10

TypeSafe 的下一步

Sam：接下来，你们还计划做什么？

Diogo：我们还有很多想发布的东西。我更希望直接把成果展示给大家，而不是只告诉大家我们正在做什么。我们还计划探索多个模型，以及更灵活的访问方式让开发者能够体验一些尚未达到正式可靠性标准、但已经展现出很强能力的模型。我也很期待让更多人参与进来，帮助我们探索这些技术的用途。

关注+星标，获取AI前沿进展与开源一线动态