From InstructGPT to Jev: What Comes After ChatGPT — Diogo Almeida, TypeSafe Co-founder & CEO

Mira Murati 前 OpenAI 核心成员 Diego 创立 Type Safe，发布首个"代码即消费者"的大模型 Jev，上线一周日处理 token 破万亿，他称 AI 寒冬已被避免。

会解数学难题的 AI，为何不会干活？

Diogo Almeida 是 TypeSafe 联合创始人兼 CEO，曾在 OpenAI 工作，并推动过早期 InstructGPT 的部署。离开后，他没有再做一个更会聊天的机器人，而是想把 AI 变成能嵌入软件、被代码调用的基础设施。TypeSafe 最新发布的 Jev，正是这条路线的一次试探：不追求把模型塞进聊天框，而是让它承担程序内部大量细小、重复、但必须可靠的判断。

这期回答了 7 个问题：

1. 为什么 AI 能解高难数学题，却自动化不了大量基础工作？
2. 为什么一次“拒答”对聊天机器人无伤大雅，对软件依赖却可能是灾难？
3. 比起同一输入必得同一输出，开发者真正需要的可靠性是什么？
4. 怎样把一个大模型任务拆成可验证、可修复的微决策？
5. 为什么拿用户真实数据训练，反而可能让模型困在当下？
6. 模型平台爆红后，为什么 CEO 把开发者社区排在投资人之前？
7. 编码智能体为什么被 KV cache 锁死在“单模型、长上下文”范式里？

被问到 RLCD 的北极星，以及 AI 为什么迟迟没有带来大规模自动化时，Almeida 把矛盾说得很直白：今天的模型已经能碰数学中的千禧年难题，却还无法替人完成许多基础、重复、并不令人愉快的文书工作。"How can we like solve millennium prize problems in math but still not automate even the most basics of works?"（我们怎么能解千禧年数学难题，却连最基础的工作都还无法自动化？）

他的答案不是“模型还不够聪明”，而是模型缺少连接真实工作的插头。AI 像一台“supercharged engine of automation”，自动化引擎的马力已经很大，但它没有合适的接口，插不进企业流程、数据库、业务规则、权限系统和异常处理里。于是它能在演示里答对题，却不能稳定地接住一张真实订单、一条客服记录或一次风控判断。

这意味着，下一轮竞争未必主要发生在“谁的模型更会答题”。真正稀缺的东西，是把模型能力拆开、嵌进软件、让它在复杂流程中持续工作的接口。TypeSafe 的赌注也在这里：如果模型质量确实重要，公司即使消失，外界或许仍要一两年才能追上这个方向。但 Almeida 也承认，他并不知道这个时间判断是否准确。模型能力只是前提；能否把它接入经济活动，才决定智能会不会变成产出。

被问到为什么反对在 API 基础层做 safety alignment，也就是让模型优先服从平台预设的安全约束时，Almeida 的论证来自软件工程，而不是价值判断。人和聊天机器人对话时，看到一句“I'm sorry I can't read DNA.py”，最多是烦一下，换个问法或自己动手绕过去。但模型一旦成了后台依赖，情况就变了：用户发来一条异常消息，模型突然拒答，下游系统甚至不知道这个隐形依赖存在，整条链路却已经断了。

"Like you want the software to just stochastically break because a user sent like a weird message in there."（难道你想让软件仅仅因为某个用户发了一条奇怪消息，就随机崩掉吗？）这里的 stochastically，意思是带随机性地发生。对软件来说，最怕的不是明确报错，而是同一个接口在难以预料的条件下换了一套行为。

Almeida 区分了两种 alignment。capability alignment 是按用户要求做事；safety alignment 则可能是让模型执行“另一个人”的规则。在聊天产品里，后者可以是产品选择；在通用 API 里，它却会破坏可编程性。这不等于他赞成把技术拿去伤害别人。他的边界是：价值判断不该以底层拒答的方式，变成所有软件系统都要承受的故障源。基础设施首先得让依赖它的人知道，它会怎样运行。

被问到 Jev 为什么没有 seed，也就是为什么不保证“同样输入永远得到同样输出”时，Almeida 先把 reliability 拆开了。类型安全、确定性、模型输出忽高忽低的 jaggedness——可以理解为能力不平整、这里很强那里突然失灵——都属于可靠性。但他认为，开发者真正更需要的不是 determinism，而是 robustness。

"you want given similar inputs get similar outputs."（你真正想要的是：相似的输入，得到相似的输出。）确定性解决的是：一字不改地重复请求，能否复现同一个答案。鲁棒性解决的则是：意思没变，但提示词里多了一个 UUID、nonce 或无关标记，模型会不会突然换一种判断。

TypeSafe 用这种方式做测试：在 prompt 中插入语义无关的 UUID 或 nonce，然后观察输出是否保持接近。因为现实软件里的输入从不会整齐划一。同一份简历可能多一个编号，同一张工单可能多一段无关日志，同一个用户需求可能换十种说法。若模型只在“标准输入”上表现稳定，它仍然无法托管业务决策。

这意味着，AI 工程的测试会从单点复现，转向检查输入邻域：改写、噪声、上下文微变之后，行为是否还一致。Almeida 并不排除未来提供确定性模型，只是提醒开发者：确定性通常要拿 intelligence per dollar，也就是每美元买到多少智能，去交换。它是否值得，得由具体场景证明。

被追问 Jev 的 choice、score、Bernoulli 等 API 原语该怎么用时，Almeida 给出的不是一套“提示词技巧”，而是一种写 AI 软件的方式。choice 接近基于 enum 的 switch：在有限选项中选一个；Bernoulli 接近 if：判断某个条件成立的概率；score 则适合排序或阈值判断。它们不是把大模型当作文案生成器，而是把它放进程序的分支结构里。

"I like to break things down into its like its smallest semantic unit."（我喜欢把事情拆到它最小的语义单元。）例如，一个系统不该只问模型“这条内容该不该拒绝”，而应拆成多个独立问题：是否涉及某类内容、是否出现某种组合情境、风险分数是否越过阈值。每一步都可单独测、单独记录失败案例、单独调整阈值。

他还主张把 state、instructions、criteria 都用结构化 JSON 传入，而不是统统塞进字符串模板或 system message。因为 system message 像“disgusting global variables”——令人厌恶的全局变量：所有规则混在一起，任何一条失效都难以定位。拆分之后，模型出错不再意味着重写整段 prompt 碰运气，而能变成具体的 bug：少了一个判断、阈值设错、遗漏了某类状态。代价也很实际：调用次数更多，编排更复杂，部分信息还会重复。这套方法成立的前提，是模型足够便宜，并适合后台并行运行。

被问到 TypeSafe 是否把自己看成 data lab，以及什么样的人才算优秀数据人才时，Almeida 先说了一件反直觉的事：他们不愿意训练用户数据，即使理论上可以通过条款拿到授权。原因不是数据没价值，而是今天的真实数据可能太有价值，以至于把模型困在今天。

"even if we had all of the data of the present, we would just overfit to the present and then it wouldn't work."（即使我们拥有当下的全部数据，也只会对当下过拟合，然后它就不灵了。）真实流量存在强烈的 power law，也就是少数高频模式占据绝大多数样本。大量用户反复问类似问题，模型若对这些模式过拟合，就会被“fracture”：在常见需求上越来越顺，却在少见组合、未来任务或边缘条件上出现裂缝。

TypeSafe 想做的不是一个只擅长服务当前流量的产品，而是多年后仍能嵌在软件栈深处的通用基础设施。Almeida 把数据工作描述成观察模型的“cognitive core”，找出它不平整的地方，再做外科手术式修补。重点不在堆更多样本，而在构造能同时泛化到多个维度的训练任务。

这意味着，未来的数据壁垒不只是用户日志规模。更难的能力是：能不能为尚未出现的软件形态设计训练任务。越贴近今天的点击流，不一定越接近未来的通用性。当然，jaggedness 不可能被彻底消除；数据团队能做的，是持续发现缺口，并避免用局部补丁制造新的断裂。

主持人提到，Jev 发布后 TypeSafe 的 Discord 社群已达到 100,000 人，而 Almeida 宁可安排 Discord town hall，也不愿把所有时间都交给 VIP 投资人与重要关系人。对此，他说，如果自己那张塞满会面的日历里没有社区的位置，会让他觉得“dirty”。他甚至认真想过，要不要在走去录音室的路上直接开一场 town hall。

"actually in my ideal world, it would be like community all the time."（事实上，在我的理想世界里，应该永远都是社区优先。）这不只是创始人的情绪表达。TypeSafe 发布前的验证并不漂亮：超过一半试玩者没有理解产品，团队几乎没有收入，非技术同事一度担心他们卖的是“维生素”——听起来有益，却不是立刻缓解疼痛的“止痛药”。

真正让产品爆发的，是开发者把它接进代码后发现，它能在后台产生价值。Almeida 甚至认为，所有人类各写几条查询，可能也比不上一个重度用户的 for loop：后者把一次定义好的重复任务放进后台，不断调用模型、持续生成结果。开发者平台的产品市场匹配，因而不一定能靠企业访谈提前测出来；它常常由少数能把新能力接入真实工作流的人先跑出来。

边界也在这里。社区优先不等于忽视企业客户，而是平台不能只根据采购流程设计产品。若最早感到价值的人是开发者，组织的注意力、文档、反馈渠道和资源分配，就应先向他们倾斜。

被问到用户不断索要的 vision、context length 等能力，以及平台应该给用户“想要的”还是“实际需要的”时，Almeida 没有给出一个漂亮答案。TypeSafe 在 stealth 阶段花了两年，押注一个外界当时并未明确索要、但团队认为显然有价值的方向。这种坚持带来了 Jev，也带来了一个难题：产品究竟应该替用户过滤复杂性到什么程度？

"developers are like we don't want to put the burden on them to figure out the genes of intelligence."（开发者会说：我们不想承担弄清智能基因到底是什么的负担。）这里的“智能基因”，指模型究竟在哪些条件下有效、哪些条件下会退化。以 context length 为例，用户会直接要求更长上下文；但上下文窗口更长，不等于模型在长上下文中不衰退，也不等于它能准确抓住真正相关的信息。

如果平台一味迎合显性需求，可能是在做讨好式开发：给了一个看上去很大的数字，却没有解决实际问题。可如果平台过度替用户判断，又会滑向 Almeida 反对的 nanny-state 逻辑：系统像家长一样替成年人做主，并把选择藏进黑箱。

这意味着，AI 平台的竞争不仅是模型能力竞争，也是产品治理竞争。什么能力应默认开放，什么能力该标记为实验性，何时坚持技术判断，何时让用户自己试，都会塑造平台的可信度。Almeida 的结论很诚实：他们“we don't know the answer to be honest”。不知道答案不是空白，而是承认这里没有一条适用于所有开发者的产品公式。

被问到最值得创业者和研究者长期投入的方向时，Almeida 点名了一件很具体的事："coding agents free from the tyranny of the KV cache."（让编码智能体摆脱 KV cache 的暴政。）KV cache 是模型推理时缓存之前 token 的键和值，用它可以避免每次都从头计算，所以很省。但它也悄悄塑造了今天编码智能体的架构：围绕一个大模型，不断往同一段长上下文后面追加内容。

这使得许多看似合理的设计变得昂贵。为什么子代理难以只做简单任务？因为要把父任务的状态传给它，子代理仍需足够强、足够便宜的模型去读懂上下文。为什么多模型路由困难？为什么压缩上下文总是损失信息？为什么多个代理很难共享工作？根源都在于状态跟着长上下文和单一模型一起移动。

Almeida 想象的替代方案，是把工作组织成带标签的子任务树：状态不必整包传递，代理按需检索相关分支；某些状态可以只读共享；多个代理则能更明确地协调读写。这样一来，简单任务可以交给轻量模型，复杂判断再升级给更强模型。

这意味着，编码智能体的下一次提升未必来自更强的单模型，而可能来自重写状态管理、记忆检索和任务分解。Almeida 没有保证这条路会成功，只认为其中有大量值得亲手试验的编程模式。真正的问题不是能否再堆一段上下文，而是能否让上下文不再成为所有智能协作的枷锁。

Almeida 的主线不是“再造一个更会聊天的模型”，而是把 AI 改造成软件可调用、可验证、可组合的基础设施。第 1 条说，AI 缺的不是智力，而是接入经济工作的接口；第 4 条则把这个接口进一步落到工程方法上：不要把全部希望压进一条大提示词，而要把任务拆成可测、可修、可记录的小决策。

第 3 条的“语义扰动下的稳定性”，和第 8 条的“摆脱 KV cache”，看似分别在谈模型评测与编码智能体架构，实际都指向同一件事：AI 必须离开单次演示，进入长期运行的软件系统。前者要求它面对细微变化时不乱跳，后者要求系统面对复杂状态时不被一段长上下文绑死。

这也解释了他为什么如此在意拒答、结构化输入、数据过拟合和开发者社区。一个模型偶尔答出惊艳答案，不能自动转化为生产力；它必须能被程序放心调用，能在出现错误时定位原因，能随着业务变化继续工作。对读者而言，真正该问的或许不是“哪个模型最聪明”，而是：你手里的工作流里，哪些小判断已经足够明确，明确到可以拆开、测试、设阈值，并交给机器在后台反复执行。