Jev 与 Next Letter Lab

一、Jev 是什么

Jev 是 TypeSafe 的旗舰模型，也是 TypeSafe 发布的第一个 System One Model。它的目标不是写一段让人阅读的长文本，而是在给定状态和明确问题后，快速做出软件可以直接使用的结构化判断。一次调用可以得到一个类型化的答案、候选答案的概率分布，以及在部分问题类型中提供的 confidence。

这里的“状态”可以是一句话、一段文档、一个 JSON 对象，或者一组按顺序排列的文本。状态描述模型需要观察的材料；问题则描述代码希望模型判断的事情。把这两个部分分开后，应用可以更容易地替换数据、记录请求、测试边界，并把最终的阈值和副作用留在普通代码中。

TypeSafe 将这种方向称为 Machine Native Intelligence：模型输出应该具有结构、可观察、可测试、速度快、成本可控等适合软件系统的属性。Jev 的价值不在于模拟一个聊天窗口，而在于把自然语言中的判断压缩成一个清晰的接口，让后续代码能够分支、排序、路由或请求人工复核。

二、System One 与普通文本模型的区别

普通大语言模型通常被训练为生成下一个 token，再把许多 token 组合成回答。调用方常常需要从回答中解析 JSON、函数名或标签，并处理格式错误。System One 的接口从问题开始：调用方先声明答案空间，模型只在这个空间中作判断，返回值直接对应声明的类型。

这不代表 Jev 比通用模型更适合所有任务。它更适合“答案形状已经明确，但判断依赖语义”的环节，例如判断工单属于哪个队列、文档是否与问题相关、消息是否触发某条规则，或者在多个工具之间选择下一步。它不适合直接撰写长回答、生成代码、解释推理过程，或替代精确的计算器和解析器。

TypeSafe 文档把这种取舍称为 fast, focused judgments。一个问题应当足够窄，让模型可以在短时间内完成一次局部判断。若需求包含多个独立因素，应把它拆成多个问题，再由代码决定权重和组合方式，而不是把所有要求塞进一个宽泛的提示词。

三、State、Instructions 与 Criteria

State 是被评估的材料。例如客服消息、订单记录、当前游戏状态、候选工具列表，都可以放在同一个 JSON 对象里。字符串适合只有一段文本的简单任务；对象适合带有字段关系的记录；数组适合消息、候选项或时间序列。Jev 目前只接受文本输入，因此图片、声音和视频必须先由其他程序转成文字或结构化字段。

Instructions 说明要判断什么；criteria 说明每个答案意味着什么。对于 Choice，criteria 是“选项 → 解释”的映射；对于 Score，criteria 是有顺序的等级列表；对于 Noul，criteria 可以分别说明 true 和 false 的含义。把边界条件写进问题定义，比在返回后猜测模型意图更可靠。

官方建议尽量减少 state 中与当前判断无关的内容。Jev 1.13 的文档特别提醒，状态越大、干扰越多，准确率可能下降。工程上更稳妥的做法是先用代码过滤和检索，再把与问题直接相关的字段交给模型；需要多个判断时，可以让它们共享一次 state 并在同一请求中并行评估。

四、三个核心问题类型

TypeSafe 把问题封装成三个可组合的 primitive。它们不是三种回答风格，而是三种不同的答案契约。一次请求可以同时包含多个问题；每个问题都独立地对同一份 state 做判断。

Choice 是相对选择：当多个选项彼此竞争时，它们的概率组成一个分布。Noul 是对一个陈述的绝对判断，多个相反或相近的 Noul 不一定会自动满足加和为 1 的关系。选择问题还是真假问题，应该在设计接口时明确区分。

五、概率与 confidence 怎么读

概率回答“在这个问题的答案空间里，各个结果分别有多大支持度”。在 Choice 中，应用可以读取完整分布，选择最高项，也可以根据业务需要保留前几项。概率不是让模型自由生成的 token 概率，而是对已经定义好的选项做判断。

Confidence 是另一条信息。它描述模型对这次 Choice 或 Score 结果的整体把握程度，适合用作自动执行、人工复核和转交更强模型的门控条件。它不是“这一次一定正确”的保证，也不应该直接当作业务成功率。

TypeSafe 对“校准”的解释是群体意义上的：在大量相似预测中，标记为 0.8 的结果应当大约有 80% 的机会成立，标记为 0.2 的结果应当大约有 20% 的机会成立。这种统计性质不能替代单个样本的验证，因此实际系统仍应记录结果、观察误差，并根据业务风险设定阈值。

六、Jev 适合和不适合做什么

官方文档与示例将 Jev 放在大型软件流程的局部决策位置。常见方向包括支持工单分类和路由、意图识别、函数或工具选择、RAG 文档筛选与重排序、结构化信息验证、内容审核、风险分级、置信度门控，以及把语义特征交给后续的传统机器学习模型。

Jev 1.13 的模型说明明确提醒：它不是计算器，计数和数字运算应交给代码；它对隐含条件、双重否定和多层间接关系更敏感；它也没有被训练成通用文本生成器。若目标是写一段自然回答，应该让生成模型负责表达，让 Jev 负责分类、校验或候选选择。

语言方面，TypeSafe 将英语列为主要训练语言。中文和其他 CJK 文本可以输入，但官方建议先用自己的数据测试准确率，并结合 confidence 做路由。这个项目的输入界面虽然支持中文，但逐字符实验更适合观察机制，不应被当作中文生产写作工具。

七、Jev 与 computer use、游戏控制

Jev 本身不是一个可以直接看屏幕、移动鼠标或按键的 computer-use agent。它目前只接受文本、JSON 对象或文本数组，也不提供点击、键盘、浏览器等副作用。要让它参与 computer use，需要由外部控制器完成三件事：观察环境、把观察结果编码成状态、执行模型选出的动作。

游戏控制是同一模式的高频循环：把角色位置、障碍物、速度、目标和可用动作编码进 state，把动作定义成有限的 Choice，例如向左、向右、跳跃或保持。代码根据概率和 confidence 决定是否执行；低置信度时可以保持不动、降低动作频率，或交给另一个模型处理。这样，模型负责局部决策，游戏循环、碰撞检测、时间步长和输入副作用仍由程序负责。

社区已经出现了用 Jev 读取模拟器状态并控制 Mario、用状态选择 Snake 动作，以及把 Jev 暴露为 MCP 工具的实验项目。这些项目说明了“状态 → 有限动作 → 执行”的接法，但它们不是 TypeSafe 官方对实时 computer use 的能力承诺。图像理解、长时规划、连续动作和安全确认仍然需要外部组件。

八、Next Letter Lab 如何使用 Jev

本项目把一个本来用于有限决策的模型，放进一个很小的逐字符实验中。用户输入需求后，服务端把需求和当前输出前缀一起作为 state，并提出一个 Choice 问题：下一个字符应该从哪些候选中选出。

1. 01输入需求用户输入一次请求
2. →
3. 02构造状态需求 + 已有前缀
4. →
5. 03选择字符读取完整概率分布
6. →
7. 04继续或结束追加最高概率项或 END

候选集合包含小写字母、数字、少量常用标点，以及 SPACE、NEWLINE、TAB 和 END。服务端不会把概率最高的字符串当作完整回答，而是每次只取一个选项，再把这个选项追加到 generated_output。下一次请求会看到更长的前缀，直到 Jev 选择 END，或者达到固定的 20 次上限。

这段实现是为了把 Jev 的“有限选择 + 概率”展示出来，不是推荐的文本生成方法。官方文档明确说，Jev 没有按长文本生成来训练；把字符一个个串起来会很慢，前面的一次误判还会成为后续所有请求的新状态。真正的生产系统应该让生成模型负责写作，再让 Jev 做路由、审核、校验或候选选择。

九、界面中的字段

十、当前限制

本页面把请求次数固定为 20 次，因此输出很短；达到上限时并不表示 Jev 判断了 END。每一轮都要等待一次网络请求，延迟会随着轮数累积。字符集合也只覆盖英文小写字母、数字和少量符号，无法完整表达中文、大小写混合文本或任意 Unicode 字符。

当前实现每次选择概率最高的允许项，并使用固定的候选顺序处理概率相同时的并列情况。它没有 beam search、回溯、采样、候选重排或人工确认，也没有把整个答案的全局一致性作为额外约束。因此页面适合用来观察局部决策和概率，不适合评估 Jev 的长文本能力或构建可靠的问答产品。

如果将这个实验继续扩展，优先级应是记录每轮 state、choice、概率和模型版本；用离线样本测试不同问题写法；把高风险动作放在 confidence gate 后；并用代码处理能确定完成的事情，例如计数、格式校验、长度限制和权限检查。