ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

Jev 火了:这个 AI 模型不写代码,只负责“做判断”

Jev 火了:这个 AI 模型不写代码,只负责“做判断” 文章目录Jev 火了这个 AI 模型不写代码只负责“做判断”什么是 System OneJev 主要会做三种题Choice选择题Score评分题Noul判断题三种问题还可以一起用为什么 Jev 可以这么快它为什么号称不会产生幻觉Jev 适合什么场景任务分类Agent 路由风险判断自动审核优先级判断工作流分支Agent 结果评估Jev 的 API 怎么调用方式 1Playground 快速试玩一个 Playground 实测例子方式 2获取 API KeyJev 模型价格用 curl 发一次请求macOS / LinuxWindowsCMD / PowerShell在 Coding Agent 中使用在 Claude Code 中使用在 Codex 等其他工具中使用提示词自动安装Jev 真正有意思的地方Coding Agent这时候就有点好玩了Jev 的价格也很有意思最后Jev 火了这个 AI 模型不写代码只负责“做判断”最近 Jev 挺火的。这个模型有点不一样。我们平时接触的 GPT、Claude、Gemini 这些模型基本都是你问它一个问题它负责给你生成答案。写文章、写代码、分析问题、总结资料本质上都是在“生成”。但 Jev 偏偏反过来了。它不负责生成内容只负责做判断。比如这个任务应该交给哪个 Agent这个请求是否需要人工处理这个操作有没有风险几个方案应该选哪个当前结果是否达到了要求一个事件的优先级到底有多高最终它给你的不是一大段自然语言而是程序可以直接使用的结构化结果。Jev 于2026 年 9 月 15 日发布是 TypeSafe 推出的首个System One模型。官方目前把它定位成一种专门用于软件工作流的模型。而且官方给出的数据也挺夸张在特定 workflow 测试中Jev 达到了193.6 倍更快、444.6 倍更便宜。当然这个数据是官方特定场景的测试结果并不是说 Jev 在任何任务上都能比 GPT、Claude 快几百倍。但这个思路本身确实挺有意思。大模型负责生成Jev 负责判断。这可能是 AI Agent 里面一个挺有意思的新玩法。什么是 System One先别急着玩 Jev。我们先搞明白它所谓的System One到底是什么。传统 LLM 的工作方式比较简单用户输入 ↓ 模型理解 ↓ 模型推理 ↓ 生成文字 ↓ 返回结果比如你问 Claude分析一下这个项目有哪些地方需要优化。它会给你生成一大段文字。但 System One 的思路不一样。它更像这样当前状态 ↓ 提出问题 ↓ 模型判断 ↓ 返回结构化结果 ↓ 程序继续执行这里有一个很关键的区别它不是让 AI 替你把事情做完而是让 AI 告诉程序下一步应该怎么走。举个简单的例子。假设你的系统里面有一个任务路由器。现在来了一个请求帮我分析一下这个 Java 项目的数据库连接问题程序需要判断这个任务应该交给哪个 AgentA前端 Agent BJava Agent C数据库 Agent D运维 Agent这种事情当然可以让 GPT、Claude 来判断。但如果每次都调用一个大型 LLM然后让它生成一段分析最后程序再从这段文字里面找答案其实有点麻烦。System One 的思路就是状态用户请求 ↓ 问题应该交给哪个 Agent ↓ Choice ↓ C数据库 Agent程序拿到结果之后直接路由。这就是 Jev 的核心玩法。Jev 主要会做三种题目前 TypeSafe 提供了三种主要的问题类型类型用来干什么返回结果Choice从多个选项中选择一个choice、probabilities、confidenceScore根据标准进行评分score、probabilities、confidenceNoul判断一个陈述是否成立01这三个名字刚开始看可能有点奇怪。其实很好理解。Choice选择题例如这个任务应该交给哪个 Agent A前端 BJava C数据库 D运维Jev 直接选择一个。这种非常适合分类、路由、任务分发。Score评分题比如根据当前信息 判断这个任务的紧急程度。然后按照预先定义好的标准进行评分。这种就适合风险评分、优先级、质量评估。Noul判断题这个最简单。例如这个任务是否需要人工审核最终得到一个 01 的结果。你可以简单理解成0 → 基本不是 0.5 → 不太确定 1 → 基本确定然后程序自己决定 0.9 自动处理 0.60.9 进一步检查 0.6 转人工这里就有点意思了。以前程序里面很多不好写死的判断if xxx: ... else: ...现在可以变成Jev 判断 ↓ 程序根据结果执行所以 TypeSafe 也把这种模式称为类似AI-powered if statements。说白了就是让 AI 帮你做那些很难写死的 if/else。三种问题还可以一起用这也是 Jev 比较有意思的地方。不是一次 API 调用只能问一个问题。你可以针对同一个状态同时问多个问题。比如一个安全告警进来了当前状态 服务器检测到一次异常登录 来源 IP 与历史登录位置不同 同时在短时间内出现了大量失败请求。一次请求里面可以问问题 1 这是不是安全事件 问题 2 风险等级是多少 问题 3 应该交给哪个处理流程分别对应Noul Score Choice最后程序拿到是否安全事件 → true 风险评分 → 0.93 处理流程 → security-review然后代码继续执行。这个思路就比较适合真正的业务系统。为什么 Jev 可以这么快原因其实也不复杂。GPT、Claude 这种模型最终需要生成大量 Token。比如你让它分析一个问题它可能给你输出几百字、几千字。模型需要不断生成Token 1 Token 2 Token 3 Token 4 ……但 Jev 的目标不是生成一篇文章。它最终可能只需要给你{choice:database,confidence:0.94}所以它不需要花大量时间组织自然语言。另外TypeSafe 的设计本身就是针对这种结构化决策场景。官方目前给出的 Jev 响应延迟大约在70ms500ms。官网还展示了一个具体 workflow 的测试Jev 0.114 秒 $0.000081 LLM 8.566 秒 $0.013880对应官方给出的结果193.6× Faster444.6× Cheaper不过这里一定要注意。这个数字是官方特定 workflow 的测试结果。不能理解成Jev 永远比 GPT、Claude 快 193 倍。更准确的说法是在适合 System One 的结构化决策任务里Jev 可以把延迟和成本压得非常低。这才是它真正值得关注的地方。它为什么号称不会产生幻觉这个地方也挺容易被误解。TypeSafe 官网直接用了Zero Hallucinations但这并不是说Jev 判断什么都不会错。它解决的是另外一个问题。比如你让一个普通 LLM从 A、B、C 中选择一个。它可能最后给你生成我认为 A 和 C 都有一定合理性……甚至自己创造一个 D。但 Jev 的输出是结构化的。如果你定义A B C它的输出就必须符合这个结构。程序不需要再从一大段自然语言里猜这个模型到底选择的是 A 还是 B所以这里所谓的“不会幻觉”更应该理解为输出被限制在预先定义的结构和类型里面。至于判断本身是否正确当然还是存在误判的可能。所以 Jev 同样会给出概率、置信度等信息。Jev 适合什么场景看到这里你应该已经发现了。Jev 并不是拿来替代 ChatGPT、Claude 的。你不会拿它来写公众号文章。也不会让它帮你写 500 行代码。它真正适合的是任务分类这个任务属于哪一类Agent 路由应该交给哪个 Agent风险判断这个操作有没有风险自动审核这个结果是否需要人工检查优先级判断哪个任务应该优先处理工作流分支当前状态应该走哪个流程Agent 结果评估这个 Agent 刚才的操作是否需要人工介入你会发现这些场景有一个共同点最终都不需要一篇文章。程序只需要一个判断。这正是 Jev 的用武之地。Jev 的 API 怎么调用Jev 已经开放注册不用再排 waitlist。新用户会送5 美元额度官方说大约能跑1.2 亿 Token。接入方式大概有这几种从最省事的开始说。方式 1Playground 快速试玩如果只是想体验一下直接打开官方 PlaygroundTypeSafe Playgroundhttps://console.typesafe.ai/playground上方填 State输入内容下方写 Questions定义任务规则点一下 Run request 就能看到结构化结果。一个 Playground 实测例子我在 TypeSafe Playground 里跑了一条真实客服场景。state我升级到 Pro 会员后一直没有生效钱已经扣了麻烦帮我看下提了一个 Noul 问题这条消息是否属于会员或付费问题运行后Jev 直接给出概率99% true 1% false方式 2获取 API Key打开 API Keys 页面创建一个 API KeyTypeSafe API Keyshttps://console.typesafe.ai/keys拿到 Key 之后本地设置一个TYPESAFE_API_KEY环境变量后面在 AI 工具中可以直接拿来用而不用担心泄露。Linux / macOSexportTYPESAFE_API_KEYYOUR_API_KEYWindowsPowerShell$env:TYPESAFE_API_KEYYOUR_API_KEYJev 模型价格根据 TypeSafe 官方 Models 页面项目数值输入价格$42 / 10 亿 tokens即$0.042 / 百万 tokens输出价格免费端到端延迟70ms ~ 500ms上下文单次请求 64K tokens其中state 最长问题 32K速率250,000 tokens/秒1,200 请求/分钟输入类型仅文本字符串、JSON 对象或文本数组输出 token 免费这一点对大量判断型调用很划算。因为 Jev 的输出通常就几个字段本来就不占多少 token。用 curl 发一次请求核心接口就一个POST /v1/systemone可以直接这样发macOS / Linuxcurl-XPOST https://api.typesafe.ai/v1/systemone\-HAuthorization: Bearer$TYPESAFE_API_KEY\-HContent-Type: application/json\-d-EOF { model: jev-latest, state: 用户连续提交了多次登录失败请求来源 IP 与历史登录位置不同, questions: { security_risk: { type: noul, instructions: 这个请求是否存在明显的安全风险 } } } EOFWindowsCMD / PowerShellWindows 下直接复制多行命令容易因为换行符解析失败。把 JSON 写进文件再用-d 文件调用。先新建一个jev_payload.json{model:jev-latest,state:用户连续提交了多次登录失败请求来源 IP 与历史登录位置不同,questions:{security_risk:{type:noul,instructions:这个请求是否存在明显的安全风险}}}PowerShellcurl-X POST https://api.typesafe.ai/v1/systemone-HAuthorization: Bearer$env:TYPESAFE_API_KEY-HContent-Type: application/json-d jev_payload.jsonCMDcurl -X POST https://api.typesafe.ai/v1/systemone -H Authorization: Bearer %TYPESAFE_API_KEY% -H Content-Type: application/json -d jev_payload.json返回的是一个结构化 JSONmodeljev-1.13.0answers.security_risk.typenoulanswers.security_risk.noul0.9696% 概率判定为真存在明显安全风险usage输入 311 tokens输出 22 tokens程序拿到0.96这个数值后可以设置一个阈值比如 0.9直接触发后续安全流程整个过程里没有必要让模型生成一大段自然语言。注意 JSON 结构model传jev-latest或固定版本号jev-1.13.0。state要被判断的当前状态。questions一个对象key 是你给问题起的名字value 是问题定义typeinstructions。返回的也是结构化结果程序拿到以后直接继续处理整个过程里没有必要让模型生成一大段自然语言。在 Coding Agent 中使用TypeSafe 提供了一个即插即用的 SkillTypeSafe Skillshttps://github.com/typesafe-ai/skills它提供了 TypeSafe API 的完整上下文三种问题类型架构模式组织评估的最佳实践这个 Skill 可用于Claude Code、Codex以及其他 Coding Agent 工具中。在 Claude Code 中使用安装 Skill终端执行两行命令claude plugin marketplaceaddtypesafe-ai/skills claude plugininstalltypesafetypesafe-ai使用的时候直接说“使用 TypeSafe 技能……”来触发也可以用斜杠命令主动调用/typesafe:typesafe-ai 分析下这个项目判断有哪些可替代的复杂逻辑或弱代码Jev 只给判断代码还是由 Claude Code 自己改。更新 Skillclaude plugin marketplace update typesafe-ai claude plugin update typesafetypesafe-ai然后重启 Claude Code或者运行/reload-plugins加载更新。在 Codex 等其他工具中使用安装 Skillnpx skillsaddtypesafe-ai/skills--skilltypesafe-ai默认会包含Codex、Cursor、Gemini CLI、OpenCode等主流 Coding Agent安装时选择自己用的那个回车即可。使用方式和 Claude Code 一样在对话里输入/Typesafe会自动出来。更新 Skillnpx skills update如果是手动复制的 Skill就用 GitHub 上的最新版本替换整个 skill 目录。提示词自动安装也可以直接把下面这段提示词发到任何支持 Skills 的 Coding Agent 里它会根据当前工具自动完成安装安装 TypeSafe 技能。如果你在 Claude Code 中请运行 claude plugin marketplace add typesafe-ai/skills 然后运行 claude plugin install typesafetypesafe-ai。如果你在其他 Coding Agent 中请运行 npx skills add typesafe-ai/skills --skill typesafe-ai 并选择你的 Coding Agent。 请使用其中一种安装方式。之后在开发此项目时即可使用 TypeSafe 技能。或者英文版的Install the TypeSafe skill. If youre in Claude Code, run claude plugin marketplace add typesafe-ai/skills, then claude plugin install typesafetypesafe-ai. If youreinanother agent, runnpx skillsaddtypesafe-ai/skills--skilltypesafe-aiandselectyour agent. Use one installation method. You canreadthe skill directly at https://github.com/typesafe-ai/skills/blob/main/skills/typesafe-ai/SKILL.md(raw: https://raw.githubusercontent.com/typesafe-ai/skills/main/skills/typesafe-ai/SKILL.md). Then use the TypeSafe skill when working on this project.如WorkBuddy、TraeWork 安装后也可以直接调用skill装好之后基本不用自己再封一层 API直接在 Coding Agent 里面调用就行。Jev 真正有意思的地方Coding Agent如果你只是拿 Jev 调几个 API我觉得还没那么有意思。我反而比较关注Jev Claude Code / Codex。因为 Coding Agent 在干活的时候其实会遇到大量“判断题”。比如这个文件要不要修改 这个任务应该调用哪个工具 这个操作需不需要人工确认 这个修改是否存在风险 这个方案应该继续还是换一个 刚才生成的代码是否需要重新检查这些判断都可以交给 Jev。于是就出现了一种很有意思的组合Claude Code / Codex ↓ 负责理解和执行 ↓ Jev ↓ 负责判断 ↓ Claude Code / Codex ↓ 继续执行也就是大模型负责干活Jev 负责判断。这可能才是 Jev 最值得玩的地方。这时候就有点好玩了比如你正在用 Codex 开发一个项目。以前可能是Codex ↓ 分析项目 ↓ 自己判断 ↓ 修改代码 ↓ 自己判断 ↓ 继续修改接入 Jev 以后可以变成Codex ↓ 分析项目 ↓ Jev 判断 ↓ 决定下一步 ↓ Codex 执行 ↓ Jev 检查 ↓ 继续 / 停止 / 转人工这就有点像给 Agent 加了一个专门的“裁判”。Codex 负责上场干活Jev 负责在旁边判断。当然这只是一个思路。真正放到项目里面还得看具体 workflow 怎么设计。但这种“模型分工”的方式我觉得确实比让一个模型什么都干更值得研究。Jev 的价格也很有意思Jev 最大的优势之一就是便宜。具体价格前面已经列过表了输入 $0.042 / 百万 Token输出侧免费。这里想说的是这个价格带来的变化。假设你的程序一天需要做大量简单判断这个任务是什么类型 是否需要人工 是否存在风险 应该走哪个分支这些调用如果全部使用一个大型 LLM成本很容易堆起来。但如果只是让模型返回true false A B 0.83这种结果使用专门的决策模型就比较合适。所以 Jev 真正解决的其实不是“如何让 AI 生成更多内容”而是“如何让软件低成本地使用 AI 做大量判断”这两个问题其实完全不一样。最后Jev 最让我感兴趣的地方并不是又出来了一个新模型。而是它换了一个思路。以前我们习惯一个大模型 ↓ 什么都干现在 Jev 提供了另一种可能大模型 ↓ 负责理解、推理、生成 Jev ↓ 负责判断、分类、路由、评分一个负责生成。一个负责决策。再把它们放进 Coding Agent 里面Claude Code / Codex ↓ 干活 ↓ Jev ↓ 判断 ↓ Claude Code / Codex ↓ 继续干活这样看下来Jev 更像是给 AI Agent 增加了一个专门负责判断的模型组件。所以我觉得Jev 最值得关注的地方并不是它能不能替代 GPT、Claude。它根本就不是奔着这个方向去的。真正值得研究的是以后一个 AI Agent是不是可以让不同模型负责不同的事情大模型负责复杂推理和生成。小而快的模型负责分类、判断和路由。程序负责真正的执行。如果这个方向能够跑通AI Agent 的成本和速度可能都会出现新的玩法。目前 Jev 还比较新官方公布的性能数据也主要来自特定 workflow真正放到复杂项目里能发挥多大作用还需要实际测试。不过光是这个思路就已经挺有意思了。AI 不一定什么都要生成。有时候它只需要告诉程序“这个走 A。”就够了。
返回列表