有人拿Jev给聊天软件配了个AI副驾——读懂对方意图,但不替你发

TypeSafe 最近开源了他们叫 "System One Model" 的东西——Jev，一个放弃字符串生成、直接输出类型安全概率化决策的模型，专为软件里的分类/路由/打分这类活儿而生。

当然，把 Jev 理解成"一次函数调用级别的智能"最直观：输入非结构化状态，输出类型安全的概率化决策，像句代码一样直接塞进软件里用。和主流 LLM 最大的不同是它干脆 "放弃了字符串生成"—— 不吐文字、不生成 token 序列，而是平行地一次性输出所有结构化结果。所以它没有幻觉，也不会犯类型错误（输出结构预先定义死，模型永远不可能写出类型不对的值），每次回答还自带校准过的置信度。

Jev 的命名也挺有意思。System One 取自卡尼曼《思考，快与慢》里主导直觉的 System 1；Jev 则来自经济学家威廉・斯坦利・杰文斯 —— 杰文斯悖论说蒸汽机效率提升反而让煤炭需求暴增。TypeSafe 想借这个名字表达：智能成本每降一个数量级，就会解锁更多数量级的使用场景。这个逻辑成立与否，要看 Jev 是不是真如宣传的那样，能在真实生产里替掉那些手写的脆弱规则。

当时大家对 Jev 还停留在"能干什么"的概念层面。现在有人把它接进真实场景了：GitHub 上今天冒出来的 Kotlin 项目 jev-chat-JARVIS，用 Jev 做了一台聊天副驾——浮在你正在用的聊天窗口旁，读懂对方意图，给你几个候选回复，填进输入框，发送始终由你自己点。

它把 Jev 用在了最合适的地方。判断模型不擅长聊天和写长文，但"判断对方在说什么、危险等级多高、该不该马上回、该用哪种动作回应"，恰恰是 Jev 那套"分类/打分/路由"最擅长的。项目里这一步是：Jev 一次请求把所有题目发出去，约 1 秒返回；然后一个生成式模型（默认 DeepSeek）起草 3 条候选回复，再让 Jev 给这 3 条排序，最后半透明悬浮窗展示。判断模型做分析和排序、生成模型做起草，各干各擅长的——这正是 System One Model 设计之初想被用到的样子。

微信 / QQ / 飞书聊天 ──(无障碍读节点)──▶ 采集最近消息                                  │              ┌───────────────────┴───────────────────┐              ▼                                        ▼   Jev 判断（一次 7 道题）                    生成模型起草 3 条候选   意图 / 危险 / 需求 / 动作 / 该不该回          │              └───────────────────┬───────────────────┘                                  ▼                        Jev 给 3 条候选排序                                  ▼                半透明悬浮窗展示 → 复制 / 填入（不发送）

采集层是另一套功夫，走的是"非侵入"路线：不 hook、不改包、不走 App 的 API，只从屏幕的无障碍服务里读当前正在显示的对话。所以换平台换的只是采集方式，判断和生成那套内核不用动。微信（Android）是第一站已经跑通，手机 QQ 适配器接进来了，飞书采集分发已接入但正文是自绘控件、要走截图加 OCR（还在补）。微信 8.0.52+ 会混淆无障碍节点，项目把服务类名伪装成系统自带的 SelectToSpeakService 才读得到气泡（实测 8.0.78 有效）；QQ 节点不混淆，照着 id 写就行。

TypeSafe 之前那句"智能成本每降一个数量级，就会解锁更多数量级的使用场景"，在这个项目里有点落地的意思。Jev 便宜到输入 token 每百万 $0.042、输出免费、响应 70ms 到 500ms，这让"给任意聊天都配一个持续在线的实时分析层"这件事在成本上变得可行——不再是高端玩家才玩得起的架构。

一个值得注意的细节是它把边界划得很清楚：程序只读消息、只把回复填进输入框，从不自动发送，明确写着"不碰转账/红包/收款"。对一个能读你聊天内容的工具，这个自我约束大概是它敢开源的底气。

来源：

• • jev-chat-JARVIS - GitHub
• • Introducing System One Models & Jev - TypeSafe AI Blog
• • TypeSafe Jev