AI 会解难题,为什么软件还不敢让它做小决定?

一个订单系统想请模型判断：这封来信是在申请退款、修改地址，还是询问物流？

程序需要的是一个稳定、可检查的结果，好让下一步流程启动。

模型却可能给出一大段解释，或者在某个输入下突然回复“抱歉，我不能处理”。

对聊天用户来说，重问一次也许够了；对一条每分钟处理数千条请求的软件流水线来说，返回值的形状一变，下游就可能停住。

模型会说话，不等于它适合成为程序里的一个可靠步骤。

这正是《跨国串门儿计划》EP735 所引述的 Latent Space 访谈中，TypeSafe 创始人 Diogo Almeida 反复追问的问题。

他曾在 OpenAI 参与指令遵循方向的工作，后来离开，做了面向程序调用的模型 Jev。

他的目标不是再造一个更会聊天的助手，而是把语义判断做成软件能反复调用的小部件。

Diogo 对主流聊天模型的批评首先来自接口。人类愿意读一段解释，理解它的含糊和保留；

程序通常需要明确字段、预设类型、可处理的错误，以及在重复调用时相对稳定的行为。

访谈里，他把突然出现的拒绝响应比作“类型错误”。

他的立场比一般工程建议更尖锐：模型作为能力内核应尽量像数据库那样提供可调用的能力，安全责任不能简单靠模型在 API 调用时临时拒绝来承担。

他把安全对齐与能力对齐分开讨论，认为让模型学会不时说“不”，会破坏软件对接口的预期。

在 Diogo 看来，能力内核要稳定可调用；安全边界则需要软件系统明确承担。

把拒绝、升级人工或权限不足设计为接口中的明确状态，是读完访谈后可采取的一种工程实现；

它与 Diogo 对模型训练目标的主张相关，但不是他在节目里给出的完整方案。

这也解释了他为何讨厌越来越长的系统提示词。团队把规则、格式、例外和语气塞进同一段文本，希望模型逐条服从。

规则稍有冲突，就难知道哪一行导致了错误；修一个边缘案例，又可能影响本来正常的情况。

Diogo 在原稿引述的访谈里说：

这不是对提示词的抽象反感。他担心程序的关键决策被塞进一段无法逐项检查的全局文本里。

团队要修一个边缘错误，就只能再改这段文本，难以预测其它分支怎样变化。

单个 Prompt 越像整套程序，问题出现时越难找到是哪一步出了错。

Diogo 对 RLHF 的批评更进一步：当模型为“生成长答案、尽量讨人喜欢”接受训练，可能逐渐丢掉低概率却有用的答案模式。

他称之为模式丢失。对聊天来说，保守回答常显得妥当；

对一个要计算风险的软件节点来说，分布被挤窄，模型的信心就可能失真。

如果模型把低概率的答案都削平，信心分数就失去了原来的含义。

访谈把这种风险放在概率校准里讨论：如果模型说某判断有八成把握，长期看相似判断的正确率是否接近八成？

软件需要的不只是一个答案，还需要知道这个答案有多不稳。

若要自动放行付款或审核申请，系统就不能只靠一句笃定的自然语言。“可能出错”得成为可记录、可设阈值、可转人工的信号。

Diogo 由此反对把人类偏好反馈视为所有模型任务的唯一目标。

Diogo 因此主张让训练目标更贴近程序调用。他反对以公开榜单或人类阅读喜好替代业务里真正需要的判断能力。

TypeSafe 公布的性能与使用指标属于公司自述；读者仍需在具体任务的数据和评测里判断其适用性。

他用“系统 1”形容 Jev 要做的事：快速、低延迟地完成大量细小的判断，而不是把每个输入都送进长链条推理。

复杂问题依然需要深度推理；大量后台工作却卡在另一处——分类、匹配、路由、排序这些看似普通但执行次数极高的节点。

Jev 押注的是高频的小判断，不是用一次长推理包办所有流程。

传统聊天 API 往往输入文本、返回文本。开发者再从输出里解析需要的字段，反复检查格式。

如果任务本来就是“选一个业务类型”，Diogo 反问：为什么还要先让模型写一段人类可读的话，再让程序把话拆回类型？

TypeSafe 主张直接传入结构化状态，并让输出落在预设的类别、布尔判断或分数中。

用户写了一封信，软件已知道订单状态、地区和历史沟通；

这些变量可以作为状态输入，而不必全拼成一封“给 AI 的长信”。

输入从故事变成状态，输出才能更直接地接到代码分支。

这和传统软件工程熟悉的类型约束很接近。`choice` 类输出像从几个枚举项中选择，适合路由到既有流程；

真假判断用于检查一个语义条件是否成立；连续分数则可以帮助排序和设阈值。

Diogo 的重点是让这些原语直接接到已有代码分支，而不是再生成一段话供另一个模型或解析器猜测。

分类、判断和打分各负一责，错误才有位置可查。

让代码直接消费语义判断，才是“机器原生”在接口层的含义。

节目把这些接口称为编程原语。可以把它想成程序里的分叉：选择退款类别、判断是否满足某条件、给工单一个优先级分数。

每一步都小，组合起来却能推动一条完整业务流程。

举个例子，用户说“上周下单的耳机还没收到，明天要送人”。

一个巨型提示词可以一次要求模型判断情绪、查物流、决定补偿、起草回复。拆开后，第一步识别订单；

第二步判断是否超出承诺时效；第三步估计紧急程度；第四步按公司规则决定可用方案；最后才生成给用户看的文字。

拆成小判断，不是让问题变简单，而是让每一步的责任和错误位置更清楚。

每个节点都能有独立测试集与阈值。某类加急请求总被漏判，就修那个节点；付款、合规等高风险分支仍保留人工复核。

强类型输出能够减少格式层面的故障，却不会神奇地消除语义误判。

把“返回一个合法枚举”与“真的替人做了正确决定”分开，才是可靠工程的起点。

工程师希望系统可预测，自然会问模型能否每次给出完全相同的结果。Diogo 的回答是把“确定性”与“鲁棒性”分开。

相同输入得到相同文本，便于测试；但更重要的是，在输入换了无关的名字、UUID 或语序后，同一语义仍落到相近的判断。

一个系统可以每次都稳定地错；可靠性还要看它能否跨越表面扰动。

他把训练目标转向程序化反馈：以代码、环境约束和可自动检查的任务，反复观察模型在这些小判断上如何表现。

这是 TypeSafe 所称的 RLCD 路线。它试图让模型为程序调用而优化，而非只为人类阅读的回答而优化。

程序化反馈的好处是可以大量重复测量：某次判断是否落在合法类别，输入轻微变化后结果是否稳定，信心分数与真实错误率是否接近。

它也有边界：测试环境能写出规则，不代表真实世界的规则永远清晰。

当业务涉及受伤害风险、歧视或例外个案，团队仍需要人来定义任务、审查数据，并决定哪里必须保留人工判断。

节目还谈合成数据。Diogo 说团队更像“数据实验室”，不打算把用户生产数据直接拿来训练。

他给出的理由是，用户提问存在长尾和偏置分布；直接追随这些数据训练，模型可能过拟合，失去处理其它情况的能力。

团队因而设计合成任务，通过程序验证和人工挑选来补模型薄弱处。

合成数据能否覆盖现实业务里罕见的情况，仍要由具体场景测试证明。

训练目标选对了，才有机会在真正要自动化的步骤上获得能力。

Diogo 对“SaaS 会被一个聊天框取代”的判断也很鲜明。

他想象的未来，是 CRM、ERP、工单和财务系统继续存在，只是过去要人手工分类、核对、选择下一步的节点，逐渐有模型在后台承担。

这样一来，用户未必每天都看到一个 AI 角色。

一个更少打断人的软件，可能只是更快地把异常订单挑出来，把需要人判断的材料提前备齐，把不必等待人的步骤自动推进。

AI 的商业价值，可能先出现在看不见的工作流里，而不是最显眼的聊天窗口。

这并不意味着软件公司会自然获益。谁掌握业务数据、谁能证明自动决策的可靠性、谁承担错误责任，仍会决定产品的边界。

模型在后台越安静，工程团队越要把权限、日志、评测和人工接管做得清楚。

访谈的锋芒就在这里：Diogo 不再问模型像不像一个聪明同事，而问它能否成为值得信赖的程序组件。

Jev 是他给出的一个答案；它的实际表现还需要用户在自己的流程里验证。

当 AI 从“会回答”走向“能被软件调用”，真正的考题才开始。