Cursor 常驻规则如何取舍

Cursor 规则越多，AI 就越听话吗？作者给出的答案是：先决定哪些约束必须一直留在上下文里，再考虑收集多少规则。alwaysApply: true 应该留给少量、通用、遗忘代价高的要求，技术栈细节则按文件匹配加载。

这篇短文值得读的地方，是提供了一套筛选规则的方法。不过，关于上下文压缩后规则会被弱化、精简规则能否改善结果，作者没有给出对照数据，需要把经验判断和已验证的效果分开看。

哪些规则值得每轮都带着

作者认为，一条规则只有同时满足三个条件，才应该设置为 alwaysApply: true：

• 遗忘它会损失时间或金钱，因此需要在上下文压缩后恢复，例如安全要求、防止任务范围扩大，以及重新读取 AGENTS.md。
• 它适用于几乎每次修改，而非只适用于 React 表单或 Spring controller。
• 它足够短，只有几行直接指令，而非整本风格指南。

这里的上下文压缩（compaction），可以理解为把较长的会话整理成更短的摘要，让后续工作继续进行。作者担心的是，长而泛的要求在这个过程中失去优先级，最后 AI 仍可能擅自引入第二套表单库。

常驻规则的价值，在于约束关键行为，而非覆盖所有知识。

作者给出的常驻核心分为三类：简要规划、把决策写入磁盘并在压缩后重读；修 bug 时不要顺手重构目录；不要把密钥提交进仓库，也不要自行编造绕过认证的方案。

其中，alwaysApply: true 是加载设置，不能被理解成模型必然遵守的保证。作者强调压缩后的恢复，恰好说明仅仅加载规则还不够。

React 和 Java 的细节应该何时出现

剩余规则，作者建议使用 globs，也就是文件路径匹配模式；或者设置 alwaysApply: false，配上清楚的描述，让 agent 按需请求。

原文针对 React + Java 仓库给出了具体拆分：

规则内容	触发范围
React 表单、TanStack Query、zod 边界约束	UI 路径下的 **/*.{tsx,ts}
Spring controllers、Bean Validation、禁止响应直接返回 JPA entities	**/controller/**/*.java、**/web/**/*.java
zod 与 Bean Validation 的映射	修改 API contract 文件时

这套划分的理由很直接：修改页面表单时，表单校验和请求管理规则才与当前任务紧密相关；修改 Java 接口时，controller 和响应对象的约束才更需要出现。把它们全部常驻，会让每轮上下文都承担与当前修改无关的内容。

但路径匹配也有前提。**/*.{tsx,ts} 必须限定在 UI 路径下，否则可能覆盖大量无关 TypeScript 文件。原文没有提供完整的 Cursor 规则文件，也没定义 API contract 的实际路径，不能直接当作配置模板复制。

作者认为，这个筛选方法同样适用于 Next-only 或 Go 项目。可以迁移的是判断标准，具体路径仍要根据仓库调整。

我的判断

我认同把规则按「遗忘成本、适用频率、长度」筛选。它比单纯追求规则数量更容易落实，也能帮助团队发现哪些要求其实只服务于局部代码。

但「上下文压缩后，长规则会被弱化」以及「900-skill dumps 为什么失败」，在原文中都是经验判断。作者没有提供 token 开销、规则遵守率或任务成功率的对照实验，不能据此认定大型规则集合必然无效。

这里还有一个实际矛盾：安全要求可能只在少数修改中触发，却有很高的遗忘成本。作者用简短的安全底线常驻、技术细节按需加载，给出了方向，但没有讨论所有边界情况。

相比把整本指南设为常驻，分层加载更有针对性；相比完全依赖 agent 自行挑选规则，globs 提供了明确的文件触发条件。但跨前后端修改 API 时，单个文件的匹配未必能带出完整约束，仍需检查契约规则是否被加载。

原文也带有产品推广：免费 Starter 包含 3 条常驻规则和 1 个 PR-review Skill，完整 React/Java Bundle 为一次性 $29。作者建议先试免费核心，再考虑升级。这是购买建议，不能当作效果证据；作者自己也说明没有销售数据背书。

能拿来做什么

• 检查现有 Cursor 规则，逐条回答「忘了会怎样、是否几乎每次都适用、能否缩成几行」，先整理出一个小型常驻核心。
• 把 React 表单、TanStack Query 和 zod 约束限定到实际 UI 目录；React + Java 仓库再单独配置 controller、web 和 API contract 的规则范围。
• 按作者提出的方法，在下一次上下文压缩后，让 agent 从 AGENTS.md 恢复任务目标与已记录决策，再检查它是否仍遵守修改范围。原文没有报告这个验证的结果，需要自己观察。
• 评估规则包时，查看它如何分配常驻与按需规则，以及触发路径是否适合仓库。文件数量和覆盖技术栈的数量，只能说明收录范围。