Cursor Rules 不生效？三十秒探针先定位是哪一层
Cursor rules 不生效？先用探针分清没加载、没注入、没服从三层，再查 frontmatter 格式、.cursorrules 遗留与 gitignore 忽略。
写了半天规则，Agent 还是按自己的来。遇到 cursor rules 不生效，先别改规则内容：打开 Cursor Settings → Rules，看你的 .mdc 在不在列表里。不在，是格式或路径问题；在但对话里没带上，是注入问题。这两种查法完全不同。
三层症状要先分开
社区里的「规则不生效」其实是三件事，混着查会一直查不到头。
没加载：Settings → Rules 列表里根本没有这条。查文件位置、YAML frontmatter、.gitignore。
没注入：列表里有，但对话的 Active Rules 里不出现，模型行为完全不受影响。查规则类型（是否 alwaysApply）、是不是旧会话、工作区根开在哪一层。
没服从：Active Rules 带上了，输出仍然违反规则。这时问题在规则本身——太长、太虚、几条互相打架，或者会话被压缩后早期上下文被挤掉。
Cursor 论坛这个帖子 是第二类的典型：用户写了一条要求每次回复末尾追加 <<CURSOR_PROJECT_RULE_OK>> 的规则，Settings 里看得见，新开 Agent 对话却既没有 Active Rules 也没有标记；手动 @ 那个 .mdc 之后模型立刻开始遵守。列表里有，不等于自动进上下文。
三十秒探针：确认规则有没有进上下文
在仓库根建 .cursor/rules/probe-always.mdc，内容越短越好：
---
description: Probe — append marker if loaded
alwaysApply: true
---
Every assistant reply MUST end with exactly:
<<CURSOR_PROJECT_RULE_OK>>
然后按顺序看三件事：Settings → Rules, Commands 里有没有 probe-always；新开一个 Agent 会话（旧会话常带着旧规则缓存）随便问一句；回复末尾有没有那个标记，UI 的 Active Rules 里有没有它。
判读也是三种：Settings 里没有，是加载失败；Settings 有但标记没出现，是注入失败；标记出现了，说明规则系统正常，你原来那条业务规则的问题在内容本身——太长、和别的规则冲突，或者 glob 没匹配上当前文件。
测完把探针删掉，别留在正式项目里。
加载失败：Cursor 没认出这个文件
还在用根目录 .cursorrules
官方文档已经把根目录 .cursorrules 标为遗留格式、计划废弃，推荐迁到 .cursor/rules/*.mdc 并写 frontmatter。论坛另一个帖子 里同一段规则放 .cursorrules 时 Agent 不遵守，挪到 .mdc 并设 alwaysApply: true 后就稳定了。两种格式同时存在时行为更难预测，迁移时把旧文件删掉，只留一套。
frontmatter 写坏了，Cursor 静默跳过
.mdc 顶部要有成对的 ---。四个高频写错的地方：alwaysApply: True 大写（应为小写 true）；globs: **/*.ts 没写成数组（应为 globs: ["**/*.ts"]）；description 里有未转义的冒号，把 YAML 截断；只写了正文，忘了整段 frontmatter。
判据很简单：改完保存，规则应当立刻出现在 Settings 列表里。这个列表是「加载没加载」的权威界面，比在聊天里问模型「你看到我的规则了吗」可靠得多。
规则放进子目录，被 .gitignore 吃掉
有人把规则放在 .cursor/rules/team/foo.mdc，结果 @ 补全和 Settings 面板都看不见它。论坛的排查结论 指向文件发现阶段会尊重 .gitignore：仓库里存在 .cursor/rules/* 一类忽略模式时，子目录里的规则被静默排除。解法是让规则目录真的被 git 跟踪（例如加 !.cursor/rules/**），或者先把规则平铺到 .cursor/rules/ 一层验证是不是这个原因。
工作区根开错了一层
规则跟着当前打开的工作区根走。打开 monorepo 根、规则却在 packages/web/.cursor/rules/，就不一定按你以为的范围生效。放探针时始终放在真正作为 workspace 打开的那一层。
注入失败：列表里有，Agent 当没看见
先确认规则类型。alwaysApply: true 才会每个相关会话自动带上；写了 globs 的规则只在你打开或编辑匹配文件时挂载；其余属于要 @ 才用、或模型主动拉取的类型。很多「不生效」其实是把第三类当成了第一类。
论坛里还记着一类环境坑：Windows 上经 Parallels 的 UNC 路径（\\Mac\Home\...）打开项目时，alwaysApply: true 表现成「仅 requestable」；同一项目拷到虚拟机本地磁盘再打开，自动注入就恢复了。用网络盘或挂载盘开发的话，值得拿探针对比本地路径和网络路径。
长会话是另一种。压缩之后模型可能丢掉会话开头注入的规则，现象是前几轮还守、后面慢慢漂。处理办法就是新开 Agent，或把关键约束再 @ 一次。这不是配置坏了，是上下文预算问题，和 Agent 省 token 里「别把整本规范塞进常驻上下文」是同一类权衡。
alwaysApply 堆多了等于都没生效
每条 alwaysApply: true 都常驻占上下文。堆五六条长规范时，模型选择性遵守的概率明显上升。可用的分配方式是：全局只留一两条极短的 always（项目身份、硬禁区），栈相关规则挂 glob（比如只对 **/app/**/*.tsx 生效），偶发流程走手动 @。
写法上正面指令比一长串「不要……」有效。单个规则文件也别写太长，社区经验常提百来行作软上限，超过就该拆。
按顺序走一遍的排查清单
- 探针规则有没有出现在 Settings → Rules
- 是否已从
.cursorrules完整迁移并删除旧文件 - frontmatter 是否合法，
alwaysApply与globs的类型对不对 - 规则是否在工作区根的
.cursor/rules/（慎用深子目录，顺手检查 gitignore） - 新开 Agent 再测，必要时
@规则文件做对比 - 用网络盘、UNC、远程挂载时，换本地路径复测
- 几条业务规则可能互相矛盾时，先只留一条，确认服从后再逐条加回
论坛与文档细节会随 Cursor 小版本变，最终判据是你本机的 Settings 列表和探针结果。
和中文界面、BYOK、代理不是一条线
规则不生效属于上下文注入问题，跟界面语言、自备 Key、网络超时无关，别混着排。界面语言看 Cursor 中文设置，自备模型看 Cursor BYOK 配置，连不上或超时看 Cursor 代理超时排查。
如果规则系统本身正常，卡住你的其实是官方套餐额度用尽或者国内支付这一层，可以看本站的 价格与额度页 对照当前方案。
常见问题
Settings 里有规则，为什么还要 @ 一次？
规则不是 Always 类型、或者 glob 没匹配当前文件时，本来就要手动挂。先确认类型再判断是不是 bug。
旧项目去年 .cursorrules 好好的，升级后 Agent 不认了？
优先迁到 .cursor/rules/*.mdc。遗留文件在部分模式下仍可能被读取，但社区反馈里 Agent 路径上最不稳定的就是它。
怎么证明规则真的进了上下文？
用文末标记探针，或者让 Agent 列出当前项目规则文件名。判据是 UI 的 Active Rules 和探针标记，别只听模型口头保证「我已阅读规则」。
规则生效了但代码风格还是飘？
常见原因有两个：规则写太虚（「写优雅的代码」），或者和 User Rules、其他 .mdc 互相冲突。改成可检查的约束：目录约定、禁用 API、必须跑的测试命令，同时把常驻规则压到最短。