Jev 为什么不想做聊天机器人：从 System One 到可编程判断层
来源：Frank Wang 玉伯：Jev：离开 OpenAI 后，他做了一个不跟人聊天的 AI。本文根据收件箱中的本地存档整理，原文转述了 Latent Space 主持人 swyx 对 TypeSafe 联合创始人兼 CEO Diogo Almeida 的访谈。文中的行业判断和公司路线均属于访谈嘉宾或原作者观点，不等于独立验证的事实。
这篇访谈最值得看的地方，不是“又出现了一个更快的模型”，而是它提出了一个反直觉的问题：AI 为什么一定要先和人聊天，才能进入软件？
Diogo Almeida 参与过 InstructGPT 和早期指令遵循方向的工作，后来离开 OpenAI 创办 TypeSafe，并围绕 Jev 提出一种不同于传统聊天模型的产品方向。按访谈中的说法，Jev 更接近一个 System One Model，或者“大型可编程模型”：它不负责替用户写一篇答案，而是把判断、分类、排序和选择直接变成软件可以调用的输出。
本文不把访谈中的叙述当成 Jev 的官方技术规格，也不重复已经整理过的 API、Choice、Score、Boolean 细节。重点放在四个问题：为什么聊天式 AI 仍然不够、为什么软件需要判断层、为什么工作流评测比榜单更接近真实价值，以及这种路线对 Agent 产品有什么启发。
一、他参与做出了“好学生”，却开始怀疑考试
Diogo 并不是从场外批评聊天模型的人。根据访谈转述，他参与过 InstructGPT 和指令遵循方向的早期工作，曾经非常直接地相信：模型太有用了，应该尽快交给用户。
他也认可早期 ChatGPT 团队对产品体验的打磨。但随着模型能力提升，一个反差变得越来越明显：模型可以给出流畅、完整、看起来很聪明的答案，真实落地却经常集中在写文案、生成解释和辅助对话；很多机械、枯燥、需要持续判断的工作，仍然要由人手动完成。
问题不一定是模型不会做，而是软件没有把模型放在合适的位置。
访谈中的另一个反思涉及 RLHF。用人的偏好训练模型，可以让回答更自然、更符合期待，但“让人喜欢”与“帮助人做出正确决定”并不完全相同。流畅、自信、结构完整的回答容易获得好评；承认不确定、提出罕见可能性、拒绝过度推断，反而可能不那么讨喜。
这里需要区分两个问题：
- 用户觉得它说得对不对；
- 它在真实任务里是否判断得对。
这一区分后来贯穿了 Jev 的产品叙事。一个系统不应该只追求“看起来很懂”，还应该能暴露自己的不确定性，并让程序决定什么时候继续、什么时候转交更强模型或人工。
二、从“调用 AI 的人”倒推到“调用 AI 的代码”
访谈里有一个很简单的倒推：如果 AI 最终承担大量有经济价值的工作，调用它的主要是人，还是代码？
人一天能发起的请求有限。程序一旦运行起来，可以持续读取信息、做判断、把结果传给下一个组件，再根据状态决定下一步。于是，真正能把 AI 变成基础设施的，不只是让人和模型聊得更自然，而是让软件可以稳定地调用判断能力。
Diogo 曾把这个方向写成文档并与 Sam Altman 讨论。按照访谈中的回忆，Sam 认可这个想法，但组织的主线仍然更多围绕聊天产品和人的交互体验展开。这里的冲突不是“老板没听懂”，而是认可一个想法，和让整个组织围绕它重新设计接口、评测和交付方式，是两件事。
对于开发者来说，分歧会落到很具体的地方：
- 能不能控制某个函数被选择的倾向？
- 能不能得到足够明确的概率或置信度？
- 能不能让输出直接进入代码分支，而不必先生成一大段文字再解析？
- 能不能在模型不确定时把任务交给另一个系统？
如果这些控制点不存在，开发者就只能在巨型提示词里反复请求模型“多做这个、少做那个”。这使得软件控制面变成了一场对话，而不是一个可测试的接口。
三、System One：不是另一个天才，而是可组合的判断函数
Jev 的命名借用了“系统一”和“系统二”的比喻，但不能把它简单理解成“人脑直觉的数字版”。更准确的工程解释是：很多软件任务根本不需要一篇长篇大论，只需要在受控答案空间里完成一次判断。
例如：
输入：工单内容、用户资料、当前业务状态
问题：应该进入哪个队列？是否需要人工复核？风险分数是多少？
输出：有限选项、布尔判断、分数、概率或置信度
后续：代码执行路由、审批、重试、降级或人工接管
它与聊天式调用的区别，不只是响应更短，而是责任边界更清楚：
| 聊天式调用 | 可编程判断层 |
|---|---|
| 模型生成一段解释 | 程序声明允许的答案空间 |
| 应用从文本中解析意图 | 输出可以直接进入分支和状态机 |
| 失败通常表现为语义漂移 | 失败可以按概率、阈值和 schema 处理 |
| 一个大提示词承载很多职责 | 多个小判断分别测试、组合和替换 |
这并不意味着系统一模型可以包办所有复杂工作。恰恰相反，它更适合作为软件内部的一个窄组件：从几个选项里挑一个、判断一个条件是否成立、对候选打分、决定是否升级，而不是直接承担开放式研究、长文写作或复杂解释。
四、把巨型系统消息拆成明确的小问题
访谈中，Diogo 特别反感把所有安全边界、流程规则和业务要求都塞进一条巨型系统消息。这样的消息很像一个全局变量：什么都想放进去，谁都依赖它，最后却很难确认哪条规则在什么时候生效。
更可控的做法是把职责拆开：
应该由代码强制的内容
- 哪些目录不能读取；
- 哪些 API 不能调用；
- 哪些用户没有权限；
- 哪些金额超过审批额度；
- 哪些状态不能逆向转换；
- 哪些数据不能写入日志。
这些内容不应该只写在提示词里。它们应当由权限系统、路径 allowlist、schema、数据库约束、网络策略和确定性校验来执行。
必须依赖模型判断的内容
- 一条请求属于哪个业务类别；
- 一段文本是否值得人工复核；
- 这个候选是否与当前任务相关；
- 哪个工具更可能解决当前问题；
- 这个输出是否包含风险信号。
这些内容可以交给判断模型，但要给它清楚的问题边界、合法答案、阈值和回退路径。
需要人工承担的内容
- 高影响动作是否真的应该执行；
- 风险阈值是否适合当前业务；
- 模型错误是否改变了业务目标；
- 是否要扩大权限、预算和自动化范围。
软件并不是把所有东西交给 AI，而是让每个必要环节都能调用 AI，同时保留代码和人真正应该拥有的控制权。
五、Jev 这个名字背后的经济假设
访谈转述把 Jev 与杰文斯悖论联系起来：资源使用效率提升、单位成本下降后，总需求未必下降，反而可能因为更多人开始使用而上升。
放到 AI 基础设施中，这个思路意味着：目标不只是让今天的一次调用便宜一点，而是让原来因为成本、延迟或不稳定而不值得自动化的判断，变得值得被软件持续调用。
因此，评价一个判断模型不能只看“每百万 token 多少钱”。更接近业务的指标是：
单位美元可用判断能力
= 正确且可执行的判断数量
÷ 完整调用成本
完整成本不止包括模型价格，还包括：
- 请求和编排开销；
- 失败重试；
- 错误判断造成的人工复核；
- 延迟影响的转化或吞吐；
- 监控、评测和校准；
- 需要转交更强模型时的二次调用。
如果模型变便宜，却让应用产生更多误路由和人工回滚，就不能称为真正的单位成本改善。
六、别拿成绩单证明它，让它去值夜班
Diogo 对公开排行榜的怀疑，不是反对评测，而是反对把一个分数当成智能本身。只要某个分数变成目标，组织就可能围绕它优化：寻找相似题目、调整数据分布、优化评测策略，最后得到的是更会考试的系统。
访谈中更看重的是工作流评测：把模型放进真正的业务任务，看它在哪些输入下出错、置信度是否有参考价值、延迟和成本是否可接受，以及它能不能连续运行。
原作者转述了一个很小但有启发性的稳定性测试：在提示词里加入一个不影响语义的 UUID。若只是添加无关字符，就让结果发生明显变化，说明系统对非因果变化过于敏感。
这类测试的价值不在于 UUID 本身，而在于它把“看起来稳定”变成了可重复实验：
- 固定真实任务和答案标准。
- 只改变与任务无关的输入噪声。
- 比较分类、概率、延迟和后续动作是否发生异常变化。
- 把高置信错误单独记录，而不是只看平均准确率。
真正让一个基础能力有价值的信号，也不一定是有人试用了几次，而是它是否被程序持续调用，是否进入后台工作流，是否在无人值守时仍然有明确的失败处理和人工接管。
但“有人在夜里持续调用”只能说明产品进入了真实流程，不能单独证明模型可靠。可靠性仍然需要客户任务、离线回放、shadow、低风险自动化和持续校准来证明。相关落地方法可以继续阅读：Jev 能不能上生产：从四次失败到置信度校准的完整验收方法。
七、训练数据与客户的暗数据不是一回事
访谈中还有一个容易被混淆的区分：合成数据和暗数据。
Diogo 认为，直接把所有用户数据拿去训练，可能让模型越来越适应最常见的需求，却忽略那些少见但重要的情况。因此，他更重视围绕能力缺口设计合成训练数据：先明确任务、找出模型不会做的部分，再构造能够覆盖边界的样本。
而客户侧的暗数据，是企业已经积累、却因为分析成本过高而没有充分处理的材料。它可能是历史工单、日志、合同、内部文档、图片或业务记录。模型变得足够便宜后，企业才可能把这些内容重新拿出来分析。
两者的方向不同：
| 数据类型 | 作用 | 主要问题 |
|---|---|---|
| 合成训练数据 | 修补模型能力缺口 | 任务设计是否覆盖真实边界 |
| 客户暗数据 | 作为软件输入被分析和处理 | 权限、隐私、质量、成本与结果验证 |
这也提醒产品团队：不要把“模型训练数据更多”自动等同于“客户数据会被拿去训练”。数据用途、保留周期、租户隔离和权限边界必须在产品合同中写清楚。
八、PMF 可能需要先被做出来
TypeSafe 早期遇到的一个问题是：很多试用者无法立即理解它卖的是什么。理解的人觉得很酷，却不知道采购流程怎样开始。这种产品像维生素，不像止痛药：它可能有价值，但用户还没有一个清晰的痛点入口。
发布之后，开发者开始用它做出团队没有预先设计的东西，并提出更高调用额度甚至算力需求。这个故事被用来说明：对于新的基础能力，需求未必会以完整的用户访谈答案提前出现，有时必须先把能力做出来，用户才能看到用途。
这不是“没有用户购买就一定是市场教育不足”，也不意味着每个新模型都有隐藏的巨大市场。产品团队仍然需要区分：
- 用户不买，是因为能力不够；
- 用户不买，是因为价值没有被包装成可理解的任务；
- 用户不买，是因为接入成本、权限或合规风险太高；
- 用户不买，是因为当前流程根本不值得自动化。
最有用的验证不是询问“你觉得酷不酷”，而是观察用户是否愿意把一个真实、重复、可衡量的工作流交给它，并且愿意为稳定结果付费。
九、不是为了创业，而是为了把问题做到底
访谈对“离开大公司创业”的叙述也比较克制。Diogo 并不把创业包装成研究员的必经之路，也不认为成立一家 AI 实验室本身就有意义。
他的区分是：
- 如果只是想自由实验，大实验室可能已经足够；
- 如果有一个清晰、重要、现有组织不愿全力投入的方向，才有理由建立新的团队；
- 关键不是创始人的光环，而是要解决的任务是否值得长期承担。
这个判断对 AI 创业尤其重要。模型、接口和算力都在快速变化，真正能形成长期产品的，不是“我也接上了一个模型”，而是团队是否对某个工作流、客户问题和结果指标有持续承诺。
十、AI 不一定消灭 SaaS，聊天框可能只是最浅的一层
很多软件的 AI 功能停留在侧边栏聊天：用户问一个问题，模型给一段回答，用户仍然要自己打开页面、复制字段、确认状态、触发动作。
Diogo 设想的方向是让判断能力退到软件内部：
用户输入
-> 软件读取业务状态
-> 判断层选择、分类或校验
-> 确定性规则检查权限和副作用
-> 系统执行或请求人工批准
-> 结果回写并留下证据
这不是把聊天框换成“全自动 Agent”这么简单。SaaS 的优势在于它已经知道客户每天在做什么，知道数据在哪里，也知道哪些重复动作值得自动化；但要真正进入流程，还必须解决权限、审计、幂等、失败恢复、人工接管和结果证明。
所以，现有 SaaS 不一定只能被替代。它们也可能成为最适合嵌入可编程判断层的宿主。
对 Agent 产品的五个工程启发
1. 把“回答”与“决定”分成两种接口
开放式生成适合解释、草拟和探索；结构化判断适合路由、筛选、校验和状态转换。不要让一个接口承担两类完全不同的责任。
2. 把模型不确定性变成流程状态
低置信度不应该只出现在日志里。它可以触发人工复核、切换更强模型、扩大检索范围或暂停副作用。
3. 代码负责硬约束，模型负责软判断
权限、路径、金额、租户、密钥和状态机不要依赖提示词；语义分类、相关性判断和候选排序才是模型更合适的区域。
4. 用任务评测替代单一榜单
建立自己的真实任务集、无关噪声集、高风险样本和回放集，记录准确率、校准、延迟、成本、重试和人工接管。
5. 让“持续被调用”成为价值信号，但不是质量证明
后台调用说明产品进入了工作流；它不代表结果已经正确。越接近无人值守，越需要审计、熔断和恢复机制。
来源边界
本文使用本地 Obsidian 文章对 Latent Space 访谈的转述作为主要来源，并保留了原作者对 Jev、TypeSafe、RLHF、工作流评测、暗数据和 SaaS 的叙述边界。文中关于工程架构、评测和 Agent 产品的内容是整理后的分析，不应归因给访谈嘉宾。
本文没有把访谈中的公司路线、融资经历、产品能力、用户数量或商业判断当作独立核验的事实；需要确认 API、模型规格、价格、延迟和生产可用性时，应回到 TypeSafe、相关 SDK 和实际测试结果。
相关延伸阅读：
संबंधित गाइड
Jev / System One Model 实测：把语言模型变成软件可直接调用的决策函数