如何在不丢失上下文的情况下从 Cline 迁移到 Zencoder (2026)

首先来看看 Memory Bank 到底是什么，因为官方文档对此的说明比大多数人意识到的要清晰得多。

"Memory Bank 是一种文档方法论，它将 Cline 从一个无状态的助手转变为一个持久的开发伙伴。通过结构化的 markdown 文件，Cline 可以在不同的会话之间‘记住’你的项目细节。"

请注意 methodology（方法论）这个词。安装说明也证实了这一点：你复制了一块自定义指令，并“将它们添加到 Cline 规则文件中，例如 .clinerules/memory-bank.md”。这里没有开关。该功能是一个存在于规则文件中的提示词约定，外加一个该约定指示智能体去阅读的文档文件夹。如果你是通过按照设置 Cline 的 Memory Bank来设置你的 Memory Bank 的，那么你即将失去的是你粘贴该代码块的规则文件，而不是文件夹。

文件夹本身很普通：

"Memory Bank 文件是项目中你和 Cline 都可以访问的常规 markdown 文件。它们按层级组织，以构建项目的完整图景。"

六个文件，各司其职：projectbrief.md 作为基础文档，productContext.md 说明项目存在的原因，activeContext.md 记录当前的关注点和最近的更改，systemPatterns.md 记录架构和设计模式，techContext.md 记录技术栈和约束，以及 progress.md 记录已完成的工作和剩余的工作。你用短语来驱动它——文档中列出了“遵循你的自定义指令”（follow your custom instructions）来让 Cline 读取 Memory Bank 并从你上次中断的地方继续，以及“更新 memory bank”（update memory bank）来触发“全面的文档审查和更新”。

因此，迁移可以干净地一分为二。文档完美迁移：它们是你仓库中的 markdown，并且在你的仓库中保持为 markdown。而机制则完全无法迁移，原因如下。

Zencoder 的文档将上下文描述为按消息组装的，来自五个来源：对项目文件结构和依赖关系的 workspace（工作区）分析、当前在编辑器中打开的文件、匹配的 skills（技能）、你通过 @ 提及附加的任何内容，以及智能体在执行期间使用其自身工具收集的上下文。这就是上下文到达方式的完整列表，而这五个来源中没有一个是始终加载的仓库指令文件。

Zencoder 确实拥有的持久、版本控制的界面是 skills（技能）：

"Skills 存储为 .agents/skills/ 中的 SKILL.md 文件，并随你的仓库进行版本控制。"

它从三个位置读取它们——<workspace>/.agents/skills/ 用于项目技能，<user-home>/.agents/skills/ 用于用户级技能，以及 <workspace>/.claude/skills/（文档将其标记为“Claude 兼容技能”）。旧的 .zencoder/skills/ 路径被描述为“已弃用但仍支持”。

现在是决定你迁移计划的一句话：

"Skills 由智能体根据任务上下文自动选择。目前不支持手动选择技能。"

当智能体认为某个技能的 description（描述）与你正在做的事情匹配时，该技能就会加载。文档直接指出，描述起到了关键作用——它是“技能的作用——智能体用它来决定何时加载它”——并且指导建议是“将其写为明确的触发条件”。

把这两部分结合起来。Cline 的 Memory Bank 依赖于在每个任务开始时无条件触发的指令。Zencoder 的等效界面则在描述匹配时触发，并且没有强制执行的手动覆盖。将 memory-bank/ 复制到 Zencoder 项目中，只会给你留下六个没有任何机制强制打开的文件。

为了对反向检查进行完整说明：Zencoder 的文档描述了技能、单条消息上下文组装和多仓库搜索。它没有描述一个跨会话积累事实的对话记忆库。它自己的建议指向了相反的方向——“漫长、多主题的聊天会积累陈旧的上下文。为每个不同的任务开始一个新聊天，以便智能体的上下文保持干净。”这是个好建议，这意味着每个任务都从仓库以及智能体选择加载的任何内容开始。

步骤 1：将 Memory Bank 拆分为步骤和常驻事实

打开这六个文件，按内容形式而不是文件名重新分类，因为目的地只有一个容器，而且它是步骤（procedure）形式的。

任何读起来像是一个序列的内容——如何运行发布、如何添加迁移、评审清单如何工作——都是候选技能。它有一个自然的触发条件（“在添加数据库迁移时使用此技能”），因此描述可以可靠地匹配它，并且它会运行良好。

任何读起来像常驻事实的内容都是难啃的骨头。描述事件总线为何如此设计的 systemPatterns.md、列出排除某个显而易见库的约束条件的 techContext.md、解释产品实际用途的 projectbrief.md——这些都没有触发条件，因为它们几乎与每个任务都相关，但又不针对任何特定任务。编写一个匹配“总是”的描述，恰恰是该机制所不适用的。

然后是 activeContext.md 和 progress.md，它们两者都不是。它们是事物进展情况的运行日志。这两个文件是 Memory Bank 让人感觉像记忆而不是文档的原因，而且它们也是完全没有去处的两个文件——这就是诸如 Cline 遗忘任务历史 之类抱怨背后的差距，只不过现在的丢失是结构性的，而不是上下文窗口问题。

步骤 2：编写步骤技能，并仔细编写其描述

在 .agents/skills/ 下为每个步骤创建一个文件夹，每个文件夹中都有一个包含 name 和 description 的 SKILL.md。把精力花在描述上，因为它是整个激活机制。“API 辅助技能”将无法匹配；而“当用户要求创建或修改 API 端点时使用此技能”则可以。

有两个字段值得了解。paths 接受 glob 模式，将技能范围限制在特定文件，这比仅靠描述更接近条件加载。而将 disable-model-invocation 设置为 true 会阻止智能体自动选择技能——鉴于目前不支持手动选择，这实际上会让该技能失效。请谨慎使用，或者干脆不用。

如果你的团队也运行基于 Claude 的工具，请注意 Zencoder 也会读取 <workspace>/.claude/skills/。一个文件夹可以同时为两者服务，而无需维护两份副本。

你不应该做的是把常驻事实塞进一个描述模糊的技能中并寄予希望。这会导致 为什么智能体技能不是记忆 中提到的失效模式：一个在技术上存在但在关键时刻从未被加载的文档。

你无法安置的那一堆内容才是最有价值的。架构原因、被否决的替代方案、解释奇特模块的约束条件、项目目前的进展——这些正是让你的 Memory Bank 值得维护的内容，而 Zencoder 的激活模型没有为它们提供可靠的触发器。

MemoryLake 将该层保留在编辑器之外，并通过 MCP 或 API 回答有关它的问题。智能体不必根据描述来猜测内容是否相关——当问题出现时它会主动询问。你的步骤技能保留在 .agents/skills/ 中，由 Zencoder 通过任务匹配进行加载，而无论智能体在这一轮决定加载什么，常驻事实都保持可解答状态。

步骤 1：创建 API 密钥

生成一个密钥并在大约 30 秒内发出你的第一个请求。在上面的步骤 1 之前执行此操作，这样在整理这六个文件时，你就有地方存放每个事实。

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

逐个文件处理无法安置的那一堆内容。来自 systemPatterns.md 的架构决策、来自 techContext.md 的约束、来自 projectbrief.md 和 productContext.md 的产品意图，以及来自 activeContext.md 和 progress.md 的当前状态。将每一个记录为带有原因的决策。支持文档也放在同一个地方——将项目文档转化为 AI 记忆 介绍了如何在不重写所有内容的情况下做到这一点。

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

让 Zencoder、Claude、Codex 和你的其他智能体通过 MCP 或 API 进行访问。每一次新聊天（Zencoder 自己的建议是开始很多新聊天）在开始时都能够回答为什么项目是现在这个样子。

第一个变化是，开始一个全新的聊天不再需要你付出任何代价。Zencoder 建议每个任务都使用新聊天，正是因为陈旧的上下文会带来负面影响，而只有当持久知识一开始就不在聊天中时，这个建议才会让人感到舒适。

第二个变化是，你的技能会变得更好，因为它们变得更聚焦。一旦常驻事实有了其他去处，每个技能就可以是一个带有精准描述的单一步骤，这正是描述匹配发挥作用的理想条件。

第三个变化是，日志文件不再是损失。activeContext.md 和 progress.md 在新工具中没有去处。将它们记录为带有日期的决策，它们就会成为新团队成员阅读的内容，而不是去滚动浏览聊天历史记录。

第四个变化是，下一次迁移会比这一次更容易。这次迁移之所以尴尬，是因为 Cline 的机制是规则文件，而 Zencoder 的机制是描述匹配。一个不属于任何一方的独立层并不关心下一个工具会选择哪种机制——这也是 Cline 遗忘项目上下文 及其在所有其他工具中的等效问题具有相同底层解决方案的原因。

将描述视为核心功能。 技能的描述是其整个激活机制。将其写为命名具体情况的触发条件，而不是命名主题的标签。

每个技能一个步骤。 将三个不相关的步骤捆绑在一起，会使你的描述无法干净地匹配其中任何一个。

在进行文件范围的工作时，请记住 paths。 Glob 范围限制是最接近条件加载的方法，它比宽泛的描述更可靠。

不要随意设置 disable-model-invocation。 在不支持手动选择的情况下，禁用自动选择会移除唯一的入口。

从旧的技能路径迁移。 文档将 .zencoder/skills/ 描述为已弃用但仍支持，并建议使用 .agents/skills/ 以与当前标准保持一致。

与 Claude 工具共享一个技能文件夹。 Zencoder 也会读取 .claude/skills/，因此同时运行这两者的团队不需要重复文件。

不要期望技能的表现像一个始终开启的规则。 如果某些内容在每个任务中都必须为真，那么任务匹配的容器就不适合存放它。

Cline 的 Memory Bank 是一个 markdown 文件夹加上一个让智能体读取它的规则文件。Zencoder 在 .agents/skills/ 中对技能进行版本控制，根据其描述自动选择它们，并且目前不支持手动选择——而且其文档记录的上下文来源是按消息组装的，而不是从常驻指令文件中加载。因此，你的 Memory Bank 中的文档可以完美迁移，但确保有机制去读取它们的保证却无法迁移。

在迁移之前，按形式拆分 Memory Bank。步骤变成技能，其描述写为触发条件，它们会运行良好。常驻事实和运行状态需要一个能够回答问题的归宿，而不是等待被匹配。完成这一次拆分，Zencoder 关于为每个任务开始新聊天的建议就会变成它应有的样子——一种保持上下文干净的方法，而不是一种重新开始的方法。