平时做技术实践时,很多问题不是概念不会,而是细节没串起来。拿“什么是Jev?10分钟教你如何给Claude Code和Codex装上J……”来说,它看着像小点,放到项目里常会牵出环境、配置、兼容性和维护成本。下面按实际采用顺序,把思路、关键写法和容易踩坑的地方讲清楚,便于大家直接对照操作。

在这个场景下,Jev(TypeSafe AI 出品)不写代码、不写文案,只做一件事——在给定上下文里给出结构化的判断结果:是 / 否、选哪个、打几分。
从实现思路看,所以它不是用来替代 Claude Code、Codex 的,而是给它们打配合:Coding Agent 负责写,Jev 负责判断。
Jev 已经取消 waitlist,注册即用,控制台入口:
https://console.typesafe.ai
在这个场景下,新账号送 5 美元额度,官方口径约 1.2 亿 Token,目前还没开放充值入口。
下面五步,走完就能用。
进入控制台的 API keys 页面新建密钥:
https://console.typesafe.ai/keys

Key 只在新建时完整展示一次,当场存好。别粘进脚本或设置文件,设成环境变量 TYPESAFE_API_KEY,后面 curl 和 Agent 都从环境里读:
# macOS / Linux,写进 ~/.zshrc 或 ~/.bashrc
export TYPESAFE_API_KEY="你的密钥"
# Windows PowerShell(当前会话)
$env:TYPESAFE_API_KEY = "你的密钥"
理解这一步时,这样 Agent 自动跑命令时看到的是变量名而不是明文,不会把密钥顺手提交上去。
Jev 不是免费模型,但它的定价结构和常规模型完全不是一个逻辑:

几个值得单独拎出来的点:
state 加上最长的那个问题合计不超过 32K。只兼容文本输入,图片、音频、视频一律不认。结合项目来看,最后这条限制需在设计调用方式时就纳入考虑:如果你的判断依据是一张架构图或者一段录屏,Jev 帮不上忙,得先由别的环节转成文字描述再喂进来。
理解这一步时,在接入任何 Agent 之前,强烈建议先用 curl 手动打一次。原因很轻松——只有看过原始得到,你才知道后面 Skill 到底帮你封装掉了什么。
curl -X POST https://api.typesafe.ai/v1/systemone
-H "Authorization: Bearer $TYPESAFE_API_KEY"
-H "Content-Type: application/json"
-d @- <<'EOF'
{
"state": "我的 Claude 账号被封号了,一直没有解封,用不了,麻烦帮我看下",
"model": "jev-latest",
"questions": {
"urgency": {
"type": "noul",
"instructions": "这个问题和登录有关系吗?"
}
}
}
EOF
得到长这样:

拆开看,这个请求体的设计思路其实很清楚:
| 字段 | 作用 |
|---|---|
state | 待判断的非结构化上下文,能够是一段话、一份日志、一段代码 |
model | 模型版本,jev-latest 表示跟随最新 |
questions | 你要问的问题集合,能够一次问多个,每个问题独立命名 |
type | 结合项目来看,问题类型,决定了得到值的形态(示例中的 noul 表示「是否成立」) |
instructions | 对这个问题的自然语言说明 |
得到里的 "noul": 0.82 是个置信度数值结合项目来看,,而不是轻松的 true/false。这一点在工程化的时候很有用:你能够自己设阈值,比如 0.9 以上才自动执行,0.6~0.9 之间转人工确认,0.6 以下直接否决。用一个布尔值是做不到这种分级的。
usage 字段也值得看一眼——这次调用输入 305 Token、输出 21 Token。结合「输出免费」的规则,这一次判断的实际成本几乎能够忽略不计。
理解这一步时,手动拼 JSON 显然不是长久之计。官方提供了一个即插即用的 Skill,仓库地址:
https://github.com/typesafe-ai/skills
理解这一步时,这个 Skill 本身不是轻松的 API 封装,它往 Agent 的上下文里塞进了三样东西:
在这个场景下,换句话说,装上它之后,Agent 不只是「会调这个接口」,而是「知道什么时候该调、该怎么问」。这个差别在实际采用中很明显。
落到代码里,Skill 同时适用来 Claude Code、Codex 以及其他主流 Coding Agent,但两类工具的安装方式不同,下面分开说。
Claude Code 走插件市场,两条命令:
claude plugin marketplace add typesafe-ai/skills
claude plugin install typesafe@typesafe-ai

落到代码里,执行过程会自动 clone 仓库、校验市场设置、装好插件。装完之后建议重启一次 Claude Code,或者直接执行 /reload-plugins 让插件生效。
非 Claude Code 系的工具走 skills.sh 这条通用链路:
npx skills add typesafe-ai/skills --skill typesafe-ai

实际处理时,它会先列出一批默认勾选的通用 Agent——Codex、Cursor、Gemini CLI、OpenCode、Cline、GitHub Copilot、Zed 等都在内,往下翻还能自己加选其他目标。确认后回车即可完成安装。
这里有个小细节:默认写入的是 .agents/skills 这个通用目录,多数现代 Agent 都会去读它,所以一次安装基本能覆盖你机器上的大部分工具,不需挨个装。
理解这一步时,Skill 的触发方式和普通 Skill 一致:既能够自然语言说「用 TypeSafe 技能帮我判断……」,也能够直接敲斜杠命令 /typesafe:typesafe-ai 主动调用。
先来个和代码无关的,用来体会它的输出风格:
/typesafe:typesafe-ai Mac mini 我有必要买吗?请直接给判断

整个过程 12 秒出结果,结论是「不必买」。
落到代码里,注意它的输出结构——不是一段和稀泥的分析,而是一张「问题 / 原语 / 结果 / 依据」四行表格,结果那栏直接写着「否(接近 0)」。它甚至还给出了结论失效的条件:只有当出现「需一台一直开着、不带屏幕的机器」这种需求时,才值得重新判断。
在这个场景下,这种「给结论 + 给依据 + 给反转条件」的三段式,比通常那种列十条优点再列十条缺点最后说「取决于你的需求」的回答,可执行性高出一个量级。
这个才是 Coding Agent 场景下的重头戏:
/typesafe:typesafe-ai 分析下这个项目,判断有哪些可替代复杂的逻辑或弱代码。

能够看到它的执行路径:先去抓 TypeSafe 的文档(llms.txt、how-to-build-with-system-one.md、use-case-map.md),摸清判断原语的适用边界,随后才开始读项目结构。这就是前面说的「Skill 提供上下文」的价值——它不会上来就瞎判断。
最后产出是这样一张对照表:

表格比常规的代码审查多出了最右边一栏 TypeSafe?从实现思路看,,逐条回答「这段逻辑该不该交给模型判断」。而且结论几乎全是「否」,同时附上了原因:
DesktopOwnerProbe.knownHijackers 写死 bundle ID —— 精确身份匹配,不是读含义,该留在代码里DesktopOwnerProbe.hijackerIDs() —— 死循环式冗余,删掉即可ClickRegion 按 visibleFrame 判位置 —— 纯几何计算DesktopService.reveal() 的重试节奏 —— 时序问题,模型解决不了竞态这个结果初看有点反直觉:花钱装了个判断引擎,结果它告诉你「这些地方都不需我」。但这恰恰是它最该被称赞的地方——一个愿意说「这里别用我」的工具,比一个哪儿都想插一脚的工具可信得多实际处理时,。文档里也明确列出了禁区:日期差、状态位、白名单、几何命中、bundle ID、文件路径,这些确定性计算一律不要交给模型。
在这个场景下,Codex 这边同样是 Skill 化调用,输入 /Typesafe 就会自动补全:

理解这一步时,对同一个 Mac mini 问题,Codex 侧用时 14 秒,结论一致:「不买」,理由是「属于想买,不是有必要买」。不同宿主 Agent 之间结论稳定,说明判断主要由 Jev 本身完成,宿主只负责组织上下文。
Skill 还在迭代,跟进更新的方式按安装渠道区分。
Claude Code 插件方式:
claude plugin marketplace update typesafe-ai
claude plugin update typesafe@typesafe-ai
在这个场景下,更新完同样需重启 Claude Code 或执行 /reload-plugins。
在这个场景下,嫌麻烦的话能够开自动更新:打开 /plugin → 选 Marketplaces → 选 typesafe-ai → 启用自动更新,之后就不用管了。
skills.sh 方式:
npx skills update
手动复制 Skill 目录的方式: 结合项目来看,没有增量更新机制,只能用 GitHub 上的最新版本整个替换掉原来的 skill 目录。这也是不建议手动安装的原因。
在这个场景下,若你懒得判断当前用的是哪个工具、该走哪条命令,能够把下面这段直接丢给任意兼容 Skills 的 Agent,让它自己识别环境同时完成安装:
安装 TypeSafe 技能。如果你在 Claude Code 中,请运行 claude plugin marketplace add typesafe-ai/skills,然后运行 claude plugin install typesafe@typesafe-ai。如果你在其他 Coding Agent 中,请运行 npx skills add typesafe-ai/skills --skill typesafe-ai 并选择你的 Coding Agent。请使用其中一种安装方式。你可以直接阅读该技能的说明文档:https://github.com/typesafe-ai/skills/blob/main/skills/typesafe-ai/SKILL.md(原始版本:https://raw.githubusercontent.com/typesafe-ai/skills/main/skills/typesafe-ai/SKILL.md)。之后在开发此项目时即可使用 TypeSafe 技能。
它会自己识别当前环境该走哪条命令,比你先搞清楚环境再敲要省事。
实操下来,这条边界比安装教程本身更值得记住。
适合交给 Jev 的:
不适合交给 Jev 的:
还有两条工程上的注意事项:
state + 最长问题只有 32K。如果你打算把整个文件塞进去判断,先估算一下长度,超了要做切片或摘要。if (result > 0.5) 会丢掉最有价值的那部分信息。建议至少分三档:高置信自动执行、中置信转人工、低置信直接否决。整套流程其实就三件事:建 Key、装 Skill、敲 /typesafe:typesafe-ai。官方把 Skill 做好了,不用自己封装 API,接入成本基本为零。
上手建议:别一上来就接进生产流程结合项目来看,。先让它审一遍你手头项目的代码,看看它判定哪些逻辑「不该交给模型」——这份清单比它给出的任何一个「是」都更有价值。
理解这一步时,总的来说,Jev是什么适合结合实际项目边做边理解。先抓住核心思路,再逐步补上细节和边界处理,最后效果会更稳定,也更容易复用。