Codex和Claude Code都跑偏了，前OpenAI研究员称Jev出现前AI世界是个悲剧
Jev 是什么：不是又一个聊天模型
Diogo Almeida 在 Latent Space 播客里反复强调一个判断：Claude Code 和 Codex 本质上还停在同一个阶段——AI 围绕人提供辅助。他关心的痛点很工程化：为什么 AI 能解千禧年数学难题，却连最基础的重复工作都自动化不了？
他的答案是 Jev，TypeSafe 公司的第一个"大型可编程模型"，内部也叫 System 1 模型或机器原生模型（machine-native）。核心设计目标只有一条：让代码成为模型输出的直接使用者。预训练面向文本补全，RLHF 面向聊天回复，RLVR 面向可验证推理，而 Jev 面向的是程序调用。公司名 TypeSafe 本身就是暗示。
Jev 这个名字来自 Jevons Paradox（杰文斯悖论）——技术进步降低资源成本后，消耗量反而上升。Diogo 把它解读为**"每美元智能"要做到行业最优**，即站在成本-能力的帕累托前沿上。
RLHF 的真正缺陷：模式坍缩
Diogo 对 RLHF 的批评比一般"RLHF 让模型讨好用户"更深一层。他指向一个几乎无人讨论的现象——mode dropping（模式坍缩）。
类比 GAN 出现前的图像生成模型：为了覆盖整个概率分布，输出会变得模糊；而 GAN 会直接丢掉小概率类别，只生成最常见的样本。RLHF 也发生了类似的事：模型偏向生成安全、常见的答案，牺牲了概率分布的真实校准。这带来两个后果：
- 长文本中的错误累积没有按直觉发生——模型为了不出明显错误，变得极其保守，但微妙的遗漏更难察觉。
- 文本模型不擅长决策——让生成文本的模型承担过多判断任务，效果天然不好。
这也是 Jev 选择 RLCD（面向校准决策的强化学习）的原因：优化目标从"给出让人认可的回答"变成"成为软件能可靠调用的能力"。
三个 API 原语：Choice、Score、Noul
Jev 的接口设计对前端/工程背景的开发者非常友好，直接映射到程序控制流：
| 概念 | 对应程序结构 | 用途 |
|---|---|---|
| Choice | switch / match | 选择分支，对应枚举选择 |
| Noul | if 条件判断 | 伯努利概率，取值连续的真/假判断 |
| Score | 排序、阈值筛选 | 评分、排序、> / < 比较 |
Noul 这个名字来自 Bernoulli 的一部分，表达伯努利概率。Diogo 强调它们不是简单的 Bool 或 float——直接用 Pydantic 映射成整数会出问题。每个原语都可以独立评估、单独设阈值，能力不足时转人工或暂不部署。
核心工程理念：把任务拆到最小语义单元
Diogo 给开发者的使用建议非常具体，而且和前端工程化思维高度一致：
- 结构化输入：状态、指令、判断标准用 JSON 对象传入，不要先拼成字符串模板。"写普通程序时，我们不会先把所有数字转成字符串再传给内部。"
- 拆小问题：把复杂任务拆到最小可独立判断的语义单元，每个问题只负责一件事。代码控制最终行为，模型只负责判断。
- 并行提问：一大段状态信息只需传入一次，给每条消息加 ID，针对各个 ID 分别提问。
- 可验证性：拆分后每一步都能单独测量，而不是给模型一大段系统消息后赌它全做对。"不要读取这个子目录""不要把 API 密钥传给 DeepSeek"这类约束，应该由程序保证，而不是靠提示词反复要求。
"过去我们给模型一大段系统消息，等它返回一大段结果，再检查它有没有遵守每条要求。现在回头看，这种做法挺不可思议的。"
这套思路本质上就是把 AI 调用当作类型安全的函数调用来设计，而不是当作聊天来设计。
反对安全对齐写进模型底层
Diogo 不反对安全本身，但反对把特定价值判断直接固化进通用模型能力。他的论点是：对于供程序调用的 API，突然返回一句拒绝，相当于发生了类型错误。
他把智能比作数据库——我们不会要求数据库在执行查询时自行判断用户会不会把结果用于坏事。API 也应该有类似的责任边界：底层提供能力，使用责任在开发者。有开发者在 Slack 上问"我们可以这样用 Jev 吗"，他的第一反应是"你是开发者，具体应用怎么设计不该由我们批准"。
他区分了能力对齐（让系统按要求完成任务，行为可预测）和安全对齐（模型优先服从提供方的另一套规则）。前者是软件工程师需要的，后者对 ChatGPT 这种直面用户的产品合理，但不该照搬到 API。
可靠性 > 确定性
Diogo 明确区分了两个概念：
- 确定性（determinism）：相同输入得到相同输出。对单元测试有价值，但不应是首要目标。
- 稳健性（robustness）：语义相近的输入得到相近判断。他更看重这个。
测试方法之一：在提示词里加入不同 UUID 作为随机标记，问题含义没变，模型判断就不该大幅变化。当前大语言模型在这一点上经常不靠谱——而开发者恰恰容易被这种细微波动坑到。
关于版本管理：已部署的模型不会悄悄改动，因为 API 是别人程序里的依赖。但新版本发布速度会比大家习惯的快得多，目前不能承诺永久维护每个旧版本。Jev 1.13.0 可能暂时作为 LTS。
不追 Benchmark，追"每美元智能"
Diogo 对公开榜单的态度近乎反感，理由也很实际：
- 刷分容易——收集与测试集相似的数据训练，等于绕几步优化基准成绩。
- 分数脱离真实价值——价格和速度好测量，但"模型到底有多好"很难用一个分数概括。
- 开发者最终要把模型放进自己的工作流，测量实际表现，不能只看价格、速度或一个总分。
TypeSafe 内部有评测，但 Diogo 管得很严，防止团队有意无意针对评测做优化。"不能在模型到底有多聪明这件事上自欺欺人。"
四类核心应用场景
| 场景 | 说明 |
|---|---|
| 暗数据分析 | 企业积累了大量因处理成本太高而闲置的数据，用 Jev 低成本分析 |
| 实时流程判断 | 响应时间每减 10ms 都有经济价值，电商、AI 助手尤其需要 |
| 验证一切 | 用 Jev 检查其他 LLM 的调用和输出，给 AI 系统加可观测性 |
| 智能软件 | 把智能判断嵌入软件核心逻辑，让程序组合出以前做不到的行为 |
Diogo 尤其看好暗数据分析和编程 Agent。编程 Agent 领域正在发生一件让他意外的事：开放式 Agent 项目都在兴奋地接入 Jev，而 Claude Code 和 Codex 围绕单模型构建——他很好奇它们会怎么应对。
发布后的真实数据
- 发布视频播放量达 3800 万次。
- 日调用量超过一万亿 Token，且夜间调用不停——说明有程序在持续使用，不只是人尝鲜。
- Diogo 更在意调用量而非注册人数："哪怕全世界每个人都来试几次，调用量可能还不如一个真正用它创造价值的开发者写下的一段循环程序。"
- 真正紧张的不是候补名单人数，而是速率限制——开发者一旦把 Jev 用进程序并获得实际价值，就会希望大幅提高调用额度。
从 InstructGPT 到 TypeSafe
Diogo 曾推动 InstructGPT 上线，早期版本甚至用了他自己设计但未公开的训练算法。它上线后很快占了当时大语言模型使用市场约 50% 的份额。但后来他看到它主要被用于营销文案写作（Jasper AI、Copy.ai）和填充网页的文字，一度担心自己让互联网变得更糟了。
转折点是一个倒推：如果 AI 以 API 形式存在，未来主要谁在调用——人还是代码？他的判断是绝大多数调用会来自代码。但当时的优化几乎都面向人与模型的对话。他跟 Sam 聊过这个方向，Sam 建议"那就去做"。他原以为一周就能验证，结果花了好几年。
"在我看来，Jev 出现之前的 AI 世界，简直是个悲剧。强大的'智能引擎'已经有了，把它接进实际业务流程的接口却仍然欠缺。"
对研究者的建议：先找 North Star
Diogo 对新兴 AI 实验室的评价很直接：光有漂亮的研究履历不会自动创造价值。他不看好拿到资金后重复前沿实验室已有工作的做法。
建议分情况：如果只是想自由尝试课题，现有实验室可能仍最合适；如果找到了值得长期投入的新任务，他支持创业。"先明确自己的核心目标，再围绕真正值得解决的问题展开研究。"
值得关注的延伸方向
Diogo 抛出两个他特别希望有人探索的方向：
- 游戏中的智能 NPC：不必每帧调用 Jev，只在状态机里加入智能判断，就能让游戏世界更生动。
- 摆脱 KV Cache 对编程 Agent 设计的限制：他写过一篇文章《KV Cache Rules Everything Around Me》，解释现有编程 Agent 为什么难做模型路由、子 Agent 效果不如预期、上下文压缩棘手。核心问题是：为高效利用 KV Cache，系统被迫持续在已有上下文后追加内容，固定在同一个模型上，偏离了软件工程里明确管理状态、抽象问题、拆解任务的做法。
"如果访问上下文的成本足够低，Agent 就不用每次从零开始工作。'持续学习'问题的一部分其实是记忆管理——信息并非不存在，而是系统不知道怎样有效找到它。"
Rainsho 的判断
这篇文章值得认真读的原因不是 Jev 本身有多强，而是 Diogo 提出的问题足够尖锐：AI 已经这么强，为什么大多数软件几乎没变？ 这个问题对前端工程师尤其刺耳——我们做了那么多 AI 聊天框侧边栏，但产品核心逻辑里几乎没有 AI 的位置。
Jev 的设计哲学——把 AI 当数据库调用、拆到最小语义单元、结构化输入、代码控制行为——和前端工程化的主流思路高度一致。Choice/Noul/Score 三个原语本质上就是把模型输出映射到 switch/if/filter，对工程师来说几乎零认知成本。如果这条路线成立，"AI 落地"可能不需要重新学一套范式，而是把 AI 能力像调用 API 一样嵌进现有代码结构里。
当然，Diogo 自己也承认 Jev 离理想状态还很远，单步推理强、多步推理下降明显。但"每美元智能"这个优化目标——不追榜单、不追参数量、只追性价比前沿——在当前 AI 军备竞赛里是一股稀缺的清醒力量。