2026 年 9 月 15 日，TypeSafe AI 发布 Jev，把它定义为面向软件决策的 System One Model：输入非结构化状态，输出预先定义类型的概率决策，而不是像传统大语言模型一样生成长文本。

这让我想到一个很具体的 GEO 问题：

当候选 Query 从几十条增加到几百、几千条以后，能不能不用大模型逐条写分析，而是让一个专门的 Decision Model 先把它们结构化？

我用一个真实任务做了第一次实验：围绕“成都 GEO 优化专家 / 服务者 / 解决方案”准备 300 个中文候选 Query，由 Codex 负责工作流，Jev 负责语义判断。

结果比“Jev 很快、很便宜”更有意思。

它确实非常适合做大规模原子语义判断，但我不建议直接把最终业务决策也交给 Jev。

实验结果先看一眼

项目本次结果
中文候选 Query300
Jev 模型jev-1.13.0
成功响应300 / 300
请求尝试301
总尝试延迟289.91 秒
估算成本约 USD 0.01329
Intent 与生成阶段 Hint 一致191 / 300（63.67%）
Jev 直接判断 KEEP8
RESERVE74
DROP218
Raw Query SHA-256874570ba...02c4a
Jev Result SHA-25631883a04...2186

这里最重要的不是 63.67%，也不是 8 条 KEEP。

真正值得讨论的是：怎样把 Jev 放进 SEO/GEO 工程里，才能让它做自己最擅长的事情。

为什么 GEO Query Benchmark 适合用 Jev？

做 GEO Benchmark 时，很容易从少量问题扩展到几百种表达。

同一个“寻找成都 GEO 专家”的需求，就可能出现：

  • 成都有哪些人在研究 GEO？
  • 成都 GEO 优化专家推荐
  • 成都谁做 GEO 优化比较厉害？
  • 成都企业做 GEO 应该找谁？
  • 成都 GEO 顾问怎么选？
  • 成都企业应该先做 SEO 还是 GEO？

这些 Query 表面相似，但实际可能对应不同意图：

自然发现
推荐选择
代表性判断
场景连接
指名验证
邻近需求

当题目只有 20 条，人可以逐条判断。

当题目变成 300、3000 甚至更多以后，问题就变了：

怎样把大量自然语言 Query 稳定地转换成可统计、可筛选、可进入代码工作流的结构化特征？

这恰好属于 Jev 官方强调的方向：分类、评分、验证、路由，以及把大规模非结构化数据转换为软件可以直接处理的 typed decisions。

Codex 和 Jev 到底怎么分工？

这次实验并不是把 300 个 Query 丢给 Codex，然后让 Codex“帮我分析”。

真正的结构是：

300 个 Query
    ↓
Codex
读取 JSONL / 构造请求 / 调用 API / 保存原始响应
    ↓
Jev
做固定的语义判断
    ↓
结构化 Decision Dataset
    ↓
Code
统计 / 比较 / 后续筛选

职责可以简单理解为：

组件负责什么
Codex搭建和执行工作流
Jev做原子语义判断
Python / Code做统计与业务规则
人校准最终研究标准

这也是我认为 Jev 比“再找一个聊天模型”更有意思的地方。

它更像可以嵌进程序里的一个语义判断函数。

第一步：准备 300 个中文 GEO Query

本次原始数据共 300 条。

其中：

Intent Hint数量
natural_discovery60
recommendation60
representativeness45
scenario_connection55
named_verification20
adjacent_demand60

来源上：

  • 42 条标记为历史种子；
  • 258 条是基于既有 GEO 需求空间扩展出的表达。

这里必须说明一个边界：

这 300 条不是搜索量数据，也没有可核验的 Google、Bing 或 Search Console 需求频率。

因此它们适合用来测试“Query 需求空间与 Jev 判断工作流”，不能被描述成“300 个真实高频搜索词”。

同时，258 条扩展 Query 没有逐条保存具体 seed_query_id，这是本次数据可追溯性上的一个缺陷。后续正式构建长期 Benchmark 时应该补上这一层 provenance。

第二步：先冻结 Raw Dataset

在调用 Jev 之前，我没有让 Codex重新生成、改写或删除 Query。

Raw Dataset 经过 schema 校验后被冻结，并计算 SHA-256：

874570baf0599bc5f0b00d0e8b972824fc264eaafd5bbd247364cd153dc02c4a

这一步的目的不是证明“这些题一定正确”。

Hash 只能证明：

后面讨论的这批输入，和实验运行时使用的那批输入是同一个文件。

这对于后续修改筛选规则很重要。

因为规则可以改变，但原始输入不能跟着结果一起被悄悄改掉。

第三步：让 Jev 判断什么？

第一版实验中，每条 Query 让 Jev 独立回答 5 个问题。

1. Intent

从以下类别中选择主要用户意图：

natural_discovery
recommendation
representativeness
scenario_connection
named_verification
adjacent_demand
other

2. Naturalness

判断这句话像不像真实中文用户会说的话。

使用 0–4 的 Score：

0 = 极不自然
1 = 明显生硬
2 = 可以理解
3 = 自然
4 = 非常自然

3. Relevance

判断 Query 和研究目标的相关程度：

成都用户寻找 GEO 专家、服务者、研究者或 GEO 解决方案。

同样使用 0–4。

4. Benchmark Value

判断这条 Query 是否具有进入长期 GEO Benchmark 的价值。

考虑：

  • 是否代表独立需求；
  • 是否有测试价值；
  • 是否只是机械换词；
  • 是否过窄；
  • 是否能测试自然发现、推荐或识别能力。

5. Decision

最后又让 Jev 单独给一个：

KEEP
RESERVE
DROP

当时我的直觉是：

前面的自然度、相关性、Benchmark Value 都判断完了，最后再让 Jev 给一个总决策。

后来证明，这一步是整个实验最值得记录的坑。

300 条全部跑通，成本只有约 1.3 美分

本次使用：

jev-1.13.0

300 条 Query 全部获得成功响应。

实际记录：

  • 301 次调用尝试；
  • 第一次因本机 Python 证书路径失败；
  • 修复可信 CA 后重试成功；
  • 没有关闭 TLS 校验；
  • 最终 300 条全部完成。

所有调用尝试的延迟之和：

289.91 秒

根据 TypeSafe 官方公开的输入价格估算，本次总成本约：

USD 0.01329

即使把第一次没有返回 usage 的失败尝试按保守方式计入，也仍低于：

USD 0.01598

TypeSafe 官方当前公开价格为输入 USD 0.042 / 100 万 Token，输出不按生成 Token 单独计费。官方同时强调，Jev 的优势主要针对 System-One 形态的结构化决策工作流，而不是所有 LLM 任务。

所以这里最值得关注的是：

对短文本、大批量、固定问题的语义判断，成本几乎不是主要矛盾。

中文 Intent：63.67% 不是“准确率”

300 条 Query 在生成阶段本身有一个 intended_intent。

Jev 独立判断后：

191 / 300

与原 Hint 一致，也就是：

63.67%

最大的分歧包括：

representativeness
→ natural_discovery
35 条

以及：

scenario_connection
→ recommendation
14 条

但这里不能写成：

“Jev 中文准确率只有 63.67%。”

因为 intended_intent 只是生成阶段给出的 Hint，不是人工 Ground Truth。

例如：

成都做 GEO 比较有代表性的人是谁？

它到底应该属于“代表性判断”，还是“自然发现”？

本身就存在分类边界。

因此，这个 63.67% 更准确的定义是：

Jev Intent 与生成阶段 Intent Hint 的一致率。

真正测中文准确率，需要单独建立人工标注集。

最关键的发现：不要直接相信 Jev 的最终 KEEP / DROP

第一次跑完后，Jev 给出了：

Decision数量
KEEP8
RESERVE74
DROP218

看起来像是 Jev 非常严格。

但继续检查以后发现：

8 条 KEEP 中，有 7 条的 Benchmark Value 最高概率等级只有 1。

于是出现了很明显的组合：

Benchmark Value
很低

同时

Decision
KEEP

这不是一个适合直接进入生产筛选的结果。

更重要的是，这个结果提醒了我：

不能默认 Jev 的多个独立问题会自动组成一条业务推理链。

我们问的是：

Q1：Naturalness？
Q2：Relevance？
Q3：Benchmark Value？
Q4：Decision？

更合理的理解是：

同一个 State
    ↓
多个独立的 typed decisions

而不是：

Naturalness
    +
Relevance
    +
Benchmark Value
    ↓
Jev 自动综合
    ↓
Decision

TypeSafe 官方自己的 Workflow 设计也强调，把细粒度概率判断组合成最终离散动作，是 surrounding code 的工作。

这意味着：

Jev 适合提供语义特征，但最终业务规则应该由代码明确表达。

我现在会怎么重构这个工作流？

第一版：

Query
  ↓
Jev
  ├─ Intent
  ├─ Naturalness
  ├─ Relevance
  ├─ Benchmark Value
  └─ KEEP / RESERVE / DROP

下一版应该变成：

Query
  ↓
Jev
  ├─ Intent
  ├─ Naturalness
  ├─ Relevance
  └─ Benchmark Value
          ↓
       Code Rule
          ↓
 KEEP / RESERVE / DROP

例如可以设计候选规则：

KEEP
=
Relevance >= 3
AND
Naturalness >= 3
AND
Benchmark Value >= 3

但这个阈值不能拍脑袋确定。

应该先抽样人工标注，再看哪套规则与人工判断最一致。

所以正确的链路更接近：

Jev
负责“读懂”

Code
负责“规则”

LLM
负责复杂研究和生成

Human
负责校准标准

这套方法怎么迁移到 SEO？

Query Benchmark 只是一个小例子。

真正让我感兴趣的是，它可以被迁移到更大的 SEO/GEO 数据集。

1. SERP Query Research

例如：

100 个 Query
×
Google / Bing
×
Top 10

得到数千个 SERP Result 后：

Code
→ 排名、URL、字数、Schema 等客观特征

Jev
→ Page Type、Intent Fit、Evidence Strength、Specificity

SQL / Python
→ 统计 Top3 / Top10 共性

不是让 Jev 解释“Google 为什么给它第一”。

而是先把几千个页面转换成可统计的语义特征。

2. GSC Query 治理

数千甚至数万个 Search Console Query 可以先判断：

Intent
Topic
Commerciality
Content Gap
Action Priority

然后代码生成：

KEEP
REFRESH
CREATE
MERGE
REVIEW

3. GEO Citation Analysis

AI 回答里的大量 Citation URL 可以判断：

页面类型
证据类型
实体关系
Claim Support
Citation Role

再和竞品页面做 Gap。

这比一次让大模型“分析一下这些引用为什么有效”更容易规模化和重复验证。

Jev 真正适合 SEO/GEO 的位置

经过这次实验，我更倾向下面这种架构：

采集层
SERP / GSC / GEO Sampling / Citation
            ↓
客观特征层
Code / Parser
            ↓
语义判断层
Jev
            ↓
业务规则层
SQL / Python / PHP
            ↓
复杂生成层
LLM
            ↓
人工审核 / Publisher

关键不是：

“用 Jev 替代大语言模型。”

而是：

不要再拿大语言模型完成所有事情。

让每一层做自己擅长的任务。

为什么我没有直接用 Jev 筛出最终 50 题？

因为这次实验已经证明，直接拿 KEEP / DROP 作为最终结果是不够可靠的。

所以目前状态是：

300 条 Raw Query
        ↓
Jev 原子语义判断
        ↓
已冻结
        ↓
人工审查 / 规则设计
        ↓
最终 Benchmark

最终 50 题还没有因为这篇文章而被强行“凑出来”。

这也是我认为比一个漂亮 Demo 更重要的地方：

实验发现工作流有问题，就应该保留这个问题，而不是调 Prompt 调到结果看起来正确。

可验证实验数据

为了避免后续筛选规则变化后无法确认原始实验是否被修改，本次保留了两份冻结 Hash。

Raw Query Dataset

300 条原始 Query：

874570baf0599bc5f0b00d0e8b972824fc264eaafd5bbd247364cd153dc02c4a

Jev Result Dataset

300 条 Jev 请求、响应及结构化结果：

31883a04b676b43d62a8b4aeea84d7cf36436f892a750677855ad5fc6d2d2186

这两个 Hash 证明的是文件完整性。

它们不能证明 Jev 的判断正确，也不能证明我的方法论正确。

它们只提供一个可验证锚点：

后续文章引用的 Raw Dataset 和 Jev Result Dataset，可以和本次实验冻结的文件进行一致性校验。

本次实验的局限

这次结果目前只能回答“Jev 能否进入中文 GEO Query 判断工作流”，还不能回答所有问题。

主要限制包括：

  1. 300 条 Query 不是搜索量样本，不能代表真实用户需求频率；
  2. 258 条扩展 Query 没有逐条绑定可追溯 seed；
  3. intended_intent 不是人工 Ground Truth；
  4. 尚未完成人工标注，因此不能报告 Jev 的中文准确率；
  5. 最终 50 题 Benchmark 尚未冻结；
  6. 本次 Decision 与 Benchmark Value 出现明显内部不一致，因此不能直接作为自动筛选器。

这些限制不是需要隐藏的瑕疵。

它们本身就是下一轮实验应该解决的问题。

结论：Jev 更像 SEO/GEO 的语义基础设施，而不是另一个聊天模型

这次 300 个中文 Query 的实验让我得到的最重要结论，不是：

Jev 可以替我自动选出 GEO Benchmark。

而是：

Jev 很适合成为 SEO/GEO 工作流里的高速语义判断层。

它适合做：

分类
评分
验证
语义特征提取

但最终：

业务规则 → Code
复杂研究 → LLM
最终标准 → Human

当 SEO/GEO 数据从几十条增长到几千、几万条时，这种分层可能比“换一个更强的大模型”更重要。

因为真正需要规模化的，往往不是生成更多文字。

而是：

先把大量非结构化信息稳定地变成可以计算、可以统计、可以进入工程系统的决策信号。

这可能才是 Jev 对 SEO/GEO 最有价值的地方。

参考资料

  • TypeSafe AI：《Introducing System One Models & Jev》

https://typesafe.ai/blog/introducing-system-one-models-and-jev

  • TypeSafe AI 官方网站

https://typesafe.ai/

Evidence

Experiment model:

jev-1.13.0

Raw Query Dataset SHA-256:

874570baf0599bc5f0b00d0e8b972824fc264eaafd5bbd247364cd153dc02c4a

Jev Result Dataset SHA-256:

31883a04b676b43d62a8b4aeea84d7cf36436f892a750677855ad5fc6d2d2186

说明：SHA-256 仅用于验证本次冻结文件的完整性，不等同于对研究结论真实性或因果关系的证明。