系统一模型：不生成长文本，而是做出选择
在 AI Engineer Code Summit 上，“系统一模型”成为一个讨论重点。这类非生成式模型返回结构化选项、分数或概率，通常比推理型大语言模型——会议语境中的“系统二模型”——更快、成本更低。
Jev 的主要创建者、TypeSafe AI 联合创始人兼首席执行官 Diogo Almeida 提出的方向是：将模型调用嵌入应用代码，让模型成为自动化流程中的决策组件。
这与让大语言模型生成一段回答有所不同：应用需要的可能不是解释，而是从若干选项中做出判断，再由代码执行后续操作。
Almeida 强调，大语言模型驱动的软件面临可靠性问题：如果系统有时表现出色，有时却犯下明显错误，而开发者无法区分这两种情况，就很难放心地执行自动化。他将 Jev 描述为“可靠的智能”，并鼓励开发者探索更广泛的自动化。
需要注意，这是他的产品主张与愿景，不等于已经验证的可靠性结论。
Glean：与大模型、分类器分工协作
Glean 的 Chinmay Goyal 介绍，团队并没有用 Jev 替代所有模型，而是将其与大语言模型及其他分类器搭配使用。
他认为，Jev 的一个重要特点是零样本灵活性：当决策空间中的分类体系发生变化时，不必反复微调模型。
Goyal 表示，Jev 已支撑 Glean 的相当一部分流程，但用户不需要知道底层具体使用了哪种模型。团队希望隐藏模型选择的复杂性，让用户直接获得能够正常工作的产品。
这个案例的重点是模型之间的分工，而不是让某一种模型承担全部任务：不同步骤可以使用不同组件，用户看到的仍然是完整的业务流程。
UiPath：用“淘汰赛”筛选文档片段
UiPath 的 Chibi Vikram 和 Kevin Bernstein 展示了一项使用 Jev 排序文档片段的测试。其过程类似淘汰赛：
- 将文档片段分成小组。
- 让 Jev 从每组中选出最相关的片段。
- 将胜出片段送入下一轮，继续比较和筛选。
据演讲者介绍，这项测试包含数千次 Jev 调用，整个过程耗时不到一秒。
这一数字只对应其展示的具体测试，不能直接视为所有部署环境下的性能保证。
Vikram 将 Jev 看作可以调整和组合的构建模块：单次模型调用的能力看起来可能有限，但通过不同的组织策略，可以完成更复杂的任务。
从实现思路上看，这个案例值得关注的不是一次调用能做多少事，而是如何将多次小规模选择组织成更大的筛选流程。
Workday：从预测输入到预测操作
Workday 首席工程师 Scott Roberts 展示了团队使用 Jev 开发的原型。
其中一个例子是：用户还在输入时，界面就开始填充请假卡片。模型不只是预测下一段文字，而是在尝试判断用户准备执行什么操作，并据此改变界面行为。
Roberts 将这一变化概括为：从“预测你想说什么”，转向“预测你想做什么”。
这展示了模型参与交互设计的一种方向，但它仍是原型，不应被理解为已经全面上线的产品能力。
工程上值得借鉴什么？
这些案例的共同点，是将模型视为软件内部可调用的组件，而不只是聊天界面背后的文本生成器。
| 场景 | Jev 的角色 | 展示阶段 |
|---|---|---|
| Glean 业务流程 | 与大语言模型、其他分类器共同参与流程 | 实际使用 |
| UiPath 文档排序 | 通过多轮小规模选择筛选文档片段 | 测试 |
| Workday 交互预测 | 根据输入预测操作意图，并影响界面行为 | 原型 |
三个案例提供了不同的探索方向，但不能合并推导出“所有任务都能自动化”或“模型可靠性已经解决”的结论。
对于在写好标智库交流 AI 工程实践的开发者，更有价值的切入点是拆解应用中的决策步骤：哪些步骤需要生成内容，哪些只需要返回一个选项、分数或概率？
先区分生成任务与决策任务，再讨论模型选择和流程编排，比单纯追求更强的文本生成能力更贴近这些案例的工程重点。
