AI 應用大模型交互助手RAG【免費下載鏈接】jev-chat-jarvis裝在手機上的對話副駕在 QQ / X / 飛書里讀懂對方、給出候選回復、一鍵填入輸入框發(fā)不發(fā)由你。非侵入只讀屏幕不 hook 不改包。項目地址https://gitcode.com/gh_mirrors/je/jev-chat-jarvis點擊查看免費下載本文基于倉庫內(nèi) docs/v1.3-plan.md 總方案文檔結合 docs/v1.3-morning-checklist.md 與當前倉庫源碼app/src/main/java/com/jev/probe/展開。Jev Assistant 是一款只讀屏幕、絕不自動發(fā)送的 Android 對話副駕它在 QQ / X / 飛書里讀懂對方、給出候選回復、由用戶一鍵填入輸入框。v1.3 版本的核心命題有三把判斷 / 回復 / 視覺三路模型接口全部做成可配置并帶連通測試、引入本地知識庫與聯(lián)系人關聯(lián)上下文、為讀不到控件樹的 App 提供截屏 OCR 采集通道。讀完本文你將完整掌握 v1.3 的配置契約、知識庫數(shù)據(jù)模型與檢索規(guī)則、OCR 分層與截屏防連射機制以及每一階段的驗收標準。一、v1.3 要解決什么問題四大目標與階段編排v1.3 總方案為一次多階段升級目標拆為四條原文逐條保留API 自定義判斷 / 回復 / 視覺三路接口的地址、密鑰、模型全部可配帶預設與各自連通測試。知識庫 關聯(lián)上下文用戶可維護本地知識庫筆記 聯(lián)系人檔案每次分析自動帶上對該聯(lián)系人的歷史記錄與相關知識回復與知識庫一致聯(lián)系人跨 App 關聯(lián)別名。OCR 采集讀不到控件樹的 App飛書正文、任意未適配 App走截屏 OCR已適配 App 樹讀空時 OCR 兜底。版本與發(fā)布版本號升到 1.3出 release 包README 更新。階段順序與依賴被嚴格固定為AAPI→ D知識庫 / 上下文→ BOCR→ C文檔 / 發(fā)布每個階段由一個執(zhí)行 agent 順序做完、構建通過再進下一階段方案文檔特別強調(diào)同一時間只有一個 agent 改代碼gradle 與文件都會沖突。每階段結束后需寫_reports/v13_階段_report.md內(nèi)容固定為改了什么逐文件→ 構建輸出末尾原文 → 裝機結果 →自驗缺口。二、硬約束隱私與兼容的紅線v1.3 沿襲項目既有約束并新增三條方案原文絕不自動發(fā)送、不碰錢、密鑰不落盤不進日志不進 git、UTF-8、禁 git commit/push。所有用戶數(shù)據(jù)知識庫、聯(lián)系人、歷史記錄只存 App 私有目錄提供清空按鈕聊天正文不進 logcat。舊配置必須自動遷移升級后原來的 OpenRouter 密鑰、回復模型、關系描述、白名單、透明度、開關全部保留可用。技術棧約束傳統(tǒng) View XML不引 Compose不引 Room用 JSON 文件 內(nèi)存緩存即可ML Kit 只在 B 階段引入。從源碼看這些約束是真實落地的KbStore.clearAll()只刪除filesDir/kb目錄源碼注釋明確API keys, whitelist and every other SharedPreferences value are untouched聊天正文從不進日志——ChatCaptureService.kt 中連調(diào)試日志都只打印side 文本長度。三、公共契約Prefs 配置字段全表v1.3 的第一份公共契約是Prefs 新字段A 階段建、后續(xù)階段只讀。以下字段、默認值與說明均繼承自方案文檔并已對照源碼 Prefs.kt 逐一核實3.1 判斷接口Jev字段類型默認值 / 說明judgeProviderStringopenrouter \| typesafe \| custom默認openrouter。從當前倉庫源碼看實際取值集合已擴展為bocha / openrouter / typesafe / vercel / zen / customPrefs.PROVIDER_*常量judgeBaseUrlStringopenrouter 默認https://openrouter.ai/apitypesafe 默認https://api.typesafe.aijudgeKeyString遷移老openRouterKey→judgeKeyjudgeModelStringopenrouter 默認typesafe/jev-1.13typesafe 默認jev-latest判斷接口的請求路徑規(guī)則方案原文 Prefs.kt 的judgeEndpoint()實現(xiàn)一致openrouter → {judgeBaseUrl}/alpha/decisions typesafe → {judgeBaseUrl}/v1/systemone custom → 用戶填完整 URL 到 judgeBaseUrl原樣 POST請求體三者相同{model, state, questions}。源碼中還加入了同為 TypeSafe 兼容協(xié)議的bocha / vercel / zen三個網(wǎng)關均走/v1/systemone它們的 base/model 預設也在 Prefs.kt 的 companion 常量中。3.2 回復接口任何 OpenAI 兼容 chat completions字段類型默認值 / 說明replyBaseUrlString默認https://openrouter.ai/api/v1填到/v1為止客戶端自己拼/chat/completions源碼replyEndpoint()正是如此拼接replyKeyString留空 用 judgeKey源碼effectiveReplyKey()replyKey.ifBlank { judgeKey }replyModelString老字段沿用默認deepseek/deepseek-chat-v3.13.3 視覺接口OCR 用OpenAI 兼容支持 image_url字段類型默認值 / 說明visionBaseUrlString默認同 replyBaseUrlvisionKeyString留空 用 replyKey → judgeKey源碼effectiveVisionKey()visionKey.ifBlank { effectiveReplyKey() }visionModelString默認qwen/qwen2.5-vl-72b-instructOpenRouter 區(qū)域可用用戶可改3.4 上下文與 OCR 開關后續(xù)階段寫入字段類型默認值 / 說明contextEnabledBoolean記錄歷史并注入。修訂后默認 false隱私優(yōu)先不落盤除非用戶主動開contextHistoryCountInt注入最近多少條歷史默認30源碼注入時coerceIn(0, 100)autoSummaryBoolean聯(lián)系人自動摘要默認true修訂后功能推遲ReplyClient.summarize()保留但不接線ocrEngineStringmlkit \| vision默認mlkitocrForUnknownAppsBoolean未適配 App 走通用 OCR默認trueocrFallbackBoolean已適配 App 樹讀空時 OCR 兜底默認trueocrAutoAnalyzeBooleanOCR 模式自動分析默認false手動點3.5 舊配置自動遷移一次性、可復現(xiàn)方案修訂明確三條遷移紀律A 階段補充遷移只做一次、judgeKey被用戶清空不得復活、舊存儲名一個不改。源碼 Prefs.kt 的migrateIfNeeded()精確實現(xiàn)以prefs_migrated_v13true布爾標記為閘門寫過標記后不再讀openrouter_key僅當judgeKey為空且老openrouter_key非空時才把老密鑰拷到judgeKey并打日志prefs migrated judgeKey.lenN只記錄長度絕不記錄密鑰本身replyModel沿用舊存儲鍵天然繼承無需處理老代碼的openRouterKey讀寫保留為judgeKey的兼容別名舊調(diào)用點無需改動即可編譯運行。四、模型客戶端拆分一條鏈路上三個專職客戶端方案將原來臃腫的JevClient拆成四個文件A 階段職責如下與源碼逐一對應jev/JudgeClient.kt // 只管 Jevjudge(snapshot, context) / rank(candidates) jev/ReplyClient.kt // 只管生成draft(snapshot, context) → 3 條summarize(text) → 摘要D 用 jev/VisionClient.kt // 只管視覺extractDialog(bitmap) / ocrLines(bitmap)B 用A 階段只建殼 jev/HttpJson.kt // 共用的 POST JSON 退避 錯誤歸類把現(xiàn)在 JevClient 里的 postJson 抽出來舊JevClient刪除或改成薄門面調(diào)用方ChatCaptureService、SettingsActivity 連通測試改用新類。4.1 錯誤信息規(guī)范一路一碼一摘要錯誤信息必須帶哪一路 HTTP 狀態(tài)碼 前 120 字響應。源碼 HttpJson.kt 用三個要素落實Route常量區(qū)分三路判斷接口/回復接口/視覺接口ApiException(route, status, snippet)的buildMessage()生成$route HTTP $status${snippet.take(120)}無狀態(tài)碼則為$route 請求失敗…傳輸層錯誤被describe()翻譯成人話網(wǎng)絡超時、域名解析失敗、無法連接、HTTPS 證書校驗失敗等且密鑰材料絕不進入任何錯誤文本。4.2 重試策略HttpJson.post()最多 3 次嘗試僅對429 / 529服務繁忙做指數(shù)退避500ms * (1L shl attempt)其他 4xx 客戶端錯誤一律不重試直接拋出讀響應體前先分支狀態(tài)碼保證 401 這類錯誤絕不會因為讀 body 異常而丟失狀態(tài)碼被誤判成傳輸失敗。4.3 視覺請求的坑位方案修訂 源碼注釋雙重印證方案修訂與 VisionClient.kt 源碼注釋共同列出的三個真花過調(diào)試時間的細節(jié)圖片用data:image/jpeg;base64,前綴Bitmap → JPEGBase64.NO_WRAP避免換行破壞 data URL選 JPEG 而非 PNG截圖 PNG 的 base64 體積會大數(shù)倍圖片 part 必須放在文本 part 之前——通義 DashScope compatible-mode 對相反順序會直接拒絕DeepSeek 官方不支持 image_urlVisionClient.supportsVision()對api.deepseek.com返回 false測試時要提示該接口不支持視覺。同時視覺 baseUrl 固定走 OpenRouter 默認、不跟隨回復接口回復接口切到 DeepSeek 會靜默弄壞 OCR故故意不繼承。4.4background/history字段的兼容策略D 階段要給 Jev 的 state 新增background背景知識與history歷史消息字段但方案不確定線上alpha/decisions是忽略新字段還是返回 400。因此 JudgeClient.kt 實現(xiàn)了降級重試帶背景/歷史請求若收到 4xx去掉這兩個字段原樣重發(fā)一次保證新字段可以拖累質(zhì)量但絕不能打斷分析。題目英文 instructions 還補了一句 facts in background are given context, not off-topic排序題同理防止模型把背景事實誤判為跑題。五、知識庫與關聯(lián)上下文D 階段5.1 數(shù)據(jù)模型存放位置方案原文context.filesDir/kb/notes.json、kb/contacts.json、kb/logs/contactId.json。數(shù)據(jù)模型與源碼 KbModels.kt 完全一致Note(id, title, content, tags: ListString, alwaysOn: Boolean, enabled: Boolean, updatedAt) Contact(id, name, aliases: ListString, apps: ListString, relationship: String, notes: String, autoSummary: String, summaryAtCount: Int, updatedAt) LogEntry(side, text, ts, app) // 每聯(lián)系人一個文件最多保留 300 條按 (side,text) 去重追加 ChatContext(contact: Contact?, history: ListLogEntry, notes: ListNote, budgetChars 1500)要點Contact.apps記錄來源包名如com.tencent.mmaliases就是跨 App 關聯(lián)的機制——同一個人在微信/QQ/飛書里標題不同全部登記為別名即可命中LogEntry每聯(lián)系人最多300 條源碼KbStore.MAX_LOG 300超限從頭部移除。5.2 存儲實現(xiàn)JSON 文件 原子寫方案修訂要求JSON 文件單寫者synchronized 原子寫臨時文件再 rename清空只刪filesDir/kb不動密鑰與白名單。源碼 KbStore.kt 全部落實所有讀寫走同一個lock對象synchronized單寫者由構造保證writeAtomic()先寫*.tmp再renameTo目標文件——POSIX 同目錄 rename 一步替換進程被殺也不會留下半個 JSONrename 失敗才退化為原地覆蓋并打日志說明非原子解析損壞的 JSON 文件時先改名備份再當作空庫絕不靜默覆蓋用戶數(shù)據(jù)readJsonArray的trustworthy標記內(nèi)存緩存 落盤雙份寫失敗即清緩存強制下次回源序列化手寫org.json不引 Gson/Moshi呼應不引 Room的輕量約束。5.3 名稱規(guī)范化與聯(lián)系人匹配方案修訂去首尾空白、零寬字符、群名尾部(數(shù)字)、大小寫不敏感后再匹配 name / aliases。源碼KbStore.normalizeName()正是四步流水線stripZeroWidth正則剔除\u200B-\u200D與\uFEFF→stripTrailingCount正則剝掉半角/全角括號包裹的數(shù)字尾巴如測試群(12)/測試群12都歸一為測試群→ trim → lowercase。findContact(title, app)命中規(guī)則會話標題 contact.name 或 ∈ aliases多個聯(lián)系人同時命中時優(yōu)先選已記錄過該包名的那個。聯(lián)系人絕不自動建檔修訂后只由用戶手建或在懸浮窗菜單里把當前會話存為聯(lián)系人一鍵建源碼KbStore.saveOrMergeContact()已存在的同名聯(lián)系人會并入包名與別名不產(chǎn)生重復檔案。5.4 筆記檢索只做兩層方案修訂把初版中文字符二元組重合度打分收窄為兩層樸素規(guī)則源碼 ContextBuilder.kt 原樣實現(xiàn)alwaysOn筆記全帶單獨占預算、不截斷其余筆記按「標簽 / 標題 ∈ 會話標題或最近 6 條消息」的包含匹配命中才帶最多 5 條MAX_HIT_NOTES 5新筆記優(yōu)先?？傤A算budgetChars 1500超預算時先丟棄最舊的歷史、再丟最后命中的整條筆記絕不截斷半條筆記。5.5 歷史記錄與去重歷史只在contextEnabled且命中聯(lián)系人時記錄opt-in默認關每次采集把當屏消息追加進該聯(lián)系人的日志文件最多保留 300 條注入前去掉屏幕上已可見的副本只刪與當屏消息(side, text)完全相同且長度 ≥ 4的副本DEDUPE_MIN_LEN 4避免把嗯好這類短文本誤判為同一句appendLog()以整屏序列為單位做增量去重與上一屏完全相同則不寫、日志尾部與當前屏前綴重疊則只追加新滾動出來的尾部、往回翻舊消息則整輪跳過——這是防止?jié)L動采集把歷史寫重寫的核心機制。5.6 注入方式與提示詞Jev 的 state 增加background關系 聯(lián)系人備注 自動摘要 命中筆記與history去掉屏幕上已有的歷史消息二者皆空時不發(fā)送字段ChatContext.isEmpty()回復提示詞固定追加「以下是關于我和對方的背景與知識庫回復必須與之一致可以直接引用其中事實不要編造知識庫里沒有的事實」——源碼 ReplyClient.kt 的knowledgeBlock()原文懸浮窗顯示一行知識庫 N 條 · 歷史 M 條ChatCaptureService里overlay.setContextInfo(ctx.notes.size, ctx.history.size)。5.7 一鍵自檢設置頁的「自檢」對應 KbSelfCheck.kt用臨時筆記 臨時聯(lián)系人 一次性 scratch Prefs不碰用戶真實配置跑通六項檢查——名稱歸一化含全角括號群名、聯(lián)系人別名命中、筆記 tag 命中、當屏去重不回流、舊消息注入、contextEnabledfalse時零注入——結束即清理最后返回自檢通過聯(lián)系人匹配 / 筆記命中 / 歷史去重 / 預算注入都正常一行結論。六、OCR 采集B 階段6.1 分層架構方案原文的分層與倉庫實際文件結構一致capture/ocr/ScreenCapture.kt // AccessibilityService.takeScreenshot 封裝限頻 ≥1s、失敗原因枚舉、Bitmap 回調(diào) capture/ocr/OcrEngine.kt // interface: recognize(bitmap, region): ListOcrLine(text, bounds) capture/ocr/MlKitOcr.kt // com.google.mlkit:text-recognition-chinesebundled capture/ocr/VisionOcr.kt // 走 VisionClient可返回結構化對話 capture/ocr/BubbleGrouper.kt // OCR 行 → 氣泡按行距、左右對齊分組side 按氣泡貼左/貼右 capture/GenericOcrAdapter.kt // 任意包名裁掉頂欄有標題的與輸入?yún)^(qū)有 EditText 的中間區(qū)域 OCR capture/FeishuAdapter.kt 改造 // 樹拿 bubble_content_container 矩形 已讀容器判 me每個矩形 OCR 正文v1.3 修訂把 B 階段收窄為只做兩件事① 飛書樹上bubble_content_container矩形 已讀容器判 me對每個矩形做 ML Kit OCR結果里剝掉已讀② 通用入口懸浮窗菜單截屏識別一次對任意 App 手動截一次整屏 OCR 并分析——不自動、不按左右判 me/other全部記為 other 并在面板標注未分邊。視覺模型 OCR 不進采集主路徑。注當前倉庫中VisionOcr.kt、BubbleGrouper.kt、GenericOcrAdapter.kt尚未落地為獨立文件通用整屏分組的實現(xiàn)內(nèi)聚在 ChatCaptureService.kt 的groupOcrLines()中按行距 1.2× 行高分組面板備注為OCR 未分邊把全部消息當作對方所說。6.2 適配器契約三態(tài)返回值方案修訂把適配器契約拆成三種返回源碼 ChatAppAdapter.kt 注釋一致extract返回null不在聊天窗列表頁、動態(tài)頁、設置頁…服務什么都不做返回ChatSnapshot(messages 為空)在聊天窗但樹里沒正文——這是 OCR 兜底的唯一觸發(fā)條件返回非空 messages 正常采集。服務只對第二種走 OCR 兜底且失敗退避 1s → 2s → 4s上限 30s絕不每秒連射。當前已接入的適配器為 QQ、X、Feishu微信com.tencent.mm因反截屏風險控制被完全禁用——不讀樹、不截屏、不 OCR、不填入僅顯示一次性提示源碼ChatCaptureService的PKG_WECHAT與WECHAT_DISABLED_MSG并有專項注釋說明。6.3 截屏實現(xiàn)窗口優(yōu)先、限頻、退避、錯誤碼人話源碼 ScreenCapture.kt 對方案修訂逐條落地API 34 優(yōu)先takeScreenshotOfWindow回退takeScreenshot(DEFAULT_DISPLAY)——窗口截屏在分屏/排除狀態(tài)欄時畫面小于整屏且有偏移因此Result.Ok攜帶scaleX/scaleY/originX/originY節(jié)點矩形與 OCR 框按(screenX - originX) * scaleX雙向換算截前隱藏懸浮窗HIDE_SETTLE_MS 120ms等一幀讓懸浮球消失、截后恢復回調(diào)里copy(ARGB_8888)后立刻close()HardwareBuffer——泄漏 HardwareBuffer 會讓系統(tǒng)合成器幾發(fā)之后餓死全局限頻 ≥ 1000ms跨實例共享lastAttemptAt因為系統(tǒng)限流是按服務計的連續(xù)失敗退避1s → 2s → 4s …封頂 30sMAX_STREAK 6回調(diào)有 3 秒看門狗超時平臺可能對受保護窗口干脆不回調(diào)防止懸浮窗永遠隱形、忙標志卡死錯誤碼 1/2/3/4/6 各給一句人話humanMessage()1內(nèi)部錯誤/系統(tǒng)拒絕2無障礙服務未聲明截屏能力去設置關掉再開3間隔太短4沒有有效顯示6窗口不可見或受保護FLAG_SECURE另有兩個自有碼 -1 截屏太頻繁、-2 截屏超時。6.4 無障礙配置與生效條件無障礙 XML config_disguised.xml 增加android:canTakeScreenshottrue同時保留flagRetrieveInteractiveWindows等采集所需 flags。關鍵生效條件方案原文寫入驗收加了該屬性后必須把無障礙關掉再開啟才生效——HyperOS 不熱更新 meta-dataHyperOS 還可能單獨拒絕無障礙服務截屏方案明確B 開工第一步先真機打一次takeScreenshot看 errorCode被拒則另起一個截屏專用服務。服務本身以偽裝類名com.google.android.accessibility.selecttospeak.SelectToSpeakService注冊見 AndroidManifest.xml讓微信這類對常規(guī)無障礙服務隱藏節(jié)點樹的應用暴露樹——微信最終仍被主動禁用是策略決定而非能力缺失。6.5 飛書適配矩形 已讀容器判 me飛書正文是繪制而非 View 布局2026-09-21 真機驗證樹里幾乎永遠沒有正文文本。因此適配器是混合型源碼 ChatAppAdapter.kt樹里收集bubble_content_container的屏幕矩形過濾頂欄/輸入?yún)^(qū)帶collectFeishuBubbleRects()在截屏回調(diào)里重新讀取——防抖 隱藏懸浮窗 拍攝之間隔了幾百毫秒列表可能已經(jīng)滾動必須重讀避免裁錯行邊判定不靠幾何飛書全員左對齊只有自己的氣泡掛已讀/發(fā)送回執(zhí)條…time_read_state_container_align_bubble以此判 me對方判 other真機上已讀容器判 me屬推斷項寫進了驗收的核對點每個矩形做一次 ML Kit OCRcleanBubbleText()剝掉氣泡尾部粘著的已讀/未讀和時間戳。6.6 通用入口截屏識別一次任意未適配 App釘釘、Telegram、微博私信等長按懸浮球 → 「截屏識別一次」整屏截一張OCR 中間區(qū)域頂部裁 12%、底部裁到 84%避開標題欄與輸入框按行距分組為偽氣泡全部記為 other并在面板標注未分邊隨后照常跑分析。手動觸發(fā)不受最新消息來自對方門檻限制每次都重新分析自動路徑則依賴ocrSignature()飛書用標題 每個氣泡矩形及邊其他用包名 標題做拍攝前去重——樹空時飛書每個 content-changed 事件都會觸發(fā)兜底沒有這道閘門光標閃爍都能變成每秒一張截屏。6.7 ML Kitbundled 中文識別MlKitOcr鎖定com.google.mlkit:text-recognition-chinese的bundled非 play-services變體模型打進 APK無 GMS 的手機也能識別、永不聯(lián)網(wǎng)下載。識別器單例化TextRecognition.getClient(ChineseTextRecognizerOptions.Builder().build())warmUp()在服務連接時于工作線程預載模型避免第一次真識別在主線程截屏回調(diào)線程承擔模型加載開銷坐標從 bitmap 空間經(jīng) scale/origin 換算回屏幕空間。方案還要求ndk.abiFilters arm64-v8a、選支持 16KB 頁對齊的版本并把包體增量與無 GMS 手機識別一次寫進驗收項。七、驗收標準每階段構建 裝機 真機方案規(guī)定的每階段驗收原文完整保留A設置頁三組接口各自連通測試通過把回復接口切到 DeepSeek 官方地址再切回QQ 分析仍正常老密鑰升級后不用重填。D在設置里建 1 條筆記含一個虛構事實 給某聯(lián)系人設關系與別名對該聯(lián)系人分析時候選回復體現(xiàn)該事實日志顯示知識庫 N 條 / 歷史 M 條清空按鈕生效。B飛書對話正文被 OCR 讀到并分析任選一個未適配 App如釘釘 / Telegram / 微博私信通用 OCR 出候選。CREADME 平臺表更新版本 1.3release 包簽名校驗通過。配套的早間裝機清單 docs/v1.3-morning-checklist.md 給出具體操作與預期adb install -r app/build/outputs/apk/debug/app-debug.apk adb shell appops set com.jev.probe SYSTEM_ALERT_WINDOW allow裝機后手機上將無障礙關掉再打開新增截屏能力HyperOS 不熱更新 meta-data然后看adb logcat -s JEVASSIST是否出現(xiàn)capture service connected與prefs migrated judgeKey.lenNN0 舊密鑰遷移成功。真機核對項還包括長按懸浮球「截屏識別一次」出候選 截屏被放行還是內(nèi)部錯誤/系統(tǒng)拒絕 HyperOS 拒絕無障礙服務截屏需另起截屏專用服務飛書里我/對方是否判反logcat 不應出現(xiàn)每秒一張截屏簽名去重生效。發(fā)布門檻versionCode 4 / versionName 1.3、targetSdk保持 35 不抬到 36、assembleRelease apksigner 校驗、記錄包體清單預期約 27 MB、以apk/jev-assistant-v1.3-release.apk替換 v1.2。八、方案的設計取舍三句話對照 docs/v1.3-plan.md 全文與其修訂記錄v1.3 的工程取向可以濃縮為三點也是閱讀源碼時最值得記住的原則隱私是硬約束而非功能密鑰只存 App 私有 SharedPreferences、只記錄長度不進日志知識庫默認不落盤、落盤只寫filesDir/kb、清空按鈕只刪該目錄聊天正文從不到 logcat。這解釋了contextEnabled修訂后默認 false、ocrAutoAnalyze默認 false 等所有默認保守的取值。失敗可診斷、降級不崩壞三路錯誤統(tǒng)一為路由 狀態(tài)碼 前 120 字background/history遇到 4xx 自動降級重發(fā)OCR 失敗退避封頂 30s 且錯誤碼全部翻譯成人話損壞的 JSON 先備份再當空庫。能簡單就不復雜不引 Compose/Room/GsonJSON 文件 內(nèi)存緩存 手寫 org.json檢索不做向量打分只做 alwaysOn 包含匹配排序邊判定能省則省通用 OCR 一律 other。方案文檔中Grok 4.7 評審后收窄的每一處修訂幾乎都在往更簡單、更保守、更可驗證的方向走。以上內(nèi)容以 docs/v1.3-plan.md 為主體骨架源碼實現(xiàn)細節(jié)均可在上述各文件路徑中核對未真機驗證的推斷項如飛書已讀容器判 me、HyperOS 截屏放行情況在方案與驗收清單中均已顯式標注為需真機確認與本文保持一致。贊分享AI 應用大模型交互助手RAG【免費下載鏈接】jev-chat-jarvis裝在手機上的對話副駕在 QQ / X / 飛書里讀懂對方、給出候選回復、一鍵填入輸入框發(fā)不發(fā)由你。非侵入只讀屏幕不 hook 不改包。項目地址https://gitcode.com/gh_mirrors/je/jev-chat-jarvis點擊查看免費下載相關推薦GPT4All本地知識庫構建與智能文檔分析技術深度解析GPT4All本地知識庫構建與智能文檔分析技術深度解析 GPT4All作為完全開源的本地大語言模型生態(tài)系統(tǒng)在數(shù)據(jù)私密性和智能文檔處理方面展現(xiàn)出卓越的技術優(yōu)勢。人工智能大模型本地部署AI 應用交互助手RAGUmi-OCR中實現(xiàn)自定義文本識別區(qū)域的技術方案Umi OCR中實現(xiàn)自定義文本識別區(qū)域的技術方案 在OCR應用開發(fā)中自定義識別區(qū)域是一個較為小眾但實用的需求。本文將探討如何在Umi OCR項目中實現(xiàn)這一功能OCR桌面應用上下文豐富技術為RAG系統(tǒng)注入深度語義理解上下文豐富技術為RAG系統(tǒng)注入深度語義理解 本文詳細探討了RAG系統(tǒng)中的上下文增強技術包括文檔級和章節(jié)級上下文分塊、相關片段提取、語義分塊以及上下文壓縮等關示例工程創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考