AI-translated from English; not yet reviewed by a fluent editor.

# Jev 的更大愿景：让 AI 决策融入我们日常使用的软件

> TypeSafe 首席执行官 Diogo Almeida 主张，将 AI 用于软件中的小型决策。本文分析 Jev 的发布、它的局限，以及哪些证据才能证明它带来了实质变化。

By BIG CHANGE Editorial

Published: 2026-09-22T00:45:03.943Z
Updated: 2026-09-22T00:45:03.943Z
Canonical: https://bigchange.ai/blog/jev-typesafe-ai-decisions-software-diogo-almeida

![Pencil sketch of document cards passing through a small decision switch, constrained by a checklist, into two output trays.](https://bigchange.ai/api/media/file/jev-interview-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE. A decision switch inside a larger workflow; not a depiction of Jev’s internal architecture.

客户修改订单上的地址。消息还要求退款，提到包裹受损，并暗示这已经是第三次出问题。把消息转化为有用的答复是一项工作；决定要更新哪些记录、由哪个团队介入，以及哪些操作需要授权，则是另一项工作。

Jev 是 TypeSafe AI 于 2026 年 9 月 15 日开放早期访问的模型，目标正是帮助软件处理这类决策。它为软件生成受约束的结构化答案。这次发布邀请人们重新思考：应用中有多少部分必须依赖与通用模型进行长时间对话。[TypeSafe 的发布公告](https://typesafe.ai/blog/introducing-system-one-models-and-jev)

Latent Space 于 9 月 21 日发布的访谈，对这套理念作了最全面的阐述。访谈对象是 TypeSafe 联合创始人兼首席执行官 Diogo Almeida，主持人为 swyx。我们审阅了这场时长两小时二十二分钟对谈的完整英文字幕，并核对了产品文档。本文分析该访谈和公开证据；我们没有独立测试 Jev 的基准表现。[观看原始访谈](https://www.youtube.com/watch?v=cFx9Z3ZXca0)

我们的理解是，Jev 最重要的主张涉及自动化的基本单位。企业或许可以先在既有流程中自动化一个边界明确的判断，再决定是否负责任地交出整个流程。如果这类判断足够便宜、能够反复执行，且容易衡量，常见的商业软件就可能获得实用能力，而不必把每次交互都变成聊天会话。

这不仅会影响软件的用户，也会影响工作流程的设计者。仍然需要有人决定哪些操作获准、什么算错误，以及由谁处理异常。决策质量将决定这种方法带来的是可靠服务，还是只是加速错误。

## TypeSafe 实际发布了什么

Jev 的公开接口接收一个状态和一组带类型的问题。它有三种基本操作：Choice（选择）从指定选项中作出选择；Score（评分）根据评分准则进行评估；Noul 则以零到一的数值表示一项陈述成立的概率。Choice 和 Score 会返回分布和置信度字段，Noul 没有单独的置信度字段。多个问题可以共享所提供的状态，但分别进行评估。[TypeSafe 的接口文档](https://docs.typesafe.ai/introduction)

在客户服务应用中，开发人员可以用这些基本操作区分地址变更请求和取消请求、评估紧急程度，并检查消息是否包含受损证据。这些是假设示例，并非 Jev 部署结果。接下来要如何处理这些答案，由应用决定。

把解读和权限分开，是一种有用的做法。AI 可以推断客户想要退款，但不能仅仅因为得出这一结论，就获得批准退款的权限。应用可以核实订单、执行退款限额，并在适当情况下要求审批。

TypeSafe 将这类模型称为 System One，借用了快速、直觉式思考的说法。应把这个名称视为对目标工作负载的描述；它不能证明模型具有人类式认知，也不能划出简单任务与困难任务之间的明确界线。一个简短的问题也可能掩盖复杂判断，尤其是在信息不完整时。

## 工程变化的重点是更小、可检查的决策

Almeida 倡导将任务拆解：提出范围狭窄的问题，然后在代码中组合答案。[访谈，1:03:02](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=3782s)

再看一次包裹受损的例子。用一句话指示系统处理投诉，会把多个判断藏进同一个答案。更容易检查的设计，是分别确认客户要求采取什么操作、能否识别订单，以及现有证据是否支持受损索赔。政策规则则应放在这些判断之外。

这让失败更容易调查。如果系统把地址变更请求转给退货团队，运营人员可以检查这项分流决策；如果受损评估有误，可以用过往案例测试这一组件。团队可以修改明确的规则来改变政策，无须重写宽泛指令，再寄希望于模型始终以同样方式理解。

这种做法也有成本。组件越多，需要维护的接口就越多；问题也可能意外遗漏让答案变得明确的上下文。两个看似独立的判断，可能依赖同一条误导性证据。即使每个部分单独看来都能接受，拼成的工作流程仍可能产生不可接受的结果。

TypeSafe 的文档模式包括同时提出多个问题、组合评分，以及把不确定案例转给其他流程处理。它们介绍的是架构选项，并不能证明某个客户流程已经适合无人值守运行。[TypeSafe 的模式示例](https://docs.typesafe.ai/patterns)

有用的测试是看任务拆解是否同时改善问题诊断和实际结果。能够说明哪个步骤出了问题，本身就有价值；降低失败的频率和后果，才是这项业务方案的依据。

![Pencil diagram: an input document branches into three parallel questions, whose answers enter a rules box before action or review.](/api/media/file/jev-interview-inline-v1.png)

## 格式有效的答案仍可能是错的

发布中“Jev 不会产生幻觉”的说法，需要从较窄的范围来理解。TypeSafe 将这项保证限定于输出是否符合允许的模式结构；这并不能证明选出的答案为真。其公告本身也区分了模式保证与实证评估。[TypeSafe 对类型安全的说明](https://typesafe.ai/blog/introducing-system-one-models-and-jev)

假设应用允许的选项包括：`damaged`、`late`以及`other`。返回`damaged`完全符合有效格式，即使包裹只不过晚到了。即使模型不能编造第四个类别，仍可能选错类别。如果清单遗漏了一个确实必要的类别，模式本身就成了问题的一部分。

结构化输出也是现有的工程方法。OpenAI 于 2024 年 8 月推出了受模式约束的 Structured Outputs，并明确指出，即使输出值符合要求，模型仍可能出错。因此，评估 Jev 时应考察其决策质量、不确定性报告、延迟和成本这一特定组合，而不能把所有结构化 AI 输出都说成是它首创的。[OpenAI 最初的公告及局限说明](https://openai.com/index/introducing-structured-outputs-in-the-api/)

对采购者而言，这一区别会改变评估计划。模式测试关注软件能否使用答案；事实测试关注答案是否与证据一致；政策测试关注由此产生的操作是否获得许可。通过其中一项，不能取代通过其余测试。

## 访谈中最重要的挑战涉及校准

在 1:09 左右，Almeida 否定了模型已经实现完美校准的说法，并承认模型会出错。[访谈，1:08:50](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=4130s)

校准关注的是：对于一组预测，模型预测的概率与实际观察到的结果是否相符。即使模型不能在每个高概率案例中都答对，它仍可能有助于提示不确定性。TypeSafe 的入门文档明确保留了这一区别。[TypeSafe 对校准的解释](https://docs.typesafe.ai/introduction/machine-learning-primer)

API 的置信度字段还需要进一步区分。TypeSafe 将其描述为根据答案分布得出的统计量，它不能与“答案正确”的独立测得概率互换使用。其文档建议根据任务及其后果选择阈值。[TypeSafe 的置信度文档](https://docs.typesafe.ai/confidence)

这些都是实际问题。设想某个分流模型处理简短英文消息时表现良好，但处理混合多项请求的长篇投诉时却力有不逮。单一汇总分数可能掩盖这种弱点。对于表现较弱的群体，高置信度的决策可能比熟悉群体中显示相同数字的决策更需要审查。

因此，团队应评估预计会收到的案例，包括信息缺失、措辞陌生和刻意混淆的输入。团队应按类别检查错误，并比较将案例送交审查的成本与错误行动的成本。阈值应是由证据支持的实际运营选择，而非从演示中照搬的数字。

有关校准的研究早在 Jev 出现前就已开展。Chuan Guo 等人 2017 年发表的一篇常被引用的论文，研究了现代神经网络校准不佳的现象及改进方法。这项研究为问题提供了背景，并没有验证 TypeSafe 的模型。[《现代神经网络的校准》](https://arxiv.org/abs/1706.04599)

## 可靠性还包括服务变化时会发生什么

对谈区分了稳健性与确定性，并讨论了版本稳定性，但未承诺普遍提供长期支持。[访谈，41:24](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=2484s)以及[49:40](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=2980s)

这些是不同的采购问题。确定性关注相同输入是否会产生相同输出；稳健性关注无关变化（例如记录编号改变）是否会导致不合理的行为变化。模型可以一直重复同一个错误答案，同时保持确定性；它也可能略有波动，但外围工作流程仍然可靠。

这两项性质都无法消除生命周期风险。企业需要知道作出某项决策时使用了哪个模型版本、该版本是否会继续提供，以及如何评估替代版本。即使在服务商的测试中有所改进，新版本仍可能改变客户精心调试过的工作流程行为。

合理的做法是保留具有代表性的案例、记录版本，并在迁移重要工作之前比较新旧版本。备用方案同样重要：准确的决策服务仍可能无法使用。如果应用没有安全的暂停方式或替代工作流，服务正常运行时间在实践中就会成为决策质量的一部分。

这就是一个吸引人的 API 如何变成运营依赖。采购、监控和迁移规划不会因为模型变快而消失。单次调用看起来如此简单，反而容易让人忽略这些工作。

## 为什么速度和价格数字需要背景

TypeSafe 宣布的工作流程结果包括速度提升 193.6 倍、成本改善 444.6 倍。公告说明这些是该公司自行编写的工作流中取得的上限表现。所谓参考答案取自其他模型给出的概率估算，而非经过独立验证的真实分类结果。公司还提醒，其简短演示有利于 Jev，且可持续的长期定价仍有待确立。[TypeSafe 对评估结果的限定说明](https://typesafe.ai/blog/introducing-system-one-models-and-jev)

这些限定应与数字一同呈现。与参考模型一致可能提供有用信息，但它衡量的内容不同于是否符合已确认的客户案例事实。供应商设计的工作流或许与买家有关，却不一定代表买家请求的实际分布。

合适的比较应包括整项工作：收集上下文、作出决策、应用规则、处理异常以及从失败中恢复。模型调用成本更低，但若送给人工审核的工作太多，总成本仍可能更高；模型调用慢一些，若能避免代价高昂的返工，也可能更经济。

延迟也需要在应用实际所在区域进行测量。在接近服务基础设施的位置进行的演示，并不代表其他地区用户的体验。交互式系统应检查慢请求，而不能只看平均值；后台处理可能更关注吞吐量和总成本。

Jev 的名字让人想到效率提升可能带来更多消费。对单家企业而言，这引出了一个预算问题：哪些新决策开始值得评估？哪些决策只是变得便宜到足以被不必要地评估？增加模型调用本身并不是成果。

## 不同的研究目标，以及尚未完成的证据

Almeida 的研究论点把数据、任务选择和 RLCD，与其对偏好优化的批评联系起来。[访谈，7:23](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=443s)以及[22:12](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=1332s)

RLCD 是“用于校准决策的强化学习”（Reinforcement Learning for Calibrated Decisions）的缩写。TypeSafe 将其描述为针对可用决策和概率进行训练，与基于人类偏好和可验证奖励的方法形成对照。这是公司对自身目标的解释，不应误当成对完整训练方法的独立验证。[TypeSafe 的 AI 入门介绍](https://docs.typesafe.ai/introduction/machine-learning-primer)

即使训练方法仍在评估，一个更广泛的问题也值得继续探讨：训练目标奖励了哪些行为？优化说服力的模型，可能很好用，却不会以便于代码处理的形式揭示不确定性。面向决策设计的接口可以让不确定性更容易处理，但输出仍须通过外部检查与现实核对。

TypeSafe 将这个问题与模式坍缩联系起来：偏好优化可能把可能输出的范围缩窄到人们会奖励的回答。这是公司对一种失败模式的解释，并非断言所有经过偏好训练的模型都无法用于决策。[TypeSafe 对偏好优化的讨论](https://docs.typesafe.ai/introduction/machine-learning-primer)

Almeida 的背景让这一论点格外有意思。他是 InstructGPT 论文的共同作者；该论文研究了如何利用人类反馈训练语言模型遵循指令。这一作者身份可以核实，但笼统声称每个实验室都犯了哪些错误，则是另一回事。[InstructGPT 论文](https://arxiv.org/abs/2203.02155)

他对预训练支出和缺乏明确方向的新实验室提出的异议，同样属于选择实用任务这一论点。[访谈，1:49:32](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=6572s)以及[2:03:10](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=7390s)

对采购者而言，相关经验是询问产品能为一项定义明确的流程做什么。研究履历、计算支出和独特模型架构可以解释一家公司如何开发产品，却无法证明在另一家企业部署时的经济效益。

访谈还谈到 Almeida 离开 OpenAI、早期采用困难以及开发者主导的增长。[访谈，1:31:27](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=5487s)以及[1:56:48](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=7008s)

这些回忆有助于理解公司的优先事项，但不是经过审计的采用证据。最终，开发者平台应以持续运行的实用工作负载，以及工作负载失败时所提供的支持来评判。产品发布后的热情值得进一步调查，却不能取代这类记录。

## 既有软件或许比新聊天窗口收获更多

Almeida 预计，SaaS 产品会变得更强，而 AI 会退居幕后。[访谈，1:19:57](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=4797s)

这是一条值得研究的可信方向，因为软件本来就有许多地方，可以通过一次有效判断改变下一步。日程应用可以在预订前识别含糊请求；媒体档案可以帮助研究人员整理资料；服务台可以区分常规更新和需要处理的投诉。这些是可能的设计，并非已报告的 Jev 部署。

用户界面几乎可能无需改变。用户会发现错误减少、重复分类变少，或更快等到合适的工作人员。已经了解工作流程并能把更好的决策融入其中的公司，可能获得商业优势。

现有软件企业仍会面临竞争。如果许多开发者都能使用同一种判断能力，单凭模型调用很难形成差异。外围产品必须提供有用的数据访问、周到的交互设计，以及可靠完成工作的方式。

关于就业的主张需要更加谨慎。减少一项任务所需的投入，可能改变人员配置、扩大服务量，或让工作转向异常处理。具体结果取决于机构及其服务需求。访谈和早期访问产品的发布，都无法证明 Jev 会保护、消除或创造多少岗位。

在 BIG CHANGE 的行业概述中，可衡量的事件是出现了另一种决策自动化方法。广泛采用、生产力收益和劳动力市场影响是之后需要用不同证据回答的问题。

## 暗数据、实时软件与演示的局限

对谈讨论了存储数据、交互式应用、验证和计算机操作演示。[访谈，1:34:50](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=5690s)

每种类别都需要不同的评估方式。档案处理可以容忍一定延迟，但需要抽样检查结果并追溯到原始记录的方案。实时界面需要可预测的响应速度。用于评估另一模型的检查器，应针对该模型实际会犯的错误进行测试，包括两个系统都犯同一个错误的案例。

对计算机进行操作时，选择操作只是系统的一部分。系统还需要准确表示界面、执行操作的方式，以及核实预期变化是否发生的方法。精美演示可以证明某个操作序列成功执行过一次；可靠自动化则需要反复试验，并能从中断中恢复。

游戏也要采用同样谨慎的判断。由模型驱动的角色可以根据更丰富的状态作出反应，同时仍由游戏引擎限制可执行的操作。这样的设计是否改善游戏体验，取决于响应速度、一致性和具体体验设计。每一帧都加入推理，并不会自动让游戏更有趣。

这些区别可以避免类别错误：应当按某个实用组件实际承担的角色评价它，不应让它自动继承外围整个应用的所有能力。

访谈还提出微调、视觉能力和其他模型形态等可能性。[访谈，1:10:27](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=4227s)以及[1:26:23](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=5183s)

规划路线图的讨论，不应被写成发布计划中的既定依赖。应围绕现有接口构建产品，明确哪些能力必须由独立组件提供，并在新功能真正推出时再进行评估。这样既能为未来改进留出空间，也不会把猜测说成产品功能。

## 编程智能体或许可以采用不同的任务分工

Almeida 提出，编程智能体可以超越单模型循环，通过更低成本的状态处理和共享上下文来协作。[访谈，1:40:17](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=6017s)以及[2:09:29](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=7769s)

一种可能的架构是：由能力较强的编程模型开发改动，再用成本较低的决策调用对相关文件分类，并通过普通软件管理后续任务；另设独立审核者检查最终补丁。这是一项设计提议，并非经过基准测试的建议，也不能证明 Jev 已能替代现有编程智能体。

吸引人之处在于有选择地提供上下文。如果子任务只需要一个接口和几项限制条件，向它发送整段对话可能造成浪费。明确的任务记录可以帮助系统辨认哪些事实重要、哪些事项已有决定，以及哪些改动仍未完成。

风险在于把协同建议误认为并发安全保证。两个智能体可能都认为自己应该写入同一个文件。概率模型不能取代防止冲突写入的软件机制。仍须通过权限、版本检查和锁机制来强制落实最终结果。

同样，以更低成本检索过去的工作，可能改善记忆管理，但并未解决所有被称为“持续学习”的问题。记住先前尝试、理解失败原因，以及可靠地适应新情境，是彼此不同的能力。有说服力的评估应考察已完成任务、回归问题、冲突和人工介入，而不是只计算智能体或调用次数。

## 安全会贯穿整个系统，而不会凭空消失

Almeida 倾向于应用层安全控制，而非让模型拒答；swyx 对其后果提出质疑。[访谈，13:11](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=791s)以及[1:42:29](https://www.youtube.com/watch?v=cFx9Z3ZXca0&t=6149s)

这里确实存在一个设计问题：无人值守的应用必须应对依赖组件拒绝执行、发生故障或返回不确定结果的情况。它需要明确的应对路径，但这一观察并不能决定每一项防护措施都应该放在哪一层。

即使模型正确识别了预期操作，应用仍须强制执行访问权限。删除记录的请求可能被完全正确地理解，却仍未经授权。即使请求在技术上有效，也可能违反运营方政策。决策服务如果缺少适当上下文，就无法负责任地回答这些问题；应用必须保留对实际操作的控制权。

把更多决策交给软件，意味着在部署前明确边界变得更加重要。团队需要决定哪些证据才够、哪些操作仍可撤销，以及个人如何质疑或纠正结果。避免了一次与模型交互中的不便，并不足以证明整个系统安全。

## 什么能证明发生了重大变化？

这次发布让一项明确的实验成为可能：选择一项结果可观察、范围有限的流程，记录当前做法，包括错误及人员修复错误所花的时间；在赋予系统操作权限之前，先用具有代表性的案例测试基于决策的版本。

衡量无需人工介入便能正确完成的案例比例、未被审核发现的错误、转交给人工的工作量，以及每个完成案例的总成本。保留原始证据，方便审核者检查结果为何获准。模型、政策或输入人群变化时，应重新进行比较。

评估可能发现，流程中只有一部分已经适合自动化。这是有价值的结果。由自动化处理常规分类，把含糊案例留给有经验的运营人员，可以很有用，却不代表有理由扩大自主权限。

Jev 的发布和 Almeida 的访谈提出了一个关于 AI 如何进入经济领域的大胆假设：反复执行、范围受限的决策，可以让人们已经依赖的软件变得更有能力。下一步证据应来自这些系统长期承担实际工作时的表现，并把错误和异常纳入核算。读者真正看得见变化的地方，就在那里。

## Sources

- [Latent Space 原始访谈](https://www.youtube.com/watch?v=cFx9Z3ZXca0) — Latent Space 对 Diogo Almeida 的访谈，于 2026 年 9 月 21 日发布。本文中提供了带时间戳的对应片段链接。
- [推出 System One 模型与 Jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev) — 2026 年 9 月 15 日。TypeSafe 发布的 Jev 早期访问公告，包括性能主张和评估局限。
- [入门介绍](https://docs.typesafe.ai/introduction) — TypeSafe 文档介绍了模型的输入状态以及 Choice、Score 和 Noul 三种提问方式。
- [置信度](https://docs.typesafe.ai/confidence) — TypeSafe 文档区分了置信度与概率，并解释应用如何使用阈值。
- [AI 入门介绍](https://docs.typesafe.ai/introduction/machine-learning-primer) — TypeSafe 对其训练目标，以及如何在多组预测间理解校准的说明。
- [模式示例](https://docs.typesafe.ai/patterns) — TypeSafe 展示如何将模型决策与应用逻辑结合。
- [在 API 中推出 Structured Outputs](https://openai.com/index/introducing-structured-outputs-in-the-api/) — 2024 年 8 月 6 日。OpenAI 介绍受模式约束输出及其局限。
- [《现代神经网络的校准》](https://arxiv.org/abs/1706.04599) — Chuan Guo 等人于 2017 年发表的神经网络校准研究。这篇论文并未评估 Jev。
- [利用人类反馈训练语言模型遵循指令](https://arxiv.org/abs/2203.02155) — 2022 年发表的 InstructGPT 研究论文，Diogo Almeida 为共同作者，研究如何利用人类反馈进行指令遵循训练。