规则文件对照：Claude Code 的 memory 与 Cursor 的 rules 各自怎么被加载
一个仓库里同时躺着 CLAUDE.md、.cursor/rules/ 和一个 AGENTS.md，团队里有人用 Claude Code，有人用 Cursor，谁也说不清哪个文件在谁那边真的生效。这篇只做一件事：把两家官方文档里白纸黑字写明的加载规则摆到一起，按位置 → 触发条件 → 优先级这三层走一遍。两个产品都是闭源的，我们没有源码也没有做过实测，所以下面每一条都注明是谁的文档写的，文档没写的部分一律说没找到。
第一层：文件放在哪，谁负责发现它
Claude Code 官方文档《How Claude remembers your project》页把 CLAUDE.md 的存放位置列成一张表，表里按加载顺序从最宽的作用域排到最具体的，一共四档：
| 作用域 | 位置 |
|---|---|
| Managed policy | macOS /Library/Application Support/ClaudeCode/CLAUDE.md；Linux 与 WSL /etc/claude-code/CLAUDE.md；Windows C:\Program Files\ClaudeCode\CLAUDE.md |
| User instructions | ~/.claude/CLAUDE.md |
| Project instructions | ./CLAUDE.md 或 ./.claude/CLAUDE.md |
| Local instructions | ./CLAUDE.local.md |
发现方式是文件系统层面的：该页写明 Claude Code 从当前工作目录向上走目录树，逐级检查 CLAUDE.md 与 CLAUDE.local.md。也就是说，你在 foo/bar/ 里启动，foo/CLAUDE.md 和 foo/bar/CLAUDE.md 都会被读到。当前工作目录之下的子目录里的同名文件不在启动时加载，而是等 Claude 读那些子目录里的文件时才带进来。
Cursor 官方文档《Rules》页的划分方式不一样，它按来源分成四类：Project Rules、User Rules、Team Rules 和 AGENTS.md。对应的存放位置在《Rules》帮助页里写得更细：
- Project rules 在项目里的
.cursor/rules/，随 git 走 - Cursor Settings 里填的 User rules 存在你的 Cursor 账号上，跨项目生效并在你登录另一台机器时同步
- 另有一种 user rule 文件放在
~/.cursor/rules（该页写明 Windows 上是%USERPROFILE%\.cursor\rules），这一份留在本机、不同步 - Team rules 存在 Cursor 的服务器上，从 team dashboard 管理，自动同步给所有成员
第一处要想清楚的差别就在这儿：Claude Code 文档描述的规则位置全部落在文件系统上，你能用 ls 数清楚；Cursor 的 User rules 和 Team rules 按其文档所述存在账号与服务器上。同一个人换一台机器，按 Cursor 文档所述，Cursor 侧的 User rules 跟着账号走（~/.cursor/rules 那一份除外）；Claude Code 侧的 ~/.claude/CLAUDE.md 在文档里只被列为一个具体路径上的文件，我们在这两页里没有找到关于它跨机器同步的任何说明，所以别当它会自己跟过去。
第二层：什么时候被拉进上下文
两边都提供了「不要每次都塞进去」的条件加载，但触发条件的写法差别很大。
Claude Code 这边是 .claude/rules/ 目录。官方文档写明：目录下所有 .md 文件会被递归发现，子目录也算；没有 paths frontmatter 的规则在启动时加载，优先级与 .claude/CLAUDE.md 相同；带 paths 的规则用 glob 限定，文档原文的例子是这样的：
---
paths:
- "src/api/**/*.ts"
---
# API Development Rules
- All API endpoints must include input validation
- Use the standard error response format
- Include OpenAPI documentation comments
这里有一句很容易被跳过、但决定你怎么写 glob 的话：该页写明路径规则是在 Claude 读到匹配的文件时触发的，不是每次工具调用都评估一遍。
Cursor 这边是 .cursor/rules 下的 .mdc 文件，靠三个 frontmatter 字段组合。《Rules》页给了一张真值表，值得原样引一次，因为它把四种行为压在了三个字段里：
alwaysApply | description | globs | 行为 |
|---|---|---|---|
true | — | — | 总是包含，globs 与 description 被忽略 |
false | — | 有 | 匹配文件进入上下文时自动附加 |
false | 有 | 无 | Agent 读 description，判断相关时把规则拉进来 |
false | 无 | 无 | 只有你在聊天里 @ 提到这条规则时才包含 |
对照下来，Cursor 多出两档 Claude Code 的 memory 文档里没有对应说明的行为：按 description 让模型自己决定拉不拉，以及手动 @-mention。需要说明的是，Claude Code 文档在讲 .claude/rules/ 时加了一条注记，把「不需要一直在上下文里的任务型指令」指向了 skills——按其文档所述，skills 在你主动调用、或 Claude 判断与你的提示相关时才加载。这两者算不算同一档能力，文档没做这层比较，我们也不替它下结论。
还有一个纯属细节但会实打实咬人的地方：同样是规则目录，两边收的文件扩展名是反着的。Cursor 文档明说 project rules 必须用 .mdc 扩展名，.cursor/rules 里的纯 .md 文件会被 rules 系统忽略，理由是它没有 frontmatter 来指定 description、globs、alwaysApply；而 Claude Code 的 .claude/rules/ 收的正是 .md。如果你打算把一套规则在两边复用，这一步不能靠复制粘贴糊过去。
glob 语法两边也不完全一样。Cursor 文档的 globs 表里，多个模式用逗号分隔写在同一个 globs 值里（例如 docs/**/*.md, docs/**/*.mdx）；Claude Code 的 paths 是 YAML 列表，并且支持花括号展开（例如 src/**/*.{ts,tsx}）。Claude Code 文档还写了两个坑：花括号展开有预算限制，超出预算的模式会被原样使用而不展开，此时字面的花括号匹配不到任何文件；glob 把 [ 当作方括号表达式的开头，像 photos [2024/** 这种解析不出方括号表达式的模式是无效的，它谁也匹配不到（同一条规则里的其它模式照常工作），要匹配字面的 [ 得写成 photos \[2024/**。这两处都附了历史说明：v2.1.217 之前，带很多花括号组的 paths 会让 CLI 在启动时卡住或崩溃；v2.1.207 之前，一个无效模式会让 Read 工具对该规则评估到的每个文件都失败。
第三层：多条同时命中，谁说了算
Cursor 文档给了一条写死的链：Team Rules → Project Rules → User Rules，所有适用的规则合并，指导意见冲突时靠前的来源优先。它还补了一句同名文件的处理：Cursor 按完整文件路径识别规则，不是按文件名，两个同名但在不同文件夹的规则只要条件都命中就都生效，不存在基于文件名的覆盖。
Claude Code 这边的措辞不是「优先级链」，而是拼接。官方文档写明所有被发现的文件是拼接进上下文的，不是相互覆盖；跨目录树的内容顺序是从文件系统根一路排到你的工作目录，所以离启动位置越近的指令排得越靠后；同一个目录里 CLAUDE.local.md 排在 CLAUDE.md 之后。规则目录的顺序也写了：用户级的 ~/.claude/rules/ 在项目规则之前加载，因此项目规则优先级更高。
这里有两处需要放在一起看。Claude Code 文档在讲全局 CLAUDE.md 时写「指令冲突时项目级指令优先」；同一套文档在讲怎么写有效指令时又写「如果两条规则互相矛盾，Claude 可能任意挑一条」，并建议你定期清理跨文件的冲突指令。两句都是官方原文，我们只能把它们指到这儿，具体某次冲突怎么裁决文档没给可预期的规则，不推断。
两边都写了同一层免责：Claude Code 文档明说它的两套记忆机制（你写的 CLAUDE.md 与 Claude 自己写的 auto memory）是 Claude 读的 context，不是 Claude Code 强制执行的配置，要保证某个动作无论 Claude 怎么决定都被拦下来，应该用 PreToolUse hooks；同一套文档在讲管理端配置时也写明，settings 里的规则由客户端强制执行，而 CLAUDE.md 只塑造行为、不是硬性执行层；Cursor 文档在 Team Rules 一节也写了，虽然支持把强制规则用在内部合规流程里，但 AI 指导不应该是你唯一的安全控制手段。别把规则文件当硬约束用。
两边碰头：同一个仓库被两个工具读
如果团队里两个工具并存，有三条来自双方文档的事实需要先知道。
第一，Cursor 官方文档写明它读 CLAUDE.md 的方式和读 AGENTS.md 一样，而且 CLAUDE.md 总是应用到每一次对话，不管 alwaysApply frontmatter 设成什么——该页给出的理由是保证与同时用 Claude Code 的项目兼容，需要条件规则就用 .cursor/rules/。也就是说，你不能靠给 CLAUDE.md 加 frontmatter 把它在 Cursor 侧变成条件加载。
第二，方向反过来不成立。Claude Code 文档明说它读 CLAUDE.md、不读 AGENTS.md。已有 AGENTS.md 的仓库要让两边共用，文档给的做法是建一个 CLAUDE.md 去 import 它：
@AGENTS.md
## Claude Code
Use plan mode for changes under `src/billing/`.
也可以用符号链接，文档给的命令是 ln -s AGENTS.md CLAUDE.md。但 Windows 上不要走这条路：该页写明在 Windows 上创建符号链接需要管理员权限或开发者模式，所以建议改用 @AGENTS.md import。这是本文里 Windows 与 macOS/Linux 差别最实际的一处。
第三，Claude Code 提供了从别家配置往自己这边搬的入口。文档写明 /init 会读 Cursor rules（.cursor/rules/ 或 .cursorrules）和 Copilot rules（.github/copilot-instructions.md），把相关部分并进生成的 CLAUDE.md；设了 CLAUDE_CODE_NEW_INIT=1 之后，/init 还会读 AGENTS.md、.devin/rules/、.windsurf/rules/ 或 .windsurfrules、.clinerules。另有 /import 命令把受支持的编码 agent 的配置带进来，包括把 AGENTS.md 这类指令文件一次性追加到匹配的 CLAUDE.md，并带过 MCP 服务器、命令、subagent 和 skills；该页写明这需要 Claude Code v2.1.213 或更高版本。
另外，Cursor 文档写明项目根的 .cursorrules 是遗留形式、将被弃用（原文为 legacy、will be deprecated），迁移步骤是：用命令面板搜 “New Cursor Rule” 建新规则、把内容抄过去、类型设成 Always Apply（文档说这与旧行为一致）、删掉 .cursorrules。命令面板快捷键该页也写了：Mac 是 Cmd + Shift + P，Windows/Linux 是 Ctrl + Shift + P。
怎么确认「到底加载了什么」
对照到这一步，最有用的其实是各自的自查手段。
Claude Code 侧，文档写明在会话里跑 /context，看 Memory files 那一栏，能确认哪些 CLAUDE.md 与 CLAUDE.local.md 真的加载了——原话是文件如果不在那儿，Claude 就看不见它。/memory 用来列出各作用域下的记忆文件位置并打开编辑。想要更细的记录，文档还提到一个 InstructionsLoaded hook，可以记录哪些指令文件被加载、什么时候加载、以及为什么加载，文档说这对调试路径规则和子目录里的延迟加载文件有用。
Cursor 侧，文档写明从侧边栏的 Customize 进 Rules 可以看到所有规则及其状态。规则没生效时该页给的排查方向是：Apply Intelligently 要确认写了 description，Apply to Specific Files 要确认文件模式真的匹配到了你正在改的文件。至于有没有类似 hook 的加载日志机制，我们在 Cursor 这两页文档里没有找到对应说明，这一点不比。
各自的边界，以及什么时候会咬到你
这些都是文档明写的限制，不是我们的推测：
- Claude Code：
/compact之后，项目根的CLAUDE.md会被重新从磁盘读取并重新注入；但子目录里的嵌套CLAUDE.md和带paths:的规则不会自动重新注入，要等下次读到匹配文件才回来。长会话里「规则突然不听了」，先往这儿查。 - Claude Code：
--add-dir加进来的额外目录，默认不加载其中的CLAUDE.md。文档给的开关是环境变量，命令原文是CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1 claude --add-dir ../shared-config，开启后会加载该目录下的CLAUDE.md、.claude/CLAUDE.md、.claude/rules/*.md和CLAUDE.local.md。 - Claude Code：项目级记忆文件里的 import 如果解析到工作目录之外，首次会弹出批准对话框列出这些文件；文档写明如果你拒绝，这些 import 会保持禁用状态，而且对话框不会再出现。
- Cursor：规则只对 Agent (Chat) 生效。文档明说它们不作用于 Tab 补全、Inline Edit（Cmd/Ctrl+K）和
Bugbot的 PR 评审，User Rules 同样不应用于 Inline Edit。指望用规则统一管住 IDE 里所有 AI 入口的，这条要提前知道。 - Cursor：Team Rules 是自由文本，不使用 Project Rules 的文件夹结构；非强制的 Team Rules 成员可以在 Customize 里自行关掉，只有勾了强制的才关不掉。
落到决策上
把上面三层收成三种处境：
一个人、一台机器、一个仓库。 差别不大，两边都是「项目根放一个文件，长了就拆到规则目录」。真正要记住的只有扩展名：Cursor 收 .mdc，Claude Code 收 .md。
团队要统一口径。 Cursor 有 Team Rules 这条服务器侧、可强制、自动同步的通道（Team 与 Enterprise 计划可用）；Claude Code 对应的是 managed policy 位置的 CLAUDE.md，文档写明它由 IT/DevOps 用 MDM、组策略、Ansible 之类工具分发，且不能被个人设置排除。两条路径的落地方式完全不同，前者在产品后台，后者在你的终端管理体系里，这决定了该找谁开工单。
两个工具并存。 关键在方向不对称：Cursor 会读 CLAUDE.md 并且总是全量应用，Claude Code 不读 AGENTS.md 需要显式 import。所以把共用内容放进 CLAUDE.md、把工具特有的条件规则各自留在 .cursor/rules/ 与 .claude/rules/，是一种不用跟任何一方的加载机制较劲的分法。Windows 上别用符号链接，用 @AGENTS.md import。
最后一句老生常谈：这两个产品的配置项都在改，上面每一条都请以官方文档最新内容为准，别拿本文当规格书用。
本文依据 Claude Code 官方文档（code.claude.com/docs）于 2026-08-17 的公开内容整理。
该产品闭源，本文只复述官方文档写明的机制，不推断其内部实现；
我们没有对文中涉及的功能做过实测，因此不涉及界面外观、操作手感与运行速度的任何描述。
该产品迭代频繁，文中涉及的命令、配置项与默认值随版本变动，请以官方文档最新内容为准。
本文不涉及价格、额度与限流的具体数值，相关信息请以官方定价与用量说明页为准。
本文涉及的另一方内容依据其官方文档整理（Cursor：cursor.com/docs 与 cursor.com/help）。
双方均为闭源商业产品，本文只对照各方公开写明的机制，不推断实现，也不对产品做优劣排名。
安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。