用 Cursor 规则触发范围控制上下文成本

Cursor 规则写得越全，不一定越划算。原文提醒了一个容易被忽略的成本：规则一旦适用，内容就会进入模型上下文；Always Apply 规则会持续占用空间，即使当前任务与它无关。

作者的建议是先调整规则的加载范围，再精简内容。约 500 行是拆分规则的实践参考，不是明确的 token 硬上限。对积累了大量项目规范、模板和检查清单的团队，这比继续往规则里加要求更值得先做。

你写下的规则，什么时候会进入上下文

Cursor 项目规则保存在 .cursor/rules 目录中，使用 .mdc 文件。规则适用时，其内容会放到模型上下文的开头。

问题在于适用范围。作者举了一个例子：一条 2,000-token 的 Always Apply 规则，每次聊天都会加载。讨论接口需要它，处理无关任务也会携带它。

常驻规则的成本，来自它反复加载，而不只是文件本身很长。

原文提到四种规则类型，类型由 frontmatter 中的 alwaysApply、description 和 globs 三个字段控制：

• Always Apply 用于始终加载的要求。
• 按文件范围匹配的规则，可以限定到 src/api/** 等路径。
• 通过描述让 Agent 判断相关性的规则，可以避开无关会话。
• Manual 规则需要通过 @ 提及才加载，适合偶尔使用的清单。

不过，原文没有给出四种类型与字段组合的完整对应表，不能直接把这份分类当作配置教程。

AGENTS.md 是更简单的常驻替代方案，不需要 frontmatter，适合简短的共享指导，但同样占用常驻上下文。换一种文件格式，并不会自动省下这部分 token。

500 行是拆分信号，不是精确预算

按原文转述，Cursor 文档建议每条规则控制在约 500 行以内，把大规则拆成职责集中的小规则。

这里有两个边界。

首先，行数不等于 token 数。原文没有提供换算关系，不能据此认定所有 499 行规则都足够轻，也不能把超过 500 行理解为无法加载。

其次，拆分只有配合加载条件才有意义。如果拆出来的文件仍然全部设成 Always Apply，常驻内容并不会因为文件变多就减少。

作者给出的另一项做法更直接：用 @path 引用文件，替代把模板和长示例粘进规则。例如，规则里放 @service-template.ts，而不是复制整个模板。

按原文描述，被引用文件不会直接内联进提示词，Agent 会在需要时通过工具读取。应关注的是「什么时候读」：模板仍然可能占用上下文，但不必每次规则加载时都提前带上。

先确认加载是否正确，再衡量占用

规则没生效和规则太贵，是两类问题。

原文列出的常见加载问题包括：在 .cursor/rules/ 中放了普通 .md 文件，而不是带 frontmatter 的 .mdc；或者规则类型与当前上下文始终不匹配。遇到这种情况，单纯删字无法解决。

对于已经正常加载的规则，作者建议先检查 Always Apply 和 AGENTS.md，判断哪些要求可以改为按路径、相关性或手动加载。

测量工具方面，原文介绍了两种入口：Cursor rules token counter 用于统计单个 .mdc 文件，并对照常见上下文窗口；Clogmeter inspector 可以一起检查规则目录、AGENTS.md 和 CLAUDE.md，标记完全重复、近似重复以及 always/never 冲突，并导出精简副本。作者称两者都在浏览器内运行，不上传内容。

这里没有给出精简前后的实测数据。工具能力也是作者对自家产品的介绍，不能据此推导出固定的节省比例。

我的判断

我认同优先控制加载范围。接口规范、模板、罕用检查清单，并不需要跟随每次对话；相比把所有要求塞进一个常驻文件，按需加载更符合它们的使用频率。

但「节省上下文」与「账单下降」还不能画等号。原文没有给出具体计费方案、请求记录或费用对照，能确定的是加载规则会占用输入上下文，无法确定每减少多少 token 就能少付多少钱。

约 500 行的建议也更适合当整理提示。原文没有证明这个长度最优，更没有比较拆分前后的任务正确率。压缩之后，必要规范是否仍能及时加载，需要结合实际任务检查。

另外，作者明确提醒规则行为可能随版本变化，却没有注明对应版本。这份内容适合指导审查方向，具体配置仍需核对所用版本的行为。

能拿来做什么

• 先审查项目里的 Always Apply 规则和 AGENTS.md，把只针对接口目录的要求收窄到类似 src/api/** 的范围。
• 把规则中重复粘贴的长模板移回独立文件，使用 @path 引用，例如 @service-template.ts，让 Agent 按需读取。
• 将偶尔使用的检查清单改为 Manual，并在执行相应任务时通过 @ 提及，同时检查超过约 500 行的规则是否需要拆分。
• 修改后分别用相关任务和无关任务检查加载情况，再比较 token 占用；如果规则完全没加载，先检查 .mdc 扩展名、frontmatter 和匹配条件。