我们发布了改进的 Jev 1.14.0，同时为梦想者推出实验性功能：图像、一种新类型和更长上下文，进入 danger zone 需自担风险。我们一直在争论可靠性与创造力之间的平衡：面向生产环境构建者，应发布经过内部极限检验的模型；但团队无法完全理解什么能激发世界的惊喜并构建酷炫科幻，也不想把极端可靠性价值观强加给梦想者。于是，在 API headers 中以 danger zone 标志分享这些功能。

太长不看：我们发布了改进后的 Jev 1.14.0，同时为梦想者带来实验性功能：图片、一种新类型和更长上下文。进入 danger zone 请自行承担风险。🔥

我们的理念

我们一直在激烈讨论的一个问题，是如何在可靠性与创造力之间取得平衡。

要真正服务好生产环境的开发者，我们就应该发布达到我们智能质量标准、并在内部经过极限压力测试的模型。

另一方面，我们的团队不可能完全理解，要如何在这个世界激发愉悦感、打造酷炫的科幻体验。我们也不想把自己对极端可靠性的价值观强加给那些梦想者。

我们的解决办法是：把这些面向梦想者的功能放在 API header 的“danger zone”开关后面共享出来。这些功能会保留在未来的模型中，就我们目前判断，它们优于市面上已有方案，并且还会持续大幅提升。但要提醒一句：我们认为它们仍有太多不稳定之处，无法为生产场景打包票！

请把这些新能力看作我们过去两年隐秘研发成果的延续。它们还不太适合自动化，但玩起来非常有趣。它们也是我们正在努力提升可靠性、以使其达到 TypeSafe 标准的早期预览。

可组合图片

我们不仅为未来的 Jev 模型启用多模态能力，也为你们熟悉且喜爱的当前版 Jev 启用了它。惊喜吧：你们熟悉且喜爱的 Jev（jev-1.13.0）其实一直是多模态的！

图片支持通过在 assets 中做查找替换来实现完全可组合。你可以把它放在我们 JSON 接口支持的任何位置：在 state、instructions，甚至 criteria 里！放手去玩，推动技术边界，也告诉我们 Jev 还有哪些地方可以改进。

提醒一下：所有模型（包括 Jev）在处理多模态时都不如纯文本表现好。把问题拆解成最简单的子问题会很有帮助。

TypeSafe-Danger-Zone-Images: true

查看文档：docs.typesafe.ai/go/images

决策之外的类型

我们还引入了另一种新类型：box。它返回单个边界框，不允许出现类型错误。这是我们第一个不纯粹用于 smart-if 语句的类型，也预览了我们超越简单决策、探索 System One Models 还能支持什么的方向。

我们最近在这方面取得了巨大进展，因此目前只在 jev-1.14.0 上启用（剧透一下）。

查看文档：docs.typesafe.ai/go/box

看来，大小确实很重要 💅

关于上下文长度，我们清楚地听到了大家的呼声。Jev 实际支持的上下文长度比我们在生产环境中开放的长得多。我们有意加以限制，是因为和所有模型一样，Jev 在更长上下文下可靠性会降低，而这种限制也能促使大家在生产环境中采用更有效的用法。

不过我们不是你父母，所以虽然我们强烈建议限制上下文长度，但你现在不必再受限：

TypeSafe-Danger-Zone-Long-Context: true

查看文档：docs.typesafe.ai/models#context-length

选择加入以帮助我们

我们很喜欢社区想要帮助模型变得更好的热情！我们增加了一个选择加入选项，让你可以用自己的查询帮助我们发现模型的不稳定之处。我们仍然不会用你的查询进行训练，但这确实让我们更容易发现问题，并协助调试你的使用场景。

jev-1.14.0

我们还在 jev-preview 下发布了新版 Jev！这次发布并不追求炫目，而是对所有方面做微小而细致的改进。大多数方面应该都会好一点点，但我们预计最大的提升出现在多语言支持上。

模型发布通常都应该是严格改进，但我们非常清楚开发者有多讨厌更新依赖。jev-latest 会在一周内更新到 jev-1.14.0。jev-1.13.0 还会保留一段时间。

我们打算在正式弃用 jev-1.13.0 前给出 60 天警告，对 jev-1.14.0 则给出 30 天警告。在此之前我们会发布一份弃用政策。

衡量智能

众所周知，我们不喜欢公开基准测试。不过，对于如何衡量对开发者最重要的那种智能形态，我们有自己内部的估算方式。

这里我们想尝试点新做法：我们会把你们当成年人看待，直接和大家分享这些内容。

几点说明：

• 这个衡量方式只是我们的最佳猜测，并且会持续演进。如果以后再次展示内部数字，不要指望它们会保持一致。
• 不要完全相信它。始终优先采用你针对自身使用场景所做的实验与评估。
• 我们只纳入开放权重模型，因为我们严格保护验证集，并且对模型提供商的数据政策感到担忧。
• 这很可能对我们自己的模型更有利。你可以直接忽略我们的模型，转而关注开源模型之间的相对排名。

下一步

很多人喜欢问我们接下来会发布什么样的科幻功能。虽然我们正在做一些令人惊叹的东西，但预计大多数发布都会是“美妙的无聊”（就像我们认为 AI 应有的样子）：全面小幅改进、更好的稳定性，以及面向真实部署的功能。

讨论气氛整体偏积极，许多人肯定更长上下文、图像框选、低延迟决策和低成本带来的实用提升，也有人好奇大家会用它构建什么。分歧主轴在于这次发布到底是真实能力迭代，还是因缺少护城河或需要投资人支持而把原本禁用的多模态能力逐步放出来；营销语气则同时引来“尴尬、像 Reddit 梗”的吐槽和“老派坦诚、令人耳目一新”的相反评价，另有不少人转向本地或隐私友好的替代方案。

认为更新在上下文、图像框、决策质量和低延迟上已有实用价值

• 不少参与者觉得，虽然单个改动不算革命性，但更长的上下文、新的 box 类型与可组合图像已经能落地；模型做决策又稳又便宜，低延迟的视觉响应更被视作可能放大一到两个数量级的设计空间。有人还希望未来支持语义分割，并提到在自己的场景里仍依赖 Gemini 3.5 Flash-Lite 做图像分割。（认可度：较多人）
• > 延迟和响应速度才是真正的游戏规则改变者，高出一到两个数量级的响应会打开很大的设计空间。（@vessenes）

怀疑官方此前故意隐藏多模态能力，这次只是逐步放出既有功能

• 有观点认为，团队早先压着一批功能不放，是因为知道自己几乎没有护城河；现在只是把原本就已具备、却被禁用的多模态能力一点点放出来，好显得更强、跑得更快，其中还带着广告口号式的包装。（认可度：少数人）
• > 感觉这等于承认大家熟悉的 Jev 1.13.0 其实一直都是多模态的，只是之前被关掉了，需要投资人补贴才打开。（@aliasxneo）

认为本地、CPU 或隐私友好的替代方案已经足够好，可作为云端替代

• 多名参与者推荐本地路线：需要轻量或隐私时，能在 CPU 上运行和训练的本地模型，很多情况下准确率与表现反而更好；也有人给出自建的 OpenDecision、dlgo 等本地或开源权重推理选择，并称本地模型 JevK5-4B 在自己的基准上只比 Jev 低不到一个点。（认可度：较多人）
• > 如果追求轻量或隐私，能在 CPU 上跑和训练的本地模型，很多情况下准确率和表现反而更好。（@nico）

批评发布文案尴尬、像 Reddit 梗或苹果广告，但文档质量很好

• 有人觉得所有发布都太“尴尬”，文案像 Reddit 版主或苹果广告口号，充满“给建造者和梦想家”“尺寸显然重要”之类的梗；但同一人也承认文档写得好，且没有把这些尴尬内容带进去。（认可度：少数人）
• > 为什么他们的每次发布都这么尴尬？就像 Reddit 版主写的一样，不过文档倒是很好，似乎没把这些尴尬带进去。（@kypro）

认为老派/企业级的发布风格反而令人耳目一新

• 与吐槽文案相反，也有人觉得这次发布很有“企业级、老派”的味道，和当下其他 AI 公司那种发布方式不同，反而让人感到 refreshing。（认可度：少数人）
• > 这种发布很有企业级、老派的味道，和其他所有模型或 AI 公司的发布方式都不一样，非常令人耳目一新。（@jofzar）

认为基准分数不可全信，必须按自己的场景实测

• 有人肯定官方主动标注“别轻信 AI 基准”的做法，并指出基准是可以被刷的指标，只能给出大致位置，真正好不好必须拿自己的用例去测。（认可度：少数人）
• > 喜欢他们直说别轻信 AI 基准：这类指标能被刷，只能给大致估计，必须按自己的用例去测。（@jjcm）

对模型降低任务门槛与社区/发布氛围感到兴奋或好奇

• 有人好奇大家会拿这些模型构建什么；也有人回顾从“需要研究团队和五年”到十二年后就能做出基于 Jev 的鸟类分类器，高兴于问题变简单、有人愿意分享成果。此外，Discord jam、网站排版像改进版 Linux From Scratch、发布贴不错等也都得到正面评价。（认可度：较多人）
• > 从“需要一支研究团队和五年”到十二年后就能做出基于 Jev 的鸟类分类器，这种让问题变简单、大家愿意分享成果的进步令人高兴。（@AftHurrahWinch）

有价值的补充

• 决策模型实现方式：用一个骨干模型（如 qwen 3.5 9b）配合特殊线性头，由线性头给出前向传播读数；相关开发者还放出兼容 Jev API 语义的本地推理引擎 dlgo，支持开源权重、视觉输入 LLM、扩散图像生成、Vulkan/快速 CPU 内核与 System One 快速推理模式。（@computerex）