什么是 Jev 决策模型？它适合干什么？

AI 把写代码这一步加速了，瓶颈却留在了"审"这一步。一个不会说话、不写代码、只输出判断的模型，能不能替我把 PR 先过一遍？

AI 写代码越来越快，卡住我的变成了"审"

用 AI 写代码这件事，速度早就不成问题了。

一个需求丢给编码助手，几分钟就吐出一个能跑的 PR。改得快，写得也多------问题是它们全都堆在那儿，等我审。

以前一天三四个 PR，我还能老老实实读完 diff，在脑子里过一遍影响面。现在一天十几个，标题还都写着 refactor、chore、fix: 调整一下样式。我慢慢开始变成这样：

扫一眼改动文件数量，不多 → 过
标题看着无害 → 过
CI 绿了 → 过

然后人就成了整条链路上最慢、也最不可靠的那一环。

有点讽刺：我们把"写代码"加速了十倍，瓶颈却原封不动地留在最后------那个坐在屏幕前、一天只能集中注意力几个小时的自己。

AI 确实还替代不了人的决策，但人的注意力被摊薄之后，决策质量是往下掉的。这才是真正的问题。

所以当 Jev 这个模型刷屏的时候，我第一反应不是"又一个新模型"，而是： "这东西能不能替我先把 PR 过一遍？"

它不是又一个聊天机器人。它不写代码，不写文档，甚至不写一个字------它只输出判断。而"判断"恰好就是我审 PR 时真正在做的事。

这篇文章，就是我找这个答案的过程。

Jev 是什么？一句话：它叫决策模型，不吐字

Jev 是 TypeSafe AI 在 2026 年 9 月 15 日发布的模型。作者 Diogo Almeida 是前 OpenAI 研究员，参与过 InstructGPT------就是让 ChatGPT 学会"听人话"的那套训练方法。

有点意思的是：他当年帮 AI 学会了聊天，现在做了个不会聊天的模型。

它的调用方式和普通 LLM 完全不同。你给它两样东西：

state ------ 要判断的原始材料（一段日志、一个 diff、一个 package.json）
questions ------ 一组答案范围预先定好的判断题

它返回三种"题型"的答案：

题型	返回什么	什么时候用
`Choice`	从你给的选项里选一个（最多 255 个）	分类、路由、归属
`Score`	在一个量表上打分	风险、严重度、优先级
`Noul`	一个是 / 否的概率（0~1）	真伪判断、门禁、护栏

关键区别在这：

普通 LLM 是把答案写出来------一个字一个字往外蹦。中间那一大段你根本不用，但钱和时间都花了。
Jev 是把答案直接算出来------一次前向就出结果，没有"生成文字"这一步。

直接后果有三条：

快。官方说端到端 70--500 毫秒。
便宜。输入 $0.042 / 百万 token，输出免费。
不可能输出你选项之外的东西。因为答案空间是你锁死的，它没法"编"。

最后一条其实挺重要。写 LLM 提示词时我们干过最多的事是什么？请你只返回 JSON，不要加任何解释------然后它还是加了。Jev 这里不存在这个问题，因为压根没有"自由生成"这个环节。

不过丑话说在前面。 它更笨：官方自报准确率 67.8%，最强 LLM 是 74.1%。它也不太稳：把 732 个相同的判断跑三遍，只有 24% 的结果完全一致。而且它不解释理由。

所以它不该被理解成"更强的 LLM"，更像"更快的 if 语句"。

那它适合干什么？AI 给了我四个问题

这是我觉得最值得记住的部分，可以参考一下：

#	问题	不过关的后果
1	是否为选择题？（能枚举出选项）	需要"生成点什么" → 换 LLM
2	高频、原子、可重复？（一天几百上千次）	低频 → 省不下什么，上它没意义
3	判错可逆或可补救？（能回滚、能复核、能事后发现）	不可逆 → 碰红线，换人或换确定性规则
4	没人会问「为什么」？（不需要解释、不需要审计）	要理由 → 它给不了，换 LLM

四问全过，它几乎总是对的工具。任何一条不过，就别用。

第三和第四条最容易被忽略，也最容易出事。下面三个例子会反复回到它们。

三个能马上用上的场景

一、报错分诊：一天几千条，真正要看的只有三条

先说一个前端每天都在经历的事。

早上打开Sentry 监控面板：过去 24 小时新增 3,812 条 JavaScript 报错，来自 47 个不同的 issue。

你不可能全看。但你也不敢不看------上个月那次线上白屏，就是从一条看着毫不起眼的 TypeError 开始的。

于是你开始赌概率：先点数量最多的、再看名字眼熟的、第三看运气。大部分时候赌对了，但你心里清楚，这不是判断，这是抽签。

那让大模型帮你读？你把这条丢进去：

javascript 复制代码

TypeError: Cannot read properties of undefined (reading 'length')
  at CartSummary (src/pages/cart/CartSummary.tsx:88)

24h 次数: 1,240      影响用户: 37（占 0.04%）
版本分布: 100% 来自 v2.13.4 及以前，v2.14.0 归零
浏览器:   92% 来自 Chrome 119/120（三个月前的老版本）

它会给你一篇八百字的分析，从"可能是接口返回结构变了"讲到"建议加强类型校验"，末尾再加一句"建议进一步排查"。

写得挺全。但它没回答你唯一想知道的那件事：这条到底要不要管。

把同样的材料递给 Jev：

javascript 复制代码

state = {
  报错:     "TypeError: Cannot read properties of undefined (reading 'length')",
  栈顶:     "CartSummary (src/pages/cart/CartSummary.tsx:88)",
  次数_24h: 1240,
  影响用户: 37,
  版本分布: "100% 来自 v2.13.4 及以前，v2.14.0 归零",
  发布记录: "v2.14.0 于 2 天前上线",
}

questions = {
  real_user_impact: Noul(),   // → 0.12  老版本残留，不是新问题
  fixed_in_latest:  Noul(),   // → 0.96  v2.14.0 已经修掉了
  is_noise:         Noul(),   // → 0.88
  owner_module:     Choice(["cart", "checkout", "payment", "search", "unknown"]),
                              // → "cart"
  severity:         Score(0, 10),  // → 2.1
  action:           Choice(["静默归档", "归入已知问题", "通知 owner", "立即叫人"]),
                              // → "静默归档"
}

一次请求，六个维度的判断同时出。注意 severity: 2.1 和 real_user_impact: 0.12 这两条------它们才是"不用管"的依据：版本分布已经归零，说明修复上线了，剩下那一千多次全是老版本客户端的残留。次数多不等于严重，这个区分靠肉眼得翻好几层才看得出来。

于是路由长这样：

javascript 复制代码

if (r.severity >= 8 || r.real_user_impact > 0.8) 
    page_oncall(r.owner_module);
else if (r.severity >= 5)  
    notify(r.owner_module);            // 进群，不吵人
else if (r.is_noise > 0.7) 
    archive().tag('降噪', state);      // 归档，但留证据
else                       
    tag(r.owner_module, 'triage-review'); // 拿不准的，交给人

一早上三千八百条，真正落到人手上的可能就三五条。这就是它和 LLM 最本质的差别------多问几个问题几乎不增加延迟，因为是一次并行算完的，不是一段一段写的。

两个坑。

第一，被降噪的东西必须可回溯。这里比别的场景更危险：判错一次"静默归档"，埋掉的可能是下一个白屏事故。所以每一条被降噪的都要留着"当时喂了什么、它判了什么"，并且定期抽样复核------尤其盯那些"数量还在涨、severity 却判得很低"的。

第二，它能分诊，不能处置 。action 里没有"关闭 issue"这个选项------真正关单交给确定性规则（比如"连续 7 天零新增自动归档"）。它只负责排序，按按钮还是人的事。

二、PR 变更风险分级：直接回答开头那个问题

上面那个场景很常见，但没正面回答我最开始的问题。这个才是------能不能让它帮我先把 PR 过一遍？

假设你收到这么个 PR：

javascript 复制代码

PR #4821  "refactor: 拆分 Button 组件"

改动文件:
  src/components/Button/index.tsx
  src/components/Button/Button.css
  src/components/Button/Button.stories.tsx
  src/styles/tokens/radius.css        ← 等等，这是设计 token

标题写的是"拆分组件"，听着是个无害的内部重构。你扫一眼大概也就 5 秒，然后决定"跑个常规 CI 就行"。

问 Jev 一下：

javascript 复制代码

questions = {
  risk:             Score(0, 10),   // → 7.2
  affected_surface: Choice(["无影响", "单页", "公共组件", "全局"]),
                                    // → "全局"（动了设计 token，全站圆角都受影响）
  review_depth:     Choice(["免审", "单审", "需架构 owner"]),
                                    // → "需架构 owner"
  run_full_e2e:     Noul(),         // → true

  // 顺手加几个专属的原子检查
  props_changed_but_types_not: Noul(),  // → 1.00  props 加了 variant，.d.ts 没同步
  stories_updated:             Noul(),  // → 0.00  Storybook 没更新
  design_token_touched:        Noul(),  // → 1.00
}

结论完全反直觉：一个自称"重构"的 PR，实际动了全局设计 token、props 类型没同步、Storybook 也没更新。 它从"低风险重构"直接跳到"需要架构 owner 审核 + 跑全量 E2E"。

这类判断的价值不在于取代人，而在于抓住人因为累、因为赶时间而放过的那 5% 的样本。

顺带说说成本。有开发者拿它审 PR，一次大约七万分之一美元，1000 个 PR 也就几美分；同样的活交给前沿模型，大概要烧掉十几美元。

三、npm 供应链：这个包没有 CVE，但它就是恶意的

这个例子最能说明"换个问法"的力量。

你 npm i 之后，lockfile 多了个包：

javascript 复制代码

react-hook-form-utils
描述:      "Handy helpers for react-hook-form"
首次发布:  3 天前
版本:      0.0.1 → 0.0.9        ← 三天发了九个版本
维护者:    账号创建于 5 天前，名下只有这一个包
scripts:   { "postinstall": "node ./setup.js" }        ⚠️
依赖:      ["axios", "child_process", "os"]            ⚠️
下载量:    12 次 / 周
README:    抄的 react-hook-form 官方文档

传统做法是查漏洞库。问题在于------查不到。

它不是"有漏洞"，它是"生来就是恶意的"。漏洞库是滞后的，投毒是实时的，这类包在漏洞库里干干净净。

那换个问法呢？不问"它有没有已知漏洞"，问"它的行为符不符合它对自己的描述"：

javascript 复制代码

questions = {
  behaviors_match_description: Noul(),  // → 0.12
    // 一个表单辅助工具，为什么要 child_process 和 os？
  has_suspicious_lifecycle:    Noul(),  // → 0.97
    // postinstall + 子进程 + 读系统信息 = 经典窃密模式
  maintainer_risk:             Noul(),  // → 0.94  账号 5 天前注册，只有一个包
  typosquat_risk:              Noul(),  // → 0.88
  supply_chain_risk:           Score(0, 10),  // → 9.4
  review_priority:             Choice(["升高优先级", "触发人工审查"]),
                                        // → "触发人工审查"
}

"声明做 A、实际也做 A"是前端包的常态，所以偏离就是信号。前端依赖树上千个包，人工根本审不完，但这个问题可以批量地问。

但这里有条死线 ：注意最后那个字段叫 review_priority，枚举里压根没有"放行"这个选项。

因为判错的代价不对称。判错"触发人工"，最多浪费一个工程师十分钟；判错"放行"，就是一次供应链攻击。

所以真正的门禁还是交给确定性机制------私有 registry 代理、lockfile 校验、无网络安装、许可证白名单、npm audit。Jev 只负责一件事：把可疑的挑出来排个队。

安全场景里，它永远只能"升高优先级"，不能"放行"。这条没有例外。

什么时候别用它

顺手补个反面清单，这四类永远别用：

任何"写点什么出来"的活------它一个字都不写，这是设计如此
任何不可逆动作------发布、回滚、删数据、安全放行
任何需要解释或审计的判定------它不解释，出了事你连"为什么"都说不出来
任何需要多步推理、或者要看图读长文档的活------32K 上下文、纯文本、不支持图片

最后：它到底是个什么角色

我想到的比喻是分诊台，不是医生。

急诊的分诊护士不治病，她决定：这个病人去哪个科、有多急、要不要直接推抢救室。真正的诊断和治疗，是医生的事。

Jev 在流水线里的位置就是这样------它决定"这事归谁、多急、要不要升级"，不做诊断，不做处置。

所以回到开头那个问题------能不能让它替我把 PR 过一遍？

能。但只到"过一遍"为止：它把该重点看的挑出来，把可以快速放过的标出来，决定权还在我手上。

这顺便也回答了我最初那个偷懒的念头。我想要的其实是"让它替我做决定"，而它真正能给的，是"别再让我的注意力浪费在不需要它的地方"。

听起来是亏了，但这才是能长期用的那一半。

回头看那三个例子，其实长得都挺像：

别人刚干完活（跑完测试、构建完、发出告警），现在需要有人赶紧判一下"这活干得对不对、有多重要"。

这种事天天都有、答案就那么几种、判错了重跑一次就行，也没人会来问它凭什么。四条全中。

反过来看，需求评审、架构设计、技术债这些为什么不适合？也不是它不够聪明------是这些事一年也碰不了几次，答案本来就说不清，而且你一定会跟人解释"当初为什么这么选"。

所以别问"Jev 行不行"，要问"这件事适不适合它干"。

同一套判断能力，拿去判"这次测试挂了是不是偶发"，挺好用；拿去判"这个架构方案行不行"，立刻就废。

不是它突然变笨了，是后面这种事本来就不归它管。

它好不好用，跟它聪不聪明关系不大，跟你要它干的活长什么样关系很大。

以后碰到新场景，不用纠结"Jev 能不能做到"，拿那四个问题过一遍就行了。