实际可以迁移的内容
在 Trae 侧。 Trae 将项目级规则保存在 .trae/project_rules.md 中，将用户级规则保存在 .trae/user_rules.md 中。它还会在项目中创建一个 .trae/rules/ 目录，你可以在其下方的子文件夹中组织规则文件——系统会递归读取这些目录。在聊天中，可以通过 #rulename 调用规则，所有内容都是纯 Markdown 格式，专门为了方便进行版本控制并在团队中共享。MCP 支持和 .rules 在 Trae v1.3.0 中一同推出，因此你配置的任何 MCP 服务器都是可以继承的概念，而不是会丢失的东西。
在 Cursor 侧。 项目规则以 .mdc 文件的形式保存在 .cursor/rules 中，每个文件都有四种启用模式之一：Always Apply（始终应用）、Apply Intelligently（智能应用）、Apply to Specific Files（应用到特定文件）和 Apply Manually（手动应用）。Cursor 还会读取仓库根目录下的纯文本 AGENTS.md，这也是 Codex、Amp、Jules 和 Factory 等读取的开放格式。不应提交的个人偏好设置则放入 Cursor 设置中的 User Rules（用户规则）中。
因此，映射关系非常直接：
| Trae | Cursor |
|---|---|
.trae/project_rules.md | .cursor/rules/*.mdc 或根目录 AGENTS.md |
.trae/user_rules.md | Cursor 设置中的 User Rules |
.trae/rules/ 子文件夹 | 独立的 .mdc 文件，每个关注点一个 |
#rulename 调用 | Apply Manually 模式，在聊天中引用 |
| MCP 服务器 | MCP 服务器，在 Cursor 中重新配置 |
无法迁移的内容。 分为三类，痛苦程度递增：
- 会话历史。 你的 Trae 对话会留在 Trae 中。没有任何工具能帮你读取它们。
- 你留在聊天中而不是文件中的内容。 大多数人在每个会话中解释的内容远比他们写下来的要多。这些解释从未在任何地方持久化。
- 被否决的方法。 这是最昂贵的损失，因为 Cursor 会兴高采烈地提出你已经尝试并回滚过的重构方案，而你将不得不花一个下午的时间重新决定一个已经解决的问题。
值得注意的是 Trae 社区为此开发的应对方案：有一些针对 Trae 的第三方工作流连续性工具包，它们可以在一个命令下保存上下文，并在另一个命令下恢复，这正是因为会话连续性必须手动构建。如果你一直在使用类似的东西，这些保存的文件就是你进行此次迁移的最佳原材料。
手动迁移
步骤 1：移动规则，并顺便进行拆分
不要将一长串 project_rules.md 直接粘贴到一个长长的 .mdc 文件中。只有当规则按关注点分离时，Cursor 的启用模式才能发挥作用。
- 阅读
.trae/project_rules.md并将其拆分为不同的主题：构建和测试命令、目录规范、代码风格、安全约束，以及关于特定子系统的任何内容。 - 在
.cursor/rules中为每个主题创建一个.mdc文件，并审慎设置其模式。通用约束设为 Always Apply。特定子系统的规则设为 Apply to Specific Files 并配合 glob 匹配。偶尔使用的指南（如发布清单、迁移步骤）设为 Apply Manually，并在需要时调用，就像你在 Trae 中使用#rulename一样。 - 不要将所有内容都设置为 Always Apply。 这很有诱惑力，但代价高昂：每条始终开启的规则都会在每次代码补全时消耗 Token。这是规则迁移中最常见的错误，它会体现在你的账单上，而不是报错信息中。
- 将
.trae/user_rules.md移入 Cursor 的 User Rules 中，而不是提交它——个人偏好不应该出现在代码仓库中。 - 如果你的项目可能会被多个 Agent 接触，考虑将与工具无关的核心内容放入根目录的
AGENTS.md中，因为 Cursor 和其他几个 Agent 都会读取它。 - 在 Cursor 中重新配置你的 MCP 服务器，并在依赖它们之前确认每一个都能正常响应。
步骤 2：重建规则从未承载的内容
抽出一个小时，写下那些只存在于 Trae 会话中的知识：
- 决策及其原因。 "队列消费者保持单线程，因为退款顺序很重要"——这一行字就能在未来一年里避免一个糟糕的建议。
- 死胡同。 尝试过并回滚的方法，以及原因。这是阻止死循环的关键。
- 本地陷阱。 在 Windows 上不稳定的测试、绝不能手动编辑的生成文件、必须在 seed 之前运行的迁移。
- 来自已保存上下文文件的任何内容。 如果你使用了 Trae 连续性工作流，现在就去挖掘这些存档——它们是你拥有的唯一会话书面记录。
将这些写成知识，而不是规则。它不属于始终开启的 .mdc，因为它每周都在增长，没有人愿意为每次补全支付 900 行前导内容的 Token 费用。
更好的方法：统一的记忆层，适用于任何编辑器
这就提出了一个显而易见的问题：这些内容到底应该放在哪里？
这两款编辑器都为你提供相同的两样东西——一个规则文件和每个会话的全新上下文。这就是为什么迁移很容易，但同时也是有损的。规则是约束的理想归宿，但不是积累知识的合适场所，而 Trae 和 Cursor 都没有提供第三个地方来存放它。因此，它最终留在了聊天中，而聊天会随着会话的结束而结束。
解决方法是添加缺失的这一层，而不是写一个更长的规则文件。MemoryLake 是一个存在于编辑器之外的记忆层，可以通过 MCP 或 API 访问，因此知识不再特定于某个编辑器——下一次迁移也不再像是一次考古工程。
步骤 1：创建 API 密钥
生成密钥并在大约 30 秒内发出你的第一次请求。
步骤 2：上传你的第一批记忆
加载你刚刚写下的决策日志，以及人们不断重复解释的材料：架构说明、API 契约、运行手册、事件总结、图表。文档、图像和其他文件都存放在同一个地方。
步骤 3：连接你的 AI 和 Agent
让 Cursor、Claude、Codex、OpenClaw 和其他 Agent 通过 MCP 进行访问。你的 .cursor/rules 文件可以重新保持简短且符合规则的形式，而每周增长的知识则保存在每个工具都可以查询的地方——包括你明年将使用的任何编辑器。
实践中的改变
第一个改变是成本，而且是可衡量的。规则文件之所以膨胀，是因为它们承担了双重职责，而始终开启的规则在每次补全时都会被计费。将知识从规则中移出并放入可查询的层中，可以减少你每次请求支付的费用，同时增加 Agent 在真正需要时能够找到的内容。
第二个改变是，切换不再是单向的。目前，如果 Cursor 不适合你，换回去意味着又一次手动重建——因此人们往往会留在一个并不好用的工具上。当知识是外部化的时候，评估一个编辑器两周时间只需要改动一下配置。
第三个改变是团队的一致性。代码仓库中的规则文件是共享的，但你输入到 Trae 聊天中的上下文却不是。如果三个开发人员对架构为什么长成这样持有不同的心智模型，他们的 Agent 就会生成三种不同风格的代码——这与 Cursor 跨机器丢失上下文 是同样的失败，只是分散在不同的人身上。
迁移后的最佳实践
在第一周审计你的规则模式
打开每个 .mdc 文件，根据它被真正需要的频率来检查其启用模式。任何不是通用约束却设为 Always Apply 的内容都应该降级。Cursor 提供四种模式是有原因的，滥用其中一种正是规则文件悄悄变得昂贵的原因。
将知识日志保存在一个地方，而不是分散在三个文件中
迁移后，人们很容易将笔记散落在 README、注释和规则文件中。为积累的知识选择一个归宿，并将所有内容都汇集到那里。碎片化的知识在功能上等同于没有知识，因为没有任何工具能够检索到它的全部。
两周内不要删除你的 Trae 配置
保留 .trae/ 和你的 Trae 安装，直到你在 Cursor 中运行了整整一周，包括进行一次真正的调试会话。迁移遗漏绝不会在第一个小时内显现——它们会在你第一次需要你以为已经迁移过来的东西时出现。同样的谨慎也适用于任何编辑器的迁移，包括从 Copilot 迁移到 Cursor 或将 Cursor 规则导出到 Claude Code。
结论
从 Trae 迁移到 Cursor 是最容易的编辑器迁移之一：两者都将指令保存在 Markdown 中，都读取规则目录，都支持 MCP。将 .trae/project_rules.md 拆分为独立的 .mdc 文件，审慎设置启用模式，而不是默认将所有内容都设为 Always Apply，将用户规则移入 Cursor 的设置中，并重新连接你的 MCP 服务器。
然后，将节省下来的精力花在任何文件映射都无法覆盖的部分。这两款编辑器都不会存储你的会话所教给你的东西，因此决策和死胡同必须由人写下来——如果它们被写入始终开启的规则文件中，你将在每次补全时为此付费，并且在下一次迁移时仍然会丢失它们。编辑器之外的记忆层才能让上下文成为你保留的东西，而不是你重新构建的东西。这归根结底与 Trae 在会话之间丢失上下文 以及 Cursor 遗忘之前的会话 背后是同一个缺陷。