💡最近两周刷到的 Jev 内容突然密集起来：官方博客《Introducing System One Models & Jev》在 2026-09-15 宣布 early access 开放，入口是 console.typesafe.ai；中文社区很快跟上，鱼皮那期讲"正式开放 + 保姆级教程 + 实战测评"，AIJasonZ 那期讲"接进 3 个生产流程，反欺诈、找客户、筛爆款"。
我这边收到的第一反应，八成是同一个：这是不是又一个更强的代码模型？能不能把我那个编码 agent 背后的模型换成它？第二反应也很一致——它既然这么快、输出还免费，为什么不直接拿来做客服对话和工单摘要？
这两个问题看着都很合理，其实都问反了。Jev 不生成文本，它输出的是带类型的决定和概率。也就是说，大家设想的第一个用法——“换个模型”——恰恰是官方文档里明确写"做不到"的那个用法。
真正值得单独写一篇的，是它换掉的那个默认假设：一次模型调用总要返回一段能读的话。这个假设一破，成本怎么算、延迟怎么比、能不能放进生产链路的关键分支，全都要重新排一遍。
这一篇就按"读懂它"的路子走：先给它一句话定义，再拆输出契约和三个原语，然后把概率这层真正的卖点摊开，最后对一遍价格、延迟和三种"它不是"；接入细节留给第二篇，官方自己列的失败模式留给第三篇。
![]()
1. 它是怎么火的，以及第一个问题几乎所有人都问反了
这一章回答：它的出处在哪，最流行的那个误解错在哪。
先把时间线钉住，省得被二手信息带着走。
| 时间 | 事件 | 口径 | 本文怎么用这条 |
|---|---|---|---|
| 2026-09-15 | 官方博客《Introducing System One Models & Jev》发布，宣布 early access 开放，入口 console.typesafe.ai | 官方口径 | 作为"它开始进入公众视野"的起点 |
| 同一时期 | 官方 Models 页把 Jev 列为 TypeSafe 的旗舰模型，并且是第一个 System One 模型 | 官方口径 | 定位依据，正文第 2 章展开 |
| 开放后一周内 | 中文社区批量出现教程与测评视频，讲上手、讲接进生产流程 | 第三方内容 | 只作为"火"的证据，具体数字不采信为结论 |
然后是那个问反了的问题。官方 introduction / coding-agents 页写得很直接：Jev不是Claude Code、Cursor、opencode、Copilot 这类编码助手背后那个模型的即插即用替代品；没有任何一个model: "jev-latest"之类的设置项，能把你的 agent 变成"Jev 驱动的 agent"。
误解里的用法：你的编码 agent --> 把背后模型换成 jev-latest --> agent 照样聊天、照样写代码 ✗ 官方明确说做不到 实际里的用法：你的编码 agent --> 帮你写调用 Jev 的代码 --> Jev 在生产链路里返回决定与概率 ✓ 官方给的正是这条Q1：那它到底火了个什么？
火的不是"更强的 coding"，而是换了交付物。以前一次模型调用要的是"一段可以给人读的文字"，Jev 这次调用要的是"一个可以直接进 if 分支的决定，外加这个决定有多确定"。这个差别足以让一批原本因为"输出不可控"而上不了生产的流程重新被评估一遍——这才是刷屏的原因，跟它写代码厉不厉害没关系。
Q2：为什么说"让编码 agent 帮我接 Jev"才是正解？
因为两边分工本来就不同：编码 agent 擅长产出文本和代码，Jev 擅长产出决定。你的 agent 写一段调用 Jev 的代码，代码里拿回choice和confidence去决定走哪条分支——这是官方反复强调的正确叠法。官方甚至还给了 TypeSafe 的 agent skill：Claude Code 插件走claude plugin marketplace add typesafe-ai/skills再claude plugin install typesafe@typesafe-ai，也可以直接npx skills add typesafe-ai/skills --skill typesafe-ai。
命令行细节、以及怎么把返回的概率落成代码分支，都留给第二篇。这里只需要记住一句：Jev 是你在生产里调用的一个服务，不是你对话时选的那个模型。
Q3：网上流传的说法里，哪几句要打折看？
- "零幻觉"确实是官方博客的原话（原文 “optimized for structured outputs and can’t hallucinate”），DataCamp、Firecrawl 只是照抄。但官方文档里对同一件事用的是calibrated，并且明确写了校准不保证单次——两处口径要分开引。准确表述在第 5 章末尾。
- “两个数量级”"The model never makes type errors"都是官方博客原话，属于发布文口径；官方那句延迟写的也确实是端到端（70ms-500ms），但倍率被限定在 “System One shaped queries”，且没点名对照组模型（第 5 章摊开对表）。
- **“接进去就能省一大笔”**要看负载形状：只按输入计费这件事，决定了省不省取决于你往里塞多少 state、一次拿回几个决定。
2. 一句话说清它是什么
这一章回答：谁提供的、名字从哪来、它背后那套世界观是什么。
一句话版本：
Jev 是 TypeSafe 提供的旗舰模型，也是它的第一个 System One 模型——读自然语言，输出带类型的决定和概率，不输出文本。
官方发布文里那句更像人话，也更值得抄进设计文档：“Think of Jev as a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out.”（把 Jev 当成一次前沿智能的函数调用：非结构化的 state 进去，带类型的概率化决定出来。）同一段里他们还交代了这套栈的构成——新的模型架构、一个并行采样器、以及一种他们叫RLCD的训练方法，这三样分别对应第 3 章的"并行"和第 4 章的"概率可用"。
这句话里有三个要各自拆开的东西。
第一层：提供者与模型 ID。提供方是 TypeSafe AI。当前线上模型 ID 是jev-1.13.0，日常更常用的是两个别名：jev-latest（SDK 默认）和jev-preview。这里有个坑，官方文档写明了：jev-preview目前和jev-latest指向同一个模型，并不存在独立的 preview 版本。GET /v1/models可以列你账户可用的模型名，目前列出来的也是别名，不是带版本的 ID。
第二层：名字出处。“System One” 取自 Daniel Kahneman《思考，快与慢》里的区分：
System 1 --> 快、直觉、并行、不需要解释 --> Jev 取的就是这一层：快速、聚焦的判断 System 2 --> 慢、审慎、串行、边想边说 --> 传统 LLM 的长链推理更接近这一层官方 concepts/system-one 页强调，命名取的是"快速、聚焦的判断"这层意思，不是给模型编人格故事。
第三层：世界观。官方 AI primer 把整套主张叫Machine Native Intelligence，核心判断是这句：大规模 AI 自动化里，约 99% 是机器与机器的交互，只有 1% 与人的交互。既然 99% 的输出压根没有人在读，优化目标就该从"读起来舒服的回答"换成"在软件里行为可预期的输出"。他们给自己的定位原话是“Building prod, not God”。
| 维度 | 通用 LLM 的典型优化目标 | Jev / System One 的优化目标（官方口径） | 落到接口上是什么 | 反例 |
|---|---|---|---|---|
| 服务对象 | 那 1%：输出给人读 | 那 99%：输出给代码消费 | 字段名、类型、取值空间都是契约的一部分 | 返回一段"建议转给账务组，因为……" |
| 好输出的定义 | 读着顺、信息全、带解释 | 类型对、取值合法、概率可统计 | probabilities/confidence可直接参与判断 | 解释很精彩但没法写成断言 |
| 失败长什么样 | 语气怪、答非所问、罗嗦 | 分支走错、阈值判错、下游炸 | 靠概率分档拦下来 | 一段没人复审的自由文本进了工单系统 |
| 成本压力 | 输出 token 越多越贵 | 只在输入侧计费 | 输出长度不进账单 | 为了"说清楚点"多烧钱 |
这里容易搞混一点：它不是"另一个更便宜的通用大模型"。TypeSafe 的立场是把"回答"这个交付物本身取消掉，换成"决定"。
顺带一条历史包袱，能帮你看清这个选择的分量：官方口径里，RLHF 被用于训练 InstructGPT 与 ChatGPT，而 TypeSafe 联合创始人 Diogo Almeida 参与了 RLHF 的共同发明。这家公司不是路过做工具，它是在自己参与发明的那条路线旁边，往反方向走了一步——差在哪，第 4 章讲。
3. 差别在输出契约，不在"聪明程度"
这一章回答：一次调用到底给你什么东西。
大多数人比模型，比的是"谁更聪明"。Jev 和 LLM 的差别不在这——它一样吃自然语言，不一样的是返回什么。
官方 concepts/system-one 页的对比很干净：与 LLM 一样理解自然语言输入，但返回类型化决定和概率，而不是生成文本；不写回复、不产代码、不解释自己的推理过程。官方给自身的优势总结是七个词：structure / reliability / observability / testability / speed / consistency / low cost。
接口长这样：
POST https://api.typesafe.ai/v1/systemone Authorization: Bearer <API_KEY>请求（官方 api.md 原文示例）：
{"state":"Help! My payouts have been failing for 3 days.","model":"jev-latest","questions":{"department":{"type":"choice","instructions":"Which team should handle this?","criteria":{"billing":"Payments, invoicing, refunds","technical":"Bugs, outages, integrations","sales":"Pricing, upgrades, new accounts"}}}}响应（官方示例，注意model字段回的是带版本的 ID）：
{"model":"jev-1.13.0","answers":{"department":{"type":"choice","choice":"billing","probabilities":{"billing":0.88,"technical":0.12,"sales":0.0},"confidence":0.81}},"usage":{"input_tokens":318,"output_tokens":34}}先看这个响应里没有什么：没有一段散文，没有"我认为应该转给 billing，原因是支付失败通常归账务"。想要理由，得你自己从probabilities里读。这就是输出契约——选项空间由你定义，它在这个空间里选，并把"有多确定"一起交回来。
三个原语各答什么问题
| 原语 | 它答的问题 | 必填入参 | 返回字段 | 空间约束 | confidence | 典型用途 |
|---|---|---|---|---|---|---|
noul | 是不是：是非题 | instructions | noul（0 = 否，1 = 是的概率） | 只有真/假两面 | 没有 | 是否欺诈、是否可退款、是否需要人工 |
choice | 选哪个：从你给的集合里挑一个 | instructions+criteria | choice+ 全量probabilities（和为 1） | 每个 Choice 最多255个选项 | 有 | 工单路由、意图分类、分派团队 |
score | 打几分：按你给的有序等级 | instructions+ 等级定义 | score+legend+probabilities | 至少2个、最多10个等级 | 有 | 风险分级、内容质量打分、优先级排序 |
三条容易漏的细节：
instructions可以是字符串、对象或数组。用对象时可以一个字段放问题、其他字段放数据，然后在问题里用反引号按名字引用那些字段。choice的criteria是"选项 → 判据描述"的 map，某个选项可以给 null——不给判据，让它自己按选项名理解。score返回的score是跨等级的概率加权值，可以落在两级之间。这恰好是"概率可用"的副产品：0.62 和 0.68 的差是有意义的，而不是硬塞给你一个整数档位。
Q1：为什么 noul 没有 confidence？
因为它返回的本来就是一个连续概率（0~1），没有"分布形状"可算。置信度是从多选项分布的集中程度推出来的量，所以只出现在 Choice 和 Score 的回答上。
Q2：一次问很多问题，答案会互相污染吗？
官方 Models 页把这条性质写成了原文：“Jev ingests the state once and evaluates every question against it in parallel”——state 只吞进去一次，所有问题对着它并行评估；而且每个问题独立评分，不会因为你换了批处理策略就得到不同答案。官方并行问答 cookbook 用 5 次重复做过验证，多数答案的标准差是 0.0。
┌--> 问题A (noul) ─┐ state 只吞进去一次 ─┼--> 问题B (choice) ─┼--> 按 key 对齐，回一个 answers ├--> 问题C (score) ─┤ └--> 问题D (noul) ─┘这个性质在工程上比看起来重要：它意味着"把 13 个问题打包成一个请求"和"发 13 个请求"拿到的是同一批答案，你纯粹是在成本和延迟上做选择，不用担心批处理改变了判断本身。
Q3：问题的 key 会被模型读到吗？
不会。key 由调用方自定，回答按同一个 key 返回；key 本身不送进模型、不参与推理。它是给你自己代码用的对齐键，叫q1还是叫shouldRefund都不影响判断结果。
Q4：出错的时候长什么样？
错误码四档：401（缺 key 或 key 错）、422（请求体校验失败）、429（超速率）、529（服务过载）。SDK 默认做指数退避重试，并遵守retry-after。
4. "概率可用"才是它真正的卖点
这一章回答：那些数字凭什么值得信，以及能信到什么程度。
这一块才是它和普通 LLM 最本质的差距。说白了：普通 LLM 也能在你的 JSON 里输出一个 0.88，但你不知道那个 0.88 是什么意思。
先看三条后训练路线的概念差别（这里只讲定位，不涉及数字）：
| 路线 | 奖励信号来自哪 | 优化目标 | 产出更像什么 | 和 Jev 的关系 |
|---|---|---|---|---|
| RLHF | 人类偏好标注与排序 | “读起来让人满意” | 更讨人喜欢的文本 | TypeSafe 联合创始人 Diogo Almeida 参与过它的共同发明（官方口径），Jev 没沿这条路走 |
| RLVR | 可自动验证的结果（数学答案对不对、代码跑不跑得过） | 有标准答案任务上的正确率 | 更强的推理与解题 | 和"输出概率的可信度"不是一回事 |
| RLCD | 官方全名Reinforcement Learning for Calibrated Decisions，官方博客与 primer 页都点名了这条路线 | 概率分布本身可不可信 | 校准过的决定与概率，而不是文本 | Jev 走的就是这条：primer 原话是"训练 TypeSafe 返回决定与校准概率，而不是生成文本" |
校准（calibration）到底承诺了什么。官方 concepts 页的原话要点是：答案是校准的，概率是拿结果反复校准出来的；但校准是跨一批预测统计出来的性质，不保证单次答案正确。
这句话对着代码写的人，有个非常具体的后果：
0.88 ≠ 这一次有 88% 的可能对 0.88 ≈ 长期看，落在 0.88 附近的那一整批预测里，大约 88% 最终是对的所以正确用法是把它当统计量、当路由信号，而不是当保证。任何"单次调用绝对可信"的写法，都是在要求一个官方明确没给的东西。
置信度算的是分布的形状
官方 confidence.md：confidence是从概率分布形状算出来的统计量（0~1），只出现在 Choice 和 Score 的回答上，分布越集中置信度越高。页面 demo 给的三选项近似式是(3 × 最大概率 − 1) / 2，一般式是(n × maxP − 1) / (n − 1)。
拿第 3 章那个响应手算一下：(3 × 0.88 − 1) / 2 = 0.82，而官方示例写的是0.81。这 0.01 的差是示例数值取近似导致的（我把它记进文末待核实），不影响怎么用。
值得注意的是：choice选的是 billing，但如果三个选项是 0.34 / 0.33 / 0.33，choice照样会给你一个答案，只是confidence极低。这就是为什么只看choice不看confidence的代码，比不看概率的 LLM 代码更危险——它给你一个看起来很确定的字段名。
三档用法，以及为什么阈值不是一个数
官方立场很明确：“I don’t know” 是有用的信号，比硬猜一个选项对你更有价值。建议的用法是把置信度切三档：
| 置信度档位 | 系统行为 | 典型场景 | 为什么要这么分 | 落地形式 |
|---|---|---|---|---|
| 高 | 自动执行 | 工单路由、批量打分、检索重排 | 错了影响面小、可批量回滚 | 代码里一个上界阈值 |
| 中 | 谨慎执行 / 请求人工确认 | 有副作用但可撤销的操作 | 需要人补一次判断 | 双阈值 + 一条待确认队列 |
| 低 | 不执行，转人工或换系统 | 破坏性操作、无法回滚的写 | 宁可不做，也不要错做 | 兜底分支，永远要写 |
但阈值不是一个数。官方特别强调：同一个系统里，只读操作和破坏性操作的门槛应该不同，风险容忍度是由你的代码来编码的。给的建议是保守起步，用自己的数据测过之后再往下调。
这一章其实正好回答了它解决的痛点：LLM 应用最难维护的从来不是"能不能跑通"，而是**“这一步走错了谁负责”**。有了概率，你在代码里写的是一条可回归、可测的阈值，而不是一句可争议的提示词。
5. 价格、延迟，和三种"它不是"
这一章回答：钱花在哪、快在哪，以及流传说法里必须修正的部分。
官方口径（models.md，针对 jev-1.13）
| 项 | 官方数值 | 对你的代码意味着什么 | 容易搞混的点 |
|---|---|---|---|
| 价格 | $42/Btok = $0.042/Mtok，只按输入 token 计费，输出 token 免费 | 成本模型里只盯 state + 问题的长度 | 免费的是输出 token，不是"调用免费" |
| 速率限制 | 250,000 tokens/秒、1,200 requests/分钟 | 两个维度独立限流，都要算 | 只按 QPS 规划会先撞上 token 上限 |
| 上下文 | 每请求64k（state + 全部问题合计）；另有32k（state + 最长的那一个问题） | 是两个约束，不是一个 | 只按 64k 设计，可能被 32k 那条卡住 |
| 输入类型 | 仅文本：字符串 / JSON 对象 / 文本数组；不支持图片、音频、视频 | 多模态需求直接排除 | 图片得先被别的模型转成文字才进得来 |
| 语言 | 英语是主要训练语言、准确率最好；含 CJK 在内的其他语言能用但不等价，官方要求上非英语负载前先用自家数据测 | 中文场景没有"开箱即同等"这回事 | 官方文档的示例全英文，别按英文效果预估中文 |
| 能不能微调 | 不对客户数据做 fine-tune 或 LoRA，所有账户用同一份权重；只能通过 state / instructions / criteria 塑形行为 | 想"调"它只能在提示结构上调 | 它不是你的私有模型，是一份公共权重 |
| 数据 | 不用客户请求与响应训练模型；企业客户有 ZDR（零数据保留） | 合规评估可以直接引这两条 | ZDR 是企业客户口径 |
还有一句要紧的：官方自己警告，当前需求量极大，上述限额可能随时变化。这组数字要定期回去核，别当成稳定合同。
为什么"输出免费"是这个模式的结果
不是促销，是架构后果：
生成式调用：输入 --> 逐个 token 生成不定长文本 --> 输出长度不可控、内容不可枚举 --> 只能按输出计费 Jev 调用： 输入 --> 在你划定的选项空间里评分 --> 输出形状由你定义、长度可控 --> 输出免费输出侧不做"写文案"这件事，成本主要压在把 state 和问题读进来的那一次前向。所以省不省钱不取决于它单价低，取决于你的负载形状：一次投进一大段 state、同时拿回好几个决定，摊薄就成立（官方并行问答 cookbook 的批量收益就是这条的证据）；反过来每次都塞一份完整上下文却只要一个布尔值，那省不下什么。
官方口径 vs 第三方实测
| 指标 | 官方口径 | 第三方实测/解读 | 这个差距该怎么读 |
|---|---|---|---|
| 响应耗时 | 官方发布文原文：“End-to-end response time is 70ms-500ms”，并称同等前沿智能水平下快40x~200x、总述为"两个数量级" | verysmallwoods 端到端350ms ~ 1s；AIJasonZ 那期视频称"实测比目前便宜的 LLM 快 5 到 7 倍，价格低 5 倍左右" | 注意官方那句自己也说的是端到端，只是限定在 “System One shaped queries” 且没点名对照组模型；第三方含自家业务链路。倍率别写进 SLA |
| 批量收益 | cookbook（约54,000字符的 GDPR 维基长文 +13个问题：8 个 noul / 2 个 choice / 3 个 score）：一次批量 vs 一问一请求，12.2x 更便宜、10.0x 更快，答案不变 | — | 官方实验但条件写得全，可以当设计依据，不能当承诺；而且那个10.0x 是把 13 次单题请求耗时串行加总得到的（官方自己标注），你原本就并发的话时延差距会缩小 |
| 检索重排 | cookbook（CLERC 法律数据集3,565段法院意见文本，BM25 先取30条候选，覆盖40个查询）：重排后top-1 从 5% 提到 18%，top-10 从 38% 提到 62% | — | 数据集特定结论，换到你的语料必须重测 |
| 类型安全 | 官方原句：“The model never makes type errors.”（所有答案都带校准概率与置信度） | TrueFoundry：能防的是格式错误的输出，防不了选错 | 见下面"零幻觉"那节 |
说明一句：以上数字全部来自官方页面或别人的实测，本文没有自行调用 API、没有计时。
三种"它不是"
| “它不是” | 具体边界 | 典型误用长什么样 | 这个需求该怎么满足 |
|---|---|---|---|
| 不是聊天 / 补全模型 | 不写回复、不产代码、不解释推理；第三方快讯（TradingView/PAnews）也直接说它不具备文本生成能力 | 拿它做工单摘要、客服首答 | 生成侧仍用 LLM，让 Jev 只负责决定 |
| 不是微调 | 全租户同一份权重，不 fine-tune 不 LoRA；行为只能靠 state / instructions / criteria 塑形 | 想"喂一批历史工单让它学会我的业务" | 把领域规则写进criteria的判据描述，把上下文写进state |
| 不是多模态 | 输入只有文本（字符串 / JSON 对象 / 文本数组），图片音频视频都不支持 | 想让它读截图、读票据照片 | 先由别的模型转成文字描述，再进 state |
第三方解读在能力边界上的共识比较一致（Firecrawl、Flowtivity 都提到）：强项是大批量分类、打分、路由、排序；做不了文本生成、多步推理、视觉输入，复杂逻辑上可能"自信地答错"。verysmallwoods 那句"适合分类路由，不适合需要解释的场景"，我觉得是这一篇里最实用的一句判断。
"零幻觉"这个说法该怎么改
先纠正一个容易传歪的点：这句话是官方自己说的。发布文原文是 “While Jev gives up string generation, it’s optimized for structured outputs andcan’t hallucinate”，DataCamp、Firecrawl 那些标题只是照抄。
真正要区分的是官方内部的两处口径：发布文用 “can’t hallucinate”，文档里对同一件事用的是calibrated（校准），并且明确写了校准是跨一批预测统计出来的性质、不保证单次答案正确。所以引用时最好连官方那句英文一起带上，别再自己加码成"它不会出错"。
准确的表述要拆成两层：
| 层次 | 成立吗 | 为什么 | 常见误写 |
|---|---|---|---|
| 形状与取值不会越界 | 成立 | 选项空间、等级、字段全由你定义，所以不会出现"编出一个不存在的选项""返回不合法 JSON"这类失败 | “它不会出错” |
| 内容不会选错 | 不成立 | 它只是不会跳出你划定的选项，在选项里面照样可能选错 | “它的判断可以无条件采信” |
一句话替掉"零幻觉"：它把幻觉的可能，从"任意文本"压缩到了"合法的选项集合之内"。压缩掉的那一半确实很有价值——你的解析代码不用再兜意外结构；剩下那一半，靠概率和置信度阈值来兜。
另外，官方还专门列了自己的已知失败模式（model-jaggedness/jev-1.13 页），这里只提一次不展开，第三篇专门写它。
最后总结
这一章回答：如果只记住三件事，记哪三件。
- Jev 是决策模型，不是聊天模型。它由 TypeSafe 提供、是第一个 System One 模型；你换不掉编码 agent 背后那个模型，你写的是调用它的代码。
- 差别在输出契约，不在聪明程度。输入 state + 类型化问题，输出带类型的决定 + 概率 + 置信度；不写文案、不写代码、不解释推理。三个原语
noul/choice/score覆盖"是不是 / 选哪个 / 打几分"，state 只吞一次、问题并行且独立评分。 - 概率可用才是卖点，但它只在群体意义上可用。校准是跨一批预测统计出来的，单次仍然会错；所以风险容忍度必须由你的代码写成分档阈值，而不是塞进提示词里祈祷。
痛点、痒点、爽点分开看更实在：
| 层面 | 它戳中的是哪一下 | 靠哪个机制 | 前提与代价 |
|---|---|---|---|
| 痛点 | LLM 输出进不了生产的关键分支：不可断言、不可回归、出错没人担责 | 类型化输出 + 概率 + 置信度分档 | 你得先把选项空间和阈值定义清楚 |
| 痒点 | 想少写一堆解析兜底代码，又怕丢掉灵活性 | 输出 token 免费、一请求多问题、key 自定 | 灵活性确实换掉了：它不给你解释 |
| 爽点 | 批量分类 / 路由 / 排序的耗时和成本一起下来 | state 吞一次、问题并行独立评分（批量 12.2x 便宜 / 10.0x 快，官方 cookbook 口径） | 英语为主，中文负载要自己测；10.0x 的前提是单题请求原本串行发 |
最后一句：把它当成"一个带概率的枚举函数"来用，这篇就没白读。
参考资料 & 致谢
[1] Introducing System One Models & Jev-官方博客
[2] System One 概念-官方文档
[3] 三种原语 noul / choice / score-官方文档
[4] Confidence 置信度-官方文档
[5] Models、价格与限额-官方文档
[6] API reference-官方文档
[7] Parallel questions 并行问答 cookbook-官方文档
[8] Re-ranking 重排 cookbook-官方文档
[9] Jev 1.13 已知失败模式-官方文档
[10] Jev 实战：接进 3 个生产流程，反欺诈、找客户、筛爆款，一天只花 1 美元-B 站视频 AIJasonZ
[11] 全网刷屏的 Jev 模型正式开放！保姆级教程 + 实战测评-B 站视频 程序员鱼皮
[12] 【Jev实测】Jev是什么？怎么用？二十分钟彻底给你讲清楚它的底层原理-B 站视频
