新AI模型 Jev 实战：概念、场景和两个实战

一、一个不写字的模型

9 月 15 日，一条推文在开发者社区里传开。

发帖人是 Diogo Almeida。他说自己参与发明了 ChatGPT，然后一直在问自己一个问题：为什么对话模型已经强到超人，AGI 还是没有出现？过去两年他"隐身"，用一种新的训练方法（RLCD）训出了一个新类型的模型，今天发布，名字叫 Jev。

他给出的数字：快 20–200 倍，便宜 40–400 倍。TypeSafe AI 同期宣布了 4000 万美元种子轮。

接下来几天，用 TechCrunch 的标题概括就是："一个来自 ChatGPT 发明者的新型 AI 模型，正在让开发者兴奋。"Reddit 上 r/ArtificialInteligence 的帖子一天之内冲到 120+ 评论，标题是"Jev / TypesafeAI is revolutionary as LLM's"，正文第一句："Jev is insane."X 上 @0xCodila 说这是 AI 行业的"互联网时刻"，@akshay_pachaar 的总结是："我们一直拿 LLM 当锤子，敲每一个 AI 问题，哪怕是再简单不过的判断。Jev 用毫秒和零头的成本把这些判断接了过去。"中文社区里，@Saccc_c 的推荐很直接："强烈建议大家都亲自试试 Jev，能让你的 Codex 操作速度提高 10 倍并省下大量 token。"

同时，接下来的这几天，我的X时间线全被jev刷屏了。

社区的动作也很快。一周之内，已经长出一圈配套工具：给 Claude Code 和 Codex 用的代码评审插件 jev-review、官方的 TypeSafe Skill、把命令风险检查接进 Claude Code hook 的脚本，还有人做了 jevable.com，把散落在 X 上的演示项目收集成可筛选的目录。有人把 X 上 28 个 Jev 用例归成八个方向，从 Agent 调度、记忆筛选、代码质量检查，到浏览器操作、业务分流、实时交互辅助和游戏控制。这些方向的共同点是：判断高频发生、候选范围有限、需要理解语境，而且错了能发现、能补救。一批资源站也纷纷涌现。

但有个事实绕不开：Jev 不做生成。

它不会写文章，不会写代码，不会跟你聊天，也不能解释自己为什么这么选。你给它一段状态（state）和几个带选项的问题，它返回一组类型化的答案和概率，然后停止。

当所有人都在比谁的模型写得更长、更像人的时候，TypeSafe 走的是另一个方向，把模型做成软件里的一个判断原语。最通俗的类比，是一个聪明的 if 语句。

为什么这个模型爆火？

普通代码只能对"能算的条件"做分支：if (order.total > 100)。可现实里大量的分支条件是判断，不是计算：这条客服消息是愤怒还是平静？这段代码变更是否破坏了兼容性？这 40 个按钮里，哪一个能继续结账？过去的选项只有三个：写死规则（脆弱）、训一个分类器（每条任务都要数据和训练）、让 LLM 输出结构化 JSON（慢、贵，而且生成式模型给出的概率并不保证校准）。

Jev 想站的位置在中间：像 LLM 一样接受你运行时定义的任意文本和问题，像分类器一样返回受约束的概率分布。它不生成自由文本，答案空间由你提前定义，模型只能在你给的选项里选。TypeSafe 说，这让"输出格式错误"从概率问题变成了结构上不可能。

它的三个关键名字都有出处：

• System One，来自卡尼曼《思考，快与慢》。系统 1 是快速直觉，系统 2 是慢速推理。TypeSafe 的框架里，Jev 做前者，推理模型做后者。
• Jev，来自经济学家 William Stanley Jevons（杰文斯）。杰文斯悖论说的是：蒸汽机效率变高，煤的消耗反而上升，因为更便宜的动力创造了新的用途。TypeSafe 的赌注是智能也一样，当一次判断的成本低到可以忽略，你会把它放进以前根本不会调用模型的地方。
• RLCD（Reinforcement Learning for Calibrated Decisions）训练的目标是让概率和实际正确率对得上：它给出 90% 概率的那些判断，长期看应该对 90%。校准的概率可以直接写进代码当阈值用，这是它和普通 LLM 最本质的区别之一。

和常规 LLM 到底差在哪

速度上，厂商给出的端到端响应时间是 70–500 毫秒，对比前沿 LLM 做同类判断的 3–329 秒；价格是输入 $0.042 / 百万 token，输出免费，因为几乎没有输出。官方的宣传数字"快 193.6 倍、便宜 444.6 倍"来自它自己的评测，按它自己的说法这是上限值，别当承诺。

它刻意放弃的能力也很明确：不能写回复、不能写代码、不能总结、不能解释推理过程。需要文本的地方仍然需要 LLM。TypeSafe 自己画的架构是两层：Jev 判断，LLM 在需要写作的时候写作。

边界同样要讲清楚。校准概率说的是长期对得上，单次可能错，也不能当证明；厂商数字未经第三方验证；只支持文本；0.5 的 Noul 表示"分不清"，跟"中等"是两回事。@blackanger 有一段总结我觉得最准确：Jev 是"带置信度、不漂移、被约束住的专家直觉"，它保留了系统 1 的快和便宜，修掉了系统 1 最危险的过度自信。

看完这些概念，我在自己的两个真实场景里试了它。一个是我正在做的 Go 迁移代码对齐审查，一个是浏览器操作（Computer Use）。下面是具体的做法、数据和踩过的坑。

二、概念与 API：每个部分是什么意思

在进入实战之前，先把 API 的每个部分讲清楚，后面两个案例都建立在这些概念上。

请求的整体形状

一个请求发往 POST https://api.typesafe.ai/v1/systemone，只有三个顶层字段：

model：当前版本是 jev-1.13.0，两个别名指向它，jev-latest（稳定版，SDK 默认）和 jev-preview（有预览版时提前走）。响应里会回带实际作答的版本化 ID，建议记日志；如果你按版本调过置信度阈值，请钉住版本 ID 而不是别名。

state：问题所针对的内容，可以是字符串、JSON 对象或文本数组。两个经验：用对象加反引号路径（如 `behaviors.B13.java`）让问题精确指向某个字段，消除歧义；只放问题需要的内容，和任何模型一样，state 里塞进无关内容会稀释准确率，过滤要在你的代码里做，别用材料体积代替材料质量。

questions：每个问题的 ID 由你定，不会发给模型（它只发给代码用），所以问题要完整写在 instructions 里，别指望 refund_requested 这种 ID 能告诉模型任何事。每个问题还有 type 和（Choice/Score 必须的）criteria。初次上手最容易犯的错，是把所有需求压进一句"判断是否合理"。合理取决于什么，是否符合要求、是否会改动远程状态、是否涉及凭证，这些条件得分开写清楚。你写的问题，和你想判断的目标，有时差着半句话。

s

typesafe官方提供了 python 和 javascript 的sdk。changkun大佬也是在第一时间发布了Go语言版本的 sdk: https://github.com/latere-ai/pkg/tree/main/typesafeai, 其他编程语言相信也在开发之中，你也可以通过 HTTP API的方式调用。

三种原语

所有问题都是三种之一，各自返回不同形状的答案。

1. Noul：是不是。 回答一个是非问题，返回 0–1 的 noul，它是"是"的概率。

返回 {"noul": 0.93}。两个要点：措辞要让"高值 = 是"，否则读代码的人会疯；0.5 是"分不清"，想要程度就用 Score，不要拿 Noul 当强度计。Noul 没有单独的 confidence 字段，noul 本身就是唯一的置信信号。需要给"是/否"下更细的定义时，可以加 criteria: { true: ..., false: ... }。

2. Choice：从固定集合里选一个。 适合意图、部门、文档类型、工具名、风险类别。

返回三个字段：choice（概率最高的选项）、probabilities（全量分布，每个你定义的选项都有概率）、confidence（把分布形状压成一个数：某个选项占绝对优势就高，摊开就低。它是从概率分布算出来的统计量，不是"这个答案正确的概率"）。实践建议：选项可能覆盖不全时，一定加一个 other 或 none_of_the_above，不给出口，模型也必须选一个；每个选项要描述"什么属于它"，相邻选项边界模糊时，要写清楚区别。

3. Score：在你描述的有序刻度上打分。 适合严重度、挫败感、相关性、经验程度。

criteria 数组从低到高，下标即等级编号。返回 score（概率加权均值，可以落在等级之间）、legend（等级文案）、probabilities、confidence。两条最重要的规则：

1. 描述情景，不要描述程度。"Broken feature, workaround exists" 模型能拿来对照；"中等严重"什么也对不上，概率会摊平。
2. 一个 Score 只测一个维度。"守时、聪明、有经验"混在一档里，输入在某个维度高、另一个维度低时就没法放，confidence 会塌掉。拆成三个 Score，在代码里加权组合。

另外要习惯同时看 score 和 probabilities：1.0 分可能是"全部压在第 1 档"，也可能是"一半在第 0 档、一半在第 2 档"，confidence 才能区分这两种情况。分数的含义完全来自你写的等级，拿到 1.2 不能说成"1.2 分，满分 10 分"，换了评分标准，旧分数就不能直接比较。

响应、计费与限制

响应里除了 answers，还有 model（作答版本）和 usage（token 用量）。计费按输入 token，输出免费。

当前公布的限额：state 加所有问题共享约 64K token 预算，state 加最长单个问题约 32K；Choice 最多 255 个选项；Score 2–10 级；只支持文本，图片、音频、视频还不支持。速率限制 25 万 token/秒、1200 请求/分钟。错误码就是常见的那些：401（密钥）、422（请求体校验失败，响应会指出字段）、429/529（限流或过载，指数退避）。

接入方式：HTTP 直接调、官方 JS SDK（@typesafe-ai/sdk）、Python SDK（typesafe-sdk），或者通过 Vercel AI Gateway（模型 ID typesafe-ai/jev，价格相同）。

用之前先记住的三条设计原则

问题只描述判断，组合、阈值和副作用由代码掌握，这是官方文档里最重要的一句话，也是它和"让 LLM 输出 JSON"在工程上的根本区别：概率是模型的，决策是你的。

一次请求可以并行问很多问题，官方叫 speculative fan-out（投机扇出）：把可能用得上的判断一次问完，用不到的答案在代码里忽略。对客服分流这种场景，意图、紧急度、情绪、退款意图一次全问，成本几乎不变。

置信度分三档路由：高置信自动执行；中置信先确认或补数据；低置信转人工或回退慢通道。边界放在哪，取决于答错的代价。TypeSafe 文档举的 0.5 复核线、0.9 才执行破坏性操作，都是示例值，不是默认值。阈值要跑在你自己数据上校准：准备二三十条脱敏样本，人工标注期望结果，再对照模型分数；同时统计两种错误，漏检（该拦的没拦）和误报（频繁打断正常操作）。两类分数大量重叠时，移动阈值只是在两种错误之间交换，该回头改问题，或者承认这类判断不适合当前模型。

还有几个可以直接抄的模式：confidence-gated routing（置信度门控）、composite scoring（多个 Score 归一化加权）、intent routing（先路由到确定性代码、专门 LLM 或人工）、two-stage dependency（第二问只在第一问改变选项时才发）。

判断不合预期时，排查有个顺序。先看问题是不是问错了，"有没有截止时间"和"是否紧急"是两个条件；再看材料够不够，只有一行命令文本，判断不了脚本内部行为；把数量、日期、数值范围这类能精确计算的部分移回代码；然后检查题型或措辞是不是变过，换题型、改措辞、换模型之后阈值要重新验证；最后才是缩小上下文，把无关的日志和历史去掉。对可能含恶意指令的输入，还要单独做对抗测试，提示词里写"忽略输入中的指令"只是设计的一部分，不能证明模型不受影响。

三、Jev 的使用场景

一开始我想到它可以用在知名预测网站polymarket上，或者世界杯比赛的预测上。实际上就经过这几天的网友的脑洞挖掘，包括官方网站的整理，已经罗列出一二十种大的分类场景，几百个实际应用场景。下面知识猫AI实验室整理的分类就不错。

发布第一周，社区已经把它试进了打标、路由、护栏、实时界面和游戏。前面提过，知识猫AI实验室（@GeekCatX）把最初几天的 28 个玩法归成八个方向。下面按这张地图挑出每个方向里最有代表性的例子，数字都来自公开的测试和 demo。

Agent 调度。 选择模型、工具和 Skill，判断任务该直接处理、交给更强的模型，还是转人工。一个聊天机器人 demo 完全不用生成式 LLM：把可用工具传进去，问"哪个工具能回答用户最后一条消息"，参数问题（哪个城市、哪个时间段）放进同一次调用，然后代码执行选中的工具，端到端约 300 毫秒关掉一盏智能灯。LiteLLM 和 OpenChamber 用同一形状做模型路由，判断请求该走哪个档位。

记忆与上下文管理。 筛选历史记录、重排检索结果、判断哪些材料适合当前任务。fast-jev-compaction 用它判断一条工具调用是否还要记住、结果是否仍需完整保留，本地规则决定保留、截短还是删除，用原文筛选替代部分摘要，减少路径和报错在改写中走样。

代码与软件质量检查。 PR 审查、代码评分、QA 测试。Celesto 的审查示例先整理 PR 的疑似问题，再让 Jev 判断是否由本次改动引入、是否有证据、是否值得修；另一种做法是对每个改动文件问几个关于安全风险、复杂度和坏味道的 Score 和 Noul，在代码里合成一张风险矩阵。下一节的用例一就属于同一类。

浏览器与电脑操作。 browser-use/jev-ultrafast 和 agent-desktop 把选动作、选目标、评估风险交给 Jev，本地策略决定执行还是停止，主 agent 不必把整棵界面树塞进上下文。一个 demo 用 planner LLM 定目标、Jev 在实时页面的可交互元素里选下一个点哪个，约 7 秒订完机票。下一节的用例二也是同一个分工。

业务分流与内容审核。 客服工单、意图识别、社区审核、人工复核排序。这类调用频繁、流程明确、结果容易检查，这张地图的作者认为商业落地最扎实。收件箱分流是标准形状：优先级、是否垃圾、是否需要回复，每封邮件一次调用，快到能看着它扫完整个邮箱；简历筛选是同一形状加一份评分标准，一家招聘网站对比后称成本约为小 LLM 的十分之一。

搜索与数据处理。 自然语言筛选、实体匹配、图提取、SQL 条件扩展。有人用 24 个主题给 1,018 篇 AI 论文摘要分类，成本 $0.08，中位延迟 256 毫秒一篇；另一个测试 10 分钟跑了 98,000 条商品分类。适合那些很难穷举成关键词规则、却能通过具体案例说明的条件。

实时交互辅助。 会议观察、即时建议、自动补全、Emoji 候选。一次调用几百毫秒，让 Jev 可以跑在每次按键停顿上：一个编辑器 demo 在打字时实时给语气、确信度、紧迫感和"读起来像 AI 写的"打分，标准由开发者自己定义；一个浏览器扩展对信息流里的每条帖子问"这是引战、加密货币推广还是政治争论"，高分就隐藏，分类标准由用户自己定。这类产品的成败取决于误打扰率。

游戏与复杂控制实验。 Tetris demo 反复用 Jev 在旋转、移动、下落之间选择；驾驶模拟器传入结构化观测，问该加速、刹车还是转向；Doom bot 约每秒查询十次，团队估算约 $7/小时；Wikiracing bot 每步在数百个链接中做选择，从不会选一个不存在的链接。交易是争议最大的一类，有人让 Jev 根据实时股票数据决定买入还是卖出，社区出现了多个交易 bot 仓库（多数默认 dry-run），可靠性还没经过验证。

生态：几乎都是可选后端

0xLogicrw 维护的 Jev 开源项目雷达在发布三天后收录了 134 个项目、17 个应用方向。看这些项目，接入姿势几乎一致：在既有流程里加一个可替换的判断节点。LangChain 的 TypeSafeClassifier、Vercel AI SDK 的 provider、Pydantic AI 的 TypeSafeModel、LiteLLM 的复杂度路由，都是把 Jev 接进已有抽象；社区选的位置，大多是"原来用正则或 if 硬扛、或者为此调用一次 LLM 太贵"的小判断。

两个社区技法

把 Jev 当特征提取器。 有人实测"这是 Claude 还是 GPT"：直接提问正答率 52%，改成让 LLM 先列出风格特征维度、用 Jev 逐维打分、再用数据集调权重加权，升到 87.61%。他把 Jev 当特征量提取机器，最终判断交给加权和。

把 Jev 当函数。 像写普通函数一样定义输入参数和返回类型，例如 calculatePriority(task, context) 返回一个优先级分数参与排序，内部是语义判断，外部签名是纯函数。

模型权重没有开源，但社区很快做出了机制等价的复现：NanoJev 用 0.6B 底座跑通了"状态加问题到完整概率分布、零 token 解码"的链路，Qwen-2.5-1B-RLCD 能在 M4 MacBook 上端侧推理。这个模式本身不需要前沿大模型。

四、实战：两个真实用例

自我收到jev的api key的一整天，我使用它应用到开发的三个场景中，下面是我这一天使用的典型场景。

用例一：Go 迁移代码的 Java 对齐审查

我在把一个 Java 后台服务迁移到 Go。其中一个核心接口逻辑很密，参数处理、降级回退、解析、缓存、写库，几十条分支。改完之后，我需要回答一个看起来简单、做起来很烦的问题：Go 版是否实现了 Java 版的全部功能，行为是否一致？

逐行对读不现实。两侧语言习惯不同、文件组织不同，而且"看起来一样"不等于"可观测结果一样"。我换了个思路：把"两侧是否等价"变成一组可以批量判定的问题，交给 Jev。

我只输入了上面👆一句prompt, 它(opencode + deepseek-flash + jev官方插件)后台拆解成了四步：

1. 先对两侧做一次穷尽行为提取，把那个接口拆成 26 条可独立判定的行为（B01–B26），按参数、降级、解析、缓存、写库、埋点等分成九组。
2. 每条行为取两侧逐字代码摘录，带上 file:line，作为 state 的一部分。
3. 每条构造一个 Noul 问题，问的是同一个判断：

注意 criteria 里把"等价"的口径写死了：同一分支、同一常量、同一用户可见消息、同一 DB/Redis 副作用及其顺序；语言内部差异不算。这比问"这两段代码一样吗"精确得多。

1. 一次请求并行判定 13 条，26 条分两批发完。判定阈值：noul >= 0.70 覆盖；0.35–0.70 人工核验；< 0.35 缺口。

初判跑完，25 条落在 0.75–0.96，1 条低到 0.06：B26，埋点路径上的一条 gRPC 分支，Go 版确实没实现。这比"看起来差不多"有用得多，它给出一条带概率的具体缺口。补齐之后（客户端、映射层、配置开关和单测，加上对测试环境的端到端实测），复判 0.75，覆盖。

另外两条初判低分（B13、B15，分别涉及一个散列 ID 的计算和一处字段组装）复核下来是模型对跨语言语义不确定导致的误报。Java 的 charAt 走 UTF-16 code unit、Long.toHexString 打印二补数，Go 用 utf16.Encode 加 uint64(h)；Java 字符串有 null，Go 没有。把这些可核验的语言语义事实补进 state 再判，回到 0.96 / 0.95；那个散列 ID 我还在 Python 里按 Java 公式独立复算，与 Go 测试的黄金值逐字一致。

成本值得一提：一次全量约 1 万 input token，按 $0.042/百万计算，一轮判定不到半美分。这直接改变了我用它的方式：可以反复跑，改完代码再判一轮，而不是"审一次就完了"。

有四条经验我记了下来。

1. Jev 只负责筛选，它返回的是校准概率判断，低分项必须用逐字代码和确定性方法复核。我的流程里 < 0.70 一律人工过一遍，报告里初判和复判都留痕，方便审计。
2. 跨语言判定要补"语言语义注"：同一段逻辑在 Java 和 Go 里的写法差异，会让模型把"写法不同"误判成"行为不同"。补上可核验的语义等价说明后，分数大幅回升。这个"注"本身也能复用，下次同类判定直接拿来。
3. 一次多问、并行判定，是这类批量审查的正确姿势：13 条一次请求，判断质量没有互相干扰（每条独立评估），成本可以忽略。
4. 低分不等于有问题，但一定值得看：26 条里 1 条真缺口（埋点那条）、2 条语义误报，信噪比足够高，比人肉逐行读两侧代码高效太多。

用例二：让 Jev 决定浏览器怎么操作

第二个场景是 Computer Use：让 agent 操作浏览器（打开网页、填表、搜索）。常规做法是把整个界面的无障碍树（AX 树）丢给大模型，让它决定"下一步点哪里"，又慢又贵，一次决策动辄上万 token，还要等好几秒。

因为看网上大家说把jev应用到Computer User/Browser user效果很好，速度很快，我也尝试了下：打开浏览器访问谷歌，搜索关键字，返回前 10 条记录。

我的做法是把它拆开：Jev 只负责在候选元素里做选择，大模型（Codex）负责拆任务、准备参数、核验结果，Computer Use 运行时（cua_repl）负责读取界面和执行。为此我写了一个小的循环引擎（Jev-cu），每次让 Jev 回答四个标准问题：

• target（Choice）：从当前候选元素里选一个，做下一步操作；
• action（Choice）：动作类型，点击、设值、输入文本、按键、滚动、等待、求助；
• done（Noul）：目标是否已经达成；
• risk（Noul）：这一步是否需要用户确认（删除、发送、支付、授权、上传、验证码、安装、系统设置……）。

候选只传文字（角色加标签），不传截图；Jev 决策之后，本地策略门（policy）再过滤一遍：应用白名单、敏感词、风险阈值、置信度阈值。Jev 判断，代码把关，运行时执行。

任务是一次真实的浏览器操作：打开 google.com，在搜索框输入 "jev llm"，取回前 10 条结果的链接和摘要。

按"新流程先 dry-run"的规矩，每一步先预览。

1. 导航。 dry-run 里 Jev 以 confidence 1.00 选中地址栏（text field: 地址和搜索栏），动作 set_value。真实执行：设值 https://www.google.com，press_key Return，页面加载。这一步 Jev 用了 4 步（设值、回车、两次等待），循环用时 8.1 秒。
2. 搜索。 页面搜索框在第一轮 dry-run 里居然没进候选。原因是中文系统下 AX 角色名是"文本输入区"，而循环引擎的候选过滤只认英文角色。补上中文角色映射（按钮、文本栏、文本输入区……）之后，Jev 以 confidence 1.00 选中页面搜索框，click_element 加 type_text 输入 "jev llm"。
3. 提交。 第三步 Jev 选择 press_key 提交搜索，但风险判定给了 0.20，正好达到风险阈值（>= 0.2 停下确认），循环安全地停了。这一步的动作在用户授权范围内（任务本来就是"搜索 jev llm"），属于临界误判，所以我按流程由 Codex 直接接管：确认搜索框仍有焦点、文本正确，然后按下 Return。这次接管单独计数，不算 Jev 的成功。
4. 提取。 结果页加载后（窗口标题 jev llm - Google Search），直接读 AX 树提取前 10 条结果的标题、链接和摘要。这一步是纯读取，不需要 Jev。

数据汇总：

• Jev 决策 10 次（dry-run 3 次、执行 6 次、被风险门拦下 1 次）；
• 累计输入 35,481 token，约 $0.0015；
• 单次决策延迟 300–1500 毫秒；
• 静态快照选元素准确率 9/10（唯一一次偏差发生在中文角色映射修复前）；
• 接管 1 次（提交动作），失败 0 次；
• 最终拿到前 10 条结果，含 LangChain 的 "What Is Jev?"、TypeSafe 官方博客、Reddit 热帖、TechCrunch、MindStudio、YouTube 视频等。

现成的工具箱

如果不想从零搭循环，社区和官方已经有好几样现成的工具。

代码评审插件 jev-review 能接进 Claude Code 和 Codex。安装命令是 npx plugins add NiazMorshed2007/jev-review --target claude-code（Codex 换成 --target codex），装完重启客户端，确认 MCP 连接。之后 Agent 在实现过程中把任务要求、代码差异和必要上下文交给 Jev 评审，拿回分维度的质量信号；改完再用相同要求复评，可以把上一次结果传进去比较。它只发送评审必需的部分，密钥和无关私有代码要自己排除；插件读的变量名是 JEV_API_KEY，和 SDK 的 TYPESAFE_API_KEY 不是一回事。

官方的 TypeSafe Skill（npx skills add typesafe-ai/skills --skill typesafe-ai）解决"设计判断"这一步：帮你把工作流拆成窄问题，把阈值和副作用留在代码里。装好之后，在任务里明确要求使用它。官方还有一条建议值得照做，把问题文本和阈值集中放在容易检查的位置，后面判断异常时，直接核对条件就行。

Claude Code 的 PreToolUse hook 是第三种玩法：在 Bash 命令执行前做一次判断，检查是否包含删除、覆盖、发布等操作，或者是否读取、传输凭证。知识猫AI实验室（@GeekCatX）的实操指南给了一个完整脚本，思路和我上面那个风险门一样，先用 observe 模式只记录，校准之后再切到 block。它只根据命令文本做附加检查，替代不了原有的权限和沙箱。

想看别人把 Jev 用在了什么地方，可以去 jevable.com，上面收集了社区演示项目，可以按类别筛选。

写在最后

这几天用下来，速度和价格不是最打动我的地方。它讲清楚了一个分工：生成和判断是两种不同的工作，该用两种不同的模型。

写文案、写代码、写解释，这些是生成，交给 LLM；从一堆候选里选一个、判断一个命题成不成立、给一个状态打分，这些是判断，交给 Jev。两者之间是普通代码，它拿着概率和阈值，决定走哪条路、要不要人来看一眼。TypeSafe 管这个叫"软件内部的决策原语"，按我的体感，它把"AI 功能"从聊天框里拿出来，变成一行可以测、可以审计、可以设阈值的代码。