如何讓 IM Bot、Cursor CLI、Gemini CLI、Codex 共用一份永久記憶

如何讓 IM Bot、Cursor CLI、Gemini CLI、Codex 共用一份永久記憶

我這次做的，不是再造一個新的“云端記憶系統”，而是把幾種不同入口的 AI 助理，統一到同一份本地文件主記憶和同一套歸檔回查機制上。

這樣無論我和 IM Bot 對話，還是在本機里用 Cursor CLI、Gemini CLI、Codex 工作，它們都能盡量延續同一段上下文，而不是每換一個入口就像失憶一次。

對我來說，這件事的核心目標很簡單：讓這些入口在我的實際使用里都像同一個持續協作的助理系統，而不是四個互不相干的工具。

為什么要這么做

如果不同入口各自保留一套上下文，問題會很快出現：

• 在 IM Bot 里說過的話，到了終端里又要重講一遍。
• 我已經確認過的語氣、身份、偏好，在另一個入口里會丟失。
• 我剛修好的流程、剛定下的規則，下一次換個工具又會重復判斷。

所以我采用的做法不是“讓每個工具都自己記住一切”，而是給它們一個共同讀取、共同追加的記憶文件，并配上統一的身份和行為規則。

實現原則

把這套共享記憶機制建立在四個原則上：

1. 同一份長期記憶只保留一個主文件，但允許把舊內容按年月歸檔。
2. 所有入口只做追加，不回頭改寫舊記錄。
3. 身份、語氣、核心規則與長期記憶分開存放。
4. 共享記憶只保存跨會話上下文，不承擔工程知識庫的全部職責。

這四點看起來普通，但它們決定了這套方案是否穩定。

尤其是只追加這一點，非常關鍵。

只要多入口都可能同時讀寫，就盡量避免“覆蓋式寫入”，否則很容易互相踩掉內容。

如何區分“共享記憶”和“知識沉淀”

這是這套方案里另一個非常重要的點。

我不會把所有信息都寫進共享記憶。

否則過不了多久，這個文件就會變成一個混亂的流水賬。

我的分法是：

該寫進共享記憶的內容

• 用戶穩定偏好
• 助理身份和語氣約束
• 長期有效的協作規則
• 以后很可能再次提到的重要決定

• bug 修復過程
• 腳本、命令、工作流
• 環境坑、依賴問題、排障經驗
• 以后別的代理復用時需要的工程細節

如果一件事同時具備兩種價值，我會這樣處理：

• 在共享記憶里寫一行結論
• knowledge/*.md里寫完整做法

這樣上下文不會丟，工程細節也不會擠爆長期記憶文件。

如何快速使用？

我已經將方法總結并寫了1個skill[1]，如果你和我一樣，同時使用多個ai CLI工具，就可以試試這個skill，或者基于這個skill，讓ai幫你改寫為你自己的永久記憶系統。

最后的結論

如果我要用一句話總結這套方案，那就是：

我不是讓 IM Bot、Cursor CLI、Gemini CLI、Codex 各自擁有一份記憶，而是讓它們共同服從同一份長期記憶、同一份身份定義、同一份行為規則。

這樣這些入口對我來說，才是真正同一個連續協作系統的不同入口。

這也是我認為目前最穩、最容易維護、最不容易失控的一種實現方式。

參考資料

skill: https://github.com/JobYu/shared-brain