第 1 章：为什么需要决策层——从"生成一切"到"只做判定"

过去几年，我们把越来越多的判断交给了大模型：该走哪个分支、这条评论要不要删、这封邮件该归到哪个文件夹。但生成式模型最擅长的是"写出各种可能"，不是"在具体这一步选哪一个"。本章说清这个错配，并引出 Jev 的核心主张：把语义判定从生成模型里剥离出来，代码重新掌握控制流。

一个被忽略的错配

先看一段几乎所有 AI 应用都写过的代码：

resp = llm.chat(f"这条评论是垃圾吗？只回答 yes 或 no。评论：{comment}")
if "yes" in resp.text.lower():
    delete(comment)

这段代码在生产里会出各种问题：模型回了"不一定，但很可能"，你的字符串匹配失效；模型先解释了三句话再给结论，in 匹配到了解释里的"yes"；模型偶尔把 No 写成 Nope；更糟的是，你不知道这一次判断的置信度是多少——0.51 和 0.99 被一视同仁。

问题的根源不是模型不够聪明，而是我们让一个生成模型去做一个判别任务。生成模型的目标是"给定上文，输出下一个最可能的 token 序列"。它输出的是一条开放文本，而你需要的是一个封闭的判定。两者之间的鸿沟，只能靠提示词和后处理去填，于是就有了"只回答 yes 或 no""请输出 JSON"这类脆弱的补丁。

Jev 的出发点正是抹掉这道鸿沟。它不生成文本，它接收一个非结构化的状态（state）、一组类型化的提问（typed questions）和一段指令（instructions），返回类型化的决策。上面那段代码在 Jev 里是这样的：

from typesafe import TypesafeClient

client = TypesafeClient()

choice = client.systemone(
    state=f"用户评论：{comment}",
    questions={
        "is_spam": {
            "type": "noul",
            "question": "这条评论是垃圾信息吗？"
        }
    },
    instructions="你是社区内容审核员，按社区规范判断。"
)

if choice["is_spam"].value:      # 布尔值，不是字符串匹配
    delete(comment)

返回的 is_spam 是一个布尔值，附带一个 P(true) 概率。控制流仍然是你的 if，只不过判定这个人换成了更擅长判定的模型，而且判定结果带有可用的置信度。

生成模型的控制流困境

把判断交给生成模型，会带来四类结构性麻烦，它们不是调参能解决的。

其一，输出不封闭。 你问"是 A 还是 B"，模型可能给你"C"、"A 和 B 都沾一点"、"看情况"。要想约束它，你就得在提示词里反复叮嘱，还得写解析器兜底，而解析器又要处理"模型没按格式来"的情况。判断这件事本身很简单，工程开销却全花在了"让它好好说话"上。

其二，成本与延迟不对等。 判别任务的规模往往很大：每条评论、每封邮件、每个候选文档都要判一次。用一个大模型做这种"多选题"，等于用一台卡车去送一封信。你付的是生成整段文字的钱，等的是生成整段文字的时间。

其三，没有概率语义。 生成模型可以告诉你它"选了 A"，但很少能稳定地告诉你"A 的概率是 0.83"。而下游逻辑常常需要这个数：0.6 以上自动处理，0.6 以下转人工。拿不到概率，阈值策略就无从谈起。

其四，不可组合、不可验证。 当判断散落在成百上千条提示词里，你没法对它们做统一测试，没法保证"换个模型版本结果不变"，也没法回答"这条判断历史上是怎么演化的"。

这四件事指向同一个结论：判别任务需要一个专门的、类型化的决策层，而不是靠生成模型兼职。

决策层站在哪里

在软件架构里，"决策层"并不陌生。编译器有词法分析和语法分析，把非结构化的源码变成类型化的语法树；策略引擎接收请求上下文，返回 allow/deny；数据库优化器拿到一条 SQL，输出一个执行计划。它们都是"接收状态、输出一个封闭决策"的组件。

Jev 要做的，是给那些只能靠语义判断、没法写成规则的决策，提供一个同等的组件。它站在生成模型和应用逻辑之间：

flowchart TB
    subgraph 传统方式
        A1["应用逻辑"] --> B1["生成模型
输出自由文本"]
        B1 --> C1["解析/校验/兜底
（脆弱且分散）"]
        C1 --> A1
    end
    subgraph 决策层方式
        A2["应用逻辑
（拥有控制流）"] --> B2["Jev 决策层
输出类型化决策"]
        B2 --> A2
    end

区别在于：传统方式里，模型输出什么、怎么解释，是运行时才知道的；决策层方式里，代码先声明"我需要一个什么样的决策"，模型只负责填这个封闭的槽位。前者是不可控的开放世界，后者是可声明、可测试的接口。

代码拥有控制流，模型只做判定

这句话是理解 Jev 的钥匙，值得单独展开。

在传统 LLM 应用里，控制流经常被"让给"了模型。你写一条提示词："如果用户想退款就走退款流程，如果用户想咨询就走咨询流程"，然后解析模型的输出再分派。这时候，路由逻辑其实在模型的输出里，它不稳定、不可测、不可审计。

Jev 把这件事反过来。路由逻辑写在你的代码里，是一个清清楚楚的 switch 或者 if/elif；模型的任务被收窄成一个问题："这条工单属于哪一类？"，返回一个带概率的类别标签。至于"属于退款就走退款"，那是代码早就写死的、百分之百确定的分支。

category = client.systemone(
    state=ticket_text,
    questions={
        "category": {
            "type": "choice",
            "question": "这条工单属于哪一类？",
            "choices": ["退款", "账号问题", "功能咨询", "投诉"]
        }
    }
)["category"].choice

match category:
    case "退款":
        route_to_refund(ticket)
    case "账号问题":
        route_to_account(ticket)
    case "功能咨询":
        route_to_support(ticket)
    case "投诉":
        escalate(ticket)

代码拿回了控制权，带来三个直接好处：可测试（给假的状态、断言选出的分支即可，不需要真的调模型）；可审计（每条分支都写在代码里，评审时一眼能看全）；可组合（路由之后是各自的处理流程，互不纠缠）。

有人把 Jev 总结成一句话，很传神："Jev 是一个特别聪明的 switch 语句。" 讽刺的是，这恰恰是它最有价值的地方——它把模型的智能塞进了一个软件工程能接住的容器里。

Jev 与 chat 模型的本质差异

把两者放在一起对比，差异一目了然：

维度	生成式 chat 模型	Jev 决策层
输出	开放文本，长度不定	类型化决策：Choice / Score / Noul
概率	通常拿不到可用的置信度	每个选项/p_i 的概率显式返回，和为 1
成本	按生成 token 计费，判别任务偏贵	决策成本极低，适合大规模判定
延迟	逐 token 生成，通常数百毫秒起	面向判定优化，可做到 150 毫秒级
控制流	常被写进提示词里，不稳定	留在代码里，确定、可测、可审计
适用场景	写作、对话、代码生成、开放式推理	分类、路由、检测、评分、检索、排序、验证、抽取

注意最后一行不是"取代"，而是"分工"。一个成熟的 AI 系统往往是两者协作：生成模型负责开放式的产出，Jev 负责给这些产出把关、分诊、排序。比如让大模型起草一封回复，用 Jev 判断"这封回复有没有承诺我们做不到的事"；让大模型检索出一堆候选，用 Jev 做重排。

这本书怎么读

全书按"认知—形态—行业—垂直—工程"五层展开：

• 第 1-3 章（基础） 解决"为什么"和"用什么"：决策层的动机、Choice/Score/Noul 三种输出、十种决策形态的选型。
• 第 4-8 章（十种形态） 逐一拆解十种形态，配真实项目，是方法论骨架。
• 第 9-15 章（行业） 进入 AI Automation Software，讲检索、路由、护栏、代码检查、招聘、客服、金融风控等七个行业用例。
• 第 16-21 章（垂直与实时） 覆盖法律、电商广告、审核、游戏、150 毫秒实时应用与科学发现。
• 第 22-24 章（工程） 讲规模化的三件事：大数据上的 Map Reduce、通用验证、Harness Engineering。

每章的结构一致：先讲这个判断难在哪，再讲 Jev 怎么解，然后落到一个真实项目（优先高 star 开源项目，没有则用官方示例），最后给出可运行的代码与实测数据。

小结

• 生成模型的核心能力是"写出各种可能"，判别任务需要的却是"选出一个封闭答案"，这是长期被忽略的错配。
• 把判别交给生成模型，会带来输出不封闭、成本延迟不对等、没有概率、不可组合四类结构性麻烦。
• Jev 提供类型化的决策层：接收 state + questions + instructions，返回 Choice/Score/Noul 三种类型化输出。
• 它的核心哲学是代码拥有控制流，模型只做语义判定——一句话概括就是"一个特别聪明的 switch 语句"。
• 它与 chat 模型不是替代关系，而是分工：生成负责产出，决策负责把关。

下一章我们打开 Jev 的调用契约，把 Choice、Score、Noul 三种输出和它们的概率语义讲清楚。