Jev quick-start guide: running the API inside Codex
A Chinese guide walks through Jev (TypeSafe System One) from installing the skill and configuring the API key to verifying with curl and sending a real Noul request in Codex, noting it suits classification, filtering and ranking rather than writing code.
我申请的waitlist很快通过了，看官网信息很多，又是英文，所以专门整理了一个指南，实测都跑通了，jev的后台也都有usage了，作为一个简单的开端。希望对有的朋友有帮助。 Jev 快速使用 Guide Jev 是 TypeSafe AI 的 System One 模型，适合做快速、明确的语义判断。在 Codex 中，它更适合负责分类、过滤、排序、风险判断和窄范围验证；代码生成、复杂 Debug、架构设计仍交给 Codex。 Jev 能做什么 Jev 有三种主要问题类型： 类型| 用途 "Noul"| Yes / No 概率判断 "Choice"| 从固定候选中分类 "Score"| 有序等级评分 典型分工： 普通代码：搜索、计算、过滤、执行 Jev：语义判断 Codex：分析、设计、编码、调试 Jev 不适合数学计算、精确计数、多步推理，也不适合直接读取整个大型 repository。 --- 从安装到第一次调用 1. 安装 TypeSafe Skill 在项目目录执行： npx skills add typesafe-ai/skills --skill typesafe-ai 安装时选择 Codex。 建议先使用项目级安装，不要急着加 "-g" 全局安装。 Skill 的作用是让 Codex 知道 Jev 的能力、API 和使用方式。Skill 安装成功，不代表 Jev API 已经被调用。 2. 配置 API Key 在 "~/.zshrc" 中加入： export TYPESAFE_API_KEY="你的 API Key" 重新加载： source ~/.zshrc 确认变量存在： if [[ -n "$TYPESAFE_API_KEY" ]]; then echo "TYPESAFE_API_KEY loaded" else echo "TYPESAFE_API_KEY missing" fi 不要直接打印完整 Key。 修改环境变量后，重新启动 Codex CLI。 3. 先验证 API 在 Terminal 中执行： curl -sS https://api.typesafe.ai/v1/systemone \ -H "Authorization: Bearer $TYPESAFE_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "state": "Production is down and customers cannot make payments.", "model": "jev-latest", "questions": { "urgent": { "type": "noul", "instructions": "Does this situation require urgent attention?" } } }' | jq . 如果返回中能看到： model answers usage 说明 API Key 和 Jev 服务正常。 4. 在 Codex 中完成第一次真实调用 启动 Codex： codex 输入： Use the TypeSafe skill. Verify that TYPESAFE_API_KEY exists without printing it. Make a REAL request to the TypeSafe System One API using jev-latest. State: "Production is down and customers cannot make payments." Ask one Noul question: "Does this situation require urgent attention?" Do not simulate the result yourself. Return: - API success/failure - actual returned model - Noul probability - input_tokens - output_tokens Do not modify project files. 看到真实返回的 "model"、Noul 概率和 token usage，才算完成 Codex → Jev 的端到端验证。 如果 Codex 只能解释 Jev，却没有真正调用 API，说明只是 Skill 生效，Jev inference 还没有跑起来。 --- Jev 的问题怎么写 Jev 更适合回答单一、明确的问题。 好： Does this diff modify authentication behavior? 不好： Analyze this patch and determine whether the architecture, security and implementation are correct. 复杂问题应该拆开： Does this patch modify authentication behavior? Does this patch add an external network call? Does this patch modify persistent storage? Does this patch change a public API? 再由代码或 Codex 综合结果。 多个问题使用同一个 "state" 时，尽量一次请求全部发送，减少 API 往返。 --- Codex 中值得尝试的场景 Repository 文件筛选 rg / symbol search ↓ 候选文件 ↓ Jev 判断相关性 ↓ 少量高相关文件 ↓ Codex 深读 不要把整个 repository 直接交给 Jev。先通过搜索缩小范围，再让 Jev rerank。 Patch 风险检查 git diff ↓ Jev ├─ 是否改 auth？ ├─ 是否改 DB schema？ ├─ 是否新增网络调用？ └─ 是否改变 public API？ Jev 在这里只提供风险信号，不能替代测试和代码 review。 Routing Issue ↓ Jev Choice ↓ frontend / backend / infra / data ↓ 对应处理流程 ---
几个使用原则 不要让 Jev 做确定性计算。 例如 diff 行数、时间差、百分比、版本号比较，都直接用代码处理。 不要问太模糊的问题。 不推荐： Is this code safe? 推荐： Does this diff expose credentials in logs? 不要让 Jev 单独决定高风险动作。 不要因为 Jev 判断“安全”，就直接 deploy、delete 或执行数据库 migration。高风险动作仍应经过规则、Codex review 或人工确认。 Threshold 要用真实数据校准。 不要随手写： if probability > 0.8: ... 最好记录： input human_label jev_probability 再根据 false positive / false negative 调整 threshold。 Questions 和 Thresholds 也建议集中管理，例如： jev/ ├── http://questions.py ├── http://thresholds.py ├── http://client.py └── eval/ --- 推荐落地顺序 先完成 Skill 安装和 API 验证，再测试两个小场景： PoC A：repository candidate reranking PoC B：git diff risk verification 与纯 Codex 流程比较： 任务成功率 Codex token usage files read 总耗时 Jev calls 人工纠错次数 测试通过率 如果任务效果不下降，同时减少了 Codex 的无关上下文和 token，再考虑把 Jev 固化进 Agent Harness。 一句话概括： Jev 负责快速缩小问题范围，Codex 负责真正解决问题。