1. Jev 是什么？把 AI 当成一个判断函数
“这条工单交给谁？”“下一步点哪个按钮？”“哪些文件值得继续读？”——这些任务需要的是一个判断，而不是一篇分析。Jev 瞄准的，就是这类高频、范围明确的小决策。
Jev 是 TypeSafe 推出的模型，官方将它归为 System One Model，强调快速、聚焦的判断。它不生成自由文本，而是根据输入材料和预先定义的问题，返回程序可以直接使用的选择、评分与概率。参见 TypeSafe 模型介绍。
Jev 是开源还是闭源，怎样试用？ 按目前官方提供的接入方式，Jev 是通过托管 API 使用的闭源模型服务，官方未提供可下载的模型权重或本地部署包。公开的 SDK、Skill 和社区项目，不等于模型本身开源。可先到 TypeSafe 官网 点击 Join Waitlist 申请入口 申请访问，通过后进入 TypeSafe 控制台 创建 API Key，并按 Quick start 调用；权限是否开放、何时获批以官方通知为准。模型当前能力与价格见 模型说明，Codex 的具体步骤见第五章。
先记住三个接口就够了：
| 接口 | 通俗理解 | 例子 | 返回结果 |
|---|---|---|---|
| Choice | 做选择题 | 工单属于账号、支付还是技术问题？ | 选项、各选项概率和置信度 |
| Score | 按标准打分 | 这次故障的影响有多严重？ | 评分、等级概率和置信度 |
| Noul | 判断一个条件是否成立 | 日志里是否有许可证获取失败的证据？ | 0～1 的概率 |
同一份材料可以同时回答多个独立问题；问题之间的依赖和后续动作，由程序组织，而不是让模型自行接管整个流程。
一个容易忽略的区别是：Jev 是模型，不是完整的自动化工具。 当前版本接收文本或文本化的结构数据；浏览器和桌面项目会先整理页面信息，再把 Jev 的选择交给执行工具。它并不是直接看截图、操作电脑。参见 模型说明。
2. 为什么值得关注？让小判断更快、更便宜
大语言模型擅长写作、编程和复杂分析，也早已能通过结构化输出返回指定格式的 JSON。Jev 的区别，不是“只有它能输出结构化数据”，而是专门围绕判断任务优化。
| 关注点 | 官方披露 |
|---|---|
| 响应速度 | 约 70～500 毫秒，具体取决于请求与运行条件 |
| 调用价格 | 每百万输入 token 0.042 美元，输出不另收费 |
| 多问题处理 | 同一状态下的多个独立问题可在一次请求中并行判断 |
它更适合放进需要反复判断的循环：筛一批文件、逐步操作页面、给连续到来的工单分类。节省每一步的等待，才可能累积成明显收益；不能把单次模型加速直接等同于整个业务加速。
下面保留一个可播放、暂停和逐步查看的演示，用同一条回归失败记录说明：生成分析、返回判断和执行动作分别发生在哪里。
同一条告警，两种工作方式
- 输入状态
- 定义任务
- 产生结果
- 检查条件
- 进入流程
regression / run-04224 个仿真作业等待；License checkout failed；许可证可用数 0；CPU 有空闲。
日志 + 作业状态 + 环境快照state / run-04224 个仿真作业等待；License checkout failed；许可证可用数 0；CPU 有空闲。
同一份事实，不添加未知信息判断归属、影响和是否阻塞，
按给定结构返回结果。
输出可以是文字，也可以是 JSON{"kind":"license", "impact":1.90, "blocked":true}Schema 可以约束格式。
文字和结构化内容仍需要验证。
无独立 confidence
能解析的 JSON，
仍可能包含错误判断。
0.90 ≥ 0.80进入许可证队列
confidence 不是正确率。
阈值需要用领域样本验证。
需要详细解释或脚本草稿时，
继续使用生成式能力。
起点相同：程序先收集事实。模型没有收到的日志、工具状态与上下文，不会凭空出现。
完整静态分镜 · 信息明确
但也别把“类型安全”理解成“不会出错”。选项合法，不代表选得正确；confidence 也不是答案正确率。 精确计数和数值计算应交给代码，中文及中英混合材料则需要单独测试。参见置信度说明、已知局限和语言支持。
3. 芯片行业怎么用？先从分诊和筛选开始
对芯片研发而言，更值得试的不是“让 Jev 自动设计芯片”，而是让它承担研发流程中的信息筛选。以下均为可探索的工程场景，并非已验证的客户案例。 先把日志、报告和版本信息整理成有限的输入，再问一个可以复核的小问题。
| 明确场景 | 给 Jev 的输入 | 让它判断什么 | 交给工程师的结果 |
|---|---|---|---|
| IT/CAD 工单分派：仿真启动失败，用户只贴了一段报错 | 脱敏报错、工具版本、运行节点、已做的检查 | 更像许可证、环境、存储还是测试平台问题？也允许“信息不足” | 建议处理团队、候选类别，附回原始日志位置 |
| 许可证告警归并：多条作业同时报 checkout failed | feature 名称、报错时间、许可证服务探测结果、相关工单摘要 | 这些记录是否可能属于同一事件？应优先复核哪些记录？ | 同一事件的候选记录清单；服务是否宕机仍按探测结果确认 |
| EDA 工具升级排障：升级版本后脚本不再接受某个参数 | 旧新版本、命令错误、检索到的迁移说明 | 哪份说明适用于当前工具和版本？哪些条目可能解释报错？ | 带来源与适用版本的资料短名单，脚本修改另行验证 |
| 设计变更检查：修改复位时序或增加时钟门控 | 需求、变更摘要、受影响模块、既有检查清单 | 是否应补查复位释放、跨时钟域、门控使能等相关项目？ | 候选检查项和待确认问题；不据此宣告 RTL 正确 |
| 夜间回归分诊：多个 test 失败，日志很长 | 退出码、首个错误、assertion 名称、seed、版本和历史摘要 | 更像基础设施、测试平台还是疑似设计问题？是否已有相似案例？ | 初步类别、相似案例、人工优先复核列表 |
| 覆盖率缺口整理：覆盖率报告中仍有未覆盖项 | 程序提取的 coverpoint/bin、关联计划、现有用例摘要 | 缺口更像场景未覆盖、配置未启用，还是需要设计澄清？ | 待补充测试或待澄清清单；不自动批准 coverage waiver |
| 时序报告分诊：同一批路径反复出现违例 | STA 提取的路径组、端点、corner、slack 和约束上下文 | 哪些摘要更可能属于同一问题？下一步先查约束、结构还是物理实现？ | 路径分组与排查建议；不改 false path，不替代 STA 签核 |
| 功耗、面积报告初筛：新版本某些模块指标异常 | 工具计算的指标、程序算出的版本差值、层级和变更摘要 | 异常更应交给哪个模块负责人？哪些变更值得一起检查？ | 异常归类与候选关联；具体数值、阈值和归因由工具及工程师核验 |
例子一：先把许可证问题从设计失败中分出来
假设早上有 200 条失败记录，其中一些包含 license checkout failed。先用代码按明确错误码、feature 和时间段归并，同时核对许可证服务探测结果；这一步不需要模型猜。
对剩下那些只有“仿真退出”、混有环境告警或用户描述的记录，再让 Jev 从“许可证／环境／存储／测试平台／疑似设计／信息不足”中选择。程序把建议类别与对应日志片段一起展示，工程师检查后再决定是否转交 CAD。模型没有找到足够信息时就保留待查，不因为选项概率较高而自动清除告警。
例子二：夜间回归失败，不把“相似”当成“同一根因”
某个 UVM 回归中，多条记录都出现 timeout，但 test、seed 和 RTL 版本不同。先由程序提取首个错误、发生阶段和 assertion；再将候选历史案例交给 Jev 排序，帮助工程师优先查看更相近的记录。
例如，一条记录伴随许可证失败，另一条在握手等待处超时，两者就不应只因都包含 timeout 而合并。Jev 可以给出“基础设施候选”“疑似设计候选”或“信息不足”；确认根因仍需要完整日志、波形和可复现步骤。相似案例只能减少查找时间，不能证明是同一个 bug。
例子三：工具升级后，先找对版本的说明
综合脚本升级后提示某个选项不再支持，知识库却同时检索到多个旧版说明。先通过检索和版本字段缩小范围，再让 Jev 判断哪些段落真正涉及该选项的替代写法，并标出信息不足的条目。
工程师拿到的是“当前版本可能适用的几份资料”，随后在测试工程验证脚本。缺少版本信息时，优先补齐版本；不让模型把旧文档里的命令直接送到生产流程。
例子四：时序违例先归类，约束修改另行评审
后端工程师拿到一批负 slack 路径后，由 STA 和解析脚本提供 corner、路径组、起终点、slack 及相关约束。Jev 可以根据这些摘要，把值得一起查看的路径分组，建议先检查时钟关系、约束完整性或特定模块的实现。
例如，多个 corner 都指向同一组跨模块端点，可以列为共同复核候选；不能据此自动添加 multicycle 或 false-path 约束。是否为真实功能路径、是否需要 ECO，以及最终是否收敛，仍以设计意图、工程评审和 EDA 结果为准。
从一个离线小流程开始
不必先搭建庞大的 Agent 平台。可以用脱敏历史回归记录跑通下面的流程：
收集退出码、关键日志和运行版本
→ 用规则处理已经明确的错误
→ Jev 对剩余记录分类，并允许返回“信息不足”
→ 疑似设计缺陷或不确定的记录交给工程师
→ 对照最终处理结果，检查分错了什么、漏掉了什么
先比较各类别分错与漏掉的记录、人工处理时间和总成本，再决定是否接入在线流程。总成本应包括材料整理、模型请求、失败重试和人工复核；同一事件的重复记录也应避免同时进入调试集和验收集，造成效果虚高。超时或接口不可用时，记录进入原有人工队列。
调度器已有的原因码不必再让模型猜；仿真、时序分析和签核仍由专业工具及既有流程负责。涉及设计资料上传、修改约束或自动重跑时，应另外确认数据权限与执行授权。
4. 值得关注的 10 个 Jev 项目
下面按用途整理了 10 个项目。项目名链接到对应仓库，功能以当前文档为准；不同项目的演示和测试口径不能直接横向比较。
01｜jev-ultrafast：高速浏览器 Agent
GitHub 仓库：browser-use/jev-ultrafast
Browser Use 团队的项目。Jev 选择操作和目标元素，需要输入文字时再调用小型生成式模型。项目记录的 Google Flights 搜索演示约 7.1 秒，从首次页面观察后计时，到展示匹配结果为止，不包含购票。详见计时说明。
02｜jev-desktop：给桌面操作增加判断层
GitHub 仓库：lahfir/agent-desktop
这是 agent-desktop 仓库提供的 Skill：把应用的可访问性控件信息交给 Jev，选择目标和操作，再由工具执行并重新读取界面。当前可从 macOS 应用场景了解它；输入文字由调用方提供。它与第五章的浏览器 Skill 是不同项目，安装和平台支持应分别看项目说明。
03｜Jev Review：代码审查前置筛选
GitHub 仓库：devagrawal09/jev-review
筛查正确性、安全性、可靠性和测试覆盖等风险，定位值得复核的代码片段，并组织后续审查。适合为人工或强模型缩小检查范围；它给出的是审查线索，不是缺陷证明。
04｜Jev Codex Router：按任务难度分配模型
GitHub 仓库：0xNatoshi/jev-codex-router
让 Jev 判断每轮任务所需的模型档位、推理深度和速度模式。作者报告，在 237 个真实对话轮次的七天回放中，相比全程使用旗舰模型的基线，按标价估算的成本约降低 60%。这是项目方的回放估算，并非本文实测账单，也不代表所有任务都有同等收益。
05｜Prism：流动性管理中的辅助判断
GitHub 仓库：irfndi/prism-liquidity-agent
面向 Solana 流动性池。其 Jev 模块评估不利于流动性提供者的交易流（Toxic Flow）、市场压力、价格回归区间的可能性，以及流动性分布方式。当前 Jev 接入默认关闭，用于旁路评估，不直接决定建仓或退出；这里介绍的是辅助判断的用法，不是收益承诺。详见 Jev 模块源码。
06｜jev-mcp：把常用判断封装成工具
GitHub 仓库：jkudish/jev-mcp
通过 MCP 工具协议接入 Codex、Claude Code 等客户端，用于对照给定证据核验陈述、检测提示词注入、筛选和重排检索结果。适合给现有 Agent 增加一层低成本检查；检查结论仍取决于输入证据和模型判断。
07｜neo4jev：在知识图谱中选择路径
GitHub 仓库：jexp/neo4jev
让 Jev 为候选关系分配概率，再用束搜索（Beam Search）保留多个值得继续探索的分支。适合研究知识图谱的多跳检索：不是一次性读完整张图，而是判断下一步往哪里找。
08｜Blink：先定位，再读代码
GitHub 仓库：ellipsis-dev/blink
根据目录和文件名判断相关性，把搜索优先引向可能包含答案的路径。适合在大代码库中做初步定位，而不是一上来扫描所有文件；定位后仍需要读取代码核实。
09｜Winnow：减少无关工具输出
GitHub 仓库：GhalebDweikat/winnow
面向 Claude Code，筛查 Read、Bash、Grep 返回的大段内容。保留相关或不确定的片段，将高置信度无关内容替换为简短占位信息；原文保留在缓存中，可按需恢复。
10｜typesafe-mcp：通用 Jev 接口
GitHub 仓库：itsmostafa/typesafe-mcp
向 Codex、Claude Code 等客户端开放 Choice、Score、Noul 判断能力。相比预设用途的工具封装，它更适合自定义分类、评级和工作流路由，让大模型少处理重复的小判断。
5. 如何在 Codex 快速体验 Jev
第一步：申请权限，创建 API Key
进入 TypeSafe 官网，点击 Join Waitlist 申请入口 提交申请。是否当天获批，以官方通知为准。通过后回到 TypeSafe 控制台，创建 API Key。
将密钥保存在本地凭据文件中，例如 .env：
TYPESAFE_API_KEY=替换为你的实际密钥
将实际凭据文件加入 .gitignore，不要把真实密钥发进聊天、截图或提交到代码仓库。官方接入说明见 Quick start。
第二步：需要编程接入时，安装官方 Skill
可以直接告诉 Codex 执行：
npx skills add typesafe-ai/skills --skill typesafe-ai
按提示选择 Codex。这个官方 Skill 帮助编码助手设计 Jev 调用、编写问题和组织工作流，不是浏览器接管插件。只想体验页面操作，可以直接看下一步。
第三步：安装浏览器 Skill
这里使用社区项目 Jev Browser Use。准备好已连接浏览器的 Codex Computer Use（CUA）、Node.js 22+ 和 TypeSafe API Key；安装 Skill 本身不会补齐浏览器连接。仓库已记录的工作流验证以 macOS 为主，其他平台应按实际环境验收。
把仓库交给 Codex，让它按 INSTALL.md 安装配置；也可以执行当前文档提供的命令：
npx skills add wy-coliney/jev-browser-use -g -a codex -y
安装后，将本地密钥文件的绝对路径交给 Codex，按安装指南完成 TypeSafe 接入，再新建任务加载 jev-browser-use。若浏览器未连接，先修复 CUA 连接；若接口返回权限错误，先检查账号访问权限与本地密钥配置，不能把普通浏览器操作当成 Jev 已经接入的证明。
版本提示：其他教程中的
jev-use名称，以及npm run install:codex -- --env-file .env，不能直接套用到所有项目。后者只有在对应仓库提供该脚本时才有效；本文采用 Jev Browser Use 当前安装说明中的方式。
第四步：用真实页面和测试结果验收
可以从自己的测试环境开始，把下面这段话交给 Codex：
请使用 Jev Browser Use 检查这个产品页：
打开筛选面板，切换筛选条件，翻页并查看详情。
点击、跳转和滚动交给 Jev；需要输入、视觉判断或复杂分析时由你接手，
处理完后让 Jev 继续。
最后核对页面是否达到目标，并运行项目已有的相关测试（如可用）。
不要付款、发布内容或删除数据。
不必盯着它逐个点击。给出明确任务和验收标准，最后看页面状态、实际调用记录、测试结果、耗时与费用，才知道这次接入有没有价值。未成功调用 Jev、仅由 Codex 完成的步骤，要单独说明。
独立开发、经常跑页面测试的，值得从一个小任务试起；芯片团队则可以先用脱敏记录验证一次分诊或资料筛选，再决定是否扩大范围。
申请入口：typesafe.ai · 控制台：console.typesafe.ai · 文档：Quick start