为什么 Cursor 会重新开始，以及究竟什么会被传递
规则可以存放的四个地方
Cursor 文档中定义的集合：
项目规则 (Project rules) 以 .mdc 文件的形式存在于 .cursor/rules 中，并进行版本控制。它们“使用路径模式进行范围限定、手动调用或根据相关性引入”。
用户规则 (User Rules) 是“在 Customize → Rules 中定义的全局偏好，适用于所有项目”。它们由 Agent (Chat) 使用，是存放沟通风格和个人习惯的理想场所。
团队规则 (Team Rules) 是“从仪表板管理的团队范围规则”，适用于 Team 和 Enterprise 方案。
AGENTS.md 被描述为“Markdown 格式的 Agent 指令。是 .cursor/rules 的简单替代方案”。它支持嵌套：将 AGENTS.md 放在任何子目录中，当处理该目录或其子目录中的文件时，它就会自动应用，其指令会“与父目录合并，且更具体的指令优先”。
大多数人只写了其中一种，并以为它涵盖了所有内容。
只有一种规则类型能保证始终存在
这就是核心所在。根据文档，Cursor 的四种规则类型如下：
| 规则类型 | 何时适用 |
|---|---|
| Always Apply | “应用于每个聊天会话” |
| Apply Intelligently | “当 Agent 根据描述判定其相关时” |
| Apply to Specific Files | “当文件匹配指定模式时” |
| Apply Manually | “在聊天中被 @ 提及之时” |
在底层，由三个 frontmatter 字段决定。alwaysApply: true 意味着“始终包含。忽略 Globs 和描述。”当 alwaysApply: false 且提供了 globs 时，规则会“在匹配的文件处于上下文中时自动附加”。如果只有描述而没有 globs，“Agent 会读取描述并在相关时拉入规则”。如果两者都没有，则是“仅在您在聊天中 @ 提及该规则时包含”。
因此，你三周前写的一个没有设置 frontmatter 字段的规则，一直在等待一个你从未输入过的 @ 提及。它并没有丢失，只是从未被邀请。
Cursor 官方的 FAQ 回答是最快的诊断方式：“检查规则类型。对于 Apply Intelligently，确保定义了描述。对于 Apply to Specific Files，确保文件模式与引用的文件匹配。”
.cursor/rules 中的普通 .md 文件会被静默忽略
这是最浪费时间的失败，因为没有任何提示。直接引用文档：“.cursor/rules 中的普通 .md 文件会被规则系统忽略，因为它没有 frontmatter 来指定 description、globs 和 alwaysApply。如果您更喜欢纯 Markdown，请改用 AGENTS.md。”
如果你一直在 .cursor/rules 内部维护 notes.md 并纳闷为什么没有任何变化——原因就在这里。请将其重命名为 .mdc 并添加 frontmatter，或者将内容移至 AGENTS.md。
规则加载了，但它引用的内容没有加载
规则在设计上就是简短的。Cursor 的指南建议将它们保持在 500 行以内，将大型规则拆分为可组合的规则，并且——重要的是——“引用文件而不是复制其内容——这可以保持规则简短，并防止它们随着代码更改而过时。”你可以使用 @filename.ts 引入文件。
这产生了一个二阶差距。“遵循我们的服务约定”只有在约定可触及时才起作用。规则是一个指针加方向，它本身并不是知识。在不同的工具中，这种区别正是为什么 Agent 会忽略你编写的指令文件的原因。
规则保存的位置并不总是你想象的地方
规则会被提交到 git，这也是团队共享它们的方式——但新规则会保存在你当前工作文件夹的 .cursor/rules 中。如果你将一个子文件夹作为项目打开，你的规则范围就会被限定在该子文件夹中。这是一个只需五秒钟的检查，却能省去一下午的麻烦。
人们尝试过的方法
在每次聊天开始时重新解释项目。 确实有效，但每次都要付出相同的代价——这就是如何停止向 AI 重复解释上下文中提到的死循环。
编写一个庞大的、始终开启的规则。 它确实适用于每个会话，并且在每条消息的模型上下文开头都会包含它。Cursor 官方列出的避免事项中包括“复制整个风格指南”——请改用 linter——以及“记录每一个可能的命令”，因为 Agent 已经知道 npm, git 和 pytest。
永远保持一个聊天窗口打开。 这只是推迟了边界，而不是跨越了边界。
将所有内容设置为 Apply Intelligently（智能应用）。 听起来很合理，但这把决定权交给了你花五秒钟写出的描述。如果描述含糊不清，规则就不会被引入。
将架构决策粘贴到规则中。 直觉是对的，但容器错了——规则应该保持简短并指向具体事物。这就是为什么 Cursor 会遗忘架构决策背后的原因。
手动在机器之间同步规则。 很常见，但容易产生偏差。跨机器边界的版本在如何防止 Cursor 跨机器遗忘中有所介绍。
解决方案：规范规则类型，然后将推理逻辑保留在规则之外
分两步走。第一步让 Cursor 加载你编写的内容。第二步为 500 行上限无法容纳的知识提供一个归宿。
审计你现有的规则并修复扩展名。 打开 .cursor/rules。任何以 .md 结尾的文件都会被忽略——将其转换为带有 frontmatter 的 .mdc，或者将其移至 AGENTS.md。
为每个规则分配最窄但始终正确的类型。 通用约束使用 alwaysApply: true。特定语言或目录的约定使用 globs。情境指南使用具体的描述，以便 Agent 能够真正判断相关性。极少需要的流程保持手动，并通过 @ 提及。
将全局内容与本地内容分开。 沟通风格和个人习惯属于 Customize → Rules 下的 User Rules。仓库约定属于项目规则或 AGENTS.md，并提交到 git，以便你的团队也能获取它们。
使用嵌套的 AGENTS.md，而不是复杂的 glob 匹配。 一个根文件加上每个主要目录一个文件，无需任何 frontmatter 即可实现范围限定，且更具体的指令会胜出。
指向规范示例，而不是复制它们。 使用 @file 引用。Cursor 的文档明确指出了原因：随着代码的更改，副本会过时。
这解决了加载问题。但它无法处理规则刻意排除的层面——为什么架构是这样的、你已经尝试并放弃了哪些方法、使某个奇怪决策变得正确的约束条件。Cursor 的指南是，当你发现 Agent 重复犯错时添加规则，这是一个很好的建议，但也承认了规则捕获的是结论，而不是推理过程。
这就是 MemoryLake 的作用：将你项目的持久知识保存在一个你的工具可以读取的层中，从而使规则保持简短，同时推理逻辑依然可用。设置只需三个步骤。
步骤 1：创建 API 密钥
登录 MemoryLake 并创建 API 密钥。一个凭证即可连接你使用的所有工具。
步骤 2：上传你的第一批记忆
编写简短的条目——每条记录一个主张——涵盖规则文件不适合承载的内容：
带有约束条件的决策。 “查询通过 repository 层进行，因为 ORM 的预加载（eager loading）破坏了分页。”规则可以陈述前半部分。但只有这种版本才能阻止该建议再次出现。
你已经否决的方法。 这是价值最高的类别，而且在仓库中无处可寻。每个新会话都会再次提出它。
跨仓库知识。 适用于跨项目的领域词汇和标准。项目规则在设计上是针对单个仓库的，而这并非如此。
你进行过多次的纠正。 这是 Cursor 自身编写规则的启发式方法——而纠正背后的推理逻辑就应该放在这里，紧挨着它。
步骤 3：连接你的 AI 和 Agent
连接你使用的工具。MemoryLake 可通过 MCP 和 API 访问，因此原生支持 MCP 的 Agent（包括 Claude Code、Codex 和 OpenClaw）可以通过指向 MCP 服务器进行连接，而其他助手则通过 API 读取相同的记忆。
三个坦诚的局限性。MemoryLake 不会编写你的 Cursor 规则，也不是它们的替代品——规则是你引导 Agent 的方式，你仍然应该正确地编写它们。它只保存你或你的 Agent 写入其中的内容，因此步骤 2 是手动的。而且规则是提示词级别的上下文，而不是强制配置，这是 Cursor 的框架，而不是我们的；记忆层并不会改变这一点。
这在实践中带来了什么改变
“为什么它没有遵守规则？”变成了一个只需两秒钟的检查。 扩展名，然后是类型，最后是模式。几乎总是这三者之一。
始终开启的规则变得简短。 当实质内容存在于其他地方时，始终开启的文件又变回了少数几个真正的约束条件，而不是随每条消息一起发送的文档。
新仓库不再是一个全新的开始。 项目规则不会在仓库之间转移。保存在它们之外的知识则可以。
团队入职培训不再是口口相传的历史。 提交的规则给出了约定；记忆层给出了原因。新员工两者都需要，而通常只有其中之一被记录了下来。
你的其他工具也能看到相同的上下文。 无论阅读它的是 Cursor、Claude Code 还是 Codex，你架构背后的推理逻辑都是完全相同的——这就是持久记忆的真正含义中所涵盖的形式。
持久有效的 Cursor 规则最佳实践
在 .cursor/rules 中使用 .mdc，或者使用 AGENTS.md。 绝不要在 rules 目录中使用普通的 .md——它会被忽略。
为每个规则深思熟虑地设置类型。 不要让 frontmatter 留空并寄予希望。留空意味着手动。
编写陌生人也能据此路由的描述。 “后端的 RPC 服务约定 and 模式”是可路由的。而“后端的东西”则不行。
将规则保持在 500 行以内，并拆分增长的内容。 这是 Cursor 官方给出的数字，而且当范围发生变化时，可组合的规则更容易重新编写。
引用文件，不要复制它们。 副本会过时；@file 引用则不会。
被动地添加规则。 文档说得很清楚：当你注意到 Agent 反复犯同样的错误时，再添加规则，在了解你的模式之前不要过度优化。
将规则提交到 git，并保持更新。 你甚至可以在 GitHub issue 或 PR 上标记 @cursor，让 Agent 为你更新规则。
首选嵌套的 AGENTS.md 进行目录范围限定。 需要维护的 frontmatter 更少，且优先级是可预测的。
将原因存储在规则之外。 规则用于引导和指向。而“为什么”才是让 Agent 能够处理你未预料到的情况的关键，它无法容纳在 500 行以内——这就是为什么 RAG 不是记忆中的普遍问题。
结论
Cursor 明确指出，模型在补全之间不会保留记忆，而 Rules（规则）是提示词级别持久、可重用上下文的机制。因此，跨会话传递上下文就是要把四件事做好：文件扩展名、规则类型、范围以及规则保存的位置。解决这些问题，大部分“它忘了”的情况就会消失。
剩下的则是规则在设计上不予承载的部分。它们有上限，旨在指向文件而不是复制文件，并且它们捕获的是结论而不是论证过程。将决策、约束和被否决的方法放在你的工具可以读取的层中，保持你的规则简短且类型正确，这样每个新会话都将同时拥有指令及其背后的原因。