Jev AI 完整教程：Choice / Noul / Score 三种决策模式，接入 Codex 自动筛选 Gmail

Jev 不是聊天模型。

TypeSafe AI 把它做成决策专用：分类、评分、真假判断，直接返回结构化结果和概率，不写解释文。杰森这条《Jev AI 完整教程：三种决策模式详解，接入 Codex 完整流程》把路径拆得很短——先在 Playground 看懂输出，再让 Codex 替你写接入代码，最后用邮箱筛选验证。

评论里有人说「自动驾驶里早有决策模型」，方向没错：车端也是封闭选项里做选择。区别是 Jev 把这件事收成可调用的云端原语，给你的 Agent 当「智能 if」。也有人问怎么决策、现在能不能注册——它不展示推理链，只给校准过的概率；账号和配额以官网实时为准，排队是常态。

Jev 是什么，以及它不做什么

给一段状态（邮件正文、聊天记录、工单 JSON），再给一组你定义好的问题。它一次返回：

• 选了哪个选项
• 每个选项的概率
• 整体置信度

它不写代码，不写回信，不替代 Codex / Claude Code 里那个会敲键盘的大模型。官方说法很明确：编码 Agent 还是用原来的 LLM；Jev 负责软件里那些重复、封闭、要进分支的判断。Skill 的作用是教 Agent「怎么正确调用 Jev」，不是把 Jev 变成程序员。

原视频：https://www.youtube.com/watch?v=SxJqfZmNaOA

先去 Playground，别一上来写接口

视频 01:43 从 Playground 入门，这是对的。浏览器里贴一段文本当 state，选 Decision type，跑一次就能看见概率条。第三方/官方 playground 常见示例包括：客服路由、退款核验、事件紧急度、Agent 下一步动作。有的页面宣称免注册可试真实模型，有额度限制；正式项目仍要 TypeSafe API Key。

上手只记三格：

1. State：原始材料，越具体越好。
2. Question：一句人话，答案空间必须封闭。
3. 输出：选项 + 概率 + 置信度，后面的 if 归你写。

三种模式：用案例而不是用术语

视频 02:22 起用邮件分类、情侣聊天把三种原语讲活。

Choice：从名单里选一个
适合部门路由、意图分类、下一步动作。
例：这封邮件属于 账单 / 技术故障 / 销售咨询 / 其他。
返回每个标签的概率。不要把「其他」省掉，开放世界里总有漏网。

Noul：这句话成不成立
适合真假门闩。官方和网关里有时叫 Boolean。
例：寄件人是否在要退款？这封信是否像促销？对方是否在表达分手意向？
你拿到的是 0–1 概率。0.92 可以自动归档，0.55 不该触发「已确认」。

Score：落在哪一档、有多严重
适合紧急度、情绪、风险。
例：把对话从「平静 → 不满 → 争吵 → 决裂」排成有序等级，模型给每档概率再插值成分数。
分数是给阈值用的，不是给心灵鸡汤用的。

视频 03:39 强调三种可以同时问。同一封邮件一次请求里就能问：属于哪类（Choice）、要不要退款（Noul）、紧急程度（Score）。并行评估，延迟不按问题个数线性爆炸。复杂决策请拆成原子问题，不要写成长推理题交给它「想明白」。

怎么接到 AI Agent

视频 04:17 的正确姿势不是「用 Jev 替换 Codex」，而是：

1. 继续用 Codex 写脚本、调 Gmail、改文件。
2. 安装 TypeSafe 官方 Skill，让它知道 API、三种原语和推荐模式。
3. 配置 TYPESAFE_API_KEY。
4. 让 Agent 生成「读邮件 → 组 state → 调 Jev → 按置信度分支」的代码。

Codex / 其他 Agent 常见安装：

npx skills add typesafe-ai/skills --skill typesafe-ai

Claude Code 则是加 marketplace 再装 typesafe@typesafe-ai 插件。装完重启或 reload，对话里明确说「按 TypeSafe skill 来写」。Skill 不会让 Jev 自己写仓库，只减少你把文档贴进对话框的次数。

Codex 实战：自动筛选 Gmail

05:41 这段是视频的产品演示。流程可以写成一条流水线：

1. Agent 通过 Gmail 接口拉未读或指定标签邮件。
2. 把主题、发件人、正文前若干字打成 state（注意隐私和最小必要原则）。
3. 一次 Jev 请求里组合问题，例如：
   • Choice：账单 / 工作 / 广告 / 社交 / 可疑
   • Noul：是否需要今天回复
   • Score：紧急程度
4. 代码执行策略：广告高置信直接打标签或归档；工作且紧急度高打星标；可疑或置信度低于阈值只加「待审」标签，不自动删除。
5. 真正回信仍交给会写字的模型，或交给你自己。

这才是 Jev 和 Codex 的分工：一个判，一个干。把删除、回复、转账写成全自动之前，先跑一周只打标签。评论里问「它如何决策」——工程上你只应信任可复现的输入输出和抽检，而不是想象中的内心独白。

写问题的几个坑

• 选项互相重叠（「投诉」和「退款」同时出现还不定义优先级），概率会被撕开。
• State 太短（只有主题）或太长（整封线程加签名加广告页），两端都伤判断。
• 用 Choice 问开放题（「他该怎么办」），模型只能在你给的坏选项里挑一个相对不坏的。
• 忽略置信度，把 0.51 当成「是」。
• 把情侣聊天、职场邮件的情感分数直接当行动指令。Score 是传感器，不是法官。

该不该进你的工作流

值得试，如果这些每天都在发生：邮件分拣、工单分流、内容是否广告、工具该不该调用、这次请求要不要上贵模型。

先不要上，如果：你要的是解释、文案、代码本身；TypeSafe 暂时注不了册或 Key 发不下来；场景一旦判错不可逆（汇款、删库、群发）。后一种必须有人工闸门，这不是可选功能。

成本侧，决策本身按输入计费、输出通常不计费，单次往往远低于一次旗舰模型生成。真正的账在「少调用了几次大模型」和「少处理了多少垃圾邮件」，要用自己的日志算，不要用发布会倍数。

最小实验清单

1. 打开 Playground，用一封真实邮件跑 Choice + Noul + Score。
2. 记下哪些阈值你会亲手采用。
3. 给 Codex 装 TypeSafe Skill，让它写一个只打标签、不删除的脚本。
4. 抽检 50 封，看高置信样本错在哪。
5. 错得多就改选项定义，而不是加长 prompt 求它「再想想」。

Jev 的完整教程其实就这一句：先规定答案长什么样，再让快模型给概率，最后用代码和人共同决定信不信这个概率。Playground 用来形成手感，Codex 用来把判断嵌进已有 Agent，Gmail 只是第一个足够脏、足够重复的试验场。