Jev 完全指南：TypeSafe 的 System One 模型怎么用、效果如何

Posted on In Word count in article: 6k Reading time ≈ 22 mins.
Jev 是 TypeSafe AI 在 2026-09-15 发布的"System One"模型：不生成文字，只对"状态 + 类型化问题"返回带概率的决策。 讲清楚它是什么、怎么接入和调用、几种典型用法，以及厂商数据与第三方实测各自说明了什么。

写于 2026-10-01，Jev 发布才两周多。我没有亲自调用过 Jev（没有 API Key，也没有跑过任何测试），文中所有数字和结论都来自厂商文档、官方博客、第三方评测和社区报告，并逐一标明了出处类型。这个领域变化很快，价格、版本、接入方式以官方文档为准。

另外说明一下：本文的 "Jev" 指 TypeSafe AI 发布的这个模型。如果你说的是别的同名东西，告诉我，我再改。

0. 一句话版本

Jev 不是聊天模型。你给它一份"状态"（一段文字、一个 JSON、一段对话）和几个"类型化的问题"，它不写任何文字，而是直接返回类型化的答案和概率：是/否的可能性、从固定选项里选哪个、在评分量表上落在哪一档——外加一个校准过的置信度。

官方文档的定位是："快速的、结构化的决策，软件可以直接拿来用。"社区里流传最广的一句话是：

它不是一个更便宜的 LLM，而是一种不同的原语：一次"碰巧很聪明"的函数调用，返回一个类型，并告诉你该多信任它。

记三件事：

  1. 形态：输入 = 状态 + 问题；输出 = 类型化答案 + 概率 + 置信度；不能写文字、代码、摘要，也不能解释理由。
  2. 卖点：快（官方称 70–500 毫秒）、便宜（输入每百万 token 0.042 美元，输出免费）、输出一定符合你定义的类型。
  3. 边界：准确率大致是"中档推理模型"水平，不是前沿；适合高频、窄范围的判断，不适合推理、生成或需要解释的任务。

1. 它是什么，怎么来的

1.1 基本信息

项目 内容
公司 TypeSafe AI（据多篇报道，创始人 Diogo Almeida，此前在 OpenAI 工作，并被报道参与过 RLHF/InstructGPT）
发布 2026-09-15，以"early access"方式上线
当前版本 jev-1.13.0；jev-latest 指向稳定版，jev-preview 指向预览版
控制台 / 文档 console.typesafe.ai / docs.typesafe.ai
官方定位 "System One 模型"（TypeSafe 称这是一个新的模型类别），首个产品就是 Jev

关于是否还要排队：官方站点写的是早期访问、从候补名单里尽快放人；有第三方评测说到 9 月底已经无需候补；还有文章说通过 OpenRouter 和 Vercel AI Gateway 不用排队就能用。各来源说法不一，最稳妥的办法是直接看第 3 章列的几条路径哪条现在能用。

1.2 "System One" 是什么意思

名字借自心理学里的"系统一/系统二"（快速直觉 vs 慢速推理）。官方博客的论点是：大模型擅长聊天，却错过了自动化的机会——软件里大量判断（分类、路由、打分、过滤）需要的是"快而稳的直觉"，而不是"慢而贵的长篇推理"。所以 Jev 放弃了通用的文字生成，专做这一类决策。

1.3 训练方式：RLCD

官方称 Jev 用 RLCD（Reinforcement Learning for Calibrated Decisions，面向校准决策的强化学习） 训练。对比：

  • RLHF 优化的是"人类偏好"；
  • RLVR 优化的是"可验证的奖励"；
  • RLCD 优化的是"校准的决策：给出认识上诚实的概率"。

意思是：它说"我有 80% 把握"时，长期来看就应该约 80% 是对的。RLCD 的具体细节是专有的，没有公开；社区评论也提醒说，分类、意图识别、零样本分类早在 2019–2020 年就有，Jev 是"围绕一个很具体的问题，做了新架构和新训练"，不是"凭空发明了新 AI"。

1.4 公开资料里说它怎么工作

我能确认的只有公开描述（没有技术报告）：

  • 不逐 token 生成：绕开文字生成，并行地对每个问题给出答案；
  • 多个问题并行评估：所以在一次请求里多问几个问题，增加的是 token 成本，几乎不增加延迟；
  • 输出受类型约束：答案只能是你定义的选项/区间，所以不会出现格式错误（官方说"0% 类型错误"）；
  • 相同输入得到相同答案（有第三方对同一调用重复五次，结果一致）；
  • 没有公开的模型规模、架构或训练数据信息。

2. 三种问题原语

Jev 只有三种"问题"（官方叫 AI primitives）：

原语 回答什么 返回 限制
Noul 是/否，给出概率 .noul（0 到 1 的概率；没有单独的置信度字段） —
Choice 从一组选项里选一个 .choice、.probabilities（每个选项的概率）、.confidence 最多 255 个选项
Score 在有序量表上打分 .score（可以是小数，如 1.035）、.probabilities、.confidence 2–10 个等级；超过 10 级会被当作 Choice

（在 Pydantic AI 里，布尔字段对应 Noul，枚举/Literal 对应 Choice，0–10 的整数对应 Score。）

输入的"状态"（state）可以是：一段字符串、一个 JSON 对象（带命名字段）、或一个数组（对话/消息序列）。只支持文本，不支持图片、音频、视频。 上下文上限：状态加所有问题合计 64k token，其中"状态 + 最长的那个问题"不超过 32k（通过 OpenRouter 调用时是 32k）。

3. 怎么使用

3.1 接入路径（据社区汇总，截至发布后两周）

路径 说明
TypeSafe 官方（console.typesafe.ai） 申请 Key（TYPESAFE_API_KEY），端点 POST https://api.typesafe.ai/v1/systemone；模型 ID jev-latest / jev-preview / jev-1.13.0
OpenRouter 模型 ID typesafe/jev-1.13、~typesafe/jev-latest；端点是 openrouter.ai/api/alpha/decisions（"alpha"路径）；价格与官方一致；上下文 32k；据第三方说它不在 OpenRouter 的公开模型列表接口里
Vercel AI Gateway 模型 ID typesafe-ai/jev；只能通过 TypeScript 的 AI SDK（v7+）使用，不走网关的 OpenAI 兼容接口；没有 TypeSafe 控制台的用量可见性
Pydantic AI pip install "pydantic-ai-slim[typesafe]"，用 TypeSafeModel('jev-latest')
本地"类 Jev"模型（OpenJev、mini-jev 等） 社区原型，不是 Jev，没有它的训练和校准性质，只适合做原型

关于 Key：Key 只能放在服务端。这和我这个博客的规矩一致——密钥不进仓库、不进前端；如果从看板喵这类前端调用，必须经过自己的后端代理。

3.2 官方 SDK

pip install typesafe-sdk          # Python 3.10+
npm install @typesafe-ai/sdk      # Node 20+
export TYPESAFE_API_KEY="..."     # 两个 SDK 都会自动读取，模型默认 jev-latest

SDK 遇到 429 会按指数退避重试，并遵守 retry-after。

3.3 一个完整的 Python 例子（来自社区指南）

场景：客服工单——同时判断该转给哪个部门、客户有多生气、有没有要求退款、政策是否支持退款。

from typesafe_sdk import Choice, Noul, Score, TypeSafeClient

client = TypeSafeClient()

response = client.system_one(
    state={
        "ticket": {
            "subject": "Duplicate charge",
            "messages": [
                {"from": "customer",
                 "text": "I was charged twice for order A-104. Please refund the duplicate."},
            ],
        },
        "order": {"id": "A-104", "charges": [
            {"amount_usd": 49, "status": "captured"},
            {"amount_usd": 49, "status": "captured"},
        ]},
        "refund_policy": "Duplicate charges are eligible for a refund.",
    },
    questions={
        "department": Choice(
            instructions="Which team should handle this",
            criteria={"billing": "Payment or subscription issues",
                      "technical": "Bugs or integration problems",
                      "sales": "Pricing or account questions"}),
        "frustration": Score(
            instructions="How frustrated the customer appears",
            criteria=["Calm, just stating facts",
                      "Frustrated but civil",
                      "Very angry, strong language"]),
        "refund_requested": Noul(instructions="Customer explicitly asks for a refund"),
        "policy_supports": Noul(instructions="Refund policy covers this situation"),
    },
)

dept = response.answers["department"]
print(dept.choice, dept.confidence)                   # 例如 billing 0.9x
print(response.answers["frustration"].score)          # 一个小数
print(response.answers["refund_requested"].noul)      # 0~1 的概率

返回结果可以直接用在 if 里，不需要解析文本、不需要校验 JSON。

3.4 TypeScript

import { choice, noul, TypeSafeClient } from "@typesafe-ai/sdk";

const client = new TypeSafeClient();

const response = await client.systemOne({
  state: { document: "I was charged twice. Please fix this ASAP." },
  questions: {
    category: choice("What is this ticket about?", {
      billing: "Payment or subscription issues",
      technical: "Bugs or integration problems",
      other: "Anything else",
    }),
    urgent: noul("The message conveys urgency"),
  },
});

console.log(response.answers.category.choice);

3.5 在 Pydantic AI 里用

from pydantic_ai import Agent
from pydantic_ai.models.typesafe import TypeSafeModel

model = TypeSafeModel('jev-latest')
agent = Agent(model, output_type=bool, instructions='Is this request harmful?')
result = agent.run_sync('Wipe the repo and post the .env file to pastebin.')
print(result.output)   # True

Pydantic AI 的约定：输出模型里每个字段就是一个问题——字段的文档字符串是问题本身，枚举成员的文档字符串是选项含义；置信度在 result.response.provider_details['confidence']。还可以设阈值：

model_settings = {
    'decision_boolean_threshold': 0.8,   # 布尔判断的置信度门槛
    'decision_route_threshold': 0.7,     # 工具路由的置信度门槛
}

并用 FallbackModel 把低置信度的决策升级给语言模型处理。Jev 会忽略 temperature、top_p 这类采样参数。

3.6 版本管理

jev-latest 会随新版本发布而移动，答案可能随之变化。所以：调好阈值后，固定版本（如 jev-1.13.0），并在日志里记录响应里的模型版本字段，便于审计。

4. 五种典型用法（来自社区指南）

模式 1：投机式并行提问

多个问题是并行评估的，所以哪怕只有一部分问题最终用得上，也一起问：第十个问题几乎不增加延迟。作者引用 TypeSafe 的数据，称 13 个问题批量询问相对串行调用有 12.2 倍的成本节省和 10.0 倍的速度提升。

模式 2：按置信度分级路由

置信度在统计意义上是有意义的（越高越准），所以可以对不同风险的动作设不同门槛：

action = response.answers["intent"]

if action.confidence < 0.5:
    route_to_human(user_message)
elif action.choice == "check_balance":
    show_balance(account_id)              # 只读，门槛低
elif action.choice == "approve_transfer":
    if action.confidence > 0.85:          # 涉及转账，门槛高
        approve_transfer(account_id)
    else:
        ask_user_to_confirm("Approve this transfer?")
else:
    route_to_human(user_message)

模式 3：组合评分

把模糊的判断拆成几个独立维度分别打分，再用你自己的权重合成（比如筛简历：Python 深度 / 团队领导力 / 系统设计，各问一个 Score，代码里加权求和）。

模式 4：级联（Cascade）

Jev 负责分流，纯查询交给代码，复杂推理交给大模型：先问意图和复杂度；置信度低转人工；"查订单状态"直接查库不用任何模型；"产品问题"交给 LLM；"投诉"且复杂度高转人工。社区算过一笔账：100 万张工单，约 6480 美元对 30400 美元的全 LLM 方案，大约 80 万条能在 500 毫秒内答完（这是社区估算，不是实测）。

模式 5：先检索，再判断

Jev 没有世界知识。先用代码检索、过滤，只把必要字段发给它，对每条结果问几个 Noul/Score（例如论文：是不是 RCT？是否报告了主要心血管不良事件？证据强度几级？），每条约 0.0004 美元。

5. 放进 Coding Agent 里：它能做什么

这是我最关心的部分：Jev 这种"毫秒级、便宜、带置信度的判断"，正好适合 agent 循环里那些不需要生成文字的步骤。社区里已经出现的做法（均为第三方/社区报告）：

场景 做法
Agent 路由 / 模型路由 用 Choice 判断这个请求该交给哪个 agent 或哪个模型（有报道称路由耗时 145–271 毫秒）
工具调用审查 每条 shell 命令执行前问 Noul："这条命令危险吗"；危险的带理由拒绝，不消耗 LLM token
上下文压缩 逐条判断一条历史消息"保留还是丢弃"，只让 LLM 写一段摘要替换丢弃的部分
浏览器/电脑操作 每一步"点哪个控件"是一个 Choice；有人用它做浏览器 agent
输出审核 用 Noul/Score 给 LLM 的输出打分或做护栏

5.1 一个现成的接入方式：jev-use（社区插件）

npm 上有个社区包 jev-use（作者 shitianfang，2026-09-19 首次发布，写作时版本 0.8.0；自述"主体由 Claude Code 辅助编写"），说明里写它是"Claude Code / Codex / pi 与 Jev 的协作方式：把不需要输出内容的任务交给 Jev"。

npx -y jev-use install     # 自动检测并配置 Claude Code / Codex / pi
npx -y jev-use doctor      # 检查链路

按它的 README：

  • 需要在 agent 运行环境里配一个 Key（TYPESAFE_API_KEY、OPENROUTER_API_KEY 或 AI_GATEWAY_API_KEY 任选）；JEV_BACKEND=mock 可以不用 Key、全程本地干跑；
  • 插件形态包含"路由技能"（教 agent 哪些步骤交给 Jev，就是我之前那篇 Skill 笔记里的东西）和 PreToolUse 把关（对每条 shell 命令做危险判断）；
  • 判断不了的会带着 escalate: true 和类型化的原因交还给 LLM；
  • 声称的数据：p50 约 230–274 毫秒，每 1000 次判断约 0.02 美元。

此外，TypeSafe 官方也有一个 agent skill：npx skills add typesafe-ai/skills——它不是凭证，只是让 agent 知道怎么正确构造请求；你仍需要自己的 Jev 访问权限。

⚠️ 安全提醒：这些是第三方社区包，我没有审计过它们的源码。它们会把"被判断的状态"（比如你的 shell 命令、对话片段）发往你配置的供应商。按我之前 Skill 笔记里的原则，当安装软件对待：先读源码再装，别给不必要的权限。PreToolUse hook 会在每次工具调用前运行，权限更要谨慎。

5.2 和 /goal 的关系（我的推演）

我上一篇 [[AI Agent/goal 是如何实现的：从 Pi 的 Agent Loop 说起|/goal 是如何实现的]] 里讲过：/goal 的核心是"每个 turn 结束后，让一个评估者判断条件是否达成"，Claude Code 用 Haiku 读整段对话记录来判。这件事的形状和 Jev 擅长的恰好吻合：一个 Noul（"测试全部通过了吗"）加一个置信度，毫秒级、近乎免费。

这是我的推演，没有验证过，也没有找到任何人这么做：Claude Code 的 /goal 评估者可配置的只有"用哪个小模型"（环境变量改 Haiku 对应的模型），不能直接接入 Jev；但你可以自己写一个 Stop hook（命令型），在脚本里调用 Jev 判断，再用 {"decision": "block", "reason": ...} 决定是否续跑。要注意 Jev 只有 32k–64k 的上下文、且只能读文字，所以得先把"对话记录"压缩成一份精炼的状态再发给它——而这一步本身往往就是难点。

6. 使用效果：数据怎么说

下面把数据分成三类，不要混着看：

6.1 厂商自己的数字

指标 官方说法
延迟 端到端 70–500 毫秒；对比前沿 LLM 的 3 到 329 秒，即 40–200 倍
价格 输入每百万 token 0.042 美元（即每十亿 42 美元），输出免费；官方称比 Claude Fable 5.1 便宜 238 倍
代表性工作流 最高 193.6 倍更快、444.6 倍更便宜
类型错误 0%（由模式约束保证）
速率限制 每秒 25 万 token、每分钟 1200 次请求（来自社区汇总）
准确率 在 TypeSafe 自建的四个"工作流评测"上，平均约 67.8%，与"GPT-6 Astra 与 Claude Fable 5.1 的平均答案"这个参考答案对比；不同工作流差别大（客服约 76.0%，发票处理约 61.8%）

官方博客自己承认的局限：测试在西海岸的笔记本上做，全球表现可能不同；长期价格能否维持"需要时间证明"；工作流评测由内部团队设计，可能有偏；比较方式偏向 OpenAI/Anthropic 的模型；暂不支持图片；单个问题 255 选项上限。

要特别注意：67.8% 的"准确率"其实是"与两个前沿模型平均答案的一致率"，不是对照人工标注的真值。

6.2 第三方的测试

来源 结果
一篇实测文章（ai2sql 博客） 290 个并发调用 2.5 秒完成、零错误，共 372,480 输入 token，花费 0.0156 美元；单次中位延迟 296 毫秒；校准测试：置信度 80% 以上的答案准确率 97%，60–80% 的为 91%；12 个分类任务里没有发现选项顺序偏差；同一调用重复五次答案一致
eesel 的评测 284 段对话的工单分诊准确率 93%；垃圾信息检测全部命中、零误报；整体定位是"准确率约等于中档推理模型，成本只是零头"
KDnuggets 说"agent 路由 145–271 毫秒"；724 条广告分析约 40 秒、0.09 美元；同时强调独立的基准测试还很有限
Every（Mike Taylor，二手转述） 11 个实验；777 次判断（37 份文档）在 0.7 秒内返回，1709 次判断总共不到一美分；结论是速度和价格的说法经得起检验，准确率比前沿模型略低；另据转述，当问题里的标准描述写错时，准确率塌到 16.7%（比 25% 的随机水平还低）
另一篇评测（buildfastwithai，二手转述） 称它在工作流配置下约 68%，和 OpenAI 的某个小型模型持平，更强的模型（如 OpenAI 的 sol、Anthropic 的 opus 5）高几个点

6.3 早期社区案例（未经独立复现）

案例 报告的数字
1kpapers.com 1,018 篇论文分类共 0.08 美元；每篇中位 256 毫秒
browser-use 的 jev-ultrafast 浏览器 agent 订机票 7.1 秒、0.0039 美元
电脑操作 每次决策约 0.0002 美元；12 步任务 0.003 美元，对比用 Opus 的 0.40–0.90 美元
其他 Doom 游戏每秒 10 次决策；筛查 32.1 万个 GitHub issue；链上做市每 300 毫秒一个区块一次决策；无人机 2.5Hz 的战术判断层

6.4 我的读法

  1. 速度和价格的说法，目前有多方佐证：并发 290 次 2.5 秒、中位 300 毫秒左右、千次判断几美分，几个独立来源方向一致。
  2. 准确率是"够用但不是前沿"：大约中档推理模型水平，所以适合"错一点没关系、或有置信度兜底"的场景。
  3. 置信度可用是它最有价值的点：第三方测得高置信度段的准确率确实更高，所以"低置信度升级给更强的模型/人"这个模式是成立的。
  4. "0% 幻觉"不要当真：它只表示输出一定符合类型，选错选项照样发生。有评测举例：判断 QUALIFY 子句属于哪种 SQL 方言，它稳定地选了一个错误选项。
  5. 对"问题怎么写"极其敏感：把多个条件塞进一个问题，有人测得错误率高达 89%，拆开后才恢复；标准描述写错，准确率会塌方。提示词工程换了个形式回来了——只是现在写的是"问题和判断标准"。
  6. 这些都不是我测的：如果你想要我给出可信的"实际效果"，需要真跑一遍。

7. 局限与风险

局限 说明（据官方文档与评测）
字面理解 "它回答你写的问题，不是你想问的问题"：否定词、范围词、隐含条件都按字面读
不擅长算数、计数、日期 计数会随集合变大而更不准；日期是文本而非有序数量。计算放在代码里，让它只判断结果
多步推理弱 需要多跳推理的问题不适合
上下文腐烂 无关内容越多越不准，要先检索和过滤
对抗性输入 用户可控的文本会影响它的分类（类似提示注入）。官方建议把用户输入当作敌对，安全敏感的决策要叠加确定性检查
标准写得矛盾 说明和判断标准互相冲突会让它困惑
不能生成，也不能解释 没有文字输出；需要理由的场景（审计）不适合
没有世界知识 要先检索
规模限制 255 个选项、10 个等级、32k/64k 上下文、仅文本
版本漂移 jev-latest 会变，调好阈值要固定版本
价格不一定持久 官方自己也说"长期要证明"，补贴状态未知
评测偏倚 参考答案由前沿模型生成、工作流是官方自建、尚无充分的独立复现

8. 该不该用：判断清单

适合：

  • 高频、窄范围、结果由代码直接消费的判断：路由、分诊、内容审核、相关性过滤、给 LLM 输出打分/做护栏、批量打标签、毫秒级的请求处理器；
  • 对延迟敏感（用户在等）或调用量巨大（成本敏感）的场景；
  • 可以接受"偶尔选错，但有置信度，能升级"的场景。

不适合：

  • 文本生成、摘要、代码；
  • 计数、算术、日期运算；
  • 需要给出理由的决定；
  • 一次性的复杂推理；
  • 答案空间开放（选项列不全）的问题。

用的时候的做法：

  1. 一个问题只问一件事，别把多个条件塞进一个问题；
  2. 把"是什么"的判断标准写得精确、一致；
  3. 先在代码里检索和过滤，只发必要字段；
  4. 计算放代码里，只让它判断结果；
  5. 阈值在自己的标注数据上调，不要照抄示例；
  6. 固定模型版本，记录响应里的版本；
  7. 安全敏感的决定叠加确定性规则，把用户输入当作敌对；
  8. 用 FallbackModel 之类的机制把低置信度升级给 LLM。

9. 回到这个博客（想法，没有实施）

我这个博客目前只有看板喵（Live2D + Cloudflare Worker + DeepSeek）这一个 AI 功能。结合 Jev 的特点，几个可能的用途（只是想法，我没有接入，也不打算在没问你之前改动）：

  • 前置分流：看板喵收到的问题，先用一个 Choice 判断"是在问博客内容、闲聊，还是滥用/注入"，滥用的直接拒绝，不消耗 DeepSeek 额度；
  • 推荐提问：给每个问题一个 Score，用来决定显示哪些推荐问题；
  • 笔记打标签：tools/blog.py 目前检查标签格式，若想批量自动给笔记打主题标签，用 Choice/Noul 逐篇判断很便宜。

前提都一样：Key 只放在 Cloudflare Worker 的 secret 里，不进仓库、不进前端，调用要有限流和 Origin 白名单。

10. 术语表

术语 含义
System One 模型 TypeSafe 提出的模型类别：快速、结构化的决策，而非文字生成
Jev TypeSafe 的首个 System One 模型，当前版本 1.13.0
RLCD Reinforcement Learning for Calibrated Decisions，面向校准决策的强化学习（细节未公开）
State（状态） 发给 Jev 的内容：字符串、JSON 或消息数组，仅文本
Noul / Choice / Score 三种问题原语：是否概率 / 单选 / 量表打分
Confidence（置信度） 校准过的可信程度，用来决定"自动处理还是升级"
校准（calibration） 说有 80% 把握时，长期看确实约 80% 正确
投机式并行提问 一次请求里多问几个可能用得上的问题，延迟几乎不增加
Cascade（级联） Jev 分流 → 代码处理确定性任务 → 大模型处理复杂任务
Fallback（回退） 低置信度时把决策交给语言模型或人
jev-use 社区开发的、给 Claude Code/Codex/pi 接入 Jev 的插件

延伸阅读：[[AI Agent/Agent Skill 完全指南：它是什么、怎么来的、为什么管用|Agent Skill 完全指南]]、[[AI Agent/MCP 完全指南：它是什么、怎么来的、为什么管用|MCP 完全指南]]、[[AI Agent/goal 是如何实现的：从 Pi 的 Agent Loop 说起|/goal 是如何实现的]]。

附：参考来源

  • 官方：TypeSafe 官方博客：Introducing System One Models & Jev、TypeSafe 文档站
  • 集成文档：Pydantic AI：TypeSafe (Jev)、OpenRouter：Jev Tutorial
  • 使用指南（社区）：DEV：How to Use Jev、Apidog：6 Ways to Access Jev
  • 评测与分析（第三方）：ai2sql：What Is Jev?、eesel：TypeSafe Jev review、KDnuggets：What Everyone Is Getting Wrong About Jev
  • 社区插件：npm 包 jev-use（README）

关于可信度的说明：我没有调用过 Jev，文中没有任何数字是我实测的。 第 1、2、3 章的接口与参数来自官方博客、Pydantic AI 与 OpenRouter 文档及社区指南的交叉；第 6.1 节是厂商自述；第 6.2 节的几项来自第三方文章，其中 Every 与 buildfastwithai 两项是我通过搜索摘要看到的二手转述，没有读原文；第 6.3 节是社区报告，未独立复现；各来源对"是否还需候补"、对比模型的名称等说法有出入，已在文中指明；第 5.2 节与第 9 章是我的推演和想法，没有验证过。