我把 Gmail、GitHub 和 Notion 接進 OpenHuman 後發生了什麼？

2026 年 6 月 1 日 · Nuvcloud 技術部落格 · 約 8 分鐘閱讀

OpenHuman 接入 Gmail、GitHub、Notion 後 Memory Tree 與 auto-fetch 資料流 — 接上最常見的「工作三角」後，OpenHuman 的 Memory Tree 會在本機持續生長——關鍵在背景 auto-fetch，不是多開一個聊天分頁。

裝好 OpenHuman 之後，我刻意沒有一次把 118 個整合全打開。官方 GitBook 上列了 Gmail、Notion、GitHub、Google 日曆、Slack……對獨立開發者或小團隊，真正構成「日常脈絡」的往往是三個：郵件談需求、Notion 寫規格、GitHub 看交付。我只接了這三樣，然後觀察 72 小時內本機到底發生了什麼。

先講結論：OpenHuman 不是「把三個分頁合成一個聊天框」。OAuth 完成後，磁碟上的 Memory Tree（記憶樹） 會自己長——預設大約每 20 分鐘 一輪 auto-fetch（見官方說明），把新郵件、頁面更新、提交記錄壓成 Markdown，寫進 SQLite 與類 Obsidian 的本機倉庫。對話品質的變化是滯後且累積的：前幾小時幾乎無感，第二天跨應用問題突然變準，第三天你會開始意識到磁碟和雜訊也是成本。

Beta 提示：專案仍標 Early Beta，連接器行為可能隨版本變動。本文依 2026 年 5 月前後公開 Release 撰寫；上線前請鎖定 GitHub Releases 版本。

1. 為什麼先接 Gmail、GitHub、Notion

這三個源涵蓋我約八成「希望 AI 能引用的脈絡」：

Gmail：客戶改需求、deadline 口頭確認、合約附件——常只活在郵件串，Notion 未必同步。
Notion：PRD、介面約定、會議紀要——結構化，但與程式庫時間軸、郵件脫節。
GitHub：誰 merge、CI 紅不紅、issue 承諾——交付真相，卻和商務郵件不在同一畫面。

ChatGPT 或 Copilot 可以單次貼其中一段，但無法持續對齊三處變更。OpenHuman 的價值是把三條管道接到同一套本機記憶庫。倉庫：tinyhumansai/openhuman；若已在想常開機部署，可先讀 OpenHuman 養在雲端 Mac 上。

2. 接入當天：OAuth 與第一輪 fetch

三者都是瀏覽器 OAuth，比自建 API Key 省事。建議順序：

先 Gmail——授權範圍務必克制，別勾「同步全部歷史郵件」；最近 30 天或「重要」標籤即可。
再 Notion——只勾仍在用的 database／頁面，行銷封存別選。
最後 GitHub——按 org／repo 授權，個人 side project 可先不接。

點完最後一個「允許」，介面不會立刻變聰明。背景會跑全量拉取：Gmail 拆成摘要塊、Notion 轉 Markdown、GitHub 的 commit／PR／issue 寫入對應目錄。Activity Monitor 裡會看到 OpenHuman 持續讀寫。

第一輪結束後打開 Memory Tree（或 Obsidian 風格 wiki），頂層大致如下：

記憶庫目錄示意

memory/
├── gmail/
│   ├── threads/
│   └── contacts/
├── notion/
│   ├── pages/
│   └── databases/
└── github/
    ├── repos/
    ├── commits/
    ├── pull-requests/
    └── issues/

此時問「總結我上週工作」往往仍空泛——模型還沒建立跨源關聯。別灰心，正常現象。

3. 三個源各自落庫後長什麼樣

資料源	auto-fetch 主要拉什麼	Memory Tree 裡	常見雜訊
Gmail	新信、串回覆、標籤變更	按 thread 的 Markdown 摘要	電子報、GitHub 通知信與真人信混在一起
Notion	頁面編輯、database 列變更	每頁一個 .md；database 常展平成表	空模板、已封存頁仍被索引
GitHub	push、PR review、issue、release	按 repo 分目錄；commit 含 hash、訊息、作者	dependabot、lint bot、fork 同步產生低價值 commit

官方會把 HTML 郵件、Notion 區塊、GitHub JSON 壓成 Markdown 再入庫。直接在 Finder 打開某個 .md，可比聊天視窗更早發現是 fetch 摘要偏了還是模型推錯。

4. 第二天起：跨應用問題突然能問了

大約 4–6 輪 auto-fetch（通常過一夜）後，我開始問以前得在三個 app 間複製貼上的問題。下面幾類確實變準（專案名已匿名）：

「客戶 A 在郵件把上線日從 6/15 改到 6/22，Notion PRD 和 GitHub milestone 對齊了嗎？」——能給不一致清單。
「本週在 repo X merge 了哪些 PR，和郵件承諾的 scope 對得上嗎？」——取決於郵件是否提到 repo 或 PR 編號。
「會議紀錄說要加 rate limit，程式 merge 了嗎？」——紀要在 Notion 且 PR 描述對得上時命中率高。

這些回答的共同點是對齊與差異偵測，不是代寫程式或代發信。此階段 OpenHuman 像讀過三個 inbox 的實習生；若要它改 Notion、開 PR，那是 OpenClaw 的執行面——記憶聚合與動作執行要分開想。

5. 沒料到的三件事

5.1 磁碟長得比聊天體驗快

三整合跑滿 48 小時，本機記憶庫從不到 200MB 漲到約 1.2GB（個人用量；若全量同步多年 Gmail 會更誇張）。monorepo commit 史與大型 Notion database 是主因。建議從第一天就 du -sh 盯增速、關掉不用的 Notion workspace、GitHub 只留 active repo。

5.2 雜訊會污染「上週工作總結」

Gmail 裡的 GitHub 通知、Notion 空模板、dependabot commit 都會進樹。緩解：Gmail 用標籤過濾；GitHub 忽略 archived repo；下指令時加約束（例如只統計含客戶名的 commit）。

5.3 筆電合蓋 = 記憶停擺

MacBook 合蓋開會兩小時，auto-fetch 日誌缺一段，隔天問「昨晚客戶有沒有回信」就不準——睡眠讓定時任務暫停，不是 bug。若三整合是核心工作流，要嘛合蓋不休眠＋接電，要嘛把分身遷到常開機機器。

6. 一週後用法怎麼變

穩定跑滿 7 天後，我固定三個習慣：

晨間 5 分鐘：24 小時內客戶郵件、阻塞 PR、Notion urgent 條目。
回信前：依 thread 與 Notion 介面頁起草確認 scope 的郵件——仍人工寄出。
週五：本週三源關於專案 Y 的不一致，並 spot-check 引用的 .md。

我還沒接 Calendar、Slack——要先證明「三角閉環」值得維護成本。會議多的人，第四個接 Calendar 往往比 Slack 划算（Slack 串比郵件更吵）。

7. 正要接入：四條實操

分批授權，每加一源觀察 24 小時磁碟與 CPU。
以 Memory Tree 為準，模型錯了先打開對應 .md。
模型路由另議——對話若走雲端 API，郵件摘要仍會出網；公司信箱有 DLP 的別接個人分身。
備份 SQLite + Markdown——等同職業與人格副本，別丟公有雲同步夾。

快速體檢（接入約 48 小時後）

du -sh ~/Library/Application\ Support/OpenHuman/memory 2>/dev/null \
     || du -sh ~/Documents/OpenHuman/memory 2>/dev/null
find . -name "*.md" -mtime -1 | wc -l

8. FAQ

Q1：只接這三個夠嗎？
對多數知識工作者夠驗證價值。接滿十幾個源之前，先優化雜訊與磁碟。

Q2：和 Gmail 內建 Gemini、Notion AI 重複嗎？
不重複——那些是單應用內問答；OpenHuman 是跨源持久索引且預設在本機。

Q3：GitHub 私有庫？
Token 在本機；風險在整庫備份外洩。FileVault、獨立使用者、別把記憶庫同步到 Dropbox。

Q4：72 小時夠決定要不要繼續？
通常夠。若跨應用仍常 hallucinate 且不願整理 Memory Tree，維持現狀即可；若晨間習慣已省時間，再考慮常開機。

Q5：一定要雲端 Mac 嗎？
不必；若合蓋斷 sync 已害你兩次以上，見下文。