企业官网建设流程全解析

💡前两篇把输出契约和并行评分讲完之后，留在桌面上的问题其实只有一个："我这个场景能不能用。"评审会上被追问的则更硬：跟现在的分类器比它新在哪？官方有没有一句话说明它不行在哪？

我翻了官方文档，翻到一页标题叫 “Jev 1.13 jaggedness” 的东西。里面是九条失败模式，每条都配了官方自己给的替代做法，页首写着 “Jev isn’t perfect”，末尾写着 “Many of these will be fixed in later versions”，Note 标着 “Applies tojev-1.13. Last reviewed 2026-09-17.”。

这就带来一个很难受的实际问题：如果我只引用官方博客里那些数字，我就是在替厂商做营销；如果我把官方承认的缺陷包装成"其实也是优点"，我就是在替读者做错误决策。而这两者在技术博客里都常见。

比较麻烦的是这两页的口径并不一致：发布文说 “can’t hallucinate”，缺陷清单页却说注入类文本能移动答案。所以真正要做的不是挑一边信，而是把"哪句话出自哪一页"分开记。

这第三篇我不想再讲它多好用，而是把官方自己写下来的那些不行一条条摊开：它不能干什么、边界卡在哪、同样的需求还有什么别的解法，以及"新范式"这三个字我该不该写进你的架构评审 PPT。

1. 先给结论：它强在哪、弱在哪、哪几类需求根本不该找它

这章回答：我的需求清单里，哪些可以交给它，哪些从一开始就不该找它。

先给一句最省事的判断：它是一个只会回答"选哪个 / 是不是 / 打几分"的模型，不会算、不会写、也不会解释为什么。

官方在 jaggedness 页对jev-1.13的总述是两面一起写的：它快、校准、擅长常识判断；同时在需要额外几层间接推理的任务上会吃力、理解上可能相当字面、在需要数值精度的任务上表现差。下面这张表是我把官方口径（jaggedness 页 + models 页 + confidence 页）和第三方解读放在一起之后的汇总，"我给它的位置"一列是我的判断，不是官方结论。

一句话把"根本不该找它"的需求先划掉三类：任何生成（文案、代码、摘要）、数值与日期算术、需要模型给出理由给审计看的场景。这三类不是我推测的，前两类是官方原文明确写的，第三类来自官方 concepts/system-one 页——System One 模型不产推理说明。

正则/代码（能精确算出来的） --> Jev（带概率的判断题） --> LLM（要文本要解释的） --> 人（不可逆动作）

Q1：类型安全是不是就等于不会选错？

不等于。这一点第三方解读的口径比我诚实，直接引用：firecrawl 说它是"只做决定"的模型，类型安全但仍可能选错，而且不能直接生成代码；truefoundry 的说法更准——它**“防的是格式错误的输出”，不等于防错**；beam.ai 认为它是靠"只能从你给的选项里选"来防幻觉，适合路由、分类、工具校验，生成类任务要留给 LLM；flowtivity 补充了一句我觉得最该贴在评审文档首页的话：它在复杂逻辑上可能**“自信地答错”**。

说白了，类型安全解决的是json.loads那一层的问题，它让你的代码永远不会因为解析失败而挂掉；判断对不对，是另一件事，而且官方那九条就是专门讲这件事的。

Q2：官方延迟和第三方实测为什么对不上？

先把官方原文钉准，因为它比流传的说法更具体：发布文写的是“End-to-end response time is 70ms-500ms”，并且补了一句"在 System One 形状的查询上、同等前沿智能水平下，快 40x~200x"。中文博客 verysmallwoods 的实测口径是端到端 350ms~1s。

所以两边的差距不是"模型侧 vs 端到端"——官方自己也说的是端到端。真正的差在三处：官方没点名对照组是哪个模型、什么部署；40x~200x 这个区间被限定在 “System One shaped queries”，也就是它擅长的题型；第三方那侧还包含自家网络与前后处理。至于"两个数量级"（官方原文 “two orders of magnitude faster and more efficient”），它是个总述而不是某次测量，我没能核实它的基准，所以不写进结论（文末待核实也记了一条）。

类型安全那条同理，官方原句是“The model never makes type errors.”，比转述的 “zero type errors” 更该被引用——它说的是不会越出你定义的类型，不是不会判断错。另外 tradingview 转载的快讯口径比较干净：TypeSafe 推出结构化决策模型 Jev，不具备文本生成能力——这条至少没有歧义。

2. 官方自己写了九种失败模式：逐条拆开看

这章回答：九条失败模式分别是什么现象、什么根因、官方自己建议怎么绕。

先把这页的性质说清楚：它不是 FAQ，是一页会过期的缺陷清单，页面自身标注 Last reviewed 2026-09-17、适用于jev-1.13，并写着 “Many of these will be fixed in later versions”。下面每一格的措辞我改写过，事实都按官方原文。

2.1 字面理解：错答案往往是你的锅

官方那句我觉得可以裱起来，原文是“When you look at a wrong answer and find yourself explaining what you really meant, that explanation is the missing half of the instruction.”（我译过来：当你看着一个错答案、开始解释你其实想表达什么时，那段解释就是缺失的那半句指令。）这条的工程含义是：Jev 不给你"模型替我脑补了一半"的红利，所以instructions和criteria要当需求文档写，而不是当注释写。你写"高风险订单"，它按字面读"高风险订单"；你心里那个"金额超 5k 且收货地址改过 且 30 天内有过退款"的定义，不写进去就不存在。

2.2 数学与数字：官方连反问都写好了

计数部分官方写得很直白：jev-1.13计数不可靠，单词字母数、词频、长列表条目数都会错，而且误差随被数对象变大而变大；官方还反问了一句"计数为什么要用模型"，能用正则或解析器找的单位就该在代码里数。官方给的改写样例就是这个思路——遍历候选、每个问一次 Noul、求和交给代码：

# 摘自官方 jaggedness 页的改写样例（阈值与列表是官方原例，非我实测）fromtypesafe_sdkimportNoul,TypeSafeClient client=TypeSafeClient(model="jev-1.13")YES=0.5# up to you on what you want the threshold to be, depends on your usecase.items=["typesafe","apple","california","banana","likes","calibration","orange","vertex"]result=client.system_one({"items":items},{f"item_{i}":Noul(instructions=f"Is `items[{i}]` the name of a fruit?")foriinrange(len(items))},)count=sum(result.nouls[f"item_{i}"].noul>YESforiinrange(len(items)))

数值表示这条更值得注意：用十六进制颜色问比用英文颜色名问表现差；给它 RGB 三元组或 hex，它无法可靠判断两个值是否接近；问高级编程语言比问汇编/二进制指令表现好。官方的替代做法是：换算在代码里做，喂给它算好的数或命名好的桶，模型只保留"这个颜色读起来像不像警告"这类真的需要判断的部分。

用 Score 做数学的那条我要单独提醒：不要用 score 的期望值或概率去插值还原两级之间的精确数值。可以用期望值判断"有没有过某个阈值"，但 score 等级的数值校准很弱。也就是说"0.62 分"这种数字不能当连续指标做报表。

2.3 日期时间：官方给了一条我可以直接抄的绕法

现象：格式混用、相对日期、季度/结算窗口/计提期这类领域边界，表现更差。官方的替代做法我认为是九条里最漂亮的一条——因为日期的每个部分都是小闭集（12 个月、31 天、有界年份），所以"抽取"这件事可以变成一个对枚举选项的 Choice，还能显式加一个"未说明"的选项，让缺失被报告而不是被猜；剩下组装成真日期、排序、时长、偏移、星期，全部交给代码。官方的 date extraction cookbook 给了完整写法，含相对日期与置信度门控。

原文 --> [Jev] Choice 抽 year / month / day（枚举 + "未说明"） --> [代码] 组装日期 --> 排序/时长/窗口判断

2.4 context rot 与对抗性内容：两条要连起来看

无关细节这条，官方是直接用词的：“Jev suffers from context rot, so unrelated material in the state costs you accuracy.”并且提示 state 有界，具体 token 上限去看 Models 页。

对抗性内容这条是我认为整个第三篇最该被工程化对待的一条：state 是数据，而jev-1.13默认不把它当敌意内容；为操纵模型而写的内容——注入的指令、故意误导的框架、为自身分类结果辩护的文本——能移动答案；官方写"我们期望未来在这点上改进"。

这里真正要注意的是它的分量：这等于官方公开承认 prompt injection 类攻击面存在，而且当前不是靠模型自身扛住的。所以只要 state 里包含用户输入、抓取内容或上游文档正文，你的自动放行决策就必须有模型之外的第二道筛（规则上限、金额阈值、人工队列）。别把"它是判别模型不是生成模型"当成天然抗注入——官方没这么说过，我也没看到任何依据。

2.5 结构不变量：官方给的两个数据很扎眼

jev-1.13极其一致（语义相近的输入会给定量相近的输出），但很多你以为会成立的结构性恒等式模型根本不保证。官方给了两组数字，我原样引用：

官方自己的说明是可比的只有noul与probabilities["yes"]，而"这两处该怎么解读都不显然"；P(noul)与1 − P(not noul)不可直接比较的原因有很多。官方结论有两条硬性：不要把在 Noul 上调好的阈值搬到 Choice 上，也不要要求模型在不同问题之间满足算术恒等式。

为什么 Noul 和 Choice 会不一样？官方的说法是：Choice 是相对的（在选项之间挑哪个），每条 Noul 是绝对的（可能全都低）。官方 skill suggestion cookbook 就在同一份候选集上同时用两者：Choice 决定选哪个技能，Noul 决定到底要不要推荐。这个"两种问法各管一段"的写法我觉得是这页缺陷清单里最值得学的一条。

2.6 生成：官方甚至带了句玩笑

jev-1.13没被训练来生成文本，靠串联 Choice 硬做生成"效果不好而且会非常慢"，原话是 “If you really need to generate text… there are other models for that.”。抽取类任务的正确顺序反过来：先用正则或生成模型列出候选，再让jev-1.13从候选里挑对的那个。

官方页尾还有一张 “avoid the following” 清单，我原样搬成正文小表：

2.7 这张清单本身的意义

我不想把"官方愿意公开一张会过期的缺陷清单"包装成产品优点——它不提升任何一次调用的准确率。但它的工程价值是实打实的：它给了你一个带日期的发布前检查点。Last reviewed 2026-09-17、适用于jev-1.13、“Many of these will be fixed in later versions”，这三句合起来的意思是：这份清单只在这个版本上成立，你上一版绕过去的坑可能已经填了，你没绕的坑可能还在。所以我的做法是把这九条直接抄成回归用例的标题，换版本时重跑一遍，而不是把它当"阅读过就算数"的文档。这条是我的判断，不是官方的承诺。

3. 三个更隐蔽的结构性短板：概率不等于置信、校准不保单次、阈值要自己养

这章回答：九条缺陷之外，还有三条不会写进缺陷清单、但直接决定你怎么写代码的东西。

3.1 confidence 只在 Choice 和 Score 上有，Noul 没有

官方 confidence 页的括号里写得很干脆：“Noul answers don’t carry one.”。后果很具体：

说白了，Noul 给你的那个数是一个概率，不是置信度；你若要门控，就得自己定一个线，而这条线官方不会给你（YES = 0.5那行注释写的就是 “up to you”）。这跟第 2.5 节是一回事的另一面：两种问法的数值语义不同，阈值不能互相搬。

3.2 校准是群体统计，它不保证你这一次

官方 AI primer 对校准的定义是跨一批预测统计成立的：被打上 0.2 的结果应该约 20% 发生，被打上 0.8 的应该约 80% 发生。官方同时明确写过：这不保证单个答案正确（concepts/system-one 页）。

还有一条官方说得挺坦白：confidence 只是"从分布形状算出的一个便捷统计量"，并且**“你并不被绑定在我们的定义上”**——全量probabilities都给你，不同用途可能有更合适的算法（官方把利弊分析推到另一篇 cookbook，而那篇尚未发布）。

我的读法：这句话把 confidence 从"官方指标"降级成了"默认工具"。如果你的门控目标是"漏放行一次的代价"，那更合适的统计量很可能不是它，而是某个选项的概率加上你自己的损失函数。flowtivity 说的"复杂逻辑上可能自信地答错"，跟这条完全不冲突——群体校准好的模型，单次当然可以坚定而错误。

3.3 阈值是你的，而且会随版本漂

官方的建议是三句话：保守起步、用自己的数据测、观察结果后再调；并且同一个系统里只读操作与破坏性操作应该设不同门槛。

第二条要单独盯：别名会漂。jev-latest/jev-preview指向的模型会随新版本变化，你这边一行代码没改，答案分布可能就变了。官方建议调过阈值就 pin 版本 ID，并靠响应里的model字段落日志。

现实证据我核对到一个，措辞克制地说：官方 Models 页当前写jev-1.13.0，而官方《Parallel questions》cookbook 的示例里 pin 的是jev-1.12——我核对时看到两处版本口径不一致。这里只陈述现象，我不推断哪个是对的，但这件事本身就是"把 model 字段落到日志里"的理由。

你真正要同时钉死的三样：模型版本 ID + 每类问法的阈值 + 该阈值测自哪份数据 少任何一样，下一次升级就是一次无人签字的行为变更

4. 平台层边界：只吃文本、预算固定、限额会变、数据得出域

这章回答：哪些不是"缺陷"、而是产品形态本身就决定了的硬约束。

这些全部来自官方 models.md（价格与限额一节含官方 Warning）。我加了"你要做的补偿"这一列，是我的判断。

关于"托管 API"这条，我把话说清楚，并且明确标注这是我的判断：官方文档解决了"你的数据不会被拿去训练"和"企业客户可以 ZDR"，但它没有替你解决数据出域。你的进程之外的每一次调用，都是一次跨网络的数据出境：字段的脱敏、境内存储、留痕合规，这几件事在架构上仍然是你的，不会因为"它只是判别模型"而自动消失。就我核对到的公开文档而言，Jev 也没有提供私有化/本地形态。如果你的红线是"原始文本不许出门"，那这条约束是硬否决项。

5. 同一件事的其他解法：什么时候不该选 Jev

这章回答：这些边界上的活儿，别的方案怎么干；以及"你有什么 → 该用什么"。

先声明：这一章不列对方的数字，也不做精度排名——我没有跑过对照实验，任何人拿一张"各家准确率对比表"给你看，你都应该问一句"在谁的数据上测的"。下面只讲适配关系。

有标注数据吗？--有--> 类别稳定吗？--稳定--> 自训分类器（权重归你） | --常变--> Jev（判据写在 prompt 里） --没有--> 能写规则吗？--能--> 规则/正则 --不能--> 只要相关性--> embedding/重排 --要文本要解释--> LLM+结构化输出 --要一个带概率的决定--> Jev（先在自己数据上测）

Q1：我已经有 BERT 分类器了，要不要换成 Jev？

我的口径是这样的：类别长期稳定、标注充足、当前精度够用、延迟与合规都在你手里——不换。反过来，如果你的类别每周都在改判据、标注永远凑不齐、或者你需要在一次请求里同时问十几个不同判断（第 6 章会讲这件事为什么是成本结构上的质变），那 Jev 值得测。这里真正的比较点不是精度，而是**"改一个判断"这件事的成本落在谁头上**：自训分类器落在数据和重训管道上，Jev 落在instructions/criteria的文案上。

Q2：能不能用它替掉 LLM 的结构化输出？

取决于你要不要文本本身。firecrawl、beam.ai、flowtivity、tradingview 转载快讯在这一点上口径一致：它做不了生成，不能直接产出代码或文案。所以常见形态是分工——它负责"选哪个 / 是不是 / 要不要执行"，LLM 负责把结论说给人听。如果你的 LLM 已经在做决定并且顺手生成文本，那换掉它的动力只可能是延迟与成本，不会是"更准"。

Q3：合规要求高的团队怎么用它？

把边界往前挪：出域前先脱敏、只把判定所需的字段送出去（这一步同时治 context rot 和成本）、不可逆动作一律加人工队列。这一条不是官方建议，是我给的做法。

6. 是不是新范式：把"新"和"不新"分别摊开

这章回答："新范式"这三个字我该不该写进评审 PPT，以及怎么诚实回答。

6.1 可以称为新的部分（都有官方依据）

6.2 不新的部分（这几条我标注为我的判断）

• "分类器输出概率"是几十年的老东西。XGBoost、BERT 的分类头都给概率，也都要做校准。Jev 与它们的真正差别不在"能不能输出概率"，而在要不要你自己有标注数据和训练管道。
• 规则仍然写在提示里。判据还是instructions/criteria，"prompt 当业务规则"那套成本一样都没省掉：不可 diff、不可单测、改一处影响面未知、会随版本漂。第 2.1 那条字面理解恰恰是这套成本的直接体现。
• “System One” 是借名，不是理论贡献。官方自己也只说取"快而聚焦的判断"这层意思，出处是 Kahneman 的术语包装。
• RLCD 我没能核实。官方 AI primer 给了它的定义和与 RLHF / RLVR 的三条路线对比，但它与既有 RL 文献的关系我没有独立核实，所以我不断言它是不是某篇论文方法的重命名（已写进文末待核实）。

6.3 营销口径与第三方口径的对照

我的诚实回答是这样：交付形态上算新，模型能力上是渐进改良。真正新的那一件事是"决策从解析文本变成采样一个带概率的决定"，连带把计费结构也改了（只按输入收费和"输出是固定形状"其实是同一件事的两面，这句是我的判断）。而"它更聪明"这种说法，被官方自己那页缺陷清单当场反驳了。如果非要写进 PPT，我建议只用"新范式"描述输出契约 + 定价结构这两件事，别用它描述智能水平。

7. 我给的采纳建议：三档清单与上线前检查

这章回答：如果明天要开评审会，我手上该有哪三张单子。

第一档：现在就能上（低风险、高吞吐、错了可回收）

• 工单 / 评论 / 内容的分类与打标
• 内容打分与分级（离散等级，不是连续数值指标）
• 候选集重排（每个候选一条问题）
• 输入侧与输出侧护栏的第一道筛
• 意图路由

第二档：先在自己数据上测，再决定

第三档：现在别指望它

任何生成（文案、代码、摘要）、数值与日期算术、需要多层间接推理的"System Two"任务、需要模型给出理由给审计看的场景、多模态输入。这五条前四条是官方原文直接支持的，第五条来自 models 页的输入模态限制。

上线前检查清单（我自己归纳的，条目要能当 checklist 打勾）

上面那份清单里，有三条是我自己的红线——这三块我现在不会让它上生产：参与资金动作的数值与日期判断（算术交给它，等于把不可靠的东西放进不可逆路径）、直面不可信输入又没有第二道筛的自动放行（官方自己说注入能移动答案）、要给监管或审计看的决策理由（它不产解释，任何理由文本都是你自己编的）。

{"note":"字段形状示例，数值借用了官方文档示例，不是一次真实调用记录","decision_id":"ticket-20260927-0812","model":"jev-1.13.0","asked_at":"2026-09-27T10:12:04Z","state_keys_sent":["ticket_text","plan","region"],"questions":{"refund_intent":{"kind":"noul","instructions":"客户是否在要求退款","noul":0.22},"route":{"kind":"choice","options":["refund","restate","human"],"probabilities":{"refund":0.01,"restate":0.99,"human":0.0},"confidence":0.97}},"threshold_applied":{"refund_intent":0.5,"route":0.8},"action_taken":"restate","human_fallback_used":false}

最后总结

• 它的边界官方已经写明白了，不用猜。九种失败模式（字面理解、数学与数字、日期时间比较、间接层、大 state 塞无关细节、对抗性内容、指令与判据矛盾、结构不变量不成立、生成），每条都配了替代做法。我的建议是把这些直接抄成你 CI 里的回归用例标题。
• 三条结构性短板比九条缺陷更能决定代码怎么写：Noul 不带 confidence、校准只是群体统计不保证单次、阈值归你且随版本重测。这三条叠在一起的含义是：门控逻辑的 ownership 在你手上，官方不会替你兜。
• 平台层有四条硬线：只吃文本、64k/32k 预算、限额可能无通知调整、不做 per-tenant 微调。加上一条我自己判断的：它是托管 API，数据出域这件事文档没替你解决。
• 什么时候别选它：有充足标注且类别稳定 → 自训分类器（权重和离线部署归你）；纯语义排序 → embedding / cross-encoder；要文本要解释 → LLM + 结构化输出；数据不许出门 → 本地小模型；能写规则 → 规则和正则。
• 是不是新范式：交付形态新（输出契约、并行独立评分、只按输入计费的定价结构、概率与阈值成一等公民、官方公开带日期的缺陷清单），能力上不新（分类器输出概率是老东西、规则仍写在提示里、“System One” 是借名）。我不会把"新范式"用在"它更聪明"这个意思上。
• 给后端/架构的一句话：把 Jev 当一台只会做判断题、且明确告诉你它哪些题会做错的推理服务用；它的价值不在于替你负责，而在于让"要不要执行"这件事第一次变成代码里可读、可测、可门控的一个数。

参考资料 & 致谢

[1] Jev 1.13 jaggedness-官方文档
[2] Models、价格与限额-官方文档
[3] Confidence-官方文档
[4] System One 概念-官方文档
[5] AI primer：RLHF / RLVR / RLCD-官方文档
[6] Skill suggestion cookbook（Choice 与 Noul 同场使用）-官方 cookbook
[7] Date extraction cookbook-官方 cookbook
[8] Introducing System One models and Jev-官方博客
[9] What Is Jev-Firecrawl 第三方解读