实际迁移了什么
首先来看看每种工具的官方文档，因为其中的差距并不在大多数人预料的地方。
Cursor 的规则文档明确说明了规则的用途和存在原因：
"大语言模型在多次补全之间不会保留记忆。规则在提示词级别提供了持久且可复用的上下文。"
规则是作为上下文注入的："应用时，规则内容会包含在模型上下文的开头。" 每个项目规则都是一个带有 frontmatter 的 .mdc 文件，frontmatter 字段决定了四种应用类型之一——Always Apply（始终应用）、Apply Intelligently（智能应用，"当智能体根据描述决定其相关时"）、通过 glob 模式的 Apply to Specific Files（应用到特定文件），以及通过 @ 提及的 Apply Manually（手动应用）。Cursor 还记录了优先级链："规则按以下顺序应用：团队规则 → 项目规则 → 用户规则。所有适用的规则都会合并；当指南发生冲突时，较早的来源优先。"
Amazon Q Developer 的项目规则存放在一个文件夹中，并且是纯 Markdown：
"项目规则定义在项目的 {{project-root}}/.amazonq/rules 文件夹中的 Markdown 文件中。"并且它们在没有声明条件的情况下被应用：
"一旦您创建了项目规则，每当开发人员在您的项目中与 Amazon Q 聊天时，Amazon Q 就会自动将它们用作上下文，并确保在生成答案时遵守它们。"
控制界面是聊天面板中的 Rules（规则）按钮，它列出了您的规则，并允许您为当前会话切换每个规则："带有复选标记的规则处于活动状态，并将应用于您的对话。" 同样的 .amazonq/rules 文件夹也适用于 GitLab 和 GitHub 中的 Amazon Q Developer，因此该层不仅限于 IDE。
所以迁移情况是这样的。规则的内容可以干净地迁移——在两边它都是 Markdown 文件中的正文。但规则的条件性无法迁移。Cursor 的四种应用类型缩减为一种有文档记录的行为加上每个会话的复选框。Amazon Q 的项目规则文档中没有任何内容描述用于 glob 匹配、基于描述的检索或手动 @ 调用的 frontmatter 字段。
还有第二件无法迁移的事情，这也是值得提前规划的事情。Amazon Q 有其自身生成的上下文层，而它恰好落入您即将迁移到的同一个文件夹中。
手动迁移
分为两个步骤。第一步是机械性的，第二步是人们常常忽略的。
步骤 1：剥离 frontmatter 并将条件融入正文
Cursor 对文件扩展名要求严格："每个规则都是一个 .mdc 文件，您可以随意命名。项目规则必须使用 .mdc 扩展名。.cursor/rules 中的普通 .md 文件会被规则系统忽略，因为它没有 frontmatter 来指定 description、globs 和 alwaysApply。"
Amazon Q 在另一个方向上同样明确——规则文件在 .amazonq/rules 中"必须是 Markdown 文件"，且文档显示的是没有 frontmatter 的普通正文。
字面值陷阱就在这里。如果您将 .cursor/rules/api.mdc 原封不动地复制到 .amazonq/rules/api.md，您就会将三行 YAML（description、globs、alwaysApply）带入一个其读取器没有记录如何使用它们的文件中。Amazon Q 不会报错。它会把 frontmatter 视为规则文本的一部分，而这些字段所表达的条件性将不复存在。
因此，请逐条规则执行以下操作：
对于原本是 Always Apply 的规则，删除 frontmatter 即可。这是一个干净的移植；它在 Cursor 中是无条件的，在 Amazon Q 中也是无条件的。
对于原本是 Apply to Specific Files 的规则，删除 frontmatter，并将适用范围写进规则本身的第一句话中。例如，glob 为 **/*.test.ts 的规则，其开头应写明该规则以测试文件为主题。您正在将机器强制执行的条件转换为陈述性条件，必须承认这在精度上是一种降级——模型现在是根据您的措辞而不是匹配的路径来决定相关性。
对于原本是 Apply Intelligently 的规则，description 字段曾是检索信号。请将其融入开头行，因为现在它必须作为普通正文而不是元数据来发挥作用。
对于原本是 Apply Manually 的规则，决定您是否真的希望它始终开启。其中一些规则之所以存在，正是因为它们默认不应该触发。这些规则适合完全不放入 .amazonq/rules，而是保存在您可以刻意调用的地方。
Cursor 自身的编写建议在迁移后依然适用，值得继续遵循：保持规则在 500 行以内，并且"引用文件而不是复制其内容——这可以保持规则简短，并防止它们随着代码更改而过时。"
如果您以前做过规则转换，这种形式会很熟悉——将 Cursor 规则迁移到 Codex AGENTS.md 在不同的目标格式中遇到了相同的 frontmatter 问题。
步骤 2：让您编写的规则避开重新生成路径
Amazon Q 可以为项目生成记忆库（memory bank），这就是迁移变得棘手的地方：
"Amazon Q 可以自动生成记忆库文件，提供项目结构、技术栈和产品信息的快速索引。此功能通过分析项目中的关键文件来创建摘要文件，帮助 Amazon Q 理解您的代码库，而无需在您每次提问时都分析整个项目。"
系统会生成四个文件——product.md、structure.md、tech.md 和 guidelines.md——并将它们写入 .amazonq/rules 下的 memory-bank 子文件夹中。这正是您刚刚将 Cursor 规则迁移进去的同一个文件夹树。
更新路径不是编辑，而是重建：
"如果您的项目发生变化，您可以让 Amazon Q generate 新的记忆库文件以更新其上下文。为此，请选择 Rules 按钮，然后选择 Regenerate Memory Bank。"
这会带来两个后果。首先，团队成员在 memory-bank/ 内手写的任何内容都会在下一次重新生成时被覆盖。其次，也是更重要的一点：因为这四个文件是通过分析您的代码生成的，所以它们只能包含您的代码中已经存在的内容。您保留一条写着"不要使用另一个 HTTP 客户端"的规则，其原因并不在代码中——因为另一个客户端根本不在那里。重新生成无法产生这句话，也永远不会产生。
这与该领域中另一个著名的记忆库形成了鲜明对比。Cline 的 Memory Bank 是一组指示智能体在工作进行时读取和更新的文件，因此其内容是智能体记录的关于项目状态的任何信息。Amazon Q 的记忆库名称相同，但来源相反：它是从代码库中生成的。两者没有优劣之分；它们是对不同问题的回答，而假设其中一个与另一个行为相同，正是团队丢失内容的原因。
因此，请将这两个层在物理上隔离开来。您迁移的规则作为独立文件直接放入 .amazonq/rules/ 中。让 memory-bank 子文件夹自动生成，并将其视为派生输出。如果您想塑造生成的内容，Amazon Q 记录了支持的方法——在 .amazonq/rules 中写一条描述您所需格式的规则，这是一个很好的特性：生成层由编写层引导，而不是相反。
更好的方法：一个比这两种工具更长寿的决策层
上面的一切都是翻译工作，下次更换工具时您还会再做一次。让您不断付出代价的不是文件格式，而是每条规则背后的推理从未存储在特定于工具的文件之外的任何地方。
MemoryLake 在这两个产品之外为这些推理提供了一个归宿，并通过 MCP 或 API 将其提供给任何提出请求的智能体。Cursor 保留其规则，Amazon Q 保留其记忆库，一切保持原样；而它与它们并存，并保存了这两者都未设计去存储的层——您决定了什么、拒绝了什么，以及原因。
步骤 1：创建 API 密钥
生成密钥并在大约 30 秒内发出您的第一次请求。在开始重写规则文件之前执行此操作，这样您在进行过程中就有地方存放推理。
步骤 2：上传您的第一批记忆
在处理上面步骤 1 中的每个 .mdc 文件时，您会发现自己在重新构建规则存在的原因。在进行过程中捕获这些内容：约定、您拒绝的替代方案，以及背后的事件或限制。同时放入支持的文档、图表和文件。
步骤 3：连接您的 AI 和智能体
允许 Claude、Codex、OpenClaw 和 Amazon Q 通过 MCP 或 API 进行访问。能够查询决策层的智能体在回答"为什么这里有这个约定"时会附带原因，而不是仅仅向您重复该规则。
这在实践中改变了什么
最直接的变化是，您在步骤 1 中丢失的条件性变得不再那么重要。glob 范围的规则存在的部分原因是为了将无关的指导排除在上下文窗口之外。当推理存在于智能体按需查询的存储中时，.amazonq/rules 可以保持真正的简短——仅包含常驻命令——而长尾内容是在相关时才被检索，而不是因为可能相关就被加载。
第二个变化体现在第一次执行 Regenerate Memory Bank（重新生成记忆库）时。您不会丢失任何东西，因为值得保留的东西从未存在于生成的文件中。
第三个变化是部分迁移不再是问题。许多团队在不同的代码库或团队的不同部分并排运行 Cursor 和 Amazon Q 达数月之久。两种格式的两个规则文件夹会发生偏离。而两个智能体都读取的同一个决策层则不会。
第四个变化发生在下一次迁移时。规则文件会再次被翻译。但推理不会，因为它从未存在于规则文件中。
从 Cursor 迁移到 Amazon Q 的最佳实践
一次只迁移一条规则，并阅读每一条。 批量复制是这里的失败模式，因为它保留了在另一端毫无意义的 frontmatter，并默默丢弃了代表一切的条件。
切勿在 memory-bank/ 内手动编写。 它是生成的输出。请将您的文件直接放入 .amazonq/rules/ 中。
在以前带有 glob 的规则中明确说出范围。 在规则开头写明它适用的文件或目录。您已经将强制执行的条件转换为陈述性条件；让这一陈述不容忽视。
使用规则来塑造生成。 Amazon Q 支持通过项目规则自定义记忆库输出。这是编写层和生成层之间有文档记录的接缝——使用它，而不是编辑生成的文件。
不要以为固定（pinning）能帮到您。 上下文固定在文档中被记录为仅在 VS Code IDE 中可用，且固定项仅适用于当前聊天标签页——新标签页会重新开始。这是一种针对单次对话的便利，而不是持久的项目层。
在两个工具都不拥有的地方，写下一次“为什么”。 这是这项工作中唯一不会重复的部分。
结论
从 Cursor 到 Amazon Q Developer 的迁移很容易被低估，因为双方都在项目文件夹中使用 Markdown。内容可以移植。但条件性不行：Cursor 的四种有文档记录的应用类型在 Amazon Q 的项目规则中没有对应的文档记录，如果您直接复制，.mdc frontmatter 中的四个字段就会变成无用的文本。
第二件需要做对的事情是文件夹规范。Amazon Q 的记忆库生成在同一个 .amazonq/rules 树的子文件夹中，并且它是重建而不是编辑的。它是对您代码库所包含内容的真正有用的索引——也正因如此，它无法保存您的代码库中不包含的决策。
仔细进行转换，将编写的内容和生成的内容保存在不同的地方，并将推理放在能够经受住下一次工具变更的地方。那么，这就是您最后一次从头开始进行这种特定的转换了。