快速判断与审慎推理：AI 报价为什么两者都需要

团队正在准备报价，客户发来一条澄清：

关于支架 B-214，请按图纸 Rev D 更新报价。Rev C 要求阳极氧化处理；Rev D 规定为机加工原始表面，不做涂层。订单数量仍为 5,000 件。请根据表面处理的变更修改报价。

看出这条消息该交给估价团队并不难，更新报价就要费些功夫了：得有人核对 Rev D，与具有约束力的技术规范对照，确认哪些工序有变化，再重新核算成本。

这几项任务需要的工具各不相同。把消息送到对的人手里，一次快速分类就够了；解读技术要求，可能需要语言模型和相关文件配合；成本的变化，要靠明确的输入和计算得出；最终结果，仍然要由工程师审批。

这类小而频繁的判断，正是 System One 模型的用武之地。Nyotta 用一批合成的供应商消息（包括上面这条支架澄清）测试了 Jev，考察它的分类结果和可重复性。

这里的 System 1 和 System 2 指什么

Daniel Kahneman 让 System 1 和 System 2 这组概念广为人知：前者是快速、凭直觉的思考，后者是审慎、费力的思考。设计 AI 工作流时，这是个很好用的类比，但它并不描述模型内部真实的运作方式。《思考，快与慢》

放到报价里，认出一条消息是交付投诉，只是个小判断；图纸和技术规范互相矛盾时决定以哪项要求为准，就得收集证据、一步步理清冲突。把两者当成同一类模型请求来处理，要么在简单任务上白费力气，要么对困难任务交代不足。

这组区分说到底针对的是任务。通用 LLM 既能快速给消息分类，也能花更长时间推理一个问题。还有些工作两类都不属于：已批准的费率乘以数量，这种事就该交给计算，模型的直觉在这里派不上用场。

Jev 是什么？

Jev 是 TypeSafe 推出的首个 System One 模型。使用时，向它提供待评估的信息，再提出带有明确答案类型的问题。按其文档，基本操作有三种：Choice，从选项中选出一项；Score，按评分标准打分；Noul，对一个命题给出 0 到 1 之间的取值。Choice 和 Score 还会返回概率分布和置信度。TypeSafe 文档

比如，我们让 Jev 把一条消息归入以下结果之一：

quality | logistics | estimating | purchasing | review | none

应用程序可以据此分派工作。TypeSafe 介绍说，这些问题是并行评估的；当同一份输入需要做好几个小判断时，这种接口值得深入研究。Introducing Jev

工作流要的只是一个决定时，未必需要一番长篇大论。这个玩笑说的是接口形式：通用 LLM 同样可以返回结构化输出。

我们测试了什么

2026 年 9 月 21 日，我们用 jev-1.13.0 测试了消息分类与请求延迟。Jev 拿到的只有合成文本和我们的指令，没有图纸、订单历史，也没有此前的对话记录。预期标签在运行之前就已写定。

我们准备了 30 条业务消息，每次调用提两个 Choice 问题：

1. 该请求应由哪个团队处理？ 选项为 quality、logistics、estimating、purchasing、review 和 none。review 用于无法识别或无关的问题；none 用于明确无需处理的通知。
2. 信息状态如何？ 选项为 clear、conflicting、insufficient 和 no_action。clear 指请求或问题可以识别，并不代表事实已经核实，也不代表已获准采取行动。

这些消息涵盖缺陷、交付延迟、价格调整、相互矛盾的报告、缺少背景信息、例行通知以及报价请求。一条消息同时涉及多个问题时，我们的分派规则按 quality、logistics、estimating、purchasing 的顺序确定优先级。每条消息发送三次，用来衡量可重复性。

对上文那条支架澄清，Jev 三次调用都返回 estimating 和 clear。下面这条消息，它同样返回 estimating 和 clear：

客户技术规范规定：“有裂纹的零件判为不合格。”这是一项验收标准，此处并未报告任何缺陷零件。请在报价中包含所需的裂纹检验。

这和我们想要的区分完全一致：这是一项检验要求，眼下并没有出现缺陷。

指标	结果
团队选择与我们的标签一致	90/90 次调用（100%）
信息状态选择与我们的标签一致	87/90 次调用（96.7%）
每次重复均与两个标签一致的消息	29/30
三次调用返回相同标签组合的消息	30/30（100%）

最后一行衡量的是标签可重复性，与是否符合我们的标签无关。几次重复中选出的答案始终不变，概率分布则偶有变化。每个输入调用三次只算一次小规模的一致性检查，不能据此断定今后的请求或后续模型版本一定表现出确定性。

唯一出现分歧的是这条消息：

请解决我昨天和你们同事讨论过的 PO 4812 的问题。能否向他了解一下细节，然后告诉我下一步怎么做？

Jev 三次调用都返回 review 和 clear。我们预期的是 review 和 insufficient，因为消息里没有交代问题本身。不过按我们的定义措辞，clear 可以指一个可识别的请求，而“向同事了解细节”恰好符合这一条。Jev 的答案也有道理。90 次调用中，Jev 有 87 次与我们的预期一致；三次分歧都来自同一个措辞含糊的问题重复了三遍，两种答案都说得通。

这对定义工作流很有启发。“这个请求看得懂吗？”和“现有信息够不够解决问题？”应该拆成两个问题分别问。定义本身含糊，模型的置信度再高也补救不了。

问题增多，延迟会怎样变化

我们选了一条消息，里面同时提到交付延迟、检验中发现的裂纹，以及下一批订单的涨价要求。针对它，我们定义了十六个命题问题，比如消息是否报告了裂纹、是否提到交付延迟、是否给出了采购订单号。

然后分三组测试：只问第一个问题，同时问前四个，同时问全部十六个，每组调用六次：

每次调用的问题数	延迟中位数	观测范围
1	211 ms	176–285 ms
4	198 ms	190–208 ms
16	237 ms	199–290 ms

以上是端到端的 HTTP 耗时，包含网络开销。调用按顺序进行，没有应用层重试，也没有剔除预热请求。在这次测试中，问十六个问题并没有花上十六倍的时间。不过每组只有六次观测，既不足以确定生产环境的吞吐量，也不足以证明它比其他模型更快。

另外还有七条诊断消息，各发送三次（共 21 次调用），加起来整个评估共完成 129 次成功请求，全部通过了我们本地的响应格式检查。诊断消息用来测试指令攻击和无关请求，不计入上文的业务消息结果。

Nyotta 如何运用这一思路

在 Nyotta 里，文档分类、信息提取与数值估算是分开处理的。图纸区域先完成分类，再从中提取特征，每个特征都保留它在原图中的位置，方便审阅。估算由专门的代码完成，它基于这些输入生成估算结果，并给出警告。

这样每个组件都各司其职：模型帮助解读工程信息，估算模型和代码负责得出数值。审阅人可以把对原始资料的解读和估算结果分开核查。

回到支架的例子，Jev 的职责很窄：给客户的澄清分类，并分派给估价团队。实验中三次调用都给出了预期的分派结果。要真正完成报价，仍然需要实际的图纸和技术规范、经认可的成本输入，以及工程审批。

为什么用 Nyotta，不直接让通用 LLM 报价？

LLM 本来就是 Nyotta 的一部分。 我们借助它的语言理解和推理能力来解读要求、提取信息，并帮助说明哪些内容需要审阅。而一份报价还离不开工程数据、明确的估算方法、计算和审批。

在 Nyotta 中，从图纸提取的特征都保留了在原图中的位置。数值估算由专门的代码负责，它同时检查输入、报告警告。有了这种分工，审阅人可以用各自适用的标准，分别检查对原始资料的解读和估算结果。

报价系统里的分工应当一清二楚：

任务	合适的工具或负责人
解读一项要求，或起草澄清内容	语言模型或多模态模型，并提供原始资料以便核对
对窄范围请求进行分类	针对该任务评估过的规则或决策模型
协调相互矛盾的要求	相关文件、推理以及工程审核
估算成本或价格	具备所需业务输入的明确估算模型
应用费率、数量和约束条件	代码、公式和校验规则
接受某项假设并发出报价	获得授权的工程师或审批人

LLM 可以调用这些工具，但计算仍要基于经认可的输入来执行，结果也要保留依据。拿支架来说，取消阳极氧化必须体现在相应工序的成本上，新价格也必须由估算结果推导出来。

Nyotta 的价值，就在于把模型的解读和这些工程工作连接起来。Jev 这类模型适合承担分类这一步。它到底有多大用处，取决于具体任务和周边的检查机制，LLM 也是一样。

真正有意义的比较，是拿一份真实的询价包来检验：贵司团队能否把每项要求追溯到原始出处，能否查看成本输入，能否清楚看到还有哪些内容等待审批？