Jev:当 AI 不再忙着说话,而开始成为软件里的判断力

从“系统一模型”的工作原理，到企业流程与多 Agent 协作的应用探索

*资料截至 2026 年 9 月 22 日。文中性能数据来自厂商披露及外部研究，未作独立复现；应用方案属于基于现有能力的设计推演，不代表已验证的落地效果。*

假设一家企业收到供应商发来的消息：

“由于原材料供应出现问题，下周的交付可能需要调整。我们正在协调替代方案，新增的运输费用希望双方另行商议。”

人读完后，很快就能意识到：这不只是普通的进度汇报，还涉及交付变化和新增费用，需要有人进一步处理。但要让软件理解这段话，就没有那么简单了。

按照关键词写规则，“延期”“索赔”“费用”等词语未必出现，出现了也不一定代表同一种意思。调用通用大模型，当然可以让它分析这段话，甚至写出一份处理建议；可是，对于流程系统来说，它此刻可能根本不需要一篇分析，只需要几个结果：消息涉及什么问题，应该转给谁，是否需要进一步复核。

Jev 所瞄准的，正是这种“人看起来不难，传统规则却不容易表达”的判断。

2026 年 9 月 15 日，TypeSafe AI 发布 Jev，并将其归入自己提出的“System One Models”，即“系统一模型”。它没有把聊天、写作或编程作为主要输出目标，而是直接返回软件能够使用的选择、评分和概率。 1

理解 Jev，最值得讨论的问题不是“它能不能取代某个聊天模型”，而是：当 AI 的主要使用者从人变成软件，我们应该怎样重新设计模型，以及围绕模型组织工作？

一、先把 Jev 放对位置：它不是聊天助手，而是判断组件

“系统一”这个名字，借用了《思考，快与慢》中快速、直觉式判断的概念。TypeSafe 用它强调的，是在明确情境下迅速作出范围有限的判断，而不是长时间展开推理。这里应当把它理解为产品与技术路线的命名，不能据此认为它已经实现了人类直觉的全部机制。 2

可以把 Jev 想象成软件系统中的一名分诊员。它不负责解决所有问题，而是阅读当前材料，回答几个预先定义的问题，再让后续流程接手。

它目前提供三种主要能力：

Choice 和 Score 会返回选项或等级上的概率分布，以及一个概括分布集中程度的 confidence 值；Noul 返回“是”的概率，不另带同样的 confidence 字段。三者可以放在同一次请求中。 3

不过，只有“问题”还不够。Jev 的另一个核心输入叫作 state，可以理解成“这次判断需要看的材料和背景”。

例如，要判断一封供应商邮件应该交给谁，背景可能包括邮件正文、相关订单、当前交付状态和部门职责。Jev 不会天然知道这些内部信息，需要由应用程序把相关内容准备好，再与问题一起提交。每次请求中的多个问题，都针对同一份 state 分别作答。 4

这意味着，搭建 Jev 应用的关键，并不是写一句“请帮我智能处理”，而是把业务拆成明确的问题：需要判断什么，依据什么判断，允许返回哪些结果，以及结果将被怎样使用。

二、它为什么可能更快：减少的不是知识，而是回答的自由度

谈到 Jev，人们很容易产生一个疑问：让普通大模型输出 JSON，不也能实现分类和评分吗？

确实如此。结构化输出并不是 Jev 的发明。OpenAI 在 2024 年就已推出能够约束输出符合指定 JSON Schema 的 Structured Outputs。因此，不能把两者的区别简单描述成“普通大模型会乱写，Jev 才能输出规范格式”。 5

更值得注意的区别，在于结果是怎样产生的。

对于典型的自回归语言模型，即使要求它只输出一个结构化结果，它仍然沿着生成序列的路径工作。Jev 的官方设计则放弃了自由文本生成，直接产生受约束的概率结果，并强调多个输出的并行计算。它不是先写一段解释，再从解释里提取答案。 6

可以用一个比喻理解这种差别。

我们原本请来一位表达能力很强的专家，让他读材料、组织语言、写下判断，最后由程序读取他填好的表格。Jev 的思路更像是：这次不需要写报告，直接对表格中已经定义好的问题作出判断即可。

当然，API 最后仍然可能用 JSON 传输结果。“不生成字符串”并不是说网络通信中不存在文字，而是说它不是依靠自由文本生成来构造那些判断结果。

这种限制带来的另一个优势，是同一份材料可以同时回答多个小问题。官方文档建议，把适合并行的判断合并到一次请求中，而不是每问一个问题就重复发送同一份材料。新增问题通常对响应时间影响较小，但问题本身仍会增加输入 token 和费用。 7

但这并不意味着任何任务都能“一次完成”。

如果后一个判断必须依赖前一个判断所获取的新材料，就仍然需要分阶段执行。例如，先识别涉及哪个项目，再去系统中查询该项目的合同，之后才能判断某封通知与合同约定是否相关。并行处理适合的是共同背景下的多个独立问题，不是跳过真实存在的信息依赖。

这里还要保留一条研究边界：我查阅的公开材料足以解释 Jev 的接口、输出方式和训练目标，但不足以独立复现其完整内部实现。 因此，不能把某种猜测出来的网络结构、参数规模或训练配方当成已经证实的原理。理解它目前能够做什么，与解释它全部内部机制，是两件不同的事。

三、比速度更重要的，是它返回的概率能不能被相信

TypeSafe 将自己的训练方法称为 RLCD：Reinforcement Learning for Calibrated Decisions，可译作“面向校准决策的强化学习”。

按照官方说明，它希望优化的不只是“选中正确答案”，还包括让输出概率能够合理反映不确定性。这与强调人类偏好或可验证任务奖励的训练目标有所区别，但不宜把这些路线理解成完全互斥的技术类别。 8

“校准”听起来很专业，其实可以用一个简单例子说明。

假设一个模型对一百条判断都给出大约 80% 的概率，那么，在足够具有代表性的同类样本上，其中相应结果实际成立的比例，也应该接近 80%。如果它总是报出 99%，实际却只有七成左右正确，那么它或许仍有一定判断能力，但表达出来的把握程度不可信。

校准讨论的是一组预测与实际结果之间的对应关系，不是给某一次判断发放“正确证书”。神经网络的概率校准问题也早已是研究主题，并不是模型开始原生输出概率后才出现的问题。 9

对软件而言，这种区别非常实际。

一个模型只回答“这条信息属于交付问题”，程序很难知道应不应该直接分流。它若同时提供合理的不确定性信号，系统就有机会区分相对明确的任务和需要补充材料的任务，让不同情况进入不同流程。

不过，使用 Jev 时还必须区分三个容易混淆的概念。

首先，选项概率不等于业务事件发生的概率。 如果问题是“这段文字是否提出新增费用要求”，返回值对应的是这个文本判断，而不是“企业未来会多支付这笔费用的概率”。问题定义不同，数字的含义就不同。

其次，confidence 不等于模型给自己评出的正确率。 Jev 的 Choice 和 Score 中，这个值是根据返回概率分布计算的统计量，表达的是结果有多集中。一个很集中的分布，仍然可能集中在错误答案上。官方文档也明确要求根据实际业务数据确定使用门槛。 10

最后，分数高，不代表把握大。 Score 的分数是等级位置的概率加权平均。一项问题可以被评为“严重程度较高”，同时模型对这一评定并不确定；也可以被非常确定地评为“严重程度较低”。严重程度和判断把握，是两条不同的轴。 11

由此看，RLCD 最有价值的目标不是让模型显得更加肯定，而是让软件有机会把“不确定”纳入工作流程。至于这个目标在某项业务上实现得如何，最终仍然要由验证数据回答。

四、它到底新在哪里：不是发明分类，而是重新包装判断能力

把 Jev 说成“人工智能终于能够分类了”，显然不准确。

早在这一轮聊天模型热潮之前，语言理解模型就已经广泛围绕分类、匹配和信息抽取展开研究。BERT 的原始论文就展示了预训练模型通过增加输出层，适配多种语言理解任务的路线。 12

Jev 值得关注的，是它试图把这类能力做成一种更通用的软件接口：用户用自然语言描述问题和判断标准，模型在约束好的结果空间中输出概率，再由程序组织后续行为。目前官方文档说明，不同客户使用相同模型权重，业务适配主要通过输入材料、问题说明和判断标准实现，而不是为每个账户单独微调。 13

因此，它更像是在尝试填补一个位置：

一边是精确但不擅长理解开放文本的普通代码；另一边是灵活、表达能力强，但未必适合承担每一个细小判断的通用生成模型。Jev 希望成为两者之间的语义判断组件。

这并不意味着它天然优于已有分类器。对于类别固定、已有充足标注数据、需要本地部署的任务，专门训练的分类模型仍然值得比较；对于必须展开多步推理、形成完整论证的任务，通用推理模型也可能更适合。评价 Jev，应当看具体任务上的质量、延迟、成本和部署条件，而不是仅凭一个新名称判断技术代际。

同样需要谨慎理解的是“零幻觉”。

TypeSafe 对这一宣传给出的明确保证，主要是输出能够匹配预先规定的结构。它不会在只允许 A、B、C 的地方自由生成一个 D。但这不能保证它不会把本该选择 A 的情况判成 B。输出合法，与判断正确，是两个层次。 14

还有第三个层次：行动是否适当。即便它正确识别了“用户要求退款”，也不等于系统已经具备退款依据、权限和完整条件。理解意图不是获得授权，模型判断不能代替程序控制。

五、公开证据告诉了我们什么，又没有告诉我们什么

Jev 的速度和价格确实具有吸引力。目前官方模型页列出的价格是每百万输入 token 0.042 美元，输出不收费。 15

作一个单纯的用量假设：每次完整请求——包括材料、问题和选项——共消耗 2,000 个输入 token，一百万次调用就是二十亿个输入 token，按上述单价计算约为 84 美元。但这只是模型调用费用，不包括文档处理、检索、存储、人工复核及错误处理成本。

至于显著的提速和降本倍数，必须回到测试方法看。官方工作流评估将任务拆成小问题，再用程序组合答案；参考结果来自其他大模型的回答，而不是全部由人工确认的业务真值。因此，这类评估说明的是特定工作流及参考标准下的表现，不能直接当成企业业务正确率。 16

外部测试提供了更多线索，也揭示了证据的边界。

LangChain 的 Agent 评估实验中，Jev 平均每次调用约 0.44 秒、成本约 0.00035 美元，重复评分的波动也较小。但实验只有五个固定的天气助手案例，每个案例重复评估一百次。它能帮助观察重复性，却不能被解释成覆盖了五百种不同业务情境。研究者也特别指出：稳定不等于正确，模型完全可能稳定地犯错。 17

一篇 9 月 21 日提交的交通事故文本研究预印本则进行了更大规模的应用探索：初筛约 50 万条叙述，对其中约 19.6 万条作进一步编码，并以 2,416 项可用人工判断评估结果。作者报告的综合 F1 为 0.908，但部分细分变量明显较弱；原始概率也存在校准问题，经过事后校准，汇总校准误差降至原来的约三分之一。这仍是早期研究，不能外推为中文企业材料上的效果。 18

还有一篇 6G 边缘服务编排预印本，把模型判断放进了真正包含后续执行的系统。在其真实图像服务实验中，Jev 的判断响应更快，但最终正确且按时完成的请求是 459 个，DeepSeek 为 463 个，两者分母都是 1,080。至少在这个设置中，局部判断更快，并没有自动转化为更多按时完成的任务。 19

这些结果共同支持一个更审慎、也更有工程意义的认识：Jev 已经显示出作为快速判断组件的潜力，但评价它的单位，不应只是一次模型调用，而应该是包含错误、复核和执行在内的完整流程。

六、应用探索：它适合出现在哪些不显眼、却重要的位置

下面的场景并不是对 Jev 现有效果的保证，而是从它的能力形态出发，探索值得验证的设计方向。

1. 文档处理：让模型选对内容，而不是重新写一遍内容

很多文档任务真正困难的地方，不是“找到一个数字”，而是“找到角色正确的那个数字”。

例如，一份材料中同时出现合同总额、累计付款、本期申请和保证金。程序可以先找出所有候选金额，但哪个是“本期申请支付金额”，还需要结合上下文判断。

TypeSafe 已经提供了这种组合方式的示例：先用规则发现候选值，再让 Jev 选择与问题对应的候选，最后由代码复制原文并规范格式。模型负责语义选择，程序负责保留原值。 20

这种思路很适合迁移到企业文档工具中。名称可以来自已有名录或实体识别模型，日期可以来自解析器，金额可以来自规则匹配。Jev 不必承担所有抽取工作，而是解决候选结果中的语义歧义。

它的价值是减少“重新生成事实”的环节，但并非没有风险：候选发现漏掉了正确内容，或者模型选错了候选，最终结果依然会错。因此，原文位置、候选列表和选择结果都应保留，重要字段不能因为“来自原文”就免于复核。

2. 知识库与研究助手：在“找到材料”和“相信材料”之间增加检查

知识库检索出来的材料，与能够支持答案的证据，并不是同一回事。

可以设想，在检索和答案生成之间增加一道检查：这段材料是否真正回答当前问题，是直接支持，还是只有主题相关性？如果材料不足，系统应该补充检索，而不是继续拼接答案。

TypeSafe 已提供对检索片段进行分类的示例，也提供了引用核验示例。后者先用普通字符串匹配检查引文是否真实存在，再用模型判断引文上下文是否支持对应主张。 21

这类设计的价值，不是再找一个 AI 来“凭感觉给答案打分”，而是把核验对象拆小：不是笼统问“这篇报告靠谱吗”，而是逐项检查具体主张与具体证据的关系。

当然，证据检查模型也会犯错。检索漏掉关键文件时，它不能凭空补齐证据；原始来源本身不可靠时，“忠实转述来源”也不等于事实正确。更合理的角色是筛查、提醒和分流，而不是充当最终真伪裁判。

3. 多 Agent 协作：减少小判断的开销，而不是再增加一个总指挥

多 Agent 工作流中，可以设计出许多范围较窄的判断：当前任务更适合哪个专业 Agent，是否需要调用某项工具，两个结果是否存在实质差异，是否需要启动额外复核。

这些位置可能比“让 Jev 全权调度所有 Agent”更值得尝试。

官方的 Skill 推荐示例就采用了分层设计：先从一个包含 182 个 Skill 的目录中筛选候选，再读取少数候选的详细信息进行复查，最终允许“不推荐任何一个”。它展示的是一种候选筛选与确认机制，而不是让模型无限制地决定下一步。 22

这个例子背后有个容易忽略的区别：“这些选项里哪个最好”，不等于“这些选项里存在适合的”。

一张只有工具 A、B、C 的选择题，可能迫使系统在三个都不合适的工具中选出一个。因此，流程应当显式容纳“均不适用”“信息不足”“需要人工判断”，必要时把“是否需要工具”和“需要哪个工具”拆开。

对于合同合议或研究复核，也应采取类似思路。两个 Agent 得出了相同结论，不代表已经形成可靠共识；它们可能引用了同一个错误来源。与其只比较结论是否一致，不如比较证据是否充分、适用前提是否相同、是否遗漏了关键例外。

4. 建筑施工企业：先识别履约信号，再交给规则与专业人员处理

回到开头的供应商消息。可以把应用目标设得很具体：从来往函件和过程记录中发现需要关注的履约信号，而不是自动认定责任或批准费用。

例如，系统先准备好当前文件、所属项目、相关合同条款和已有往来记录，再分别判断：文本是否明确表示交付安排可能变化，是否提出新增费用主张，是否要求对方确认，是否与此前记录存在需要核实的差异。

这些判断可以形成结构化标签。之后，由程序结合已核实的日期、金额、项目状态和内部职责规则，生成待办或进入复核队列。至于通知是否具有法律效力、对方主张是否成立、企业应采取什么措施，则继续由专业人员及必要的深入分析承担。

这一设计与 TypeSafe 官方强调的“把复杂判断拆开、用代码组合结果”的路线一致。模型处理语义，代码处理精确计算和既定规则，二者不应混在一个笼统提示词里。 23

进一步的想象，是把历史项目文件转化成可分析的数据。

过去的复盘材料，可能只有一篇篇叙述。经过经过验证的语义标注，可以逐步形成“哪些情形被提及、何时被首次记录、后来如何处置”等字段，再用传统统计方法研究其关系。TypeSafe 也已经提供了将自然语言问题的结果转成数值特征、供下游模型使用的探索示例。 24

但这里必须守住一个认识边界：文本中的风险信号不等于已经发生的客观事实，统计关联不等于因果关系。项目记录越完整，可能只是让系统“看见”更多问题，并不意味着该项目管理更差。智能化不能把记录质量的差异，误当成业务质量的差异。

七、从演示走向实际使用，最难的仍然是业务设计

Jev 的接口可以很简单，但“调用成功”距离“能够放心使用”还有相当距离。

首先，问题和选项本身就是业务标准的一部分。

“这份合同风险高不高”是一道模糊题。不同人可能分别考虑金额、责任、履约条件和争议处理，而且权重并不相同。更适合落地的方式，是先把可观察的事实和判断维度拆开，再明确哪些结果只用于提示，哪些结果会影响流程。

评分等级也应描述具体情况，而不是只写“低、中、高”。官方 Score 文档明确建议用可区分的情境定义等级，并用已知样例验证，而不是把较高置信度当成问题设计成功的证据。 25

其次，需要用自己的数据验证，而不是搬用演示中的门槛。

一个可行的试点，可以从单一文件类型、单一判断目标开始，例如公开或获准使用的材料分类。建立人工参考结果，对照关键词规则、现有模型与 Jev，比较漏判、误判、人工复核比例和完整处理成本。测试样本不仅应包含容易判断的情况，还应有否定表述、条件表述、历史事件、材料缺失及跨文件才能理解的情况。

对于少见但重要的风险，仅看总体准确率尤其容易误导。设想一千份材料只有十份存在目标问题，系统全部回答“没有问题”，也能获得 99% 的表面准确率，却没有发现任何一个真正需要关注的对象。因此，应该分别观察漏掉了多少真实问题、发出了多少无效提醒，以及减少了多少人工工作。

再次，受约束的输出并不能替代安全控制。

官方已经披露，当前版本在精确计算、日期比较、多层间接推理和充满无关内容的长输入上存在短板；对抗性文本也可能影响判断。这意味着，Jev 即便被用于识别提示注入，也不能作为唯一的安全屏障。 26

写入、删除、发送、审批等动作，应当由权限、白名单、确认机制和可追溯流程控制。模型返回一个很高的数字，不应该自动获得绕过这些控制的能力。

同样，“多个问题分别评估”不等于所有答案之间必然逻辑一致。官方甚至列出了分别询问某个命题及其否定时，结果不满足直观互补关系的情况。因此，跨问题的一致性检查仍应由程序承担，不能把概率简单拼接成一个必然成立的推理链。 27

最后，部署条件可能比单次调用价格更重要。

目前官方说明，英文是 Jev 的主要训练语言，其他语言包括中文并非具有同等效果；当前版本只接受文本输入。模型有上下文限制，也不适合把整座资料库直接装进一次请求。正式使用还应记录具体模型版本，避免自动变化的模型别名使原先调好的门槛失效。 28

对于内部合同、尽调和项目资料，还必须单独评估数据处理条件。公开文档介绍的主要使用方式是云端 API；官方承诺不以客户数据训练模型，并为企业客户提供零数据保留选项。但“不用于训练”“不保留数据”和“数据不离开本地”，并不是同一件事。是否能够使用，仍应取决于材料性质、组织要求和实际服务安排。 29

结语：值得学习的，不只是一个模型，而是一种分工

Jev 最有启发性的地方，并不是证明“AI 应该少说话”，而是提醒我们：不是所有智能任务，都需要以一段语言生成过程作为中心。

有些任务需要开放探索，需要长时间推理，需要形成可供人理解和讨论的论证。另一些任务只需要在明确材料和标准下，作出一个小而及时的判断。让同一种工具承担所有任务，未必是最合适的系统设计。

TypeSafe 的公开理念，是把语义判断做成能够与普通代码组合的基础能力，而不是让模型接管全部软件逻辑。这个方向值得关注，但它是否适合某项业务，仍需要逐项验证。 30

对企业而言，真正可以沉淀的资产，也不只是“接入了 Jev”。更重要的是把隐含在个人经验中的判断标准写清楚，积累经过核验的样本，明确哪些错误可以容忍、哪些必须拦截，并让每一步处理都能够回看。

模型可以更换，接口可以变化，而这些工作会持续改善系统。

因此，对 Jev 最值得做的尝试，或许不是马上搭建一个新的“大而全智能平台”，而是在既有流程里找到一个位置：那里长期需要人读一小段材料、作一个范围明确的判断，后续规则又能够清楚表达。

把这个位置做好，比让整个流程看起来都由 AI 驱动，更可能带来实际价值。

好的智能系统，不仅要能够迅速作出判断，还应当知道判断依据是什么、何时必须停下来核验，以及谁有权作出最后决定。

参考来源与引用说明

来源核对日期：2026 年 9 月 22 日。原对话导出只保留了引用编号，没有提供其网址映射。以下是根据正文每一处主张重新查找并核对的来源，并非从原对话恢复的原始引用清单。正文 30 处标记已改为可点击的编号链接，标题、段落、表格和加粗格式保留。官方文档为动态页面；厂商披露、外部评测与预印本的证据性质仍按正文区分。

1.TypeSafe AI｜Introducing System One Models & Jev。官方发布文章，Diogo Almeida，2026-09-15；对应发布日期、模型定位与输出形式。

2.TypeSafe AI｜System One。对应名称与《思考，快与慢》的关系，以及快速、范围明确的判断定位。

3.TypeSafe AI｜Primitives (Questions)。对应 Choice、Score、Noul 的返回字段，以及同次请求混合提问。

4.TypeSafe AI｜State。对应 state 的含义、业务背景组织和同一 state 下独立提问。

5.OpenAI｜Introducing Structured Outputs in the API。官方发布文章，2024-08-06；对应 JSON Schema 约束输出的推出时间与作用。

6.TypeSafe AI｜Introducing System One Models & Jev。参见 Frontiers, Old and New 与 Side-by-side demonstration；对应自回归生成与并行概率输出的官方对比。

7.TypeSafe AI｜Primitives (Questions)。参见 Ask multiple questions together 与 When one question depends on another；对应批量问题、额外 token 费用和跨请求依赖。

8.TypeSafe AI｜AI primer。参见 RLCD and calibrated decisions；对应训练目标及概率校准含义。

9.Guo 等｜On Calibration of Modern Neural Networks。Chuan Guo、Geoff Pleiss、Yu Sun、Kilian Q. Weinberger；ICML 2017，PMLR 70:1321–1330。对应现代神经网络概率校准问题。

10.TypeSafe AI｜Confidence。对应 confidence 从概率分布计算、分布集中程度，以及按业务风险和自有数据设置门槛。

11.TypeSafe AI｜Score。参见 Response structure 与 Reading a Score；对应等级位置的概率加权平均，以及 score 与 confidence 的区别。

12.Devlin 等｜BERT: Pre-training of Deep Bidirectional Transformers for Language Understanding。Jacob Devlin、Ming-Wei Chang、Kenton Lee、Kristina Toutanova；NAACL 2019，4171–4186。对应预训练表示增加输出层以适配语言理解任务。

13.TypeSafe AI｜Models。参见 Customizing Jev；对应各账户使用相同权重，以及通过 state、instructions、criteria 适配业务。

14.TypeSafe AI｜Introducing System One Models & Jev。参见 Hallucination and Type-safety 的 Nuance；官方将图中的零值解释为 schema matching 保证。该说明不构成语义判断正确率保证。

15.TypeSafe AI｜Models。参见 Current models；核对时 Jev 1.13.0 标价为每百万输入 token 0.042 美元，输出免费。价格可能更新。

16.TypeSafe AI｜Workflow evals。参见 Assume the harness is correct；对应固定工作流及外部模型生成参考标签的评估方法。

17.Daniel Shea、Seán Roche｜Jev-as-a-Judge for Agent Evals。LangChain，2026-09-20；对应 5 个固定天气案例、每个重复 100 次、平均 0.44 秒及 0.00035 美元/次。属于小范围重复评估。

18.Amir Rafe、Subasish Das｜Calibrated Decisions at Scale: Converting Police Crash Narratives into Probabilistic Crash Variables with a System One Model (Jev)。arXiv:2609.24052v1，2026-09-21，预印本。摘要及正文表 5、6、7 对应样本数、综合 F1 和校准结果。校准误差由 0.0231 降至约 0.0069。 补充来源：论文全文。

19.Delong Li 等｜Fast Intent-Driven Service Orchestration with Jev for 6G Edge Networks。Delong Li、Xu Wang、Haochen Gong、Rui Lang、Guangsheng Yu；arXiv:2609.23136，2026-09-19，预印本。摘要直接列出真实图像服务中 Jev 459、DeepSeek 463，分母均为 1,080。

20.TypeSafe AI｜Pre-parsed value extraction。对应规则发现候选、模型选择语义角色、代码复制原值并规范格式的三步示例。

21.TypeSafe AI｜Double-checking citations。对应先查引文是否存在，再判断来源上下文是否支持主张。检索片段分类另见同一文档站的 Classifying RAG passages。 补充来源：Classifying RAG passages。

22.TypeSafe AI｜Skill suggestion。对应 Hermes 目录的 182 个 Skill、两轮筛选、读取前三项详细信息，以及允许全部拒绝。

23.TypeSafe AI｜Introduction。参见 Atomic questions, composed in code；对应拆分单一判断、用代码组合结果的官方设计原则。施工企业流程是文章的应用推演。

24.TypeSafe AI｜Autoresearch feature discovery。对应将自然语言问题的输出转为数值特征，再训练下游 CatBoost 模型的官方示例。

25.TypeSafe AI｜Score。参见 Writing good levels；对应以具体情境描述等级、区分维度并使用已知样例验证。

26.TypeSafe AI｜Jev 1.13 jaggedness。页面注明适用于 jev-1.13，最后审阅于 2026-09-17；对应精确计算、日期、间接推理、无关长上下文及对抗性内容的限制。

27.TypeSafe AI｜Jev 1.13 jaggedness。参见 Common-sense structural invariants；对应分开提问不保证概率互补或其他跨问题恒等关系。

28.TypeSafe AI｜Models。参见 Current models、Aliases 与 Language support；对应文本输入、上下文限制、版本别名和英文之外语言的效果限制。

29.TypeSafe AI｜Legal。对应不使用用户数据训练的官方说明，以及企业客户可申请零数据保留。具体数据处理安排以实际协议为准。

30.TypeSafe AI｜Composable AI: Build Prod, Not God。官方理念文章；对应语义判断作为可组合基础能力、代码负责精确计算的分工。

Jev 发布的媒体报道

•Tim Fernholz，TechCrunch，2026-09-18：A new kind of AI model from a ChatGPT inventor is thrilling developers。