实际迁移了什么
每个 CLAUDE.md 文件，原封不动。 Augment 的规则文档列出了 Auggie 加载文件的“以下优先级顺序”：
1. 自定义规则文件（通过--rules标志），2.CLAUDE.md，3.AGENTS.md，4. 工作区指南（.augment-guidelines），5. 工作区规则文件夹（<workspace_root>/.augment/rules/），6. 用户规则文件夹（~/.augment/rules/）
有两点非常引人注目。CLAUDE.md 的优先级高于 AGENTS.md，这与其他几个智能体使用的顺序相反。而且这两个外部文件名都排在 Augment 原生规则目录之上，而用户级目录排在最后。
嵌套的 CLAUDE.md 文件可以迁移，并保留其作用域。 Claude Code 会在目录树中向下发现 CLAUDE.md 文件，并指出“所有发现的文件都会被拼接进上下文中，而不是相互覆盖”，顺序是“从文件系统根目录向下到你的工作目录”，因此“距离你启动 Claude 较近的指令会最后被读取”。
Augment 在结构上做了类似的事情，但触发方式不同。其文档这样描述层级规则：“当你处理某个文件时，Augment 会在该文件的目录中寻找 AGENTS.md 和 CLAUDE.md”，然后“向上遍历目录树，检查每个父目录中是否存在这些文件”，并且“所有发现的规则都会包含在该工作会话的上下文中”。搜索“在工作区根目录停止”。规则还会“按对话会话进行缓存，以避免重复引入”。
因此，一个包含 src/frontend/CLAUDE.md 和 src/backend/CLAUDE.md 的 monorepo 的行为大致符合你的预期。当在 src/frontend/ 中进行工作时，该文件及其父目录的文件会被加载；而后端文件则不会。
导入（Imports）无法迁移。 Claude Code 支持在 CLAUDE.md 内部进行 @path 导入，并有一个文档记录的细节：“导入解析会跳过 Markdown 代码跨度和围栏代码块”，因此用反引号包裹的 @README 会保持字面值。Augment 的规则文档描述的是带有可选 YAML frontmatter 的普通 Markdown 文件，并没有记录导入语法。迁移后的 CLAUDE.md 中的任何 @path 行都应被视为文本——在依赖它之前，请先将导入的内容平铺（flatten）到文件中。
有一种规则类型没有 CLI 目标。 Augment 的工作区规则接受一个 type 字段，文档中记录了两个值：always_apply 和 agent_requested，而 IDE 插件则暴露了第三个值。CLI 页面明确指出了这一差距：
“CLI 中不支持手动规则。CLI 会跳过<workspace_root>/.augment/rules/中带有type: manual的规则——因为没有 @-mention 机制来按需附加它们。”
IDE 端的页面也重复了这一点：Manual 是“仅限 IDE——通过 @ 提及按需附加；CLI 会跳过”。如果你的团队同时使用这两个界面，手动规则在编辑器中是生效的，但在终端中却不存在。
用户级规则会丢失其 frontmatter。 Augment 文档指出“~/.augment/rules/ 中的用户规则总是被视为 always_apply，并且不支持其他 frontmatter 类型”。你放在主目录中的任何内容都会在每个项目的每个会话中启用，无论其 frontmatter 写了什么。
自动记忆（Auto memory）无法迁移。 Claude Code 有两个持久化系统，其文档将其描述为互补的：你编写的 CLAUDE.md 文件，以及自动记忆——“Claude 根据你的纠正和偏好自己编写的笔记”——存储在每个项目的 ~/.claude/projects/<project>/memory/ 下，并在“每个会话（前 200 行或 25KB）”中注入。Augment 也有一个记忆系统，但完全不同：Cosmos Experts 将“作用域知识存储在共享虚拟文件系统 (VFS) 中”，Expert 的记忆“属于其团队”，并且有两个文档记录的模型：简单和嘈杂。两者都不会读取对方的文件。我们在引导 Augment 的 Experts 记住什么中单独介绍了 Cosmos 方面；本指南是关于指令层的，这是一个具有不同生命周期的不同机制。
手动迁移
步骤 1：决定 CLAUDE.md 是否保持权威，并坚定这一选择
你有两个合理的选择，而失败的模式是两者都不选。
选项 A：保留 CLAUDE.md。 它排在第二位，行之有效，并且能让尚未切换的任何人继续使用 Claude Code 读取该仓库。代价是 Augment 的原生功能——每个规则的 type frontmatter、可以独立审查的单条规则文件——将无法使用，因为单个 CLAUDE.md 没有 frontmatter，也没有文件边界。
选项 B：转换为 .augment/rules/。 你可以为每个规则创建一个文件，每个文件都有自己的 type，这是这两种工具中最接近条件加载的功能。但其代价是没人能预料到的，值得用专门的段落来说明。
Augment 的层级发现仅涵盖两个文件名。其文档指出：“只有 AGENTS.md 和 CLAUDE.md 文件会被层级发现”，紧接着又指出：“.augment/rules/ 中的文件仅从工作区根目录加载，而不从子目录加载”。
因此，转换为 Augment 自身的格式会让你失去目录作用域。你的 src/frontend/CLAUDE.md 以前只在前端进行工作时加载。将相同的内容移动到 .augment/rules/frontend.md 后，它会从工作区根目录加载，并应用于所有内容。在这一维度上，该厂商的原生格式是其支持的三种格式中作用域能力最弱的。
对于大多数团队来说，实际的解决方案是拆分：在目录作用域发挥实际作用的地方保留嵌套的 CLAUDE.md 文件，而仅将 .augment/rules/ 用于需要非“总是启用”的 type 的仓库级规则。不要仅仅为了让目录树看起来整洁而转换嵌套文件。
无论你选择哪种方式，都要进行验证，而不是凭空假设。Claude Code 自身的一致性说明是一个很好的检查理由：“如果两条规则相互矛盾，Claude 可能会任意选择一条。”两个规则树同时加载正是你遇到并非自己编写的矛盾规则的原因，而且你无法检查其解决机制。我们在调和冲突的 CLAUDE.md 层级中详细介绍了如何在 Claude Code 端审计这种情况。
步骤 2：重新声明你的条件规则，并检查字符预算
Claude Code 的条件加载机制是带有 paths frontmatter 的 .claude/rules/，加上它自己的说明，即没有 paths 的规则“在启动时加载，其优先级与 .claude/CLAUDE.md 相同”。Augment 的机制则是 type 字段。
有意识地对它们进行映射。一个受路径作用域限制的 Claude Code 规则，要么变成其适用目录中嵌套的 CLAUDE.md（从而保留作用域），要么变成一个 agent_requested 规则，其 description 声明了它的适用时机。当你能写出很好的描述时，Augment 的指南更倾向于后者：“如果你想优化上下文的使用，请优先选择 agent_requested 而非 always_apply。对于这些规则，智能体将判断该规则是否与你当前的任务相关。”请注意，agent_requested 必须提供 description，并且它承担了所有的筛选工作。
然后检查预算，因为 Augment 公布了硬性限制，而 Claude Code 仅公布了建议。Claude Code 建议你“将每个 CLAUDE.md 文件控制在 200 行以内”——这是指导意见，而非上限。Augment 的限制部分则是硬性上限，并记录了溢出时的行为：
“用户指南（User Guidelines）目前限制为最多 24,576 个字符。工作区指南（Workspace Guidelines）+ 规则（Rules）限制为最多 49,512 个字符。如果超出这些限制，用户将在应用内收到通知，并按以下顺序应用：（手动规则、总是启用 + 自动规则、.augment-guidelines）。”请阅读最后一句话中的顺序。当超出预算时，手动规则最先被应用，而 .augment-guidelines 最后被应用。如果一个团队一直将 .augment-guidelines 视为权威文件，那么在面临预算压力时，他们实际上是将优先级最低的项视为了权威。
如果你的团队中有人使用插件而不是 CLI，还有一个特定于 IDE 的细节：“在 VSCode 中定义的指南不会传播到 JetBrains IDE，反之亦然。”用户指南存储在本地 IDE 存储中，因此它们既不共享，也不受版本控制。任何对多个人都重要的内容都应该放在仓库中。
更好的方法：任何优先级列表都无法重排的推理层
这两种工具都会对文件进行排序。但它们都不存储规则存在的原因。
正是这一差距使得这种迁移具有文件移动所没有的风险。当你决定将嵌套的 CLAUDE.md 转换为 agent_requested 规则时，你也决定了其 description 的内容——而该描述决定了该规则是否会再次加载。如果最初的约束是“支付模块不得使用共享的重试助手，因为在特定的失败路径上它会重复收费”，规则在移动后得以保留，但原因却没有保留，下一个读到这条没有合理解释的简短规则的人就会将其删除。
MemoryLake 保存了这些合理解释：裁决、尝试过的方法、被拒绝的原因以及时间。它存在于这两个指令系统之外，因此优先级变化和格式转换无法对其进行重排。从这里开始。
步骤 1：创建 API 密钥
为仓库创建一个工作区并生成一个 API 密钥。将其作用域限定在仓库，而不是 Claude Code 或 Augment，因为关键在于它的生命周期比这两者都长。
步骤 2：上传你的第一批记忆
在转换任何内容之前，遍历你的 CLAUDE.md 目录树，并记录下每个非显而易见的规则存在的原因。添加你反复向 Claude Code 提出的纠正——这些正是其自动记忆在本地积累的纠正，而且它们无法迁移。然后添加在迁移过程中做出的决定：你保留了哪些文件、转换了哪些文件，以及刻意留下了哪些文件。
步骤 3：连接你的 AI 和智能体
连接 Auggie，并在过渡期间保持 Claude Code 的连接。两者都读取相同的集合，因此对于你尚未移植的规则，无论有人碰巧使用哪个智能体，其推理仍然可用。
这在实践中改变了什么
“它已经能用”的陷阱不再让你浪费一个月的时间。你在第一天就知道 CLAUDE.md 排在第二位，因此你可以深思熟虑地做出保留或转换的决定，而不是在以后才发现你新的 .augment/rules/ 文件一直被一个你遗忘的文件压在下面。
转换不再意外丢失作用域。一旦你了解只有 AGENTS.md 和 CLAUDE.md 会被层级发现，“将所有内容移动到原生格式”就不再是一个显而易见的清理方案了。
溢出不再是隐形的。Augment 的上限带有文档记录的应用顺序，因此一个接近 49,512 个字符的团队知道哪个类别会首先降级，而不是去猜测为什么某个规则不再适用。
双界面问题也有了名字。在 VS Code 中有效但在 CLI 中被跳过的 manual 规则并不是你通过阅读规则文件就能发现的 bug；这是文档记录的行为，你要么围绕它进行设计，要么被它惊吓到。
在 Augment Code 第一个月的最佳实践
在转换前进行盘点。列出仓库中的每个 CLAUDE.md、AGENTS.md、.augment-guidelines 和 .augment/rules/ 文件，并写下你期望加载哪些文件。然后从每个文件中测试一条刻意设计的奇特规则，看看哪一条实际生效。这是捕获我们在为什么智能体忽略你的指令文件中描述的情况的最快方法。
保持嵌套文件嵌套。目录作用域在两种外部格式中是免费提供的，但在原生格式中不可用。这是一个不同寻常的激励机制，它倾向于让你保留原有的目录树。
将 description 字段写为触发条件。对于 agent_requested 规则，描述是整个激活机制。“React 组件开发模式和最佳实践”——Augment 自己的例子——比规则内容的摘要更好。
将 ~/.augment/rules/ 仅视为“总是启用”的规则。那里的 frontmatter 会被忽略，因此你放在主目录中的任何内容都适用于你打开的每个项目。请将其保留给真正的个人偏好。
不要依赖 Augment 的自动导入来查找所有内容。它“会寻找 markdown 文件，例如以 *.md 或 *.mdx 结尾的文件”，这很有帮助，但与清单（manifest）不同。如果某个规则很重要，请将其放在优先级列表指定的某个位置。
请记住，这两种工具都不强制执行。Claude Code 说得很明白——“Claude 将它们视为上下文，而不是强制配置”，并建议使用 PreToolUse 钩子“无论 Claude 做出什么决定都阻止某项操作”。规则描述的是意图。强制执行是另一个层面的事，在这次迁移的双方都是如此。关于内部约定的这个问题在让 Claude 坚持你的约定中有所涵盖。
结论
这次迁移中令人惊讶的不是有什么东西坏了。而是有一段时间什么都没坏。CLAUDE.md 在 Augment 的优先级列表中排在第二位，因此你的指令层可以继续工作，而该工具的原生格式则在下面闲置。
值得有意识做出的两个决定：CLAUDE.md 是否保持权威，以及是否将任何嵌套文件平铺到 .augment/rules/ 中——因为该目录仅从工作区根目录加载。做好这两点，这将是成本最低的智能体迁移之一。如果做错了，你将花费数周时间去调试那些从未加载过的规则，而该工具在此期间其实一直在读取你的旧文件。