实际传输的内容
页面会传输为 Markdown，这正是你需要的格式。 单个页面可以导出为 PDF、HTML 或 Markdown & CSV。对于整个工作区，设置 → 工作区 → 常规 → "导出所有工作区内容" 会提供 HTML、Markdown 或 CSV —— 其中 Markdown & CSV 选项会为每个页面生成一个 .md 文件，为每个数据库生成一个 CSV，并将子页面和资产保存在旁边的文件夹中。
在开始之前，有几个限制值得了解：
- "包含子页面" 会使嵌套页面作为单独的文件下载。对于单个页面导出，这是商业版（Business）和企业版（Enterprise）计划的功能；但无论如何，它都适用于所有工作区导出。
- 大型导出通过电子邮件发送。 Notion 会发送一个下载链接，而不是直接开始下载，并且该链接会在 7 天后过期。根据工作区的大小，处理可能需要长达 30 小时，因此工作区导出是你在午饭前启动的事情，而不是你干等着的事情。
- 你只能得到你能看到的内容。 "导出者无权访问的页面（例如其他用户的私有页面）将不会包含在导出中。" 如果真正的架构文档存在于队友的私有页面中，它就不会出现在你的导出中，并且你不会收到任何提示。
- 工作区 PDF 导出功能即将取消。 Notion 正在移除将工作区内容导出为 PDF 的选项，该变更将在 2026 年 8 月 31 日之前逐步推送到各个工作区。HTML、Markdown 和 CSV 仍将保留，单个页面也仍然可以导出为 PDF。如果你以前的备份习惯是导出工作区 PDF，那么这个习惯无论如何都需要改变了。
数据库会传输为 CSV，这比看起来更容易丢失信息。 Notion 数据库由行、视图、关联（relations）和汇总（rollups）组成。CSV 只给你行。任何从关联中计算出来的内容，即使能传输过来，也只是作为文本，而你实际用来理解数据的视图则完全无法传输。
Notion AI 本身不会传输，而且它也不应该被传输。 Notion AI 的价值在于对你的实时工作区进行解答 —— 整个工作区、最新的内容，包括你永远不会想到要交给编码智能体的页面。这确实是一个很好的功能， Cursor 无法复制它。这次迁移并不是要 "离开 Notion"；对于大多数团队来说，正确的最终状态是 Notion 仍然保留文档，同时在代码所在的地方也存在与构建相关的子集。
页面之间的链接大多会断开。 Notion 的内部链接是工作区 URL。在导出的文件夹中，它们要么指向 Notion（如果你保留工作区，这没问题，但离线时就没用了），要么解析为与智能体预期不符的文件名。请做好准备，你导出的文档会比它们在 Notion 中看起来更扁平、关联度更低。
手动迁移
步骤 1：导出编码智能体实际可以使用的页面
不要一上来就进行整个工作区的导出。这是最慢的途径（长达 30 小时），它会拖进会议记录和营销页面，而且庞大的体积保证了你会跳过真正重要的筛选步骤。
相反，浏览你的 Notion 侧边栏，并将页面分类到三个桶中：
- 与构建相关且持久的 —— 规格说明书、架构文档、模式（schema）、API 契约、决策日志、客户的硬性限制。这些是你要导出的内容。
- 与构建相关但易变的 —— 冲刺看板、任务数据库、状态页面。把它们留在 Notion 中。编码智能体无法从上周看板的快照中受益，而且该快照在几天内就会失效。
- 与构建无关的 —— 其他所有内容。工作区的大部分内容。
然后导出第一个桶。打开每个页面，使用其导出选项，选择 Markdown & CSV，并在该页面是父页面时开启 "包含子页面"（如果你所处的计划不支持单页子页面导出，则使用工作区导出）。你将获得 .md 文件以及一个资产文件夹。
在进行过程中，有两件事需要检查。第一，你期望的某些内容是否因为存在于某人的私有页面中而缺失 —— 如果决策日志有缺失，通常就是这个原因。第二，你导出的页面是否其实是一个伪装的数据库；如果模式存在于 Notion 表格中，你得到的 CSV 将是缺少关联的行，你会想要正确地写出该模式，而不是交付一个描述不完整的 CSV。
步骤 2：将 Notion 页面转换为规则和仓库文档
导出的 Notion 页面本身并不是一个有用的智能体输入。Notion 页面是为人们浏览而写的 —— 标题、折叠菜单、标注、中间的表格、顶部三段历史记录。Cursor 需要一个简短的常驻规则，或者一个可以指向的文档。
根据这种区别进行拆分，因为 Cursor 有两个不同的归宿：
常驻规范 → `.cursor/rules`。 项目规则以 .mdc 文件的形式保存在 .cursor/rules 中，受版本控制，包含 frontmatter 字段 description、globs 和 alwaysApply，并有四种激活模式：
- Always Apply（总是应用） —— 每次聊天会话
- Apply Intelligently（智能应用） —— 当智能体根据描述决定其相关时
- Apply to Specific Files（应用于特定文件） —— 当文件匹配某种模式时
- Apply Manually（手动应用） —— 在聊天中被 @ 提及（@-mentioned）时
利用这种粒度。你的 API 规范可以使用指向 API 目录的 globs。你的通用工程标准可以放入 Customize → Rules 下的 User Rules 中，这些规则适用于所有项目。Cursor 的文档建议将规则保持在 500 行以内，并将较大的规则拆分为可组合的片段 —— 这是个好建议，因为任何“总是应用”的内容都会在每次请求时加载。你也可以在项目根目录中使用 AGENTS.md 作为 .cursor/rules 的替代方案，包括子目录中的嵌套文件。
参考资料 → 仓库文档。 模式、规格说明书、决策日志以 Markdown 形式放入 docs/ 中，并进行清理：结论在前，修剪历史，保留日期。然后，规则中的一行字就可以告诉智能体去哪里寻找 —— "在更改 db/ 下的任何内容之前，请先阅读 docs/schema.md" —— 而不是将内容粘贴到每次都会加载的规则中。
坦白面对你所构建的东西。Cursor 自己的文档解释了为什么存在这种机制： "大型语言模型在补全之间不保留记忆。规则在提示词级别提供持久的、可重用的上下文。" 规则在每次请求时重新提供上下文。它们保存了你导出并清理的内容（截至你操作的那天）—— 而 Notion 仍在不断更新。
这种分歧是人们低估的部分。下个月 Notion 中的规格说明书更新了，但你的 docs/spec.md 没有更新。两个月后，智能体正在针对一个过时的副本进行构建，而每个人都以为它正在读取最新的副本。
更好的方法：统一的记忆层，文档与代码
看看步骤 2 是什么：你导出了一个产品知识的快照，手动将其转换为另一个产品的格式，并创建了第二个会与第一个产生偏差的副本。
这种偏差才是真正的成本，而不是花费的那个下午。这正是两者之间的记忆层所解决的具体问题：不再是仓库中的过时副本，而是一个存储库保存与构建相关的知识，并且你的两个助手都从中读取 —— 这样，记录一次的决策就是每个工具都能看到的决策。
MemoryLake 就是为此而生的记忆层 —— 模式、决策、限制条件都保存在一个存储库中，Cursor 可以通过 MCP 读取，其他任何工具可以通过 API 读取。导出不再是一次迁移，而是变成了一种在文档发生变化时可以重复的摄取（ingestion）过程。
客观地看待双方的优势。Notion 确实是一个非常适合存放文档的地方 —— 协同编辑、结构、权限，以及 Notion AI 跨整个工作区的解答，这些是任何规则文件都无法比拟的。保留它。而 .cursor/rules 是版本控制中的纯文本，在拉取请求（pull requests）中进行审查，并由你的团队自动继承；对于常驻规范，也保留它。记忆层则是为了介于两者之间的知识：对于规则文件来说太长，对于作为快照留存来说太重要，且需要被多个工具使用。
步骤 1：创建 API 密钥
生成一个密钥，并在大约 30 秒内发出你的第一次请求。将其保存在你的环境变量或机密管理器中，而不是保存在会被提交的配置文件中。
步骤 2：上传你的第一批记忆
放入你刚刚筛选的文档、图像和文件：规格说明书、架构文档、模式、决策日志、客户限制条件。尽可能上传导出的源文件，而不是你浓缩的摘要 —— 你可能在摘要中省略掉的限制条款，通常是六周后起关键作用的那一个。
步骤 3：连接你的 AI 和智能体
让 Claude、Codex、OpenClaw 和其他 AI 智能体通过 MCP 或 API 访问记忆。Cursor 支持 MCP 服务器，所以这只是一个配置项。对于没有 MCP 客户端的工具，通过 API 检索你需要的内容并将其注入到提示词或工作流中。
这在实践中带来了什么改变
第一个区别是，"我们对租户模式做出了什么决定？" 这个问题会在编辑器中得到解答，并附带推理过程，而不是让你跳转到 Notion 标签页。
第二个区别是，过时副本的问题不复存在。当存储库是双方都读取的源头时，更新决策就会在所有地方同步更新 —— 而不是更新了 Notion，却留下一个在暗中与之一致性冲突的 docs/ 文件。
第三个区别是被否决的方案会一直保持被否决状态。交接后最常见的失败是智能体提出了规格说明书中明确排除的方法，因为该排除决定存在于一个没人导出的 Notion 页面中。一旦它带着原因存在于存储库中，这种情况就会停止。
而且这具有普适性。“规格说明书存在于文档工具中，代码存在于编辑器中”的模式是相同的，无论文档工具是 Notion 还是其他工具，也无论编辑器是 Cursor 还是下一个新工具 —— 这与将研究转移到编码智能体中以及将原型升级为真正的编辑器最终需要相同的层是同一个原因。
迁移的最佳实践
在导出前进行筛选，而不是在导出后
工作区导出可能需要 30 小时并给你所有内容，这意味着你会跳过整理。十个精选页面胜过四百个页面，而且正是在整理过程中，你才会注意到“当前”的规格说明书有三个相互冲突的版本。
根本不要导出易变页面
冲刺看板、任务数据库和状态页面在导出后几天内就会失效。把它们留在 Notion 中，并在需要时指向 Notion。动态数据的快照比没有数据更糟糕，因为它们看起来很权威。
检查因权限导致的缺失
你的导出静默地忽略了你无权访问的页面，包括队友的私有页面。如果决策日志看起来比你记忆中的要单薄，这是首先要检查的事情 —— 解决办法是去问人，而不是重新运行导出。
正确编写模式，而不是交付 CSV
Notion 数据库导出为行。关联、汇总和视图 —— 那些使其易于理解的部分 —— 无法保留。如果数据库是你在结构化内容方面的唯一事实来源，请将其写成文档，并在正文中说明其关系。
为你结转的每个文档标注日期
导出的文档是一个快照，而这次迁移的全部风险在于快照被误认为是最新内容。在文件中放入导出日期。这只需要一行字，却能区分一个过时的文档和一个具有误导性的文档。
结论
从 Notion 到 Cursor 是一次转换，而不是简单的传输：将与构建相关的页面导出为 Markdown & CSV —— 按单页导出，或从设置 → 工作区 → 常规导出整个工作区，需要注意的是，大型导出通过电子邮件发送且链接 7 天有效、可能需要长达 30 小时、不包括你无法访问的页面，并且在 2026 年 8 月 31 日之前将失去工作区 PDF 导出选项 —— 然后将常驻规范转换为有范围限制的 .cursor/rules，并将参考资料转换为你所指向的、带日期的仓库文档。
值得深思熟虑的选择是之后会发生什么。docs/ 中的快照可以为这个仓库服务，直到 Notion 在没有它的情况下继续更新。而双方都读取的记忆层意味着你记录一次的决策就是你的编辑器看到的决策，这是唯一一个在下个季度不需要重新做一遍的方案。