企业官网建设流程全解析

• AI 应用
• 大模型
• 交互助手
• RAG

Jev 聊天助手（jev-chat-jarvis）是一个三端并行的开源对话副驾项目：只读屏幕、不注入、不 hook、不替你发送。本文以仓库根目录的 CONTRIBUTORS.md 为核心骨架，梳理该项目的维护者分工、三端支持范围、采集架构差异、贡献者必须遵守的三条红线、认领与自测流程，并结合 Android 主入口仓库的源码（采集适配器、OCR 兜底、输入回填、无障碍伪装、前台保活）逐条给出实现级证据。读完本文，你将清楚这个项目"谁在做哪一部分、各端怎么采、哪些改动会被拒绝、以及作为新贡献者从哪里入手"。

项目定位：一份名单背后的三端架构

CONTRIBUTORS.md 开篇即明确：Jev 聊天助手是一个三端并行的开源项目，只读屏幕、不注入、不 hook、不替你发送。这份名单记录谁在做哪一部分，方便使用者知道该找谁，也方便新贡献者找到入口。

从维护者与分工表格可以看到项目的组织形态——主仓库之外的姊妹项目同样归在同一个组织下：

Android 仓库（当前仓库）是主入口，macOS 与 Windows 为独立仓库。当前仓库内的 README.md 同样印证了这一结构：macOS 版"看屏 + 本地小模型判断意图和风险，再按话术生成回复候选，纯只读"；Windows 版"聊天窗口旁挂的回复辅助，窗口截图 + 本地离线 OCR，3 条候选一键填入，发送永远手动"。

三端支持范围：同一套内核，不同的采集方式

CONTRIBUTORS.md 给出三端当前覆盖范围：

关键结论是：三端共用同一套判断内核，差异在采集方式——Android 走无障碍节点加离线 OCR，macOS 与 Windows 走屏幕录制加 OCR。这一点在当前 Android 仓库源码中可以得到完整印证：

• 按包名分发的适配器机制：ChatCaptureService.kt 中adapters以包名为键注册了QQAdapter()、XAdapter()、FeishuAdapter()三个适配器，服务按前台包名分发，适配器只负责把当前窗口变成统一的"标题 + 消息列表（谁说的、说了什么）"，下游判断、候选、悬浮窗、填入全部通用。
• 适配器的三态契约：ChatAppAdapter.kt 中接口extract(root, res)的返回语义是：null表示不在聊天窗（服务完全不动作）；消息列表为空表示在聊天窗但树里没有正文（服务可走截屏 + OCR 兜底）；消息非空表示正常采集。这正是"飞书支持 OCR 兜底"和"其它未适配 App 支持手动截屏识别一次"在代码层的落点。
• QQ 全链路：QQ 节点不混淆（9.3.50 实测），正文是带id/mjn的 TextView，聊天输入框id/input作为"是否在聊天窗"的判据；因为 QQ 全程只有一个 Activity，判"是不是聊天窗"只能看树里有没有该有的节点，不能看 Activity 名。发送方按气泡贴近哪侧头像列判断（我侧在右约 width−156，对方在左约 13% 宽度）。
• X / Twitter 私信全链路：X 是 Compose 界面，消息整行没有 resource-id、text 为空，内容全部在contentDescription里（如"你：…。8:11 上午。Read。"），适配器解析分隔符、时间戳与 Read 标记后还原出发送人与正文；发送方来自"你 / You"标签而非几何位置。
• 飞书 OCR 兜底：飞书正文是自绘控件，树里只有气泡矩形bubble_content_container，适配器把矩形与"已读状态"（只有自己的气泡带time_read_state_container_align_bubble）上报进快照，服务随后对每个矩形做离线 OCR。
• 微信已全面下架：从源码看，ChatCaptureService.kt 的adapters列表只挂 QQ、X、飞书三个适配器，WeChatAdapter虽保留在 ChatAppAdapter.kt 中但并未接入；前台是微信时只弹一次性"微信已限制读取，请在别的软件上使用"提示，绝不读树、不截屏、不 OCR、不填入。这与 README.md 中"微信 Android 版已全面下架，不提供微信采集与分析"的说明一致。

三条项目红线：破坏任何一条的改动都不会被接受

CONTRIBUTORS.md 明确指出，任何被破坏这三条红线的改动都不会被接受：

1. 纯只读：不注入目标 App、不 hook、不解密数据。
2. 发送永远手动：程序不替你按发送键，填入只是把候选放进输入框。
3. 只处理你自己有权查看的聊天。

这三条红线并非口号，Android 仓库的源码与配置可以逐条对应：

• 纯只读的实现证据：
  • 无障碍服务声明在 AndroidManifest.xml 中，权限仅有INTERNET、SYSTEM_ALERT_WINDOW、前台服务与通知相关权限，没有任何 root / Xposed / 改包所需的声明；采集完全依赖系统无障碍服务暴露的界面内容，与读屏软件工作方式相同。
  • 无障碍配置 config_disguised.xml 只申请canRetrieveWindowContent（读取窗口内容）与canTakeScreenshot（截屏），没有注入或修改目标 App 的能力。
  • 值得注意的实现细节：服务类名伪装为系统风格的 SelectToSpeakService.kt（继承ChatCaptureService，所有逻辑都在父类），注释明确说明"伪装是穿过微信节点混淆的手段"；即便这样，微信仍被整体下架，可见项目对"只读"边界的克制。
• 发送永远手动：服务唯一的写操作是ACTION_SET_TEXT（或剪贴板粘贴兜底）把回复填进输入框。GuardedInputWriter.kt 的填写序列是"setText → 150ms 校验 → focus → 重试 setText → 校验 → 复制到剪贴板 → 清空 → paste → 校验"，全程不触发发送动作；ChatCaptureService.kt 中fillInput成功时提示"已填入，确认后自己发送"。测试 GuardedInputWriterTest.kt 覆盖了会话切换中途停止写入、粘贴兜底等场景，验证"不发送"是经过测试保证的行为。
• 只处理你有权查看的聊天：采集发生在当前活动窗口（rootInActiveWindow），适配器每次先确认"是不是聊天窗"，服务还校验会话标题是否在用户白名单内（prefs.isAllowed）；离开聊天界面或切到系统 UI / 桌面即收起悬浮窗。

贡献者名单与各端分工

CONTRIBUTORS.md 的贡献者部分按职责分组：

• 测试：HeiGeAi 负责三端真机验证与问题复现，覆盖 Android、macOS、Windows 的日常使用场景。
• Android：Finderchangchang（同时也是主维护者）。
• macOS：eatmoreduck、shanyazhou、baishatan、xixikaixin、liubai00。
• Windows：rezoch340。

从三端测试的覆盖面可以推断，这是一个"三端共核、各自适配"的协作模式：测试岗位横跨三个仓库，说明三端共享同一套判断内核与验收标准。仓库内 docs/acceptance.md（验收标准文档）正是这种公共尺子的体现，它要求"建者不自证，贴真实输出"：

• 构建（A）：assembleDebug零 error，产物app/build/outputs/apk/debug/app-debug.apk存在。
• Jev 判断层（C）：运行python tools/jev/calibrate.py，输出每道题在标注集上的命中率表格与置信度分布；要求标注集不少于 20 条中文对话片段、danger_level打分与人工标注的平均绝对误差 < 1.0 档、true_intent/she_needs命中率 ≥ 60%、全部请求 HTTP 200 且无 key 泄漏到 stdout。
• 真机冒烟（D）：对方新消息 1.5 秒内悬浮窗出现分析且候选 ≥ 3 条已排序；点"填入"后输入框出现文本且未发送；自己发的消息不触发、切换会话上下文重置、App 切后台悬浮窗隐藏；密钥不出现在 logcat、断网给可读错误不崩溃；10 分钟静默期 Jev 调用次数为 0。

这条验收标准与三条红线一一咬合：tools/jev/calibrate.py与 tools/jev/ 目录下的 Python 脚手架（calibrate.py、questions.py、jev_client.py等）支撑"判断层校准"，真机冒烟中的"填入后未发送"则直接验证红线 2。

想参与：认领、自测与流程约束

CONTRIBUTORS.md 给出参与规则的核心：贡献流程、认领规则与自测要求写在 macOS 仓库的 CONTRIBUTING.md（同样适用于另外两端）：先认领再动手、一个 PR 只做一件事、改哪层跑哪层的自测。联系与需求反馈走公众号私信，或加入交流群（见各仓库 README）。

对 Android 主入口仓库而言，"改哪层跑哪层的自测"可以落到具体位置：

• 改采集适配器：涉及 ChatAppAdapter.kt，需在 ChatCaptureService.kt 的adapters注册，并按 README 的建议先用adb shell uiautomator dump观察目标 App 暴露的节点；适配器返回null（不在聊天窗）与返回空消息列表（在聊天窗但树里没正文）的语义区别是关键——只有后者会触发 OCR 兜底。
• 改输入回填：涉及 GuardedInputWriter.kt 与 ChatCaptureService.kt 的fillInput，配套单测在 GuardedInputWriterTest.kt，会话状态相关单测在 ConversationSessionTest.kt。
• 改判断层：涉及 tools/jev/ 的题目集与校准脚手架，自测跑python tools/jev/calibrate.py并对照 docs/acceptance.md 的 C 项指标。

许可证与名称使用限制

CONTRIBUTORS.md 最后说明：代码以 MIT 协议开源；使用名称或域名时不得暗示由原作者出品或背书，详见各仓库根目录的 NOTICE。本仓库 NOTICE 的完整约定是：允许个人和商业使用、修改、再分发、集成进自有产品，无需付费或事先授权；分发或商用时必须保留 LICENSE 与 NOTICE，并在产品「关于」页、说明文档或发布页注明出处（推荐写法：基于 Jev 聊天助手二次开发 / 集成）；不得使用「Jev 聊天助手」「jev-chat」名称或官网域名暗示由原作者出品或背书。这与 README.md 的版权与许可章节一致。

小结：从名单到工程原则

CONTRIBUTORS.md 表面上是一份贡献者名单，实质上是项目的协作契约与架构说明书：三端共用判断内核、按采集方式分工（Android 无障碍节点 + 离线 OCR，桌面端屏幕录制 + OCR）；三条红线作为验收的硬约束（纯只读、发送永远手动、只处理有权查看的聊天）；认领、单 PR 单任务、分层自测作为流程约束。新贡献者可以从 README.md 的"适配一个新的聊天 App"小节入手（在 ChatAppAdapter.kt 实现适配器并注册到 ChatCaptureService.kt），再以 docs/acceptance.md 的构建、判断层校准与真机冒烟标准验证自己的改动——只要不碰三条红线，改动就有被接受的余地。

• AI 应用
• 大模型
• 交互助手
• RAG