MineContext：火山引擎開源螢幕 AI 助手，把畫面變成日報、待辦與可問答的上下文庫

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

想讓 AI 幫你記住自己看過什麼、做過什麼，這類工具的官網都會講同一句話：資料存在本地、隱私有保障。MineContext 也不例外。但這句話值得追問一層：截圖的「存」和截圖的「懂」，是不是發生在同一個地方？翻開它的原始碼，答案很清楚：擷取與儲存確實都在你的機器上，但把畫面變成意義的那一步，預設是一個你自己填 key 的雲端視覺模型，而官方 Quick Start 推薦的服務，正是開發者自家的豆包。把它當「自帶金鑰的螢幕上下文管線」來評估，比當「私有版 ChatGPT Pulse」更貼近它的真實樣貌。

它是誰做的：火山引擎官方倉庫，Apache-2.0 授權

MineContext 的 GitHub 倉庫掛在 volcengine 組織下，這是字節跳動旗下火山引擎的官方帳號，原始碼檔案普遍帶著 Beijing Volcano Engine Technology Co., Ltd. 的版權行。授權是 Apache-2.0，LICENSE 檔實際存在，商用與改作在授權層面沒有障礙。到 2026 年 8 月中旬，倉庫累積約 5,468 顆星、407 次 fork。

技術組成是 Electron 殼加 Python 後端：前端用 Electron、React 與 TypeScript，後端是一個叫 opencontext 的 Python 套件，走 FastAPI，儲存用 SQLite 搭向量資料庫 ChromaDB。這個組合直接決定了幾個現實：有 Mac 與 Windows 安裝包、沒有 Linux 版、第一次啟動時要先把 Python 後端環境裝起來，官方說這步大約兩分鐘。

功能主軸用一句話講：背景每幾秒截一張螢幕，交給視覺模型理解，轉成結構化的上下文存進本機資料庫，再由定時任務把這些上下文變成日報、待辦、洞察與活動紀錄，推到首頁。你也可以反過來對它提問，或拿收集到的上下文做二次創作。

Pin

每五秒一張截圖之後，資料走了哪三層

信任問題要分層看，MineContext 的三層各有不同的答案。

擷取層在你的機器上完成。原始碼的預設值寫得很具體：每 5 秒截一張，截圖先壓到最大 1920 像素，再以感知雜湊去重，畫面相似度太高的當場丟棄，留下來的累積成每批 20 張送分析。被丟棄的重複截圖即時刪除，通過去重的原始截圖則留在本機磁碟，由每日清理任務刪掉 15 天前的舊檔，所以磁碟上隨時保有一批近期畫面。截圖範圍可以自己框選，不用整個螢幕都交出去。

理解層是整個工具的岔路口。它需要兩個模型：一個看得懂畫面的視覺語言模型，一個把文字轉成向量的嵌入模型，兩者都走 OpenAI 相容協議，端點、金鑰、模型名稱由使用者自己填。官方支援清單是 OpenAI、豆包與自訂服務三選，README 的推薦寫得很直白：考量成本與效果，建議用豆包，並附上控制台連結，視覺模型指定 Doubao-Seed-1.6-flash、嵌入模型指定 doubao-embedding-vision，申請入口都在火山引擎北京機房的服務區。截圖會以 base64 編碼放進請求內容送出，這是標準的視覺模型呼叫方式，但意味著畫面內容確實離開了你的電腦。

儲存層回到本機。理解後的結果進 SQLite 與 ChromaDB，位置在 ~/Library/Application Support/MineContext/Data，想備份、想整份搬走、想刪除，檔案都在你自己手上。

遙測方面，前端依賴清單與整個原始碼樹都找不到 Sentry、PostHog、Firebase 這類統計 SDK，聯網元件主要是模型 API 呼叫與 electron-updater 的更新檢查。鎖屏行為也可以在原始碼裡對答案：程式掛了鎖屏與系統暫停的事件處理，一觸發就停止擷取，解鎖或恢復後接著跑；有趣的是，最初提出這個需求的 issue 到現在還開著。未關閉的 issue 不代表功能沒做，但這是靜態讀碼得到的結論，實際鎖屏時的表現，裝了之後值得自己確認一次。

README 的隱私對比句，要對照自己的 Quick Start 一起讀

MineContext 的 README 有一段與 ChatGPT Pulse 的對比，隱私那條寫的是：你的資料完全在本機裝置上處理與儲存，不依賴雲端伺服器。單看這句話，會以為它是純離線軟體。

但同一份 README 的快速開頭，第一步就是填 API 金鑰。兩段並讀，準確的描述應該是：儲存與檢索在本機，理解預設在雲端，而且「完全不依賴雲端」這件事，只在本地模型路徑上成立。這倒未必是有意的誤導，更像是行銷對比句把 BYOK 架構講成了離線架構。自帶金鑰的設計真正的含義是：畫面內容送給誰，決定權在使用者，官方伺服器不經手、也不代管。

對台灣讀者，有個中性的事實要先知道：官方推薦的預設端點是火山引擎北京服務區的豆包模型。要把螢幕內容送進哪個機房，每個人自己的舒適度不同，這裡只陳述流向，不替任何人下結論。介意的人有兩條現成的替代路：換 OpenAI 相容的其他服務，或走下一節的完全本地方向。同品類裡，Dayflow 走的是類似的分層設計，本站先前拆解過它的三條截圖資料路徑與付費邊界，兩者的差異後面會對照。

真想讓資料一毫米都不離開機器，路是存在的：README 支援用 LMStudio 之類的工具跑本地模型，走 OpenAI 相容端點接進來，官方也說這樣任何資料都不會離開本機環境。代價同樣具體：你要同時在本機跑得動一個視覺語言模型加一個嵌入模型，硬體門檻與調校功夫都在使用者身上。Mac 上「模型自選、資料留本機」這個方向近來不少工具都在做，Osaurus 把長期記憶與加密身分留在本機、模型隨你接本機或雲端，是同一個思路的另一種實作，可以對照著看。

它實際會產出什麼：日報、待辦、洞察，和一個看得到用量的後台

收集只是前置，這個工具真正交付的東西是定時任務的產出。原始碼裡的預設值顯示，每日報告的生成時間是早上 8 點，另有週期更長的週報，內容從你前一天累積的上下文裡長出來：摘要、待辦建議、可留意的洞察、活動紀錄。這些產出直接推到應用首頁，不用你自己想起來去問。

背後的組織方式則圍繞六種上下文類型展開：實體、活動、意圖、語意、程序、狀態。一般使用者不需要記這套分類，它的重要性在於：你的螢幕歷史最後會變成一個可以檢索、可以問答的結構化語料庫，而不只是一疊流水帳。Chat 功能就建立在這上面，能對著「我上週三在看什麼」這類問題給答案，也能拿既有上下文當素材生成新內容。

費用可控性有一個少見的加分：後端在 localhost:1733 開了一個除錯後台，能看到 token 消耗與用量統計，也能調整自動任務的間隔與提示詞。等於 API 花了多少錢、哪些任務在燒量，攤在明面上。官方 README 的後台示範圖以每小時為粒度畫出用量曲線，尖峰那個小時就燒掉 255,642 個 token，一整天加總是百萬級的量，而用量幾乎全落在視覺模型上，嵌入模型小到貼著零軸；估算帳單時，直接按這個量級抓比較準。去重機制對成本有實質幫助，畫面沒變就不送分析，但批次大小 20 張的設定也提醒你：送出的量取決於你的畫面變化頻率，整天切換視窗的人與整天讀文件的人，帳單不會在同一個量級。

Pin

現在上車要接受的現實：版本停在 2026 年 1 月，藍圖完成不到十分之一

評估一個要長期常駐背景的工具，維護節奏與實際成熟度比功能列表重要，而這兩點 MineContext 都有明確的事實可查。

時間線是這樣的：倉庫 2025 年 6 月建立，9 月發出第一個版本 v0.1.0，之後在 10 到 11 月一個月最多出到三版，走到 2026 年 1 月 28 日的 v0.1.8，然後 release 線就停了。main 分支最後一次提交是 2026 年 5 月 7 日，內容是一個安全修補：把應用內部的 vikingdb 協議沙箱化，限制它只能讀應用資料目錄。這個修補本身值得肯定，因為修補前的問題不小，該協議原本可以被用來讀取本機任意路徑的檔案，原始碼註解裡甚至直接以讀取 ~/.ssh/id_rsa 當例子說明風險；但一個資安等級的修補成為三個多月來的最後一筆主線提交，也說明了目前的節奏。

issue 堆積是另一個訊號。到 8 月中旬有 122 個開著的 issue，其中包含幾個社群修補的 PR：修圖片處理程序記憶體洩漏的、修檔案上傳路徑驗證的，都還沒被併入主線。功能面上，README 那張洋洋灑灑的上下文來源規劃表列了約 30 項，目前打勾的只有螢幕截圖與應用內筆記編輯兩項能力（連結上傳同屬 P0 也尚未完成），文件、圖片、影片、程式碼、微信與 QQ 聊天紀錄、行動裝置截圖、智慧眼鏡與手環同步，全部屬於規劃中。換句話說，宣傳裡那個包山包海的數位生活記憶庫，現在裝到的是「螢幕加筆記」的先行版。另外，Linux 使用者在 issue 裡問過版本計畫，這個問題目前沒有得到官方回覆。

這些事實湊起來的判斷是：它是一個官方背書、授權乾淨、架構也想得清楚的專案，只是目前處在明顯減速的階段。下載點在 GitHub Releases 的 v0.1.8，有 Mac 的 dmg 與 Windows 的安裝程式；macOS 從 v0.1.5 起有 Apple 公證，不用再手動解除隔離屬性。裝完的第一件事是授與螢幕錄製權限並重啟，接著框選截圖區域、填模型金鑰，這幾步走完它才開始累積你的上下文。

想要工作日誌，還是一座能回答「我當時在看什麼」的資料庫：和 Dayflow 的分工

同樣是「定期截圖交給 AI」，這個品類裡兩個代表做的其實是兩種產品。Dayflow 每 10 秒截一張，目標是把一天拼成敘事清晰的工作時間線，產出 standup 與週報，記錄是主角；MineContext 每 5 秒截一張，目標是把長期累積的畫面歷史變成能檢索、能問答，也能拿來當創作素材的語料庫，語料是主角。

邊界條件的差異也大：Dayflow 只有 Mac 版，App 端 MIT 開源，雲端分析與同步走官方付費服務；MineContext 有 Mac 與 Windows 版，Apache-2.0 開源，沒有官方代管服務，分析力完全取決於你自己接的模型。要交週報、要回顧時間去向的人，Dayflow 的形態更對；想養一座能問「我那時候在看什麼」的個人上下文庫、且願意自己管金鑰的人，MineContext 的形態更對。把螢幕內容交給工具處理的信任衡量，在螢幕錄製工具的介紹裡也談過同類的取捨邏輯。

適合誰，不適合誰

適合的輪廓：工作大量發生在螢幕上、想要一份長期可問答的個人活動紀錄的知識工作者與創作者；願意自己申請與管理 API 金鑰、把模型服務當積木來換的人；能接受上游專案目前處於低速維護、出問題要自己翻 issue 的人。

該繞開的人也明確：要開箱即用、不想碰任何設定的，官方沒有代管方案，這條路對你是純折騰；需要計費等級工時報表的，這類工具的產出是敘事型紀錄，撐不起請款單；螢幕內容涉及高度機密、且無論如何不接受任何雲端視覺模型的人，除非你打算走全程本地模型，否則一開始就不該考慮這個品類；Linux 使用者目前沒有安裝包可裝。

常見問題

鎖屏或離開座位時，它會自己停止截圖嗎？程式碼掛了鎖屏即停、解鎖恢復的處理，系統暫停同樣會停，這是靜態讀碼的結論；要求這個功能的 issue 仍開著，實際表現建議自己確認一次，離開座位前手動按停錄製仍是最保險的做法。

有 Linux 版嗎？沒有。目前只有 macOS 與 Windows 安裝包，Linux 版本有人在 issue 問過，官方沒有給出時間表。

可以完全不上雲嗎？可以。它支援 OpenAI 相容的自訂端點，接 LMStudio 這類本地模型服務後，視覺理解與嵌入都留在本機，代價是你得自己準備跑得動模型的硬體與設定。

回頭看開頭那個問題：MineContext 說的資料在本地，指的是擷取與儲存兩層，理解層預設在你自己選的雲端模型上。把這個結構想清楚再決定裝不裝，比任何功能列表都值得。授權乾淨、無遙測、資料存放位置明確、用量後台透明，這些是它站得住的地方；維護放緩與藍圖兌現度，則是你下載前要自己加權的變數。