将系统一模型集成到功能中
系统一模型在一次前向传递中回答有类型的问题。它不生成文本。输入状态，输出带有校准概率的类型化答案。它是一个可以阅读的 if 语句。
当决策窄范围、预设且重复时使用它。不要将其用于任何需要书面解释的任务——那仍然是 Claude 的工作。
首先：这真的是正确的工具吗
回答以下三个问题。如果任何一个答案是“否”，则停止，并保留 LLM 调用。
- 可能的答案是否事先已知？ 选项上限为 255 个。
- 调用者是否只需要标签，而不是推理？如果下游有人需要阅读解释文本，你需要的是文本模型，而这（系统一模型）是错误的工具。
- 是高吞吐量，或者有人在等待吗？ 这是一个延迟和成本的优化，而非能力提升。它知道的并不比 Claude 多。在每晚对 50 条记录运行的定时任务中，它只会给你带来一个依赖，别无他用。
基于三个任务 150 条手工标注记录（我们的 2026 年 9 月 20 日运行）：Jev 与 GPT-5.2 持平，达到 145/150，且成本降低 46 倍（每 1,000 条记录 $0.036 对比 $1.64），但端到端速度仅比 GPT-4.1-mini 快 1.7 倍——公布的 40-200 倍提升是针对 3-329 秒的多步骤前沿工作流，而非单次调用。
开源复现并非即插即用。 同一运行：Von 1.0.1 (395M) 92/150 (61%)，Laya (421M) 62/150 (41%)。它们的失败模式是坍塌到一个类别而非逐步降级——Von 在一个包含 5 个命令的 50 条命令集合中预测了 25 次 exfiltration。置信度门控无法挽救这种情况：捕获 Von 的错误意味着将 92% 的流量升级，Laya 为 100%，而 Jev 仅为 8%。仅当你已经在自己标注的数据集上测量过它们时才使用它们。
三种问题类型
"lead_type": {"type":"choice", "instructions": "...", "criteria": {"opt_a":"desc","opt_b":"desc"}}
"is_urgent": {"type":"noul", "instructions": "..."} # -> 0.0–1.0
"priority": {"type":"score", "instructions": "...", "criteria":["ignore","low","high"]}
在一次调用中提出你需要的所有问题——它们都在同一次前向传递中解析，因此四个问题的成本大致相当于一个问题。
响应结构（Jev 和 Von 均适用）：
r["answers"]["lead_type"]["choice"] # 标签
r["answers"]["lead_type"]["probabilities"] # 完整分布
r["answers"]["lead_type"]["confidence"] # 用于门控
r["answers"]["is_urgent"]["noul"] # 0.0–1.0
r["answers"]["priority"]["score"] # 在尺度上的位置，例如 2.41
工作流程
1. 首先构建标注集——至少 50 条记录
不可协商，且是价值最高的单一步骤。在编写任何问题标准之前，手动标注来自你将指向此模型的实际流中的记录。没有它，你无法区分是问题不好还是模型不好，而且故障是静默的——参见 jev-eval。
2. 像对新员工解释一样编写标准
同一问题的四种表述方式的差，每个任务 50 条记录（我们 2026 年 9 月 20 日运行）：
| 任务 | Jev | Von (395M) | Laya (421M) |
|---|---|---|---|
| Agent 命令风险 | 44-49 (10 分) | 9-23 (28 分) | 18-28 (20 分) |
| 潜在客户分类 | 47-49 (4 分) | 22-34 (24 分) | 15-24 (18 分) |
| 工单路由 | 41-47 (12 分) | 23-41 (36 分) | 22-36 (28 分) |
在命令任务上对 LLM 进行的相同扫描：Haiku 4.5 46-48 (4 分)，GPT-4.1-mini 45-50 (10 分)，Jev 44-49 (10 分)，GPT-5-mini 41-49 (16 分)。
Jev 并不比小型 LLM 对措辞更鲁棒——它同样有 10 分的波动，而 Haiku 是测试中最稳定的模型。请关注下限，而非波动范围：每个托管模型的最低点都在 82-92%，且保持可交付状态，而 Von 的最低点为 18%，Laya 为 36%。不要将其解读为“编写更好的标准，开源模型就能赶上”——早期一个 15 条记录的测试就得出了这个结论，而且它是错误的。更丰富的标准并未可靠地提高性能：在潜在客户分类任务中，Von 在简洁措辞下得分为 34/50，而在精心编写的措辞下得分为 28/50。影响这些数字的是对表面形式的敏感性，而非理解力，因此每一次未来的标准编辑都意味着一次未宣布的回归风险。
为每个选项编写：它是什么，它不是什么，以及可能诱使错误答案的边界情况。当一个选项应该占主导地位时，显式地命名默认选项。
3. 针对标注集校准阈值——永远不要假设 0.5
Noul 是概率，而非布尔值。Jev 的 noul 有一个下限：在显然洁净的记录上，它仍返回 0.2–0.5，而 Claude 返回 0.0。在测量数据上，有用的截断点在 ~0.85，而非 0.5。阈值不能在模型之间迁移——切换模型时需重新扫描。
不要手动编写扫描逻辑。jev-eval 负责校准并提供了该工具：
python ~/.claude/skills/jev-eval/scripts/sweep.py labelled.json configs.json \
--backend jev --question <name>
4. 设计置信度门控
将低置信度的答案门控升级到 Claude。同一脚本报告两个重要的指标——门控捕获了多少比例的错误，以及它升级了多少比例的流量——并为结果打标签。一个捕获了所有错误但升级了 73% 流量的门控会得到 saves nothing 的评分，因为它是一条带有额外步骤的慢路径。如果看到这种情况，修复方法是更好的标准，或者使用托管模型，而不是换个阈值。
a = r["answers"]["lead_type"]
if a["confidence"] < GATE:
return escalate_to_claude(state) # 慢路径
return a["choice"] # 快路径
5. 在功能标志后发布，记录两条路径一周
记录系统一模型的答案和旧路径本应给出的答案。在基于真实流量进行比较后，再完全切换。永远不要只依据评估集数字就切换。
访问路径
# 1. TypeSafe 直接访问——密钥在 macOS Keychain，服务名为 `typesafe-api-key`
export TYPESAFE_API_KEY="$(security find-generic-password -s typesafe-api-key -w)"
curl -X POST https://api.typesafe.ai/v1/systemone \
-H "Authorization: Bearer $TYPESAFE_API_KEY" -H "Content-Type: application/json" \
-d '{"model":"jev-latest","state":"...","questions":{...}}'
// 2. Cloudflare Workers AI——无需等待列表
await env.AI.run('typesafe/jev', { state, questions })
# 3. Von——本地、免费、Apache-2.0、395M ModernBERT
# pip install von-sdk
import von
r = von.system_one(state="...", questions={"x": von.Noul(instructions="...")})
r.answers["x"].noul
陷阱
- Von 的
Choice接受criteria=，而非choices=。 如果猜错会得到 Pydantic 错误。 - Von 返回
.answers[k]，而非.nouls[k]/.choices[k]。LangChain 包装器与原始 SDK 在这里有所不同。 - Von 的 34 秒冷启动加载权重。应在启动时预热；永远不要将其计入延迟测量。
- 不要将 noul 的阈值设为 0.5。 参见步骤 3。
- Jev 是早期访问权限，单一供应商，无 SLA。 在没有回退到 Claude 的情况下，不要将其用于面向客户的关键路径。
- 小型评估集会撒谎。 15 条记录中两个托管模型都达到 100% 几乎证明不了什么。使用数百条。
相关
jev-eval 构建并运行标注集。jev-audit 用于发现代码库中哪些现有 LLM 调用值得转换。