同時用個人 Claude、公司 Claude 和 Codex 之後，我一開始根本不考慮維護三套設定。

我的直覺是：第一個 Claude 帳號已經調好的全域規則、Skills、MCP、Plugin 和 Agents，其他帳號應該都直接跟著它。帳號變多，只是多了登入身分與可用額度，不該讓我重新養三個版本的 AI 工作環境。

所以我開始跟 AI 討論一個很實際的問題：要不要直接用 symlink，把每個帳號的設定資料夾連回第一個 Claude？還是乾脆把共用設定抽到外面的資料夾，讓現在三個、未來更多的 AI 帳號都指向同一個地方？

後來把問題拆開，才發現多帳號不該等於三套環境；但「全部都共用」也不是答案。

帳號不是工作方法

這三個帳號在我這裡的角色很單純：個人 Claude、公司 Claude、以及 Codex。它們處理的是登入身分、可用方案和額度；不是三個不同的工作人格。

真正希望固定下來的是另一層：Agent 是誰、怎麼分工、回覆用什麼語言、遇到專案時先讀什麼規則，以及哪些工作可以直接交給某個 Skill。

我把它分成三層：

層次負責什麼是否共用
帳號登入身分、方案與額度不共用
runtime 設定Claude 或 Codex 各自的原生設定、權限語意不硬合併
工作規格全域規則、Skills、Agent 的角色與共享契約，以及 OpenMemory／Obsidian 等 MCP 的使用規則盡量只留一份

這樣切完之後，切換帳號比較像換一張可以使用的門票，不是換一個新同事，也不用重新交代我平常怎麼工作。

先決定共同來源要放在哪裡

一開始有兩條路：

  1. 直接把第一個 Claude 帳號的設定當母體，其他帳號用 symlink 指回來。
  2. 在帳號設定之外另建一個共用資料夾，讓所有 runtime 都從那裡讀取。

第二條路看起來很乾淨，但要多維護一個抽象層，還要替每個工具設計怎麼接回去。以我目前的使用方式，第一條更直接：~/.claude 已經是最早調好的工作環境，就讓它成為共同來源。

個人 Claude 直接使用它；公司 Claude 與 Codex 則把真正需要共用的東西用 symlink 指回來。

~/.claude/                 ← 共同來源
├── CLAUDE.md              ← 全域工作規則
├── skills/                ← 可重複呼叫的工作流程
└── agents/                ← Claude Agent 定義


~/.claude-company/
├── CLAUDE.md → ~/.claude/CLAUDE.md
├── skills/    → ~/.claude/skills/
└── agents/    → ~/.claude/agents/


~/.codex/
├── AGENTS.md  → ~/.claude/CLAUDE.md
└── skills/    → ~/.claude/skills/

這不是為了讓資料夾看起來整齊，而是把「修改的地方」收斂成一個。以後我替 session-summary 補一條規則，或替 Agent 加一個共同的工作契約，只改共同來源；三個入口下次啟動時讀到的就是同一份內容。

這也和我在 Session is Skill：把一次 AI 任務變成下次可呼叫的 SOP 裡做的事相同：能重複使用的不是某次對話，而是被整理好的工作方式。既然工作方式是一份資產，就不該複製三份等它們慢慢漂移。

新帳號要接上的，其實是我的長期記憶

最初的願望其實是讓 Skill 跟 MCP 可以完整複製過去。因為我已經用 OpenMemory 和 Obsidian 建了一套第二大腦：一邊記住跨 session 的偏好與決策，一邊保存討論過程、文件和問題的長期紀錄。

所以新增一個 AI 帳號時，我希望它不是從零開始聊天。它應該立刻擁有同一套讀取記憶的能力：遇到需要過去脈絡的問題，就知道去查 OpenMemory；需要回看原始討論或文件時，也找得到 Obsidian 裡的紀錄。

對我來說，這樣才叫新增了一個額度。它多提供一個可以調整模型、切換用量的入口，但不需要重新認識我是誰、過去做過什麼，或我希望怎麼和 AI 合作。

但實作時不能只看資料夾名稱就整包連過去。例如 Claude 的 settings.json 和 Codex 的 config.toml 本來就不是同一種東西；權限、MCP、Plugin 的註冊方式與 runtime state 也各有自己的語意。能直接共用的設定可以收斂，必須留在原生 runtime 的設定就保留獨立，反而比較清楚。

Agent 也是同一個原則：Claude 與 Codex 可以各自用最適合自己的格式定義角色與啟動方式；但兩邊都會用到的報告格式、驗收條件或模板，放成 shared contract。共用的是工作規格，不是強迫兩個工具長得一樣。

另一個容易混淆的點是路徑。symlink 解決的是「內容由哪裡共用」；全域規則裡提到的 reference 則用絕對路徑，解決的是「不管從哪個專案啟動，這份參考資料都找得到」。兩件事分開後，帳號切換和工作目錄切換都不會把設定帶到迷路。

Git 只保護設定骨架，不收集工作痕跡

這套環境我也會放進 Git，但只追蹤設定本體、Agent 定義與 symlink。登入憑證、對話歷史、快取、資料庫檔案這些 runtime state 不該一起 commit。

原因不只是避免把敏感資料送進版本庫。這些東西也不是「重建工作環境」需要的內容；重新 clone 設定後，該回來的是規則與結構，不是某次對話或某個帳號的登入狀態。

所以多帳號環境真正要備份的，是我和 AI 如何合作的方式，而不是 AI 曾經替我記住了什麼。

切換的只是額度與 LLM

後來我很喜歡這個心智模型：帳號是可替換的登入入口，工作環境才是我長期在培養的東西。

當個人額度不適合眼前的工作，我可以換公司帳號或切到 Codex；但 Agent 的角色、寫作流程、專案進場規則還是同一套。這樣切換工具的時候，不會有「又要重新把 AI 教成我熟悉的樣子」的感覺。

三個帳號當然還是三個帳號。只是它們終於不用再各自養一個平行宇宙。