Claude Code 團隊記憶：CLAUDE.md、Git 還是 MCP？的封面圖片

Seiji Nakaya

如果團隊希望其 Claude Code 代理能夠記住決策與上下文，有三種工具會被提及：一個 CLAUDE.md 檔案、Git 本身，以及 MCP 記憶伺服器。它們常被視為競爭者。但其實並非如此——它們涵蓋不同的層面。以下是其界線。

CLAUDE.md：每個儲存庫的常駐指示

CLAUDE.md 是 Claude Code 會自動讀取的檔案。它適合用來存放 穩定的、儲存庫範圍的慣例：編碼風格、架構說明、「用這個指令執行測試」、「金額以整數分為單位」。

擅長：很少改變的持久規則；零設定；與程式碼一起版本控制。

其極限：它是靜態且每個儲存庫獨立的。它不適合用來記錄「今天早上我們決定了什麼」，因為這些內容每天都在變化，而且它無法跨儲存庫運作，也無法在代理做出決策的「當下」捕捉該決策。它也無法幫助兩個代理避免同時編輯同一個檔案。

Git：程式碼的真實來源

Git 已經儲存了你的程式碼及其歷史記錄，而 commit 訊息和 PR 則解釋了為什麼會發生某項變更。有些團隊嘗試將其擴展為共享的「記憶」——一個提交到儲存庫的 Markdown 知識庫或更新日誌。

擅長：它目前是、也應該繼續是程式碼本身的權威記錄。歸屬與歷史記錄是免費附帶的。

其極限：大多數協作上下文都沒有可附加的 diff——「暫時不要碰這個模組」、「我們正在標準化 X」、「誰在負責付款功能」。將這些內容推送到 Git 會將協作變成一個需要拉取、合併和解決衝突的檔案。合併衝突正是你試圖避免的東西，而提交的知識庫會重新引入這些問題。Git 也是輪詢式的：代理只有在 fetch 之後才能看到更新，而不是在寫入的當下。

MCP 記憶：程式碼周圍的工作上下文

MCP 記憶伺服器為代理提供一個小型的共享儲存空間，它們可以透過工具即時讀寫，跨越不同工作階段與機器。MCP 是一個開放標準，用於將 AI 應用程式連接到外部系統。這是專門用來存放那些從未進入 commit 的決策與上下文的層面——在某些工具中，也用於檔案宣告和任務看板等協作原語。

擅長：在代理做出決策的當下捕捉它；將其提供給不同機器上的不同代理進行連接；保持供應商中立（任何 MCP 用戶端——Claude Code、Cursor、Codex）。

其極限：它不是你的程式碼儲存庫。它不應該試圖成為 Git，而一個好的 MCP 也不會 fetch 或 clone 你的儲存庫。

界線，一句話總結

  • Git 是 程式碼 的真實來源。
  • CLAUDE.md 存放 穩定的、每個儲存庫的指示。
  • MCP 記憶 存放 即時的、跨機器的決策與協作。

它們可以互相搭配使用。將程式碼留在 Git 中，將慣例放在 CLAUDE.md 中，並將快速變動的團隊上下文——「我們決定了 v2」、「Carol 負責付款功能」、「API 凍結了嗎？」——放在一個共享的 MCP 層中，讓每個代理都能讀寫。

Vibsync 如何定位

Vibsync 就是那個 MCP 層：持久的團隊記憶（remember / recall）、非同步的代理間問答（ask / reply），以及檔案宣告 + 任務協作——單一端點、供應商中立、帶上你自己的模型。它刻意不擷取你的原始碼；Git 仍然是真實來源。一個代理記錄的決策，會被另一台機器上的新工作階段繼承，而不需要任何人複製貼上上下文。

如果你的團隊不斷向新的 Claude Code 工作階段重複解釋相同的決策，這就是這個層級可以填補的缺口。在測試期間免費試用——將你的代理指向 mcp.vibsync.com/mcp。

揭露：本文由 Vibsync 團隊撰寫。Vibsync 由 LOOSEDAYS Co., Ltd. 開發。

原文發表於 Vibsync 部落格。

#### HASHNODE BODY（以下；從評論中設定欄位）

如果團隊希望其 Claude Code 代理能夠記住決策與上下文，有三種工具會被提及：一個 CLAUDE.md 檔案、Git 本身，以及 MCP 記憶伺服器。它們常被視為競爭者。但其實並非如此——它們涵蓋不同的層面。以下是其界線。

CLAUDE.md：每個儲存庫的常駐指示

CLAUDE.md 是 Claude Code 會自動讀取的檔案。它適合用來存放 穩定的、儲存庫範圍的慣例：編碼風格、架構說明、「用這個指令執行測試」、「金額以整數分為單位」。

擅長：很少改變的持久規則；零設定；與程式碼一起版本控制。

其極限：它是靜態且每個儲存庫獨立的。它不適合用來記錄「今天早上我們決定了什麼」，因為這些內容每天都在變化，而且它無法跨儲存庫運作，也無法在代理做出決策的「當下」捕捉該決策。它也無法幫助兩個代理避免同時編輯同一個檔案。

Git：程式碼的真實來源

Git 已經儲存了你的程式碼及其歷史記錄，而 commit 訊息和 PR 則解釋了為什麼會發生某項變更。有些團隊嘗試將其擴展為共享的「記憶」——一個提交到儲存庫的 Markdown 知識庫或更新日誌。

擅長：它目前是、也應該繼續是程式碼本身的權威記錄。歸屬與歷史記錄是免費附帶的。

其極限：大多數協作上下文都沒有可附加的 diff——「暫時不要碰這個模組」、「我們正在標準化 X」、「誰在負責付款功能」。將這些內容推送到 Git 會將協作變成一個需要拉取、合併和解決衝突的檔案。合併衝突正是你試圖避免的東西，而提交的知識庫會重新引入這些問題。Git 也是輪詢式的：代理只有在 fetch 之後才能看到更新，而不是在寫入的當下。

MCP 記憶：程式碼周圍的工作上下文

MCP 記憶伺服器為代理提供一個小型的共享儲存空間，它們可以透過工具即時讀寫，跨越不同工作階段與機器。MCP 是一個開放標準，用於將 AI 應用程式連接到外部系統。這是專門用來存放那些從未進入 commit 的決策與上下文的層面——在某些工具中，也用於檔案宣告和任務看板等協作原語。

擅長：在代理做出決策的當下捕捉它；將其提供給不同機器上的不同代理進行連接；保持供應商中立（任何 MCP 用戶端——Claude Code、Cursor、Codex）。

其極限：它不是你的程式碼儲存庫。它不應該試圖成為 Git，而一個好的 MCP 也不會 fetch 或 clone 你的儲存庫。

界線，一句話總結

  • Git 是 程式碼 的真實來源。
  • CLAUDE.md 存放 穩定的、每個儲存庫的指示。
  • MCP 記憶 存放 即時的、跨機器的決策與協作。

它們可以互相搭配使用。將程式碼留在 Git 中，將慣例放在 CLAUDE.md 中，並將快速變動的團隊上下文——「我們決定了 v2」、「Carol 負責付款功能」、「API 凍結了嗎？」——放在一個共享的 MCP 層中，讓每個代理都能讀寫。

Vibsync 如何定位

Vibsync 就是那個 MCP 層：持久的團隊記憶（remember / recall）、非同步的代理間問答（ask / reply），以及檔案宣告 + 任務協作——單一端點、供應商中立、帶上你自己的模型。它刻意不擷取你的原始碼；Git 仍然是真實來源。一個代理記錄的決策，會被另一台機器上的新工作階段繼承，而不需要任何人複製貼上上下文。

如果你的團隊不斷向新的 Claude Code 工作階段重複解釋相同的決策，這就是這個層級可以填補的缺口。在測試期間免費試用——將你的代理指向 mcp.vibsync.com/mcp。

揭露：本文由 Vibsync 團隊撰寫。Vibsync 由 LOOSEDAYS Co., Ltd. 開發。

原文發表於 Vibsync 部落格。