小蜗

当 AI 开始负责“判断”：一篇讲懂 Jev 的科普

2026-09-23AI21 分钟

目录

过去几年，我们对 AI 的印象几乎都来自 ChatGPT、Claude、Gemini 这一类 LLM（Large Language Model，大语言模型）。

你问它问题，它给你写答案；
你给它需求，它帮你写代码；
你丢给它一份文档，它帮你总结；
你让它操作电脑，它甚至可以分析当前状态，再决定下一步做什么。

所以我们很容易形成一种惯性：

只要一个问题需要“理解语言”，就应该交给大语言模型。

最近 TypeSafe AI 发布的 Jev，提供了另一种思路。

Jev 是 TypeSafe AI 首个公开发布的 System One Model（系统一模型），目前处于 Early Access（早期访问）阶段。

它和我们熟悉的大语言模型有一个很明显的区别：

它并不以“生成文本”为主要目标。

它不会用来写一篇文章，也不是为了生成几百行代码。

它更擅长做另一件事：

判断。

比如：

  • 这封邮件是不是很紧急？
  • 这个搜索结果和我的问题有没有关系？
  • 这个任务应该交给哪个模型？
  • 这个工具调用有没有风险？
  • 这段历史信息以后还有没有价值？
  • Agent 现在应该继续搜索，还是已经可以停止？
  • AI 给出的引用，真的支持它前面的结论吗？

这些问题有一个共同点：

我们不需要 AI 写一篇文章。

真正需要的是：

是不是？
选哪个？
程度有多高？

TypeSafe 对 System One 的概括很简洁：

unstructured state in, typed probabilistic decisions out

可以翻译成：

非结构化状态输入，类型化的概率决策输出。

简单画一下：

纯文本 
自然语言、文本、JSON、程序状态
              │
              ▼
             Jev
              │
              ▼
      类型化的概率判断

听起来只是 AI 世界里又多了一种模型。

但如果沿着这个思路继续往下看，它可能影响的并不只是“模型选型”，而是我们以后怎样设计 AI 软件。

一、先用一个简单例子理解 Jev

假设你在开发一个客服系统。

用户发来一句话：

“你们怎么又扣了我一次钱？我明明已经付过了。”

如果交给传统大语言模型，我们可能写一个 Prompt：

请判断用户的问题属于什么类型，是否要求退款，情绪是否激动，并返回 JSON。

模型可能返回：

JSON 
{
  "category": "billing",
  "refund": true,
  "sentiment": "angry"
}

今天的大语言模型已经非常擅长 Structured Output（结构化输出），也可以通过 JSON Schema、约束解码等方式，保证输出符合指定格式。

所以 Jev 和 LLM 的真正区别并不是：

一个能输出 JSON，一个不能。

问题应该换一种问法：

如果我根本不需要模型“写东西”，只是需要它做几个判断，有没有一种更直接的模型接口？

在上面的客服例子里，程序真正关心的其实是：

纯文本 
这是不是账单问题？

用户是不是在要求退款？

用户现在有多不满？

Jev 就是围绕这种任务设计的。

Choice：选择题

Choice 用来从有限候选项里做选择。

例如：

这个客服问题应该交给哪个部门？

候选项：

纯文本 
billing
technical
account
other

模型在候选项中选择，并给出相关的概率分布和 confidence（置信度）。

它很适合：

  • 意图分类
  • Tool 选择
  • Agent 路由
  • 模型路由
  • Skill 选择

Noul：是非判断

Noul 可以简单理解成一个 Yes / No 命题的概率判断。

例如：

用户是否在要求退款？

返回的核心信息类似：

纯文本 
0.95

于是程序可以直接使用：

Python 
if refund_probability > 0.9:
    ...

它特别适合：

  • 是否相关
  • 是否危险
  • 是否需要人工
  • 是否完成目标
  • 是否应该保留某条信息

Score：连续量表评分

Score 用来判断某种属性的程度。

例如：

用户的不满程度有多高？

可以把它定义在一个连续量表上，比如：

纯文本 
0 ───────────────────── 10
完全平静              极度不满

模型返回评分，同时提供相应的概率分布和 confidence。

它可以用来衡量：

  • 相关性
  • 风险
  • 质量
  • 紧急程度
  • 复杂程度

因此，如果非要用一句大白话解释：

LLM 擅长回答和生成，Jev 擅长替程序做判断题。

二、LLM 已经会 Structured Output，为什么还需要 Jev？

这是理解 Jev 最重要的问题。

今天的 GPT、Claude 等模型完全可以可靠地输出符合 Schema 的 JSON。

比如：

JSON 
{
  "route": "coding",
  "risk": 0.2,
  "need_search": true
}

所以如果把 Jev 的卖点理解成：

“LLM 会乱输出，Jev 不会。”

其实会过度简化问题。

真正的区别在于二者优化的任务不同。

LLM 原生面向生成

大语言模型的基本工作方式是 Autoregressive Generation（自回归生成）。

简单来说：

纯文本 
输入
 ↓
生成 token 1
 ↓
根据前面的内容生成 token 2
 ↓
生成 token 3
 ↓
……

这是一个非常强大的设计。

因为只要最终结果能够表示成字符串，它几乎什么都能生成：

  • 文章
  • 代码
  • JSON
  • SQL
  • 对话
  • Tool Call

这种开放性，是 LLM 最强大的地方。

Jev 原生面向决策

Jev 则主动放弃了一部分自由度。

它并不试图生成任何可能的字符串，而是围绕有限类型的判断进行设计。

例如：

纯文本 
当前任务应该去哪？

A. search
B. coding
C. research
D. human

模型不会自己创造一个：

纯文本 
E. maybe_search_later

如果输出空间里没有这个选项，它就不能输出。

因此可以把二者简单理解成：

纯文本 
LLM

复杂输入
   │
   ▼
生成开放内容
   │
   ▼
文本 / 代码 / JSON / Tool Call

而 Jev 更接近：

纯文本 
Jev

复杂输入
   │
   ▼
在预定义空间中做判断
   │
   ▼
Choice / Noul / Score + 概率

需要特别说明：

“不会输出类型之外的结果”并不等于“不会判断错”。

例如候选项只有：

纯文本 
猫
狗
兔子

Jev 不会突然回答“河马”。

这是类型安全。

但它仍然有可能把猫判断成狗。

这是语义正确性。

两者不是一回事。

三、Jev 有哪些比较特别的特性？

理解 Jev，官方发布时强调的几个设计特点很重要。

1. 输出原生围绕有限类型设计

传统 LLM 即使最终返回结构化结果，本质能力仍然来自一个生成模型。

Jev 则从接口层面围绕：

纯文本 
Choice
Noul
Score

这样的判断原语组织。

所以它关注的不是：

“怎样把一段自由文本可靠地限制成 JSON？”

而是：

“程序究竟需要哪些决策变量？”

这是两种不同的设计思路。

2. 概率本身就是接口的一部分

例如：

这封邮件是不是紧急？

系统真正有价值的输出，不一定只是：

纯文本 
YES

还可能是：

纯文本 
0.97

这样程序就可以决定：

Python 
if p > 0.9:
    自动处理

elif p > 0.6:
    进入人工审核

else:
    普通处理

这意味着“不确定性”可以真正进入代码分支。

TypeSafe 把 calibrated probability（校准概率）作为 System One 的重要设计目标。

所谓校准，可以粗略理解为：

如果模型长期把一批判断预测为 80% 可信，那么这些判断实际正确的比例，也应该尽可能接近 80%。

当然，这不意味着某一个 0.8 的判断一定正确。

实际产品仍然需要用自己的业务数据测试阈值。

3. 一次可以进行很多独立判断

这是 Jev 一个很容易被忽略的特点。

LLM 生成文本通常是连续的：

纯文本 
token 1 → token 2 → token 3 → token 4

而很多 Jev 问题彼此之间并不存在这种依赖。

例如收到一封客服邮件，我们可能同时想知道：

纯文本 
是不是退款请求？

是不是技术问题？

是不是垃圾邮件？

用户是不是非常生气？

是否需要人工处理？

是否存在流失风险？

是不是紧急问题？

这些判断可以围绕同一个 State（状态）一起提出。

TypeSafe 把这种能力称为 parallel sampling（并行采样）。

这件事很重要，因为它意味着我们可以换一种方式设计 AI 软件：

不是问一个非常大的问题：

“请综合分析当前状态并决定下一步。”

而是同时获得很多比较小的语义信号。

后面再由代码组合。

4. 发布时输出侧不单独计费

按 TypeSafe 在 2026 年 9 月发布 Jev 时公布的价格口径：

纯文本 
输入：
每百万输入 token 0.042 美元

输出：
免费

官方原文对输出的描述是：

too cheap to meter

也就是输出侧成本低到没有单独计量。

这里更值得关注的不是具体价格。

价格以后完全可能调整。

重要的是背后的计算模式：

Jev 不需要像大语言模型一样连续生成几百、几千个输出 token。

主要工作发生在：

理解输入并做判断。

而不是：

把答案一个 token 一个 token 写出来。

5. 它针对低延迟判断设计

同样按照 TypeSafe 在 Jev 发布时公布的厂商数据，Jev 的端到端延迟大约在：

纯文本 
70～500 ms

TypeSafe 还公布过几十倍乃至更高的速度和成本提升。

但这些数字来自他们自己的特定 workflow benchmark（工作流评测），官方也明确说明，不应该把极端提升数字简单泛化到所有任务。

所以真正值得注意的不是：

“Jev 一定比 LLM 快多少倍。”

而是：

当一次语义判断便宜到足够频繁地调用时，我们可以把 AI 放进以前根本不会考虑调用模型的位置。

比如：

纯文本 
每个搜索结果

每次 Agent step

每次 Tool Call

每个 RAG chunk

每段日志

每条业务记录

这会带来完全不同的架构。

四、这种能力离普通人的日常软件并不远

先不讨论 Agent。

实际上，我们每天使用的软件里，到处都是这种：

人一眼可以判断，但普通规则很难准确表达。

邮件和消息整理

程序很容易知道：

纯文本 
谁发来的？
几点发来的？
有没有附件？

但下面的问题就困难很多：

纯文本 
这封邮件是不是很紧急？

对方是不是在等我回复？

这是通知还是需要我采取行动？

对方是不是明显不满意？

这里有没有一个隐含的 Deadline？

这些问题通常根本不需要 AI 写一篇分析。

系统可能只需要：

纯文本 
urgent              0.91
needs_reply         0.82
customer_unhappy    0.76
sales               0.04

然后普通程序决定：

Python 
if urgent > 0.8 and needs_reply > 0.7:
    放进优先处理队列

这里的 AI 不再是聊天机器人。

更像一个后台的“语义传感器”。

搜索

传统搜索很擅长解决：

哪些文档和这些关键词、向量比较接近？

但在真正使用搜索结果时，我们还经常需要回答：

这篇文档到底能不能帮助回答当前问题？

假设搜索系统拿到了 50 个候选结果。

我们未必要把 50 个全文全部交给昂贵的大模型。

可以先进行判断：

纯文本 
文档 A 对当前问题有帮助：0.94
文档 B：0.12
文档 C：0.87
文档 D：0.03

最后只让真正相关的结果进入后续流程。

这可以用于：

  • 网页搜索
  • 企业文档
  • 邮件
  • 聊天记录
  • 代码库
  • 日志
  • RAG（Retrieval-Augmented Generation，检索增强生成）

TypeSafe 官方也把 Search（搜索）、Retrieval（检索）和 Ranking（排序）列入 System One 的典型使用场景。

自然语言控制软件

再比如用户说：

“有点困了，把客厅弄舒服一点。”

如果家庭设备能执行的动作本身就是有限的：

纯文本 
房间：
客厅 / 卧室 / 厨房

灯光：
关闭 / 低亮 / 中亮 / 高亮

模式：
阅读 / 休息 / 睡眠

那么系统未必需要一个 LLM 先生成完整的智能家居计划。

可以直接判断：

纯文本 
room?
→ living_room

mode?
→ rest

brightness?
→ low

TypeSafe 官方的 Function Calling（函数调用）cookbook 展示的也是类似思路：对于函数名、枚举参数这类有限候选空间，可以把自然语言调用拆成多个判断问题，而不一定需要生成模型自由生成整个函数调用。

这其实意味着：

很多所谓的 AI 功能，最终可能只是“自然语言 → 类型化的软件操作”。

五、在 Agent 里，Jev 最值得关注的三个场景

如果把范围放到 Agent（智能体），Jev 的用途会一下子扩大很多。

但没必要列几十种场景。

大部分都可以归纳成三个问题：

去哪里？
什么信息值得留下？
当前结果够不够好？

场景一：Route——模型、Tool 和 Skill 应该选哪个？

现在一个 AI 产品经常同时拥有：

纯文本 
普通小模型
Coding Model
Reasoning Model
Search
几十个 Tool
大量 Skill
多个 Sub-Agent

问题是：

当前请求究竟应该交给谁？

现在很常见的一种实现方式，是再调用一个 LLM 来决定。

但如果输出空间本身已经明确：

纯文本 
general
coding
research
search
human

这其实就是一个典型 Choice。

例如：

纯文本 
用户请求
    │
    ▼
   Jev
    │
    ├── 简单问题 ──→ 小模型
    │
    ├── Coding ───→ Coding Model
    │
    ├── Research ─→ Research Agent
    │
    └── 高风险 ───→ Human

还可以同时判断：

纯文本 
complexity      0.31
need_search     0.93
need_code       0.04
risk            0.08

再让普通代码综合这些信号决定路线。

同样的思想也适用于 Tool 和 Skill。

假设一个 Agent 拥有：

纯文本 
300 个 Skill
500 个 Tool
几十个 MCP Server

没有必要每次都把全部定义塞给主模型。

可以先：

纯文本 
        用户请求
           │
           ▼
     第一层语义筛选
           │
    300 Skills → 8 个
           │
           ▼
      第二层精细判断
           │
           ▼
       1～3 个候选
           │
           ▼
          LLM

TypeSafe 官方的 Skill Suggestion cookbook 就展示了类似的二阶段 Skill 筛选方式。

这可以理解成：

Capability Discovery Layer，能力发现层。

场景二：Context——哪些信息值得进入和继续留在上下文？

如果真正使用过 Coding Agent，很容易遇到一个问题：

Context（上下文）会越来越长。

一次普通的修 Bug 可能经历：

纯文本 
用户描述问题
    ↓
搜索代码
    ↓
读取文件
    ↓
跑测试
    ↓
500 行错误日志
    ↓
继续读取文件
    ↓
修改代码
    ↓
再次测试

这些内容不断累积。

传统解决办法之一是 Summary（摘要）。

也就是让一个 LLM 把历史压成一段短文本。

但代码开发很依赖精确信息。

比如原始日志里有：

纯文本 
order-export.test.ts
Timeout 5000ms
src/services/orderExport.ts:42:19
authorization header

如果最后变成：

“之前订单导出测试失败了。”

大意没有错。

但真正有价值的定位信息可能已经丢失。

社区项目 fast-jev-compaction 提供了一种很有代表性的工程实践：

不重新总结历史，而是判断每一组 Tool Call / Tool Result 是否还有保留价值。

例如：

纯文本 
这个 Tool Call 以后还重要吗？

这个 Tool Result 的全文以后还需要吗？

最后：

纯文本 
结果重要
   ↓
完整保留

调用重要，但结果没必要全文保存
   ↓
保留调用，截断结果

两者都不重要
   ↓
删除

这和 Summary 有一个本质区别：

Summary 在重新描述历史。

这种方式是在决定：

历史应该保留多少。

如果继续向前推一步，甚至不一定要等 Context 塞满以后才做压缩。

每次调用 LLM 之前，都可以动态决定：

纯文本 
            所有候选信息
                  │
                  ▼
        ┌─────────────────┐
        │ Context Compiler │
        │  语义相关性判断   │
        └─────────────────┘
                  │
         ┌────────┼────────┐
         ▼        ▼        ▼
        保留     截断      忽略
         │
         ▼
        最小必要 Context
         │
         ▼
        LLM

这里的 Context Compiler（上下文编译器）是一个进一步的架构推演，不是 TypeSafe 官方产品名称。

但它背后的逻辑很直接：

Prompt 未必是一份固定文本，它可以是每次请求临时编译出来的一组最相关信息。

场景三：Verify & Control——结果对不对？还要不要继续？

Agent 里还有大量模型调用，本质上并不是为了产生新内容。

它们只是在问：

纯文本 
刚才有没有取得进展？

搜索结果够不够？

这个回答真的解决问题了吗？

还需要继续搜索吗？

应该重试吗？

要不要换策略？

是不是应该升级到更强模型？

这些问题都很像 Noul / Score。

因此一种新的 Agent 结构可能是：

纯文本 
                    ┌── relevant?
                    │
                    ├── enough?
Tool Result ─→ Jev ─┼── retry?
                    │
                    ├── stop?
                    │
                    └── escalate?
                           │
                           ▼
                       普通代码
                           │
                  ┌────────┴────────┐
                  ▼                 ▼
              下一步 Tool        强 LLM

也可以应用在模型级联上。

例如：

纯文本 
便宜模型
   │
   ▼
生成结果
   │
   ▼
  Jev
   │
   ├── 通过 ─────→ 直接使用
   │
   └── 有问题 ───→ 强模型重新处理

TypeSafe 官方的 Structured Data Extraction Cascade（结构化数据提取级联）cookbook 展示过类似模式：

纯文本 
mini model
   ↓
Jev verify
   ↓
必要时升级 reasoning model

这代表一种很实用的成本结构：

强模型不一定是所有请求的默认处理器，它可以成为困难情况的兜底处理器。

六、从“一个模型”到 Agent 的控制平面

把前面的场景继续归纳，可以发现 Jev 做的事情其实很统一。

类型 核心问题 常见例子
Route 去哪里？ 模型、Tool、Skill、Agent
Filter 要不要看？ 搜索结果、RAG、代码文件
Compact 要不要留？ Context、日志、Tool Result
Gate 要不要做？ Tool Call、风险动作
Verify 做对了吗？ 回答、引用、Patch
Control 下一步怎么办？ stop、retry、escalate

这些看起来是六种能力。

但本质上都是：

复杂语义输入 → 一个很窄的决策空间。

例如：

纯文本 
Route
→ A / B / C

Filter
→ yes / no

Compact
→ keep / drop

Gate
→ allow / block

Verify
→ supported / unsupported

Control
→ continue / stop / retry

这也是为什么 Jev 更像 Agent 的控制平面，而不是 Agent 的大脑。

可以画成：

纯文本 
                        用户
                         │
                         ▼
                  ┌────────────┐
                  │   Route    │
                  │  路由判断   │
                  └─────┬──────┘
                        │
            ┌───────────┼───────────┐
            ▼           ▼           ▼
          Tool         LLM        Agent
            │           │           │
            └──────┬────┴────┬──────┘
                   │         │
                   ▼         ▼
                 Filter     Gate
                  过滤       门禁
                   │         │
                   └────┬────┘
                        ▼
                     Execute
                       执行
                        │
                        ▼
                     Verify
                       验证
                        │
                ┌───────┼────────┐
                ▼       ▼        ▼
              Stop    Retry   Escalate
              停止    重试      升级

其中大语言模型依然承担最重要的复杂能力：

  • 规划
  • 解释
  • 写作
  • 代码生成
  • 多步推理
  • 开放式问题解决

Jev 做的则是另一类工作：

高频、封闭、需要语义理解，但不需要自由生成的判断。

Semantic Sensor：语义传感器

Jev 的并行判断能力还可以带来另一种设计思路。

传统 Agent 很喜欢问：

“请综合分析当前状态，并决定下一步。”

这里实际上把很多问题混在了一起。

另一种方式是一次得到很多独立信号：

纯文本 
goal_complete             0.21
made_progress             0.83
tool_result_relevant      0.94
need_more_context         0.72
contradiction_detected    0.08
user_constraint_violated  0.11
switch_strategy           0.63
escalate_model            0.41

再由程序决定：

Python 
if goal_complete > 0.85:
    finish()

elif contradiction_detected > 0.8:
    investigate()

elif switch_strategy > 0.7:
    replan()

这有点像给 Agent 装了一排 Semantic Sensor（语义传感器）。

普通软件已经有：

纯文本 
温度传感器
距离传感器
速度传感器

未来的 AI 软件可能还会拥有：

纯文本 
相关性传感器
风险传感器
完成度传感器
冲突传感器
意图传感器

每一个传感器都只回答一个很窄的问题。

代码负责把这些信号组合起来。

这比让一个 LLM 同时承担感知、判断、计划和控制，更接近传统软件工程中的职责分离。

七、它做不了什么？

看到这里，很容易产生另一个误解：

那以后是不是很多 LLM 都不需要了？

并不是。

Jev 主动放弃自由生成，本身就意味着非常明确的能力边界。

不适合开放式生成

例如：

帮我写一篇关于 Jev 的文章。

应该使用 LLM。

而不是 Jev。

不适合复杂、多阶段推理

如果一个任务需要：

纯文本 
理解问题
 ↓
建立假设
 ↓
推导
 ↓
寻找反例
 ↓
修正假设
 ↓
继续推理

这更适合 Reasoning Model（推理模型）。

不应该拿语义模型代替确定性代码

例如：

纯文本 
13892 × 7123

直接计算。

再比如：

纯文本 
2026-09-18 是否早于 2026-09-23？

直接比较日期。

没有理由叫 AI。

TypeSafe 官方也明确指出 Jev 1.13 在数学、计数、日期比较和多层间接推理等方面存在明显边界。

更多 Context 不一定更好

这是另一个重要特点。

很多人使用 LLM 的第一反应是：

不确定怎么办？再塞更多 Context。

但对于判断模型，大量无关内容反而可能干扰结果。

因此实际使用时，更重要的是：

给它判断真正需要的信息。

这也是为什么 Filter、Retrieval 和 Context Compiler 这类思路会非常重要。

概率不能替业务承担责任

假设模型判断：

纯文本 
删除这个账户是否安全？

0.96

也不意味着代码就应该：

Python 
if p > 0.9:
    delete_user()

高风险、不可逆行为仍然应该依赖：

  • 权限系统
  • 硬规则
  • 审批
  • 人工确认
  • 事务
  • 回滚机制

概率适合帮助系统分流。

它不是安全证明。

八、真正值得关注的，也许不是 Jev 这个产品本身

Jev 最终是不是会成为主流，现在还很难判断。

未来也可能出现更多类似的：

纯文本 
System One Model
Decision Model
Jev-like Model
Semantic Classifier

真正值得关注的是它代表的工程思想。

过去几年，我们很容易把所有带一点“智能”的问题都扔给 LLM。

Tool 不知道怎么选？

让 LLM 选。

搜索结果不知道有没有用？

让 LLM 判断。

答案不知道对不对？

再调用一个 LLM Judge。

下一步不知道怎么办？

继续让 LLM 想。

系统最后容易变成：

纯文本 
LLM
 ↓
Tool
 ↓
LLM
 ↓
LLM Judge
 ↓
LLM
 ↓
Tool

一个模型同时承担：

  • 生成
  • 路由
  • 判断
  • 验证
  • 控制

而 Jev 背后的思路，是把这些能力重新拆开。

纯文本 
需要生成
   │
   ▼
  LLM

需要复杂推理
   │
   ▼
Reasoning Model

需要语义判断
   │
   ▼
  Jev

需要精确计算
   │
   ▼
  Code

需要执行副作用
   │
   ▼
  Code

高风险决策
   │
   ▼
 Human

这其实是一个非常朴素的软件工程原则：

不同的问题，交给不同的组件。

最终可能形成这样的架构：

纯文本 
                  用户输入
                     │
                     ▼
              ┌─────────────┐
              │ Jev：判断层  │
              │ 路由/过滤/门禁│
              └──────┬──────┘
                     │
          ┌──────────┼──────────┐
          ▼          ▼          ▼
         Code       LLM        Tool
       确定逻辑   生成与推理     执行
          │          │          │
          └──────────┼──────────┘
                     ▼
              ┌─────────────┐
              │ Jev：验证层  │
              └──────┬──────┘
                     │
                     ▼
                Code 决定下一步

所以我觉得最值得记住的，并不是：

“Jev 是一个速度更快的模型。”

也不是：

“Jev 是一个更便宜的 LLM。”

而是：

软件过去很擅长计算数字、判断精确条件、执行确定性逻辑，却很难直接判断“意思”。

例如：

纯文本 
这封邮件紧不紧急？

这个结果相不相关？

用户是不是在拒绝这个方案？

这份证据是否真的支持这个结论？

这个 Agent 有没有完成任务？

这段历史以后还有没有价值？

这些事情对人来说很自然。

对传统程序却很难表达。

大语言模型让计算机第一次能够较好地理解这些语义。

Jev 代表的进一步尝试，则是：

不要每一次都让 AI 写一篇答案。

有时候，我们真正需要的只是：

纯文本 
if meaning:
    do_something()

如果这种判断未来能够做到足够快、足够便宜、足够稳定，那么 AI 进入软件的方式可能会发生一个很重要的变化。

过去我们是在软件旁边放一个：

AI 助手。

未来，我们可能开始直接在软件内部使用：

AI 判断。

这两者并不是同一件事。

前者是让软件调用一个会聊天、会生成内容的智能体。

后者则意味着：

语义理解本身开始成为软件的一种基础能力。

最后，用一句话概括这种分工：

LLM 负责想和写，Jev 负责判，代码负责做。

这不是说三者之间存在绝对边界。

它更像一种工程上的职责划分：

把生成和复杂推理交给 LLM，把高频、封闭的语义判断交给 Jev，把确定性逻辑和最终控制权留给代码。

如果这种分工最终成立，那么 Jev 真正可能改变的，并不是某一个 AI 产品。

而是我们写 AI 软件的方式。

参考资料

本文采用 CC BY-NC-SA 4.0 协议许可，转载请保留原文链接及作者。