Screenpipe：把你的螢幕操作變成可檢索的 AI 記憶

我最近看高星 GitHub repo 時，最讓我停下來多看幾分鐘的，不是又一個聊天機器人，而是 Screenpipe 這種「把使用行為變成記憶層」的工具。它想解的問題很直接：我們每天在電腦上做了很多事，但真正需要回頭找資料時，卻只剩模糊印象。曾經看過的內容、做過的操作、聊過的會議，常常散落在不同 app 裡，最後只能憑記憶重建。

Screenpipe 的切入點不是幫你再做一個筆記本，而是先把上下文保存下來。它在官方 README 裡把自己描述成 AI memory for your screen，架構也很清楚：事件驅動的擷取、音訊處理、本機 SQLite + FTS5、localhost API、以及可以掛上自動化 agent 的 pipe 層。這代表它不是單純錄影，而是把「看見、聽見、搜尋、再行動」串成一條可重用的管線。

我覺得它真正有價值的地方

第一，它把記憶從人腦搬到可查詢的系統裡。這件事看起來像小改進，但實際上會改變你怎麼工作。當你可以問「我剛剛五分鐘看了什麼？」或「今天和誰談了哪些產品需求？」時，你不再只是回憶，而是在檢索。

第二，它是 local-first 的思路。官方文件提到它會把截圖存到磁碟、本機資料庫做全文搜尋，並提供本機 REST API。對很多團隊來說，這比把所有內容直接丟上雲端更容易接受，尤其是碰到內部文件、敏感畫面、或日常開發工作流時。

第三，它不是只有 UI，而是有明確的開發者入口。README 裡直接提供桌面版下載，也提供 CLI：npx screenpipe@latest record。如果你想把它接進 Claude，甚至可以用 MCP：claude mcp add screenpipe -- npx -y screenpipe-mcp。這種設計很適合我這種會想把工具接到工作流裡的人，因為它不是只能看，還能被其他 agent 讀取和操作。

我會怎麼開始試

如果是第一次碰，我不會先想太多理論，會先做三件事。

先跑起來

直接下載桌面版，或者在終端機執行：

```bash

npx screenpipe@latest record

```

先做一個可驗證的查詢

安裝好之後，不要急著接一堆自動化，先問最簡單的問題：

- what did i see in the last 5 mins?

- summarize today conversations

如果它真的能把你剛剛看過的畫面或對話找回來，價值就已經成立一半。

再接到 agent 工作流

當你確定搜尋可用，再把它接進 Claude 或其他 agent，讓它變成一個可查詢的上下文來源。這時候 Screenpipe 才真正從「錄製工具」變成「可被代理使用的記憶層」。

這類工具的限制也很明顯

我不會把 Screenpipe 當成所有團隊都該立刻上線的標配。它的優點和風險是同一件事：因為它很接近你的工作現場，所以也很接近你的隱私、資安和儲存成本。

你需要想清楚三件事：

哪些畫面可以被保存，哪些不行
這些資料要留多久，誰可以查
團隊是否真的需要持續捕捉上下文，而不是偶爾使用即可

另外，它雖然有本機搜尋和 API，但要把它用得好，仍然需要一點工程化思維。若只是想要一個簡單筆記 app，它可能太重；但如果你的目標是做個人知識回放、AI 工作流、或 agent 上下文層，它就很有戲。

誰適合先試

我會優先推薦這幾種人先碰：

想把日常操作變成可搜尋上下文的開發者
需要記住會議、截圖、螢幕操作的人
正在做 agent、RAG、個人知識庫整合的人
想研究 local-first AI 工具架構的人

如果你只是想看熱鬧，Screenpipe 會像一個很酷的產品；如果你正在找下一代「工作記憶」的基礎層，它就值得放進待辦清單。

我最後的判斷

我會把 Screenpipe 看成一個很清楚的訊號：AI 工具正在從「回答問題」往「保存上下文」移動。這個方向很重要，因為真正讓人省時間的，不只是模型更會說話，而是它能不能記得你剛剛做了什麼，並把這些資訊變成下一步行動。

如果你想看一個把螢幕、麥克風、搜尋、API 和 agent 串在一起的實作案例，Screenpipe 是很值得研究的起點。

參考資料