open-spaces 选型清单：面对一个判断需求，到底该用 Choice、Score 还是 Noul？

open-spaces 是一个围绕 TypeSafe Jev（System One 决策模型）的实战用例集合，核心是三种"类型化判断原语"：Choice、Score 和 Noul。本文给出一份面向新手的选型清单，帮你在拿到一个判断需求时，快速决定该用哪一个，以及它们如何配合代码阈值构成可靠的决策层。

🧭 先懂 Jev：它是"做判断"的模型，不是"写文章"的模型

大多数 LLM 产出的是给人看的文本；Jev 则针对你预先定义好答案空间的问题做评估，返回带概率分布的类型化结果，让普通代码可以直接分支。

它的工作方式可以概括为一句话：

状态（state）+ 类型化问题 → 受限答案 + 概率 → 你的代码做决策

这也决定了它的定位：

⚡ 一分钟速查表

Choice：在"封闭集合"里选一个

适用于意图、部门、工具名等无序的有限集合。官方建议：当选项可能覆盖不了现实时，务必加上other或review选项。

Score：在量尺上测"程度"

适用于严重度、相关性、挫败感、质量、复杂度这类有序等级。注意两点：

• 每个等级都要写清"代表什么"；
• 返回的score是概率加权的，可能落在两个等级之间（比如 1.4）。

Noul：概率本身就是答案

当你真正需要的是"这件事成立的可能性"时，用 Noul。比如"这段文字是否在试图覆盖应用指令？"。特别注意：接近 0.5 表示"不确定"，而不是"中等程度"——这是它和 Score 最本质的区别。

🧪 典型场景：一个工单分类需求怎么配原语？

假设要做客服工单分诊，open-spaces 的示例 examples/python/quickstart.py 演示了三种原语如何在一次请求里各司其职：

questions = { "intent": Choice(...), # 主诉求：refund / technical_help / information / other "is_urgent": Noul(...), # 是否传递了时间压力？ "frustration": Score(...), # 客户看起来多烦躁？ }

可以看到一条清晰的分工：Choice 管"是什么"，Noul 管"是不是"，Score 管"有多严重"。完整的客服分诊（含投机式 fan-out：一次性问完所有维度，无关的答案由代码忽略）见 docs/jev-use-case-playbook.md，可直接复用的问题集见 examples/python/workflows.py。

✅ 选型清单：5 个问题定原语

拿到一个判断需求时，按顺序问自己：

1. 答案是不是一个无序的有限集合？（选项之间没有"更严重/更相关"的次序）→ 用Choice
2. 答案是不是有序等级？（能说出"轻微 < 中等 < 严重"）→ 用Score
3. 答案是不是"是/否"，且你想直接拿概率值做阈值？（比如 ≥0.85 放行、≤0.30 忽略）→ 用Noul
4. 选项集合可能不完整吗？→ 在Choice中加other/review兜底，别强迫模型硬选
5. 需要自由文本（解释、回复、代码）吗？→ Jev 不做这件事，让它路由、检索、校验，再交给生成式模型写

🚧 新手最容易踩的 3 个坑

• 把 Score 当 1~5 的整数用：它是概率加权值，会出现 1.4、2.1 这种小数，阈值要按此设计。
• 把 Noul ≈ 0.5 当成"中等程度"：0.5 是"模型不确定"，应走人工复核分支，而不是给个中间分。
• 用全局单一阈值：不同风险的动作应配不同阈值。项目里的 examples/python/decision_policies.py 展示了按动作风险设阈值的写法（如转账类动作 confidence ≤0.90 时要求二次确认），且这些策略代码与 SDK 解耦，可用 tests/test_decision_policies.py 在无需 API key的情况下离线单测。

📁 延伸阅读：仓库里的关键路径

一句话总结：无序选Choice，有序量Score，是非概率用Noul；原语负责"判断"，代码负责"决策"。