本节摘要:本节拆开 Jev 的一次调用。输入有两个:state——程序状态,模型看到的"世界",可以是字符串、对象或数组;questions——一组带类型的约束问题,每个问题的 ID 由你命名且不会发给模型,纯粹是你代码里的变量名。输出是每个问题一个受约束答案:答案空间在请求里被你预先枚举死,模型结构上不可能产出列表之外的值——这就是官方"0% 幻觉 / 0% 类型错误"的准确含义:数学上由结构保证的形状安全,而判断的正确性是另一回事。本节最后看一个完整请求与响应的样子,为第 3 章的三种类型做铺垫。
阅读完本节,你应当能够:
┌────────────────────────────┐ state ─────▶ │ │ ───▶ 受约束的答案(类型安全,绝不越界) (程序状态) │ Jev │ │ (System One 模型) │ questions ───▶ │ │ ───▶ 概率分布 + 置信度(RLCD 校准) (带类型的问题) └────────────────────────────┘
state(状态):模型看到的"程序当前的世界"——一段用户消息、一张工单的 JSON、一次工具调用的参数。支持三种形态:字符串、对象、数组。
💡 优先用对象:对象让每个问题的 instructions 可以用反引号路径引用具体字段(如
`ticket.body`),比把所有信息揉成一段自然语言更稳、更可维护(第 8.1 节展开状态设计)。
questions(问题):一个字典,key 是你起的问题 ID——它不发给模型,纯粹是你代码里的变量名,起有意义、稳定的名字(is_urgent 而非 q1)。每个问题包含:
type:三种类型之一(noul / choice / score,第 3 章逐一拆解);instructions:自然语言判别标准,写给"阅卷老师"看;criteria:类型对应的答案空间定义(选项表 / 等级表;是非题没有此字段)。每个问题返回一个答案,形态由类型决定(第 3 章详表)。共同点有两个:
官方宣称 Jev "0% 幻觉 / 0% 类型错误",这句话需要精确理解:
| 含义 | 来源 | |
|---|---|---|
| 保证的 | 答案的形状:必在枚举空间内,不会出现 billing 之外的字符串、不会 JSON 解析失败 | 结构保证(数学上的,不是经验性的) |
| 不保证的 | 判断的正确性:可能选错选项、给错概率 | 判断质量取决于 schema 设计 + 模型能力(第 10.2 节核心批评) |
一个设计糟糕的选项表不会因为"类型安全"而变好——错误会被包装成一个看起来合法自信的答案。所以本教程把 schema 设计当作一等编程技能来讲(第 3 章的设计准则、第 9 章的回归集循环都是为此)。
// POST https://api.typesafe.ai/v1/systemone { "model": "jev-latest", "state": { "ticket": { "subject": "Stripe 连接失败", "body": "试了三天,客户付不了款,每小时都在损失", "tier": "paid" } }, "questions": { "is_urgent": { "type": "noul", "instructions": "`ticket.body` 表达了紧迫性或时间敏感性" }, "route": { "type": "choice", "instructions": "该工单应路由到哪个团队", "criteria": { "billing": "计费与支付问题", "technical": "产品故障", "other": "以上皆非" } } } } // 响应(示意): // "is_urgent": {"noul": 0.97} // "route": {"choice": "billing", "probabilities": {...}, "confidence": 0.8}
两个问题并行求值、一次返回——这是 Jev 扇出经济学(第 5.1 节)的基础。
骨架清楚了,但什么任务适合塞进这个骨架?下一节给出全书第一使用心法:选牌,不报牌名。