如何设置 Cline 的 Memory Bank 并保持其最新（逐步指南，2026）

它是文档，而文档会老化

驱动 Memory Bank 的自定义指令块是用第一人称写的，非常值得字面阅读：“我是 Cline，一名专业的软件工程师，我有一个独特的特征：我的记忆在不同会话之间会完全重置。这不是一个限制——正是它促使我保持完美的文档。在每次重置后，我完全依赖我的 Memory Bank 来理解项目并有效地继续工作。”

一切都源于这句话。Cline 并不是在记忆，而是在阅读。如果文件说项目使用的是 REST，而你在三周前已经转向了 GraphQL，Cline 并没有感到困惑——它只是对一个错误的文件做出了正确的反应。

六个文件中的一个变化速度远快于其他文件

其核心结构是六个具有明确层级关系的文件：作为“塑造所有其他文件的基础文档”的 projectbrief.md，然后是基于它构建的 productContext.md、systemPatterns.md 和 techContext.md，最后汇入 activeContext.md 和 progress.md。

这六个文件的老化速度并不相同。projectbrief.md 可能在一年内都是正确的。而 activeContext.md 涵盖了“当前关注点、最近的更改、下一步工作”，并且根据文档，它“更新最频繁”。

这种不对称性正是整个维护问题的所在。最容易过期的文件，恰恰也是 Cline 在任务开始时最依赖的文件，因为它是描述你昨天在做什么的文件。

更新是一个必须有人记住去运行的命令

Cline 为你提供了三个命令：“initialize memory bank”（初始化 memory bank）用于创建结构，“update memory bank”（更新 memory bank）用于触发“完整的文档审查和更新”，以及“follow your custom instructions”（遵循你的自定义指令）让 Cline 读取 bank 并从你上次中断的地方继续。

文档列出了应该触发更新的四个条件：“发现新的项目模式”、“在实施重大更改后”、“当用户请求 update memory bank 时（必须审查所有文件）”以及“当上下文需要澄清时”。

这四个条件中有三个取决于人类的察觉。这并不是对该设计的批评——这正是文档方法论的本质——但它确实告诉你应该把精力放在哪里。

只初始化一次，之后再也不碰。 这是最常见的模式，大约能维持两周。然后，bank 描述的将是一个不复存在的项目版本，由于 Cline 会非常自信地阅读它，错误的上下文比没有上下文还要糟糕。

只有在出现问题时才运行“update memory bank”。 到那时，更新就变成了彻底的重写，而不是增量更新，而彻底的重写往往会被拖延。

把所有内容都塞进 activeContext.md。 这是人们打开最频繁的文件，因此它会不断堆积架构说明、技术栈决策和未决问题，直到它不再是当前关注点的摘要。层级结构的存在正是为了防止这种情况。

将 Memory Bank 视为自动压缩（auto-compaction）的替代品。 这是不同的工具。文档直接建议了这种分工：“你也可以让 Auto Compact 处理日常的上下文管理，并将手动的 'update memory bank' 留给重要的检查点。”

以为在正确的文件夹中放一个 .md 文件就足够了。 Memory Bank 需要指令块处于激活状态。将其复制到 Cline Rules 文件（例如 .clinerules/memory-bank.md）或你的全局自定义指令中——否则这些文件就只是普通文件，这也是 why agents ignore your instruction files 的一种表现形式。

在单台机器上进行设置，并假设团队其他成员也拥有它。 如果指令块存在于你的全局自定义指令中，而不是在代码库中，你的同事根本就没有 Memory Bank——他们只有一个没有任何智能体被告知去阅读的 markdown 文件文件夹。其症状令人困惑：bank 看起来得到了维护，因为你在维护它，但对其他所有人来说，它似乎毫无作用。

为模型编写 bank，而不是为下一个人编写。 这些文件是你代码库中的纯 markdown 文件，这意味着人类在代码审查和新员工入职时会阅读它们。写成简短关键词列表的条目制作成本较低，但一个月后，无论是对人类还是对模型来说，都极难验证。

设置分为三个步骤，而第三步是大多数指南都会忽略的部分。

步骤 1：安装指令，然后初始化

将 Memory Bank 自定义指令块从 Cline 的文档复制到 Cline Rules 文件中（文档给出的示例是 .clinerules/memory-bank.md），然后让 Cline “initialize memory bank”（初始化 memory bank）。

刻意选择存放位置。Cline 的常见问题解答将其视为一种权衡：“自定义指令全局适用于所有项目。而 Cline Rules 文件是特定于项目的，并存储在你的代码库中，这使得它很容易与协作者共享。”对于任何超过一个人的项目，代码库版本更胜一筹，因为只有你拥有的全局指令会产生一个只有你维护的 Memory Bank。

还有一个值得了解的第三种选择：条件规则可以“仅在处理 memory-bank/ 文件时激活 Memory Bank 指令”。如果常开版本挤占了你的上下文，这会非常有用。

让 Cline 创建初始结构，而不是手动编写六个文件。文档建议从基本的项目简报开始，让结构自然演变，Cline 填充层级结构的一致性比人类填写模板要好得多。

步骤 2：根据变化速度拆分这六个文件，并按该节奏进行更新

明确写下谁在什么时候更新什么。一个行之有效的方案：

• projectbrief.md 和 productContext.md —— 在里程碑处进行审查，而不是在会话结束时。
• systemPatterns.md 和 techContext.md —— 当架构或依赖决策实际发生变化时更新，并与该更改在同一个 commit 中提交。
• activeContext.md —— 在每个工作会话结束时更新。文档明确指出：它“变化最频繁；在每次会话后更新它”。
• progress.md —— 在恢复工作时进行审查，因为它“跟踪里程碑”。

然后使用文档中描述的上下文窗口工作流，因为它可以兼作维护仪式。当你的上下文窗口填满时：让 Cline “update memory bank” 以记录当前状态，开始新对话，然后让 Cline “follow your custom instructions”。通过这三个相同的动作，你将获得一个全新的窗口和一个最新的 bank，这比日历提醒要可靠得多。

关于完整更新的一个警告：“update memory bank” 意味着 Cline “必须审查所有文件”。这是非常彻底的，但并不是免费的——在大型 bank 上，这是一次相当大的消耗。请将其保留给检查点，并让日常修剪通过 Auto Compact 进行，正如常见问题解答所建议的那样。

步骤 3：将超出代码库生命周期的事实保存在其他地方

这就是该设计的局限性。Memory Bank 的范围限定在项目目录中，并围绕代码库构建。这对于 systemPatterns.md 是正确的，但对于你的智能体同样需要的大量其他事物来说则是错误的。

客户和领域细节。关于你希望如何完成工作的偏好，这些偏好在你接触的每个代码库中都是通用的。决策背后的推理比结果更重要。与使用不同工具的队友共享的任何内容。

这些都不属于单个仓库中的六个 markdown 文件，强行塞进去只会让 Memory Bank 变得臃肿且过时。代码库之外的记忆层保存了跨项目的那一半，而 Memory Bank 则继续做它真正擅长的事情。MemoryLake 的设置只需三个步骤。

步骤 1：创建 API 密钥

登录并从你的控制面板生成一个 API 密钥。它属于你个人，而不是属于某个代码库，这使得相同的知识可以在不同项目之间跟随你，而无需在每个新的 Memory Bank 中重新建立。

步骤 2：上传你的第一批记忆

从你一直想粘贴到 activeContext.md 中但实际上与当前关注点无关的内容开始：长期偏好、领域词汇表、客户详细信息、决策及其背后的原因。然后添加你已经在第二个代码库中重新解释过的内容。

步骤 3：连接你的 AI 和智能体

将 Cline 指向该存储。特定于代码库的一半保留在 Memory Bank 中，你的团队可以在拉取请求（pull request）中对其进行审查；持久的一半则无需在每个新项目中重新输入。

第一个变化是 activeContext.md 变得更小，因此能够保持准确。一个只包含当前关注点的文件，是一个你可以在会话结束时花 30 秒诚实更新的文件。而一个已经变成通用知识垃圾场的文件，则是你会被迫跳过更新的文件。

第二个变化是，启动一个新代码库不再是从零开始。在今天，一个新项目意味着一个空无一物的全新 Memory Bank，你必须在第一周重新建立 Cline 已经学过两次的偏好。而将持久的一半存储在外部，只有特定于项目的文件才是新的。

第三个变化是，使用不同工具的队友不再被孤立。Memory Bank 是 Cline 的约定；使用其他智能体的同事无法将其作为记忆读取，只能将其作为文档。如果你的团队中有一半人已经切换——例如，在从 Cursor 迁移到 Cline之后——共享层就是让两部分人都能基于相同事实工作的关键。

• 对于任何超过一个人的项目，将指令块放在代码库中，而不是全局设置中。
• 在每次会话结束时更新 activeContext.md。 它是唯一一个以会话为更新周期的文件，也是 Cline 阅读最仔细的文件。
• 将架构更新与改变架构的 commit 绑定。 systemPatterns.md 绝不应该作为一个单独的琐事来更新。
• 使用“填满仪式”作为你的更新触发器。 更新、新对话、“遵循你的自定义指令”。将免费的维护工作附加到你已经在做的事情上。
• 将完整的“update memory bank”运行留给检查点。 它会审查每个文件；让 Auto Compact 处理日常的上下文管理。
• 当某个主题值得单独建档时，在 memory-bank/ 下添加文件， 正如文档允许复杂功能、集成规范或测试策略那样——而不是无限期地扩大单个文件。
• 排除跨项目的知识。 如果一个事实在你的下一个代码库中同样适用，那么 Memory Bank 就不是它的合适归宿。
• 每月自己阅读一次 bank。 它是你代码库中的纯 markdown，这是它最大的优势——这意味着如果人类去看，过时之处是显而易见的。审计你的 AI 记忆了什么 同样适用于这里，就像适用于任何隐藏的存储一样。

Memory Bank 是这个领域中比较诚实的设计之一。它不声称模型记住了任何东西；它明确指出记忆会重置，而文档才是存活下来的东西。这种诚实正是它起作用的原因，也正是它会失效的原因——一个建立在文档之上的系统继承了文档的失效模式。

在代码库中设置它，根据变化速度拆分这六个文件，将更新与你已经在做的事情联系起来，并将超出此代码库生命周期的知识保存在同样能持久存在的地方。