为什么模式比措辞更重要
Windsurf 用一句话说明了这一机制：“每个工作区规则通过其 frontmatter 中的 trigger 字段声明激活模式。这控制了规则内容何时提供给 Cascade 以及消耗多少上下文窗口。”
一个字段决定两件事：规则是否到达智能体，以及它的成本是多少。文档中记录的选项如下：
always_on —— “在每条消息的系统提示词中都包含完整的规则内容。”成本：每条消息。
model_decision —— “系统提示词中仅显示描述。当 Cascade 判定该描述相关时，它会读取完整的规则文件。”成本：始终包含描述；按需加载完整内容。
glob —— “当 Cascade 读取或编辑与 glob 模式匹配的文件时应用规则。”成本：仅在触及匹配文件时。
manual —— “规则不在系统提示词中。您通过在 Cascade 输入框中输入 @rule-name 来激活它。”成本：仅在被 @ 提到时。
将这些成本看作一个阶梯。从 always_on 转到 model_decision 会将固定的单条消息成本转化为描述大小的成本，并按需加载主体内容。转到 glob 会使成本取决于您触及的内容。转到 manual 则使成本取决于您的主动要求。
现在来看看重塑整个过程的部分：
“全局规则文件（global_rules.md）和根目录级的 AGENTS.md 文件不使用 frontmatter —— 它们始终启用。”这两个界面没有模式。从结构上讲，它们始终启用。因此，在您优化任何内容之前，您的一部分预算已经预先支出了——而限制额度会告诉您支出了多少。全局文件位于 ~/.codeium/windsurf/memories/global_rules.md，应用于所有工作区，且“限制为 6,000 个字符”。工作区规则在 .devin/rules/（首选）或 .windsurf/rules/（备用）中每个文件存放一个，且“每个文件限制为 12,000 个字符”。
而且还有第三个人们容易忘记的始终启用界面：“工作区根目录下的旧版单文件 .windsurfrules 仍会被读取。”如果您在多年前迁移到了规则目录，但从未删除该文件，那么它仍在被加载。
AGENTS.md 的模式是根据位置而不是 frontmatter 分配的：“根目录级 = 始终启用，子目录 = 该目录的自动 glob。”这是一个非常优雅的默认设置，这意味着将文件向上移动一个目录会默默地将其成本从条件性转为永久性。
这类问题的通用版本——规则存在但未按预期运行——在为什么智能体会忽略您的指令文件中有所讨论。
人们尝试的其他替代方法
将所有内容设置为 always_on。 这感觉最安全：规则肯定存在。但它也会在您从未离开前端的会话中，将您每条消息的预算花在 Terraform 规范上，并且成本会在长对话中不断累积。其症状就是当 Windsurf 的智能体丢失上下文时中所描述的漂移现象。
编写更短的规则而不是更改模式。 这很有帮助，但解决的是错误的变量。在整个会话中，每条消息都加载一个 400 字符的规则，其成本仍然高于仅加载两次的 3,000 字符规则。简短和激活是独立的杠杆，而第二个杠杆更强大。仅靠简短这一方法的局限性是为什么更短的提示词还不够的主题。
转而依赖自动生成的记忆。 Windsurf 自身也建议不要这样做，用它自己的话说：“对于您希望 Cascade 可靠重用的知识，请将其编写为规则或添加到您仓库中的 AGENTS.md 中，而不是依赖自动生成的记忆（Memories）。规则是版本控制的、可与团队共享的，并且能让您对激活进行显式控制。”它的对比表也指明了记忆的定位：“让 Cascade 记住一次性的事实；对于持久的知识，首选规则或 AGENTS.md。”还要注意文档现在包含的范围限制——记忆被记录为仅适用于旧版 Cascade 智能体，而作为新标签页默认设置的 Devin Local 智能体不会持久化它们。
将所有内容合并到一个文件中以简化。 这用一组可管理的模式决策换取了一个无差别且始终启用的块，并且会遇到单文件字符限制。该决策在文件夹层面的版本已在合并 Windsurf 和 Devin 规则文件夹中进行了详细阐述。
假设企业规则可以解决这一混乱。 它们并不能，文档中明确指出：系统级规则会“与工作区和全局规则合并，为 Cascade 提供额外的上下文，而不会覆盖用户定义的规则。”管理员基线会增加您的预算，而不是取代它。
解决方案：评估每个规则的成本，然后将模式与成本进行匹配
决定不是“哪种模式最好”。而是“这个规则实际相关的频率是多少”，这些模式对应着四个坦诚的答案。
步骤 1：盘点每个界面，包括没有模式的界面
在更改任何内容之前，先列出所有内容。规则可以来自五个地方，而其中只有一个具有 trigger 字段：
位于 ~/.codeium/windsurf/memories/global_rules.md 的全局文件 —— 始终启用，6,000 个字符。
根目录级的 AGENTS.md —— 始终启用，无 frontmatter。
子目录 AGENTS.md 文件 —— 自动 glob 其所在目录。
工作区根目录下的旧版 .windsurfrules（如果仍然存在）—— 检查此文件，因为这是您在不知情的情况下消耗预算的最常见来源。
.devin/rules/ 或 .windsurf/rules/ 中的工作区规则文件 —— 每个规则一个文件，每个文件 12,000 个字符，并且是唯一可以选择模式的界面。
首先累加始终启用的总额。这个数字是您的底线，也是在加载任何条件规则之前每条消息都必须支付的成本。
步骤 2：将每个工作区规则归入四个坦诚答案之一
逐个规则地询问它真正相关的频率。答案直接对应：
每条消息都相关。 诸如“用英国英语回复”或“绝不提交到 main 分支”之类的内容。这些应该获得 always_on。这类规则应该极少，它们的合并大小才是您关心的数字。
有时相关，且不可预测。 智能体在出现某个主题时应该获取的领域知识——例如支付限制、合规规则。这些是 model_decision，描述在这里起到了关键作用，因为它是默认加载的唯一部分。将其写成“何时使用此规则”的句子，而不是标题。
涉及特定文件时相关。 任何与文件相关的规范：测试规范、迁移安全、生成的代码。这些是 glob，这通常是最大的优化点，因为大多数规范都是与文件相关的，而人们以前将它们设置为了始终启用。
在您要求时相关。 发布清单、事件处理程序，以及任何您刻意调用的内容。这些是 manual，您可以通过 @rule-name 激活它们。
如果一个规则不适合这四种情况中的任何一种，这就具有诊断意义。这通常意味着该文件是将两个规则强行拼凑在一起的——一个是始终成立的，一个是视情况而定的——将它们拆分可以使每一半都获得适合的模式。
步骤 3：通过矛盾法验证，而不是通过阅读文件
您无法通过查看 frontmatter 来确认模式，因为问题在于智能体是否实际接收到了内容。
对于 glob 规则，打开一个不应匹配的文件，并要求进行该规则会改变的操作。如果规则的行为仍然出现，说明您的模式比您想象的要宽泛。然后打开一个应该匹配的文件，并检查该行为是否出现。
对于 model_decision 规则，在不提及规则名称的情况下询问该主题。如果智能体没有获取该规则，那么问题出在描述上，而不是主体上。
对于 manual 规则，确认 @rule-name 调用能够解析——并确认在您未提及它时，该规则不适用，这正是该模式的全部意义所在。
在更改模式后，对每个规则执行一次此操作。这是区分“已设置的模式”与“起作用的模式”的唯一方法，也是发现当 Windsurf 忘记您的项目规则时中问题的相同方法。
在 MemoryLake 中进行设置
经过这次梳理后，有两样东西会保留下来，但其中只有一样适合放在规则目录中。指令——如何表现、首选什么——应该完全放在 Windsurf 放置它们的地方。而背后的原因则不然：“我们使用整日计费”是一条规则，而“因为财务系统拒绝非整日”则是让智能体能够判断该规则何时不再适用的依据。
MemoryLake 保存了这第二层内容，它不受字符限制，也不受任何单一编辑器的约束。您的规则会变得更短，您的始终启用底线会降低，并且您使用的每个工具仍然可以获取这些推理过程。
步骤 1：创建 API 密钥
登录并打开您的工作区设置，生成一个 API 密钥。这是您的编辑器和智能体用于读取同一层内容的凭证，因此只需创建一次，并确保每台机器都可以访问它。
步骤 2：上传您的第一批记忆
将推理过程从规则主体中移出：为什么存在每个规范、您拒绝了哪种方法、是什么限制使得显而易见的答案变得错误。规则文件保留指令；记忆层保留理由。
步骤 3：连接您的 AI 和智能体
连接 Windsurf 以及您在其中工作的任何其他工具。相同的推理过程会同步到每个工具中，这非常重要，因为规则目录不会随您转移到下一个工具，而其中的决策应该随之转移。
这在实践中带来了什么改变
第一个变化在一个会话内就能衡量出来。将与文件相关的规范从 always_on 移至 glob 可以将它们从每条消息中剔除，长对话在第二个小时内便不会再出现性能退化。
第二个变化是 model_decision 变得可用了。这是最有趣的模式，也是最常被浪费的模式，因为写成标签形式的描述无法给智能体提供任何决策依据。而写成条件形式，它就会变成一个有效的按需加载界面。
第三个变化是您的始终启用底线变成了一个您心中有数的数字。在 6,000 字符的全局文件、根目录 AGENTS.md 以及可能被遗忘的 .windsurfrules 之间，这个底线往往占据了人们以为自己正在管理的大部分预算。
第四个变化是规则不再承载推理过程。更短的文件可以轻松契合 12,000 字符的限制，而理由则保存在人类可读且其他工具可加载的地方。不这样做的代价会体现为当 Windsurf 忘记 Cascade 上下文时中所描述的上下文丢失。
规则激活的最佳实践
默认使用 glob，而不是 always_on。 大多数规范都与文件有关。让智能体的接触范围与之匹配。
将 model_decision 的描述写成条件。 “在处理支付流程或退款逻辑时使用”优于“支付规则”。描述是默认加载的唯一部分。
检查后删除旧版文件。 工作区根目录下的 .windsurfrules 仍会被读取。它要么是您的唯一可信源，要么就不应该存在。
注意移动文件带来的影响。 子目录中的 AGENTS.md 是该目录的自动 glob；根目录下的相同文件则是始终启用（always-on）。目录移动即意味着成本的变化。
在优化其余部分之前，先计算始终启用的总额。 在每条消息都加载 6,000 字符全局文件的情况下去优化条件规则，这是错误的顺序。
将自动生成的记忆视为一次性的事实。 这是 Windsurf 自身的定位，其建议是将持久知识编写为规则或放入 AGENTS.md 中。
在任何模式更改后重新验证。 frontmatter 的编辑并不是证据。矛盾法验证才是。
结论
Windsurf 已经完成了最难的部分：它公布了每种激活模式的成本以及每种模式何时加载。这四种模式清晰地对应了关于规则相关频率的四个坦诚答案，而大多数规则目录配置错误，仅仅是因为没有人坐下来针对每个文件回答这个问题。
所以，去回答它。盘点没有模式的界面，累加它们让您承担的底线成本，将剩余的规则归入四个桶中，并通过矛盾法进行验证，而不是仅仅阅读 frontmatter。然后将推理过程从规则主体中移出，因为字符限制绝不是存放“为什么存在这些规范”的合理解释的地方——而且因为您使用的下一个工具将会有它自己的限制、它自己的模式，并且根本无法读取这个目录。