Jev 聊天助手 - 手机端对话副驾 AI 回复建议工具

解决什么

在社交对话场景中,用户常面临三大痛点:不知道对方真实意图、不确定该如何回复、担心回复不当引发风险。Jev 聊天助手通过 AI 技术提供"先判断后回复"的解决方案:它读取手机屏幕上的聊天内容,先用判断模型分析对方真实意图、危险等级(1-9级)和最佳应对策略,再根据分析结果生成 3 条候选回复并排序。整个过程不修改聊天软件、不自动发送消息,只把回复填入输入框,发送权完全由用户掌控。

为何火

该项目在 GitHub 上线 12 天即获得 7293 星,核心原因有三:一是技术路径独特,采用 Android 无障碍服务读取屏幕内容而非 hook 或逆向,规避了封号风险;二是功能设计贴合国内用户需求,支持 QQ、X(Twitter)、飞书等主流平台,并提供本地知识库与联系人档案功能;三是隐私保护到位,所有数据存储在本机 App 私有目录,密钥和聊天历史不上传云端,OCR 识别也在本地完成。此外项目提供 Android/Windows/macOS 三端支持,降低了跨平台使用门槛。

核心功能

两阶段 AI 分析:判断模型先输出对方意图、危险等级、是否需要立即回复等信息(约 1 秒),再由生成模型起草 3 条口语化候选回复,最后判断模型按适配度排序。这种设计避免了直接生成回复可能出现的偏离语境问题。

多平台适配:QQ 通过无障碍读取节点全链路支持,X/Twitter 私信解析 Compose 节点,飞书因正文自绘采用 ML Kit 离线 OCR 识别。未适配的 App 可手动触发整屏 OCR(微信除外)。

知识库与联系人系统:用户可添加笔记(支持标签与常驻设置)和联系人档案(姓名/别名/关系),分析时自动匹配相关背景信息。可选开启聊天历史记录(默认关闭),带上最近 30 条消息提升上下文理解。

灵活接口配置:判断/回复/视觉三路接口独立配置,内置 OpenRouter、博查 Jev、TypeSafe、Vercel、OpenCode Zen、DeepSeek 官方、通义兼容等预设,每张卡支持一键连通测试。只配置判断接口时,其余两路自动继承密钥。

安装

下载仓库中的 APK 文件(需 Android 11+ 且 ARM64 架构),通过 adb 或直接安装:

adb install -r apk/jev-assistant-v1.4-release.apk

安装后需完成三步配置:1)在设置中填入 API Key(最简单方式是只填 OpenRouter 密钥);2)开启无障碍服务、悬浮窗权限;3)小米/HyperOS 用户需额外开启自启动与省电白名单。升级到 1.3+ 版本后需重新开启无障碍服务以激活截屏能力。

适合谁

社交重度用户:频繁使用 QQ、飞书或 X 私信,需要快速响应但又担心回复不当的职场人士或客服人员。

隐私敏感用户:不愿使用需要登录账号或上传聊天记录的第三方服务,希望数据完全本地化处理的用户。

多场景切换者:需要在不同社交场景(工作/私人/客户)维护不同人设,依赖知识库与联系人档案功能保持回复一致性的用户。

不适合:iOS 用户(目前仅支持 Android)、微信 Android 用户(已明确不支持)、无法访问海外 API 服务的用户(国内 Gemini/OpenAI 受区域限制,需使用 OpenRouter 等中转或国内模型)。

社区评价

暂无足量社区公开讨论,以下为基于项目本身的中立评估:

从技术实现看,该项目采用无障碍服务而非逆向工程的路径较为稳妥,但这也带来局限性——依赖各平台 UI 结构稳定性,聊天软件更新可能导致适配失效。飞书采用 OCR 补正文的方案说明无障碍 API 覆盖不全,OCR 准确率和性能开销是潜在风险点。

从隐私角度看,项目承诺本地存储且不自动发送是加分项,但用户配置的第三方 API 服务商(如 OpenRouter)会接收聊天内容,这部分数据流向取决于服务商隐私政策,项目文档已明确告知但仍需用户自行评估风险。

功能设计上,"先判断后生成"的两阶段流程理论上优于直接生成,但实际效果取决于判断模型质量。内置多个 API 预设降低了配置门槛,但对普通用户而言仍需理解 API Key 获取流程,且部分服务(如 OpenCode Zen 的 jev-1.13 模型)按 token 计费,长期使用成本需考量。

选型对比

vs 商业聊天助手(如 ChatGPT 官方插件):Jev 完全开源且本地化,无需订阅费用,但需自备 API Key 且配置门槛较高。商业方案通常提供开箱即用的体验和客服支持,但数据必须上传云端。

vs 其他开源聊天机器人(如基于 Xposed 的微信插件):Jev 不依赖 root 或框架,兼容性更好且封号风险低,但功能范围受限于无障碍 API 能力,无法实现自动发送、消息撤回等深度操作。Xposed 方案功能更强大但需要解锁 bootloader 且存在检测风险。

vs 纯 OCR 方案(如 Talon):Jev 优先使用无障碍服务获取结构化数据,仅在必要时(如飞书)才启用 OCR,效率和准确率更高。纯 OCR 方案通用性强但性能开销大且易受界面变化影响。

取舍关键:如果追求零配置与云端便利选商业方案;需要深度控制且接受刷机风险选 Xposed;在意隐私、不想 root、能接受 API 配置成本则选 Jev。

已知坑

平台限制:QQ 仅在 9.3.50 版本实测群聊场景,1v1 按结构推断未充分验证;X 私信仅测试中文界面,英文界面未验证;飞书依赖 OCR 识别正文,复杂排版或多语言混合可能识别错误。

设备兼容性:仅支持 ARM64 架构,老旧设备或 x86 模拟器无法运行。小米/HyperOS 系统需手动配置自启动与省电白名单,否则后台冻结导致无法实时读取消息。重装 App 后悬浮窗权限会被重置。

API 依赖:国内直连 OpenAI/Gemini 受区域限制,必须使用 OpenRouter 等中转服务或国内模型。判断模型推荐 gpt-4o 或 gemini-2.0-flash-thinking-exp-1219,回复模型默认 deepseek-chat-v3.1,但模型选择直接影响分析质量和成本,需根据实际场景调优。

隐私边界:虽然本地存储,但聊天内容会发送到用户配置的 API 服务商,服务商的数据处理方式不受项目控制。开启聊天历史记录后,敏感对话会持久化存储在本机,卸载 App 前需手动清空。

功能局限:不支持自动发送(设计如此),不支持微信 Android 版(已明确放弃),未适配的 App 只能手动触发 OCR 且无法区分"我/对方"。OCR 有限频机制,快速滚动聊天记录时可能漏识别部分消息。