封面图片：Claude Code 团队记忆：CLAUDE.md、Git 还是 MCP？

Seiji Nakaya

如果团队希望 Claude Code 代理记住决策和上下文，有三种工具可选：一个 CLAUDE.md 文件、Git 本身，以及一个 MCP 记忆服务器。它们常被视为竞争对手，但并非如此——它们覆盖不同的层级。下面是它们的分界线。

CLAUDE.md：每个仓库的永久指令

CLAUDE.md 是 Claude Code 自动读取的文件。它适合存放稳定且仓库范围的约定：编码风格、架构说明、“用此命令运行测试”、“金额以整数分计算”。

擅长：持久且很少变更的规则；零设置；与代码一起版本控制。

局限：它是静态的且仅限单个仓库。它不适合“今天上午我们决定了什么”这类每天都在变化的内容，也无法跨仓库使用，也无法在代理做出决策的那一刻捕获它。它也无法防止两个代理同时编辑同一文件。

Git：代码的唯一真相来源

Git 已经存储了你的代码及其历史，提交信息和 PR 说明了变更发生的原因。有些团队试图将其扩展为共享的“记忆”——提交到仓库的 Markdown 知识库或更新日志。

擅长：它就是且应该继续作为代码本身的规范记录。归属和历史记录免费获得。

局限：大多数协调上下文没有可附加的 diff——“暂时不要碰这个模块”、“我们正在标准化 X”、“谁在负责支付功能”。将这些推送到 Git 会把协调变成一个需要拉取、合并和解决的文件。合并冲突正是你试图避免的问题，而提交的知识库会重新引入它们。Git 也是基于轮询的：代理只有在 fetch 之后才能看到更新，而不是在写入的瞬间。

MCP 记忆：代码周围的工作上下文

MCP 记忆服务器为代理提供了一个小型共享存储，它们可以通过工具实时读写，跨会话和跨机器。MCP 是一个开放标准，用于将 AI 应用程序连接到外部系统。这是那些从未进入提交的决策和上下文的层级——在某些工具中，还提供文件声明和任务看板等协调原语。

擅长：在代理做出决策的瞬间捕获它；通过连接提供给不同机器上的不同代理；保持供应商中立（任何 MCP 客户端——Claude Code、Cursor、Codex）。

局限：它不是你的代码存储。它不应该尝试成为 Git，一个好的实现也不会获取或克隆你的仓库。

一句话总结的分界线

  • Git 是代码的唯一真相来源。
  • CLAUDE.md 保存稳定的、每个仓库的指令。
  • MCP 记忆保存代码周围的实时的、跨机器的决策和协调。

它们可以组合使用。将代码保存在 Git 中，将约定保存在 CLAUDE.md 中，将快速变化的团队上下文——“我们决定用 v2”、“carol 负责支付功能”、“API 冻结了吗？”——放在共享的 MCP 层中，每个代理都可以读写。

Vibsync 如何适配

Vibsync 就是那个 MCP 层：持久的团队记忆（remember / recall）、异步的代理间问答（ask / reply），以及文件声明 + 任务协调——单一端点、供应商中立、自带模型。它故意不摄取你的源码；Git 仍然是唯一真相来源。一个代理记录的决策会被另一个机器上的新会话继承，无需任何人复制粘贴上下文。

如果你的团队不断向新的 Claude Code 会话重复解释相同的决策，这就是这个层级填补的空白。在 beta 期间免费试用——将你的代理指向 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 已经存储了你的代码及其历史，提交信息和 PR 说明了变更发生的原因。有些团队试图将其扩展为共享的“记忆”——提交到仓库的 Markdown 知识库或更新日志。

擅长：它就是且应该继续作为代码本身的规范记录。归属和历史记录免费获得。

局限：大多数协调上下文没有可附加的 diff——“暂时不要碰这个模块”、“我们正在标准化 X”、“谁在负责支付功能”。将这些推送到 Git 会把协调变成一个需要拉取、合并和解决的文件。合并冲突正是你试图避免的问题，而提交的知识库会重新引入它们。Git 也是基于轮询的：代理只有在 fetch 之后才能看到更新，而不是在写入的瞬间。

MCP 记忆：代码周围的工作上下文

MCP 记忆服务器为代理提供了一个小型共享存储，它们可以通过工具实时读写，跨会话和跨机器。MCP 是一个开放标准，用于将 AI 应用程序连接到外部系统。这是那些从未进入提交的决策和上下文的层级——在某些工具中，还提供文件声明和任务看板等协调原语。

擅长：在代理做出决策的瞬间捕获它；通过连接提供给不同机器上的不同代理；保持供应商中立（任何 MCP 客户端——Claude Code、Cursor、Codex）。

局限：它不是你的代码存储。它不应该尝试成为 Git，一个好的实现也不会获取或克隆你的仓库。

一句话总结的分界线

  • Git 是代码的唯一真相来源。
  • CLAUDE.md 保存稳定的、每个仓库的指令。
  • MCP 记忆保存代码周围的实时的、跨机器的决策和协调。

它们可以组合使用。将代码保存在 Git 中，将约定保存在 CLAUDE.md 中，将快速变化的团队上下文——“我们决定用 v2”、“carol 负责支付功能”、“API 冻结了吗？”——放在共享的 MCP 层中，每个代理都可以读写。

Vibsync 如何适配

Vibsync 就是那个 MCP 层：持久的团队记忆（remember / recall）、异步的代理间问答（ask / reply），以及文件声明 + 任务协调——单一端点、供应商中立、自带模型。它故意不摄取你的源码；Git 仍然是唯一真相来源。一个代理记录的决策会被另一个机器上的新会话继承，无需任何人复制粘贴上下文。

如果你的团队不断向新的 Claude Code 会话重复解释相同的决策，这就是这个层级填补的空白。在 beta 期间免费试用——将你的代理指向 mcp.vibsync.com/mcp。

免责声明：本文由 Vibsync 团队撰写。Vibsync 由 LOOSEDAYS Co., Ltd. 构建。

最初发布于 Vibsync 博客。