为什么规则存在却从未生效
首先来看看有多少东西可以被视为规则。Cline 的文档列出了它识别的四种类型，“以便您可以使用来自其他工具的现有规则文件”：Cline Rules 位于 “.clinerules/, .cline/rules/”，被描述为“支持的工作区规则目录”；Cursor Rules 位于 .cursorrules，标记为“自动检测”；Windsurf Rules 位于 .windsurfrules，同样是“自动检测”；以及位于 “AGENTS.md, ~/.agents/AGENTS.md” 的 AGENTS.md，被描述为“跨工具兼容的标准格式”。
这已经比大多数人想象的范围要广了，这意味着从以前的工具遗留下来的 .cursorrules 并不是不起作用的。这四种类型最终都会汇集到同一个地方：“所有检测到的规则类型都会出现在 Rules 面板中，您可以在其中单独切换它们。”
第一个关卡就是该面板。“每个规则都有一个开关来启用或禁用它。这使您能够细粒度地控制哪些规则适用于当前任务，而无需删除规则文件。” 这个功能非常有用——文档中给出的例子是：“您可能希望在原型设计时禁用严格的测试规则，或者只有在开发特定客户的功能时才需要特定于该客户的规则”——而代价是，您在三周前关闭的规则在磁盘上看起来与处于活动状态的规则完全相同。
第二个关卡是通过 YAML 前置元数据实现的条件激活。“当 Cline 处理请求时，它会从您当前的工作中收集上下文（打开的文件、可见的标签页、提及的路径、编辑的文件），评估每个规则的条件，并激活匹配的规则。” 文档中记录的受支持条件只有一个：“目前，paths 是受支持的条件，” 它接收一个 glob 模式数组。
围绕该条件的三个行为决定了大多数实际情况，且这三个行为都在文档中有所说明。“无前置元数据：没有前置元数据的规则始终处于活动状态。” “空 paths 数组：paths: [] 意味着规则永远不会激活。使用它来临时禁用规则。” 以及 “无效的 YAML：如果无法解析前置元数据，Cline 会选择放行（fail open）。规则会以原始内容可见的形式激活，以帮助调试。”
最后一点是一个重要线索。如果规则的原始前置元数据出现在 Cline 的输出中，它并没有加载失败——它只是因为 YAML 无法解析而以调试形态加载了。
人们通常会尝试的其他方法
更强势地重写规则。 对从未到达模型的指令增加语气并不能改变任何事情。这还会让文件在真正生效的那天变得更糟。
将规则复制到两个受支持的目录中。 这没有必要，文档中也提到了：“当两个目录都存在时，都会进行搜索，因此您无需将规则复制到这两个位置。” 他们还指出了新文件的存放位置：“VS Code Rules 面板仍会在 .clinerules/ 中创建新的工作区规则。”
删除前置元数据以“使其始终适用”。 这确实有效，而且是文档中记录的行为——但如果广泛应用，它会重新带来条件限制原本要解决的问题。文档直接指出了代价：“随着规则库的增长，为每个请求加载每个规则会浪费上下文 Token，并可能分散 Cline 的注意力。”
用散文描述文件而不是直接命名。 文档中包含一个提示，读起来就像是看过了人们这样做之后写下的：“在提示词中明确指出文件路径。'更新 src/services/user.ts' 可以可靠地触发基于路径的规则；而'更新用户服务'则可能不行。”
假设这是一个记忆问题。 有时确实是——一个正确应用但仍让 Cline 重新推导项目事实的规则是另一种失败，更接近于如何设置 Cline 记忆库的范畴。但是，一个从未触发的规则是一个激活问题，解决方法在面板和前置元数据中。
假设它与其他编辑器中的失败相同。 症状相同，但机制不同。当其他工具在会话中途丢失项目规则时，问题通常与范围和会话状态有关，而不是双关卡激活模型，正如为什么 Cursor 会忘记项目规则中所讨论的那样。
解决方法：列举每个规则源，检查两个关卡，然后用测试规则进行验证
步骤 1：列出 Cline 视为规则的每个文件，包括那些不是您编写的文件
打开 Rules 面板，将其视为一份清单，而不仅仅是一个设置屏幕。每个检测到的类型都会出现在那里，因此该面板是您发现旧的 .cursorrules 或 .windsurfrules 仍被提供给模型的地方。
然后检查磁盘上的两个工作区位置——.clinerules/ 和 .cline/rules/——因为“VS Code、Desktop 和 CLI 都支持这两种布局，” 并且同事可能使用了您没有打开的那一个。加上全局层级：全局规则位于系统的 Cline Rules 目录中，文档指出 “Cline 还会从 ~/.agents/AGENTS.md 中读取跨工具的全局 AGENTS 指令。”
对于列表中的每个文件，记录两件事：它的开关是否打开，以及它是否有前置元数据。这两项就是地图。开关打开且没有前置元数据的文件始终处于活动状态。开关关闭的文件无论前置元数据写了什么都是不起作用的，因为“关闭条件规则的开关将完全禁用它（即使路径匹配它也不会激活）。”
既然您已经到了这一步，请应用结构化建议，因为它使地图易于维护：“每个文件只关注一个问题。按主题拆分规则：coding.md 用于代码风格，testing.md 用于测试要求，architecture.md 用于架构决策。这使得打开或关闭特定规则变得容易。” 单个大型规则文件会为您提供一个开关来控制六个不相关的问题。
步骤 2：对照 Cline 实际评估的上下文阅读 glob 模式
模式只是问题的一半；另一半是 Cline 正在将其与什么进行比较。文档记录的上下文有五个输入：“您的消息：提示词中提及的文件路径”，“打开的标签页：当前在编辑器中打开的文件”，“可见文件：在活动编辑器窗格中可见的文件”，“编辑的文件：Cline 在任务期间创建、修改或删除的文件”，以及“待处理的操作：Cline 即将编辑的文件”。
随之而来的是两个结果。首先，时机不是固定的：“条件规则可以在您的第一条消息时激活，也可以在打开相关文件时激活，或者在任务中途 Cline 开始处理匹配文件时激活。” 一个在开始时似乎不存在的规则很可能在稍后才生效。其次，规则可能会因为您未曾预料的原因触发，因为另一个窗格中恰好打开了一个不相关的文件。
然后结合文档记录的语法阅读 glob 本身。* “匹配除 / 之外的任何字符”，** “匹配包括 / 在内的任何字符（递归）”，? “匹配单个字符”，[abc] “匹配括号中的任何字符”，而 {a,b} “匹配任一模式”。这些例子值得牢记：src/**/*.ts 涵盖 “src/ 下的所有 TypeScript 文件”，*.md 涵盖 “仅在根目录下的 Markdown 文件”，**/*.test.ts 涵盖 “项目任何位置的测试文件”，而 src/components/*.tsx 涵盖 “直接在 components 中的 TSX 文件（不嵌套）”。
组合规则非常宽容：“如果任何模式与您上下文中的任何文件匹配，规则就会激活。” 这就是为什么过宽的模式比过窄的模式更容易引起误触发——这正是同一文档在其故障排除说明中标记的权衡，其中“规则意外激活”指向 “** 是递归的，可能匹配比预期更多的内容” 以及与模式匹配的打开文件。
步骤 3：用一个临时测试规则进行验证并留意通知
当这起作用时，Cline 会发出一个信号，了解这一点可以将猜测转化为确认。当条件规则激活时，文档指出 “您将看到一条通知：'Conditional rules applied: workspace:frontend-rules.md'。”
文档中记录的使用方法是使用一个临时规则。在 .clinerules/ 中创建一个小文件，其唯一的前置元数据是您不确定的 paths 模式，其主体是一行显眼的内容——文档建议类似于 “TEST: This rule should activate for your/pattern/here files.” 然后 “处理该路径中的文件，并检查是否看到激活通知。”
如果什么都没有出现，故障排除列表很短且有序：“检查上下文中的文件路径是否与 glob 模式匹配”，“验证规则在规则面板中是否已开启”，以及“确保 YAML 前置元数据具有正确的 --- 分隔符。” 按此顺序运行它们，因为第一个最常见，而第三个会导致最奇怪的症状——记住，无法解析的前置元数据会选择放行，并显示原始内容。
文档还建议了一种构建模式的方法，而不是凭空猜测：“先宽后窄”，从类似 src/** 的内容开始，在看到匹配项后精细化为 src/features/auth/**。如果您根本不想手动编写文件，可以使用 /newrule 斜杠命令 “让 Cline 交互式地创建规则。”
在 MemoryLake 中进行设置
规则是指令：如何在这里编写代码、避免什么、遵循哪些约定。但对于规则所暗示的另一件事——背后的决策和原因——它们并不是一个好的容器。当您在决定某个规则是否仍然适用时，您希望能够检索到这些决策和原因，而不是将它们加载到每个任务中。一个您有意向其中写入 MemoryLake 条目的存储库可以将这一半内容分离开来，因此收紧 glob 永远不会让您丢失规则背后的推理。您可以用自己的语言亲自编写这些条目。不会从您的规则文件或 Cline 的设置中读取、写入或删除任何内容。
步骤 1：创建 API 密钥
登录并从您的工作区设置中生成一个 API 密钥。这是您的智能体和集成所使用的凭据，因此在开始迁入任何内容之前先创建它。
步骤 2：上传您的第一批记忆
从您的规则文件遗漏的“原因”开始：为什么遗留目录是禁区、哪种约定在何时取代了哪种约定、某种约束是为了防范什么。将每个原因写成简短的独立笔记，以便可以单独检索。
步骤 3：连接您的 AI 和智能体
连接您使用的助手和智能体。然后，推理就会随您跨工具移动，而与特定编辑器读取哪个规则目录无关。
这在实践中改变了什么
调试有了一套操作顺序。您不再是重写规则，而是检查开关，然后是前置元数据，接着是对照五个上下文输入检查 glob，然后运行测试规则并留意通知。四项检查，全部都有文档记录的答案。
旧的工具文件变成了一种决策，而不是意外。您遗留下来的 .cursorrules 会被检测到并提供，因此它要么是有意属于您的规则集，要么应该被清除。这也使得您在工具之间迁移规则时的方向更加清晰，正如如何将 Cursor 规则迁移到 Claude Code中所讨论的那样。
提示词的措辞成为设置的一部分。由于您消息中提及的路径算作上下文，因此命名您打算更改的文件并不是吹毛求疵——根据文档本身的提示，这是您可用的最可靠的触发方式。
默认情况下，规则库不再无休止地增长。一旦您能看到哪些规则是始终开启的，始终开启的层级就变成了您管理的预算，而不是您继承的一堆杂物。这与促使人们首先整合分散的规则文件的压力是一样的，这在如何整合 Kilo Code 规则文件中有所讨论。
反复出现的抱怨得到了重新诊断。“它又忘记了我们的风格”有时是一个有已知原因的激活问题，而不是记忆问题——在改变任何事情之前，这个区别值得理清，它也决定了为什么 Cline 会忘记您的代码风格中的修复方式。
必须证明其已应用的规则的最佳实践
保留一个始终开启的文件，并以此命名。文档本身示例布局的结尾是 universal.md，并附有注释 “无前置元数据 = 始终活动。” 一个以其行为命名的文件可以告诉下一个人他们正在看什么。
在规则主体中放入预期的触发条件。顶部的一行字——“预期为 src/components 激活”——将未来的每一次误触发变成两秒钟的对比，而不是一番调查。
宁可要几个范围狭窄的文件，也不要一个范围宽泛的文件，这样开关就是一个精确的仪器。这就是“每个文件只关注一个问题”的实际回报。
在重构后重新运行测试规则。移动目录会改变您的 glob 匹配的内容，而工具链中没有任何东西会告诉您某个模式已停止匹配。
将跨工具文件视为始终开启。根目录中的 AGENTS.md 或 ~/.agents/AGENTS.md 会被检测为规则源，而共享文件之所以共享，恰恰是因为它没有针对每个工具进行限制。无论您最终采用何种设置，规则中到底应该包含什么这一更广泛的问题都值得定期重新审视，这就是Cline 的最佳记忆设置中所涵盖的内容。
结论
只有当 Cline 规则的开关打开且其条件匹配时，它才会到达模型。当这两个关卡关闭时，它们都是静默的，而且四种不同的文件类型会汇入同一个面板，因此被忽略的规则并不总是您正在查看的那个规则。
梳理一次地图：每个规则源（包括继承的规则源）、每个规则源的开关状态、每个规则源的前置元数据，以及对照五个文档记录的上下文输入读取的 glob。然后保留一个临时测试规则，因为激活通知是系统中唯一的积极信号——而一个您可以重新运行的检查，胜过您重写并寄予希望的规则。