拆解开源"Jev 聊天助手"：读屏、判断、候选回复的三段式架构

社区里把 Jev 接微信最成熟的产物，是一类开源的"Jev 聊天助手"。我把它的公开说明梳理了一遍，发现它值得讲的不是噱头，而是一套挺清晰的工程架构：读屏、判断、起草回复三段分工。这篇就从技术角度拆解它怎么搭起来的、每一段各司其职做什么、以及非侵入设计为什么重要。文中架构据开源项目公开说明整理，官方口径数据可核实，Jev 仍处早期访问阶段。

Jev 是 TypeSafe AI 推出的高速低成本 AI 判断器，区别于 ChatGPT、Claude 这类生成式大模型，它不做自由问答、文案创作和代码编写，核心定位是软件或 AI 系统中的专用判断组件：输入当前状态加上固定候选选项或评判标准，输出确定性选择（Choice）、量化打分（Score）或真伪概率（Noul）。核心优势是决策 70～500ms、输入 0.042 美元每百万 token 且输出免费、专注封闭式判断规避幻觉、承接大模型的琐碎判断从而降本增效。

一、痛点：把整段对话丢给大模型，慢贵还难落地

如果直接把聊天对话整段丢给大模型，让它又理解又回复，会遇到几个问题：逐字生成慢，成本高，输出还难以直接驱动下一步动作。而且用关键词规则做自动化，对方换个说法就失效。真正好用的聊天辅助，需要把"理解判断"和"生成回复"这两件事分开做。

二、三段式架构：读屏、判断、起草

Jev 聊天助手的核心，是把工作拆成三段，各用最合适的技术。

下面这张图是它的整体架构：

开源 Jev 聊天助手的三段式架构

第一段是读屏取对话。它不去动聊天软件本身，而是通过系统的无障碍服务读取当前屏幕上显示的对话内容；遇到无障碍读不到的情况（比如某些界面把文字画成图像），就对气泡截图，用本地离线 OCR 把文字识别出来，图片不上传。这样拿到对话，而不触碰任何数据库或账号。

第二段是 Jev 判断。把读到的对话作为状态交给 Jev，一次性回答几道判断题：对方大概想干嘛、危险或风险等级多高、该不该马上回、最好怎么应对。这一步大约一秒出结果，且因为是封闭判断，输出稳定、不越界。

第三段是生成模型起草候选。判断清楚之后，由一个生成模型（社区常用 DeepSeek 等）起草几条口语化的候选回复，再由 Jev 按"最合适"给这几条排序，展示在悬浮窗里。判断归 Jev、生成归大模型，分工明确。

三、关键设计：非侵入与只填不发

这套架构里有两个设计我觉得最值得学。

一是非侵入。它不 hook 聊天软件、不重打包、不读取聊天数据库，只靠读屏获取当前显示的内容，密钥也只存在本机。这让它在合规和安全上比那些改包外挂稳健得多。

二是只填不发。候选回复选中后只填入输入框，绝不自动发送，发送权永远在用户手里；它也不碰转账、红包、收款这类敏感操作。这是把"能力"和"责任"分清楚，AI 提供判断和候选，人来做最终决定。

架构上还有个便利：因为读屏和判断是通用的，接入一个新的聊天 App 往往只要写一个几十行的适配器，把"怎么取到当前对话"补上即可，后面的判断、起草、排序逻辑都能复用。

四、边界与合规

必须说清楚：这类工具的正当用法是"辅助判断"，不是"自动操控微信"。自动读取、自动代发微信消息属于违规，有触发风控、封号的风险。开源项目普遍强调只填不发、非侵入，正是为了守住这条线。

技术上也有边界：Jev 的中文适配偏弱，官方也承认，OCR 识别可能出错字或判错收发方向；判断可能失误。所以它给的是参考，不是定论。

五、避坑与落地建议

先说能力边界：Jev 不做计数、精确计算、日期换算、开放式创作和无边界推理，这些不该指望它。落地建议三条：一是三路接口（判断、生成、视觉）分开配置，判断用 Jev、生成用合适的大模型，各选各的；二是先在少量会话上验证判断质量再扩大范围，中文场景尤其要先测；三是始终保持"只填不发、发送权在人"，涉及隐私的对话谨慎开启。把读屏、判断、生成三段拆清楚，各用最合适的技术，这套架构才既好用又守得住底线。