实际迁移了什么
规则内容可以干净地迁移。 Amazon Q 的项目规则是纯 Markdown，没有 frontmatter（前置元数据）——其文档指出规则文件“必须是 Markdown 文件”，并展示了纯文本的主体内容。Amp 的 AGENTS.md 也是纯 Markdown。将您的 .amazonq/rules/*.md 内容合并到代码库根目录下的 AGENTS.md 中，内容即可保持完整。
目录位置可以迁移，但默认范围更广。 Amp 的包含规则值得多读两遍：
“当前工作目录（或编辑器工作区根目录）以及父目录（上至$HOME）中的AGENTS.md文件始终会被包含。”
“当智能体读取子树中的文件时，子树中的 AGENTS.md 文件会被包含。”子树部分正是您想要的——每个区域一个指令文件，当智能体接触到该区域时加载。而父目录部分则是需要仔细检查的。如果您将多个代码库放在一个共享的父目录下，并且在通往您家目录的路径上的任何位置存在 AGENTS.md，它都会在每个代码库中加载。Amazon Q 文档中记录的规则位置是 {{project-root}}/.amazonq/rules，且其文档并未描述向上查找父目录的行为——因此，当您转向 Amp 时，这种延伸是全新的。
文件名回退机制对您有利。 Amp 文档指出：“如果目录中不存在 AGENTS.md，但存在名为 AGENT.md（没有 S）或 CLAUDE.md 的文件，则该文件将被包含。”因此，一个已经从其他工具中携带了 CLAUDE.md 的代码库会在每个目录下被自动识别。请注意优先级顺序——AGENTS.md 排在第一位，另外两个作为回退——这与某些智能体发布的顺序相反。
单会话规则选择没有对应的承接功能。 这是真正的改变。您在 Amazon Q 中的习惯是打开 Rules 按钮，并为当前任务选择一个子集。Amp 拥有一个始终开启的层和一个条件机制，而这个条件机制的工作方式有所不同：您从 AGENTS.md 中 @ 提及一个文件，而被提及的文件可以包含一个 globs frontmatter 字段。Amp 的文档指出：“只有当 Amp 读取了与任何 glob 匹配的文件时，带有 globs 的被提及文件才会被包含”，并且“如果没有指定 globs，则在被 @ 提及机制触发时，该文件始终会被包含。”
这是一种两步间接机制——在 AGENTS.md 中进行提及，加上被提及文件中的 glob 匹配——它是由智能体读取了哪些文件触发的，而不是由您在开始前选择的内容触发的。我们在将 Amp 的指令范围限制在适用的文件内中详细介绍了这一机制；这里的重点更窄。您的 Amazon Q 复选框是对此任务的声明。而 Amp 的 glob 是对这些路径的声明。这两者不可互换，您之前按任务选择的规则必须重新表达为关于文件路径的规则，或者接受它们作为始终开启的规则。
您的记忆库会作为静态文件迁移。 Amazon Q 可以生成一个记忆库——包含 product.md、structure.md、tech.md 和 guidelines.md 四个文件，写入 .amazonq/rules 下的 memory-bank 子文件夹中。其文档清楚地描述了该机制：该功能“分析您项目中的关键文件以创建摘要文件，帮助 Amazon Q 理解您的代码库，而无需在您每次提问时都分析整个项目。”更新它们意味着选择 Regenerate Memory Bank（重新生成记忆库）。
Amp 文档中记录的指令界面是 AGENTS.md 文件、技能和插件，这些页面中没有一个描述了生成或重新生成步骤。因此，这四个文件变成了您需要手动维护的普通 Markdown，其中三个描述了代码中已经阐明的内容。这种区别非常重要，以至于我们从另一个方向围绕它撰写了一篇完整的指南，即从 Cursor 迁移到 Amazon Q Developer。简而言之：工具可以从您的代码库中重新生成的任何内容，其实本来就已经存在于您的代码库中了。只有第四个文件 guidelines.md 可能包含任何解析器都无法生成的决策——而这正是需要手动迁移的文件。
压缩（Compaction）行为不同，且两个版本都不是持久的。 Amazon Q 记录了 /compact 命令，这是一种“替换上下文窗口中详细对话历史”的摘要，并补充了两个值得记住的细节：“在当前会话结束之前，您完整的对话历史在聊天界面中仍然可见”，以及“当您重启 IDE 时，详细的聊天历史将会重置”。Amp 的文档描述的是线程（threads）而不是压缩命令。无论哪种方式，对话都不是存放您下周需要的内容的地方。
没有可移植的会话记忆存储。 Amazon Q 的记忆库是一组生成的代码库摘要，而不是它记录的关于您的信息。Amp 的文档索引将 AGENTS.md、技能和插件描述为其自定义界面，并没有描述每个会话的记忆存储。因此，双方都没有存储库到存储库的迁移——这听起来像是省去了工作，但实际上，如果您不够谨慎，这也是导致迁移过程中丢失知识的原因。
手动迁移
步骤 1：按规则是关于任务还是关于路径进行分类
在 Amazon Q 中打开 Rules 按钮，并记录下对于每个规则文件，您实际上在哪些会话中勾选了它。这个列表才是您要迁移的东西，而不是文件本身。
您在每个会话中都会勾选的规则直接放入根目录的 AGENTS.md 中。这些是最简单的规则——内部规范、构建命令、审查清单。
您在特定区域工作时勾选的规则将变成子树中的 AGENTS.md 文件。将前端规则放在前端目录中。Amp 会在“智能体读取子树中的文件时”加载它，这比其他任何机制都更接近您的复选框行为。
您按文件类型勾选的规则将变成带有 globs 的 @ 提及文件。在 AGENTS.md 中添加一行提及，然后为被提及的文件提供一个 globs 列表。这里有两个字面细节需要注意。Amp 文档指出，“除非 glob 以 ../ 或 ./ 开头，否则它们会隐式地带有 **/ 前缀，在这种情况下，它们指的是相对于被提及文件的路径”——因此，一个单纯的 *.ts 会匹配任何地方，而不仅仅是该文件旁边。此外，“代码块中的 @ 提及会被忽略，以避免误报”，因此在围栏示例内部的提及将不起作用。
您按任务勾选的规则——例如“在此任务中使用严格的审查清单”——没有明确的去处。针对每条规则，决定它是变成始终开启还是被丢弃，并记录下您丢弃了哪些规则。这个类别是迁移中容易悄悄丢失行为的地方，因为规则文件仍然存在，但根本不会被应用。
然后进行验证。Amp 提供了一种查看结果的方法：“要查看 Amp 正在使用的智能体文件，请从命令面板中选择 agents-md list。”从您实际工作的目录（而不是代码库根目录）运行它，并将列表与您的预期进行对比——特别是那些您不知道自己拥有的父目录文件。
步骤 2：处理记忆库和家目录延伸问题
两项清理工作，现在做都比三个月后做要容易。
首先是记忆库。阅读所有四个生成的文件，并标记出解析器无法从代码库中生成的每一句话。在 product.md、structure.md 和 tech.md 中，这几乎没有内容——它们是代码的摘要，而代码依然存在。在 guidelines.md 中，这可能会有很多内容，因为 Amazon Q 允许您使用项目规则来塑造生成内容，而团队通常使用它来注入标准而不是描述。将这些解析器无法生成的句子移动到 AGENTS.md 中，并删除其余内容。将三个重新生成的代码库描述文件带入始终开启的上下文层，会在每次请求中消耗您的 Token，而且不会告诉智能体任何它无法自行读取的内容。
其次，遍历从您的工作目录到 $HOME 的路径，并列出其中的每一个 AGENTS.md、AGENT.md 和 CLAUDE.md。Amp 的父目录包含机制一直延伸到最顶层，并且它的两个 $HOME/.config 位置——$HOME/.config/amp/AGENTS.md 和 $HOME/.config/AGENTS.md——“如果存在，则始终会被包含”。根据您的平台，位于 /etc/ampcode/AGENTS.md、/Library/Application Support/ampcode/AGENTS.md 或 %ProgramData%\ampcode\AGENTS.md 的系统级文件也是如此。
如果您的组织部署了这些系统文件之一，那么您的有效指令集就会比您的代码库更大，而代码库中没有任何记录。在您开始调试找不到原因的行为之前，请先记录下那里有什么。这种练习的通用形式是审计您的 AI 实际记住了什么。
更好的方法：将任务级别的理由保存在路径 glob 无法触及的地方
您按任务选择的规则是这次迁移无法承载的，而它们也是最有价值的规则。您应用于每个文件的规则通常是一种规范。而您应用于这次修改的规则通常是一种判断——而判断是有原因的。
MemoryLake 保存了这些内容：决策、它适用的对象、它排除的内容以及原因。它不受路径范围限制，也不受会话范围限制，因此只有在上下文中才有意义的规则可以保留其上下文。从这里开始。
步骤 1：创建 API 密钥
为代码库创建一个工作区并生成一个 API 密钥。将范围保持在代码库级别，这样该层就不会与任何一个工具的配置目录绑定。
步骤 2：上传您的第一批记忆
从您在步骤 1 中无法安置的任务级规则（即您有选择性地勾选的规则）开始。对于每条规则，记录它适用的对象以及它存在的原因。然后添加在解析器测试中保留下来的 guidelines.md 中的任何内容，以及您在此次迁移期间做出的决策：哪些规则变成了始终开启，哪些变成了 glob，以及哪些被您丢弃了。
步骤 3：连接您的 AI 和智能体
连接 Amp，并在两者都在使用时保持 Amazon Q 的连接。两者都读取相同的决策集，因此您尚未重新表达为 glob 的规则仍然可以获取其背后的推理。
这在实践中改变了什么
您不再丢失选择性规则。您根据情况勾选的规则是转向始终开启模型时的首要牺牲品，因为当它们不再适用时不会报错——它们只是变成了无人阅读的文件。
您的始终开启层保持精简。您无需合并包括三个重新生成的代码库描述文件在内的所有内容，而是只携带解析器无法生成的句子，其余的留空。
调试有了一个起点。当 Amp 的行为无法用您的代码库解释时，您有一份写好的路径上父目录和系统文件的列表，并可以使用 agents-md list 进行确认。
而且您减少了重复解释。丢失规则的经常性成本是需要有人在提示词中重新阐述它，这就是如何停止向您的 AI 重复解释上下文中所描述的模式。始终开启或由 glob 触发的规则不需要重新阐述。而悄悄停止应用的规则则需要永远重复解释。
在 Amp 上第一个月的最佳实践
在第一周内，从三个不同的目录运行 agents-md list。结果会随着您的工作目录而变化，而这正是子树机制的全部意义所在。
当边界是目录时，首选子树文件而不是 glob。移动部件更少，无需考虑隐式的 **/ 前缀，而且文件就放在编辑该代码的人能够找到的地方。
让每个 glob 范围的文件只负责一项工作。当任何 glob 匹配时，Amp 就会包含一个被提及的文件，因此一个涵盖四个无关模式的文件加载的频率是其所需频率的四倍。
不要将个人偏好放在共享路径中。您打开的每个项目中始终会包含 $HOME/.config/amp/AGENTS.md。这是存放特定于设备的命令的正确位置，而不是存放您同事尚未同意的观点的正确位置。Amp 自己的表格也说明了这一点，将该位置列为“个人偏好、特定于设备的命令以及在提交到代码库之前在本地测试的引导”。
有意识地拆分大型子项目。Amp 的建议是保持“顶层 AGENTS.md 的通用性”，并在“每个子项目的子树中创建更具体的 AGENTS.md 文件”。这也是模拟 Rules 按钮为您所做工作的最廉价方式。
如果您以后再次迁移，您在此处构建的清单将使迁移成本变得极低——同样的清单使得从 Amp 迁移到 Codex成为一项文件操作，而不是考古工作，也是从 Claude Code 迁移到 Amp背后的相同清单。
结论
Amazon Q 给您一个复选框并要求您进行筛选。Amp 给您一个从工作目录一直延伸到 $HOME 的包含规则，并要求您小心留在该路径上的内容。两者都是合理的合理设计。两者互不包含。
顺利的迁移始于写下您当时选择了哪些规则以及原因——在文件移动之前，当答案还在您脑海中时。糟糕的迁移则是复制四个文件，删除一个复选框，并在六周后发现关于支付模块的规则自切换以来就从未应用过。