奈何让 IM Bot、Cursor CLI、Gemini CLI、Codex 共用一份长期追悼

我此次作念的，不是再造一个新的“云霄追悼系统”，而是把几种不同进口的 AI 助理，谐和到团结份土产货文献主追悼和团结套存档回查机制上。

这样岂论我和 IM Bot 对话，照旧在本机里用 Cursor CLI、Gemini CLI、Codex 使命，它们齐能尽量不绝团结段崎岖文，而不是每换一个进口就像失忆一次。

对我来说，这件事的中枢目的很大要：让这些进口在我的施行使用里齐像团结个捏续合营的助理系统，而不是四个互不有关的器用。

为什么要这样作念

淌若不同进口各自卫留一套崎岖文，问题会很快出现：

在 IM Bot 里说过的话，到了结尾里又要重讲一遍。我照旧阐发过的口吻、身份、偏好，在另一个进口里会丢失。我刚修好的历程、刚定下的法例，比赛下注app官网下一次换个器用又会重迭判断。

是以我接纳的作念法不是“让每个器用齐我方记取一切”，而是给它们一个共同读取、共同追加的追悼文献，并配上谐和的身份和活动法例。

罢了原则

把这套分享追悼机制树立在四个原则上：

团结份永恒追悼只保留一个主文献，但允许把旧内容按年月存档。悉数进口只作念追加，不回头改写旧记载。身份、口吻、中枢法例与永恒追悼分开存放。分享追悼只保存跨会话崎岖文，开云不承担工程常识库的一齐职责。

这四点看起来庸碌，但它们决定了这套决议是否谨慎。

尤其是只追加这少量，高出要道。

只很多进口齐可能同期读写，就尽量幸免“掩饰式写入”，不然很容易彼此踩掉内容。

奈何折柳“分享追悼”和“常识千里淀”

这是这套决议里另一个高出进犯的点。

我不会把悉数信息齐写进分享追悼。

不然过不了多久，这个文献就会造成一个紊乱的活水账。

我的分法是：

该写进分享追悼的内容用户谨慎偏好助理身份和口吻拘谨永恒灵验的合营法例以后很可能再次提到的进犯决定该写进常识库的内容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

• 奈何
• 开云官方app
• bot
• CLI
• IM