Jev 是革命还是骗局？从 0 拆一个「非自回归决策模型」

最近 Jev 蛮火的，但一直没时间真的去试一下，今天下午有空就动手实操了下。

同一个模型，有人写「这是通往 AGI 的一步」，有人写「这些案例都是骗人的」。

闪客两条视频我都看了：一条叫《你管这破玩意叫 Jev？》，一条叫《这些 Jev 的案例都是骗人的》。它们说的其实不是同一件事，第一条拆的是模型本身，「快」和「没有幻觉」是怎么来的；第二条拆的是用它做的 demo，「8 分钟通关我的世界」到底证明了什么。

这篇比较长，先给个目录：

• 拆解（第一到九节）：它是什么、为什么快、「没有幻觉」错在哪、那个 demo 证明了什么、真 Jev 实测
• 方法（第十节）：怎么对待 AI 时代的新知识
• 动手（第十一节）：一套能跑的作业

---

一、先把「是不是骗局」换成一个能回答的问题

「Jev 是不是骗局」这个问题没法回答，因为它没有边界。你没法证明一个东西「是骗局」，就像你没法证明一个人「是坏人」。

能回答的是这四个：

• 它把哪一部分工作，从原来的做法里拿走了？
• 拿走之后，延迟、成本、正确性各发生了什么变化？
• 它宣称解决的问题，和它实际解决的问题，是同一个吗？
• 那个用来证明它的 demo，如果换掉它，结果会变吗？

这四个问题都有明确答案，而且大部分你可以在自己电脑上测出来。下面我一边讲机制，一边把每个问题的实验做掉。

---

二、大模型不擅长什么：从计算器说起

先从一个大家都认的共识开始。

大模型不擅长精确计算。你问它 4837 × 291 等于多少，它可能给你一个很像但不对的数。这件事没人有异议，所以工程上的标准做法是：把计算交给计算器，别让模型算。

视频里有个很好的类比。假设我发布一个模型，宣称比普通大模型快 1 万倍、完全没有幻觉、永久免费，但它只能做两个数的加法，而且输入必须严格符合我规定的格式。

你一眼就看出来我在耍花招。因为我做的事情，本质上是把加法从模型里拿出来，交给了一段代码。代码当然比模型又快又准又便宜。

关键不在于「这算不算作弊」，而在于这个边界划在哪里、划得合不合理。

计算器这个边界划得很干净：两个数相加有唯一正确答案，而且不需要理解语义。

那么，还有哪类问题，大模型其实也不擅长，但边界没那么干净？

---

三、第二类问题：固定枚举的判断

想象一个客服工单系统。工单进来，你需要回答几个问题：

• 该路由给哪个部门？（billing / technical / refund / account）
• 紧急程度几级？（0 / 1 / 2 / 3）
• 客户流失风险高吗？（是 / 否）

对大模型来说这没什么难度。但请注意你实际上在干什么：你把一个擅长自由发挥的生成式模型，强行当成了一个分类器，还限制了它的输出格式。

这跟让大模型当计算器是一回事，不是它真正擅长的用法。

那能不能像计算器一样，单独写个程序处理？不能。因为这里需要理解语义：你得读懂「我上周五用信用卡续费了年度会员，但 App 里还是显示免费版」，才能判断这是 billing 还是 technical。

所以这里有一个真实的优化空间，但边界不能像计算器那样一刀切。

这就是 Jev 这类模型切进去的地方。官方文档对它的定位可以概括成一句话：

保留大模型的语言理解能力，但不生成文本，直接返回你的代码能用的类型化判断和概率。

它的官方文档把用法定义成三种「原语」（primitives）：

原语	回答什么	返回什么
choice	从一组选项里选一个	选中的选项 + 每个选项的概率 + 置信度
score	把内容放到等级量表上（比如 0-3）	分值 + 各等级概率 + 置信度
noul	一个是非问题	P(true)，0 到 1

一次请求可以混着问多个问题。请求长这样：

{
  "state": "客户说信用卡续费成功，但 App 里还是免费版……",
  "model": "jev-latest",
  "questions": {
    "department": {
      "type": "choice",
      "instructions": "这条工单应该路由给哪个部门？",
      "criteria": { "billing": null, "technical": null, "refund": null }
    }
  }
}

返回的是：

{
  "model": "jev-1.13.0",
  "answers": {
    "department": {
      "type": "choice",
      "choice": "billing",
      "probabilities": { "billing": 0.88, "technical": 0.12, "refund": 0.0 },
      "confidence": 0.81
    }
  },
  "usage": { "input_tokens": 318, "output_tokens": 34 }
}

注意 answers 里没有一句自然语言。这是理解后面所有事情的关键：它返回的是类型化的值，你的代码可以直接分支、排序、路由，不需要解析。

顺带一提，usage 里 output_tokens 是 34，但输出 token 不计费，你只为 input token 付钱。

---

四、为什么它能「快」：三个可以分开测量的机制

现在回答第一个问题，它的快，是哪几部分贡献的？

先把基础做法摆出来，给它一个公平的位置。

基础做法是一次调用，让模型读完工单，回答全部 5 个问题，输出一个 JSON。

这个做法在很多场景下够用。工单量不大、延迟不敏感、下游能容错，它完全没问题。引入新方案之前，先确认基础做法在什么条件下会失效。

失效条件有三个，一个比一个深。

缺口一：自回归生成，是一个字一个字往外蹦的

大模型输出文本的方式叫自回归：生成第一个 token，把它接到输入后面，再生成第二个，如此往复。输出长度直接决定耗时。

你问 5 个问题、要求输出结构化 JSON，模型要先写花括号、写字段名、写引号、写逗号。这些字符对下游代码毫无价值，但每一个都要花时间生成。

一个非常朴素的优化：把 5 个问题拆成 5 次调用，并发发出去。每次只输出一个很短的 JSON，5 次同时跑，理论上快 5 倍。这就是「并行采样」最朴素的版本。

但这里有个前提，我在实验里会撞上它。

缺口二：重复的前缀，可以共享

5 次调用里，工单文本完全一样，只有问题不同。也就是说，模型对工单的「理解」被重复计算了 5 次。

推理服务里有个东西叫 KV cache：模型读过的内容，中间计算结果可以存下来复用。如果多个请求共享同一段前缀，这段前缀的 KV cache 就能复用，省掉重复计算。

这是纯工程优化，跟模型本身没关系。

缺口三：既然只要一个标签，为什么要生成文本

这是最本质的一步，也是这类模型真正动刀的地方。

先说清楚来源。官方文档确认了行为：No text generation, no parsing，不生成文本，返回类型化的值和概率分布。但官方没有公开技术论文和权重，所以「内部到底怎么实现的」这一层，只能从民间开源实现（视频里提到有人把 Qwen 的最后一层改造成打分器）和第三方技术文章里还原。

下面这段是「这类模型」的通用做法，不是 Jev 官方确认的架构。但因为它能解释你观察到的所有行为，作为心智模型是够用的。

一个标准的 Transformer 语言模型，最后一层做的事情是：把隐藏状态映射成一个词表上的概率分布，词表可能有十几万 token，然后从这个分布里采样出下一个 token。这个映射层通常叫分类头（lm head）。

Jev 这类模型把这一层换掉了。它不再映射到词表，而是针对你给出的那几个候选选项，分别过一个小的打分器，直接得到每个选项的分数，softmax 之后就是概率。

这就是为什么它不生成文本，它压根就没有生成文本的那个头。

那它输出的 JSON 是哪来的？是工程代码拼的。模型给出 {"billing": 0.91, "technical": 0.06, ...}，你的代码挑出概率最高的那个，拼成 {"department": "billing"} 返回给用户。

这个细节很重要，讲「幻觉」的时候会用到。

---

五、实验一：把「快」拆成能测量的东西

我把上面三种做法在同一台机器上跑了一遍。同一个工单，问 5 个固定枚举的判断问题：

• A1 串行自由生成：一次调用问完 5 个问题，让模型自由生成 JSON
• A2 拆开并发：自己把 5 个问题拆开，5 个 HTTP 请求并发发出去
• A3 约束解码：一次调用，但用 JSON Schema 约束输出

环境是 Apple M5 / 24GB / 本地 gemma4:12b，3 轮取中位数：

做法	HTTP 次数	耗时 ms	输出 token	能解析成 JSON	严格结构通过
A1 串行自由生成	1	4811	53	100%	0%
A2 拆开并发	5	7265	40	100%	100%
A3 约束解码	1	4456	50	100%	100%

两个反直觉的地方。

反直觉一：拆开并发没有更快，反而更慢

7265ms 对 4811ms。为什么？

因为 ollama 默认只给一个推理槽位。5 个请求是排队的，每个请求还要重新 prefill 一遍工单文本。所谓「并发」，在服务端变成了串行。

「并行」不是免费的技巧，它是一种要花钱买的基础设施。视频里说「手动拆成三次并行调用就能快三倍」，这个结论成立的前提是，你有一个真正能并发的服务层（托管 API，或者配好并发槽位的推理服务）。

我给服务端开了 4 个槽位想验证这一点，结果在 24GB 机器上跑 12B 模型时以 HTTP 500 告终，没拿到干净数据。日志里能看到代价：4 个槽位意味着上下文被切成 4 份，每个槽位 4096，模型本身已经吃掉 9399 MiB 显存。

这就是那句「复杂度不会消失，只会转移」的具体样子：你把复杂度从模型生成转移到了服务端调度，代价是显存、上下文长度和运维复杂度。

反直觉二：A1 的 JSON 100% 能解析，但严格校验 0% 通过

A1 返回的是这个：

{"department": "billing", "urgency": 3, "churn_risk": true,
 "sentiment": "angry", "human_intervention_required": true}

语法完全合法。但对照我约定的 schema：

• need_human 被悄悄改名成 human_intervention_required
• urgency 从字符串 "3" 变成了数字 3
• churn_risk 从 "true" 变成了布尔 true

下游代码按 need_human 取值，会直接拿到 None。这就是视频里说的「结构幻觉」，它输出的一定是 JSON，但不一定是你约定的那个 JSON。

而且三轮全都一样，不是偶发。

还要注意一点：A2 和 A3 的严格通过率是 100%，功劳不在「拆开」，而在「约束」。A2 的每个子问题我也加了 schema 约束。所以这里其实是两个独立机制：

机制	解决什么	我的实验里的效果
拆开并发	输出长度 → 延迟	单槽位下无效果甚至更慢
约束解码	输出结构 → 可靠性	结构通过率 0% → 100%

把两件事混在一起讲，就是营销话术的常见做法。

---

六、「没有幻觉」这句话，错在哪

现在回答第三个问题：它宣称解决的问题，和它实际解决的问题，是同一个吗？

先说「幻觉」这个词。它在日常讨论里被混着用了，其实至少有两层意思：

• 结构幻觉：输出的格式不符合约定，JSON 缺字段、枚举值越界、类型不对
• 内容幻觉：格式完美，但答案是错的

视频里说，Jev 官网宣称「解决了幻觉」。而根据前面的机制，它解决的只是第一层：因为输出不是模型生成的，是程序按你的 criteria 拼的，所以枚举值不可能越界，JSON 不可能破损。这不是概率意义上的「很难出错」，是工程意义上的「不可能出错」。

这确实是价值。但它跟「回答得对不对」没关系。

我做了个实验验证这个区分。8 道固定枚举的题，用 JSON Schema 约束解码来问，其中 2 道是陷阱题，正确答案根本不在选项里：

模式	JSON 合法率	值在枚举内	答案正确率	中位耗时 ms
约束解码	100%	100%	37.5%	2889

8 题全部产出合法 JSON，全部落在枚举内，只有 3 题答对。

两道陷阱题它照样给出了「完全合法」的答案：账号安全、6。格式上无懈可击，内容上完全错误。

结构正确率 100%，内容正确率 37.5%。这两个数字可以同时成立。

顺便说个坑：这个实验我第一次跑的时候没关闭思考模式，模型把 200 个 token 全花在内部推理上，response 字段是空的。「模型没输出」和「模型输出错了」是两回事，我把那次数据标为无效了。这种坑只有自己跑才会遇到。

---

七、实验二：那个末影龙 demo 证明了什么

现在回答第四个问题：那个 demo，如果换掉 Jev，结果会变吗？

先说视频二作者做了什么。他把那个开源项目下载到本地跑起来，然后把交互日志全部捞出来做了可视化。关键发现是：

• 165 次「决策」里，129 次（78.2%）只给了 1 个候选动作
• 给 2 个候选的时候，两个选项的差别只是坐标差 1 格（挖这个方块还是那个方块）
• 地图种子是固定的，完整通关路线、物资坐标、先收集什么收集多少，全部写在规划模型的系统提示词里
• 那些「方向键、空格、鼠标移动」的操作，是程序预先写好的动作模板

所以他的实验是：把决策模型换成随机选择器，结果一样；把规划模型也去掉，结果还是一样。

我没有那个项目的代码，也没法测量它。但我可以按他报告的这个结构做模拟，看看「决策模型」在这种结构下能贡献什么。这个模拟不需要任何模型，几秒钟就跑完：

=== 场景 1：候选动作由程序预置（那个 Minecraft 项目的结构）===
决策次数 165，其中只有 1 个候选的 129 次，占比 78.2%

选择策略                       通关率      多花步数          5 次里至少成功一次
无模型（照路线执行）               57.7%       0.0               98.6%
随机选择器                    57.7%      19.7               98.6%
永远选第一个                   57.7%       0.0               98.6%
完美选择器（上界）                57.7%       0.0               98.6%

=== 场景 2：候选动作没有被预筛过（真正需要判断的场景）===
每一步给 5 个候选，正确动作的位置随机，选错一步就崩

选择策略                       通关率
随机选择器                     0.0%
永远选第一个                    0.0%
完美选择器（上界）               100.0%

读法：场景 1 里四种策略的差距，就是「决策模型」在这个 demo 里的全部贡献，零。

「随机选择器」唯一的影响是多花 19.7 步（多挖几个方块），通关率一模一样。因为 78.2% 的步骤只有一个候选，剩下 21.8% 的步骤选错也无所谓。

而场景 2 才是决策模型真正被需要的地方：候选没被预筛过，选错一步就崩，随机策略的成功率是 0。

那个 demo 从来没有进入场景 2。

这里要小心一个推理跳跃。这个结论不说明「Jev 没用」，它说明的是：

那个 demo 没有证明 Jev 有用。

这两句话差别很大。作者可能确实是个工程能力很强的程序员，能搭出这套东西本身就不容易。问题在于，他把「程序预先写好的路线和动作模板」的功劳，记在了「模型的决策能力」头上。

---

八、实验三：直接问真 Jev

前面所有实验用的都是本地的 gemma4:12b。它们验证的是方法，「拆开并发」「约束解码」「候选预筛」这些机制到底管不管用。

但它们回答不了一个问题：Jev 自己准不准。

所以我调了真的 Jev（/v1/systemone，返回 jev-1.13.0）。下面每组数字都是真实响应。

先说一个意外发现：官方文档是公开的

我原以为会面对一个黑盒，视频里说它「没有公布实现细节」。但 docs.typesafe.ai 有完整的 API 参考、置信度计算公式，还有一页专门讲 Jev 1.13 的已知缺陷。

那页的开头写着：

Jev isn’t perfect. Here are some jagged edges we are aware of with jev-1.13.

它自己列了 9 条失效模式，其中几条和视频「揭露」的内容高度重合：

官方承认的缺陷	原文
不会数数	does not count reliably… The model recognizes the shape of an answer rather than tallying
不擅长数学	Jev is not a calculator. We strongly recommend implementing any mathematical logic in code
选项顺序会影响答案	the order of a Choice’s options can affect the answer, and jev-1.13 leans toward the option that comes first
不能生成文本	not trained to generate text… there are other models for that
会被对抗性内容影响	Content written to adversarially steer the model… can move the answer

这件事本身值得记一笔：一个被批评「靠营销」的产品，把缺陷清单写得比很多开源项目都细。

而且官方文档明确说了一句关键的话，置信度只是概率分布的派生统计量：

TypeSafe’s confidence is one reasonable way to summarize a distribution, not the only one.

Choice 的公式是 (p_max − 1/n) / (1 − 1/n)。也就是说，「95% 置信度」只意味着概率分布很尖，不代表模型做了二次确认。

这正是我下面要测的。

D2：正确答案不在选项里，它还自信吗

这是我认为最重要的一组。4 道题，3 道是陷阱题，正确答案根本不在选项里，1 道是对照组：

题目	正确答案	在选项里？	它选了	confidence	选中项概率
发票抬头开错，归哪个部门	财务/开票	否	售后维修	0.94	0.96
abcdefgh 有几个字母	8	否	6	0.95	0.96
这段 Rust 代码是什么语言	Rust	否	Go	0.25	0.50
对照组：扣款成功但会员没生效	计费	是	计费	0.69	0.79

3 个陷阱题里，2 个给出了 0.94 / 0.95 的高置信度错误答案。

这就是视频里那个「99% 概率是重度营销 + 99% 置信度」为什么不能当证据。高置信度和正确答案之间，没有必然联系。当正确答案不在选项里时，它不会说「我不确定」，而是挑一个最不坏的，然后给它 96% 的概率。

第三条陷阱题它给了 0.25 的低置信度，说明这个信号不是完全没用，但你不能依赖它。

公平地说，这个坑官方文档里提到了，给的解法是加一个显式的「未提及」选项：

it gives you somewhere to put an explicit “not stated” option so a missing part is reported rather than guessed.

但这是「调用方要自己想到」的责任，不是模型自带的保护。而「置信度能告诉你该不该信」这个直觉，在这里是失效的。

D3：换个选项顺序，答案会翻吗

官方自己承认「偏向前面的选项」。我用同一个工单、同一组选项，只改排列顺序：

排列	它选了	confidence
[计费, 技术, 退款, 账号]	账号问题	0.43
[账号, 退款, 技术, 计费]	账号问题	0.32
[退款, 计费, 账号, 技术]	账号问题	0.23

答案没翻（三次都选了「账号问题」，而且它在三个排列里分别位于第 4、第 1、第 3 位，看不出位置偏好）。

但 confidence 从 0.43 掉到 0.23，掉了一半。同一个判断，只因为选项换了个顺序，置信度就变了。

这条缺陷官方说 in some cases，我的单次测试没复现出答案翻转，但复现出了置信度漂移。如果你用 confidence 做阈值门控（官方推荐的模式），这个漂移会直接影响你的路由决策。

D4：批量 vs 拆开

官方文档声称：13 个问题放进一次调用，比拆成 13 次调用便宜 12.2 倍、快 10 倍。

做法	耗时	input tokens
1 次调用（13 问）	1306 ms	870
13 次调用（并发）	2872 ms	7878
比值	快 2.2x	省 9.1x

省 token 这一项，实测 9.1x，和官方说的 12.2x 很接近。

速度快这一项，实测只有 2.2x，远低于官方说的 10x。原因很清楚：我这 13 次是并发发的，墙钟时间由最慢的那一个请求决定，而不是 13 倍串行。官方那个 10x 大概是按串行调用算的。

这个差异本身是个好教材：同一个「快 10 倍」，在不同对照条件下可以是 10x 也可以是 2.2x。看到性能数字，第一件事是问「跟什么比」。

顺便，这也修正了视频里的一个说法。视频说 Jev 快是因为「把问题拆成多次调用并行发」，官方文档说的恰恰相反：不要拆，放进一次调用。Jev 的「并行」是请求内部一次前向传播里同时算完所有问题，不是扇出成多个请求。

D5：校准，预测概率和实际正确率对得上吗

30 道有确定答案的是非题，一次调用问完：

指标	结果
准确率（0.5 为阈值）	96.7% (29/30)
真陈述的平均 P(true)	0.930
假陈述的平均 P(true)	0.018

分桶看：

概率桶	样本数	平均预测	实际为真
[0, 0.2)	13	0.018	0.0%
[0.2, 0.4)	1	0.370	100%
[0.8, 1.01)	16	0.965	100%

看起来校准得不错：说「几乎不可能」的 13 题，实际全假；说「几乎肯定」的 16 题，实际全真。

但要老实说这个测试的局限：这 30 题太简单了，分布是双峰的，29 题落在两端，中间区间只有 1 个样本。它没有真正检验「中间地带」的校准，而中间地带才是置信度真正有用的地方。

答错的那 1 题也挺有意思：地球上最大的沙漠是撒哈拉沙漠，它给了 P(true)=0.37。严格说，最大的沙漠是南极洲（按降水量定义），所以它的犹豫不算错，是我出题时把常识当成了事实。

D6：把难度拉开，看置信度跟不跟得上

为了补上 D5 的短板，我又出了 36 道题，按 easy / medium / hard 各 12 道：

难度	题数	准确率	真陈述平均 P	假陈述平均 P	Brier
easy	12	100.0%	0.970	0.020	0.0010
medium	12	100.0%	0.934	0.084	0.0148
hard	12	91.7%	0.876	0.102	0.0414

置信度确实跟着难度走：真陈述的平均 P 从 0.970 一路降到 0.876，Brier 分数单调变差。

唯一答错的是「珠穆朗玛峰的高度每年都在上升」，它给了 P(true)=0.420。这是诚实的犹豫，不是自信的错误。它知道自己拿不准。

把 D2 和 D6 放在一起，才是完整结论

这两个实验看起来矛盾：一个说它自信地犯错，一个说它校准良好。其实它们测的是两件不同的事：

场景	表现
有确定答案的是非题（noul）	校准良好，难度上升时置信度会下降
选项覆盖不全的选择题（choice）	会给出 0.94 / 0.95 的自信错误答案

它的置信度在「我知道我拿不准」这件事上是可信的；但在「我的选项里根本没有正确答案」这件事上，它不会报警。

这个区别有实际后果。如果你用 choice 做分类，而你的选项集合漏了一种真实情况，模型不会说「这不在我的选项里」，它会挑一个最不坏的，然后给你 96% 的概率。你的下游代码如果按 confidence 门控，会放心地执行这个错误决定。

官方文档给的解法是显式加一个「未提及」选项。但这是调用方要自己想到的责任，不是模型自带的保护。

这组实验改变了什么

把跑之前听到的说法，和跑之后的结果并排放：

跑之前听到的说法	跑之后的结果
它没有公开技术资料	官方文档完整公开，还自带 9 条缺陷清单
快是因为把问题拆成多次并行调用	官方推荐不要拆；批量省 token 9.1x、快 2.2x
选项顺序会影响答案	答案稳定，但 confidence 漂移一半
它其实是个很聪明的分类器	选项覆盖不全时，它会自信地给错答案（D2）
它的置信度是校准过的	属实，但只在是非题上（D6）

它是个真实的、可用的工程工具，官方文档也相当诚实。但「置信度」这个信号，不能当成「答案正确」的保证来用。

---

九、所以 Jev 到底有没有用

绕了一圈，回到最初的问题。我的判断是：

它是一个真实的工程优化，但它优化的那个东西，和它宣传的那个东西，不是同一个。

值得用的场景：

条件	为什么
任务是固定枚举的判断，且选项集合稳定	打分器只在给定选项上工作，选项越稳定收益越大
调用量很大，延迟和成本敏感	省掉的是逐字生成的开销，量越大越明显
下游是代码而不是人	只需要一个标签，不需要读一段自然语言
你能接受把格式约束写进调用方	这是它的代价，见下

不值得用的场景：

条件	为什么
需要开放式生成（写文案、总结、对话）	它压根不生成文本，这是能力边界不是性能问题
选项集合频繁变化或需要模型自己发现新类别	打分器绑定在给定选项上
调用量小、延迟不敏感	基础做法够用，多引入一个模型只增加运维面
你需要解释性（为什么这么判断）	它给的是概率，不是理由

而它的代价，视频里那句话说得最准：

复杂度不会消失，只会转移。

它把复杂度从模型生成转移到了调用方：

• 你的输入必须符合它要求的格式
• 你的选项集合必须是固定的、有限的
• 它的输出是相对固化的，要接入别处得你自己处理
• 你多了一个需要部署、监控、版本管理的模型

默认建议：如果你手上有一批「高级 if-else」式的判断任务，而且量足够大，这类模型值得试。但先做个对照实验，用你现在的大模型加约束解码跑一遍，看看差距值不值得多引入一个组件。我上面的实验一就是干这个的。

关于 confidence，有一条必须记住：它是概率分布的派生统计量，不是「答案正确」的保证。第八节的 D2 里，它对两个正确答案不在选项里的问题给出了 0.94 / 0.95 的置信度。用它做门控可以，但别把它当成正确性校验，尤其要确保你的选项集合覆盖了所有真实情况，或者显式加一个「未提及」选项。

---

十、怎么对待 AI 时代的新知识

前面所有内容都是「术」。这部分是「道」。

1. 把「真假判断」换成「边界判断」

「这是不是骗局」是个坏问题，因为它逼你在「信」和「不信」之间二选一。而现实里绝大多数技术宣称，是部分为真、部分夸大、边界被故意模糊。

换成这些问题，你立刻就能开始工作：

• 它把哪部分工作拿走了？
• 拿走之后，什么变好了，什么变差了？
• 它宣称解决的问题，和它实际解决的问题，是同一个吗？
• 那个 demo，如果换掉它，结果会变吗？

这四个问题有一个共同点：它们都能被验证，而不是被相信。

2. 把声明分成四类

看到一个新东西，先把它的说法分成四堆：

类型	例子	你该怎么做
可测量	「快 10 倍」「$0.042/百万 token」	找对照条件、找样本量。能自己测就自己测
可验证	「不生成文本」「返回概率分布」	找一手材料：官方文档、API、代码
无法验证	「砍掉了分类头」「用了 RLCD 算法」	官方没公开论文和权重，只能当第三方还原
只能靠信任	「通往 AGI」「革命性突破」	直接归到营销，不用花时间反驳

大部分争论之所以吵不出结果，是因为双方在用不同类别的声明互相攻击。一边拿「通往 AGI」来证明价值，一边拿「成本对比不公平」来证明骗局，两边说的都对，但不在同一个层面上。

3. 一手材料永远比二手转述便宜

这次最直观的例子就是模型名被转写成三种写法。而这只是最表层。

我在核查的时候还发现一个更有意思的：那篇「我一年前就做了同样的事」的技术文章，声称自己的第二篇论文提出了「基于 RL 的 schema 决策框架」。我去查了那篇论文的实际标题：

Confidence-Aware Routing for Large Language Model Reliability Enhancement

讲的是生成前用置信度做路由，跟「schema 决策框架」不是一回事。第一篇文章的标题和摘要倒是对得上。

这不是说作者在撒谎，而是说：哪怕是当事人自己写的、带链接的技术文章，涉及「谁先做的」「谁更好」的部分，也会因为立场而失真。而且那篇文章本身就在推广作者自己的开源模型。

一手材料在哪：

• 官方有没有公开技术论文和权重？（Jev 两样都没有）
• 有没有可复现的代码？
• 那些性能数字的对照条件是什么？

但这里有个我一开始判断错的地方。

我最初把「没有公开论文和权重」当成了负面信号。直到翻了它的文档站（第八节），才发现判断标准不该是「公开 vs 不公开」，而是它公开了什么：

公开的东西	说明什么
技术论文、权重、训练数据	可复现，但商业模型很少给
API 参考、行为契约、失效边界	够你判断「能不能用」，这才是工程上真正需要的
benchmark 图、营销话术	基本没用

「没公开论文」和「没讲清楚」是两件事。前者是商业选择，后者才是你要警惕的信号。

4. 区分「我不懂」和「它没讲清楚」

AI 领域的新概念密度很高，很容易产生一种感觉：听不懂是我水平不够。

但很多时候，讲不清楚是讲述者的问题。判断方法很简单：如果一个概念你听三遍还是不知道它在什么条件下失效，那大概率不是你的问题。

真正讲清楚一个技术，一定会讲到它的边界。只讲能力不讲边界的，要么是没想清楚，要么是不想让你想清楚。

顺便，这篇视频一的作者就做得很规范，他明确说了 Jev「非常有用，是工程实践上的一个很好的优化」，然后才批评它蹭「解决幻觉」的热点。能承认对方价值的人，批评才值得听。

5. 焦虑的正确用法

视频二结尾有句话我很认同：AI 时代该焦虑的时候还是要焦虑，但由错误甚至欺骗性信息导致的焦虑，是没有必要的。

具体一点：焦虑应该花在「我的工作里，哪部分正在被这类工具替代」上，而不是花在「某个模型是不是通往 AGI」上。前者你能做点什么，后者你什么都做不了。

---

十一、怎么动手

上面几组实验都是我自己跑的，思路和参数都写在正文里了。想复现的话，下面这几步就够了。

先跑一个不需要模型的

末影龙那个模拟不需要任何模型，纯随机数，几秒钟出结果。它最能说明「一个 demo 可以什么都不证明」。

再跑需要模型的

前面几组用本地 ollama 加一个小模型就能跑，量级和结构差异都看得出来：

ollama pull gemma4:12b
ollama serve

真 Jev 那组需要一个 API key，从 TypeSafe 的控制台拿，按量计费。跑完 5 个测试大概几万 token，成本不到一分钱。key 只从环境变量读，别写进代码里。

四个由浅入深的作业

作业一（改条件）：把实验一里的工单文本换成你自己领域的文本，问题换成你工作里真实存在的判断。看看「自由生成」的字段名还会不会跑偏。换个领域，结论还成立吗？

作业二（找边界）：把第六节那个约束解码实验的选项从 4 个加到 20 个，再加几道陷阱题。看看「约束解码」的答案正确率怎么变。枚举越多，模型是更准还是更不准？

作业三（诊断矛盾指标）：第五节那个实验会给你两个数字，「能解析成 JSON」和「严格结构通过」。如果这两个数字差很多，说明什么？如果它们一样，又说明什么？什么情况下你会只看第一个数字，然后被坑？

作业四（最重要，也最容易做错）：用你自己领域的陷阱题，正确答案故意不放在选项里。看看它会不会照样给你一个高置信度的错误答案。如果你的业务里存在「选项覆盖不全」的可能，这个测试必须先做。

一个进阶想法

视频一提到网上有民间实现：把 Qwen 的最后一层分类头拿掉，换成打分器，用专项数据训练。如果你有 GPU，这是理解「非自回归决策」最彻底的方式，因为你会亲眼看到「没有生成头」这件事意味着什么。

提示：实验一里 A2 和 A3 的严格通过率都是 100%，但原因不同。想清楚这个区别，你就理解了「约束」和「架构」是两条独立的路径。

---

结尾

绕了这么大一圈，最后能带走的是这么一句：

不要问「这是不是骗局」，要问「它把哪部分工作拿走了，代价转移给了谁」。

这个判断可以迁移到下一个你遇到的 AI 新概念上，不管它叫什么名字，也不管它的名字被转写成了几种写法。

一个可以立刻做的动作：把末影龙那个模拟里「只有 1 个候选」的步骤从 129 降到 0，让决策模型每一步都在真的做选择。工作量涨了将近 5 倍，实测结果是这样：

随机选择器	单选项 129 步	单选项 0 步
通关率	57.7%	57.7%
多花步数	19.7	92.2

它多做了 5 倍的决策，通关率纹丝不动。

决定「决策模型重不重要」的，不是它做了多少次决策，而是它的候选是不是被人预先筛过。这就是「程序预筛」和「模型决策」之间的真实分界线。

---

本文有两组实测数据。第五、六、七节用的是本地 Apple M5 / 24GB / gemma4:12b，验证的是方法，样本量 3 轮 / 8 题，只够看出量级和结构差异。实验三（第八节）调的是真的 Jev，返回 jev-1.13.0，验证的是产品，每组数字都是真实响应。