为什么两个规则文件夹最终会产生冲突
一旦您找到文档，其中记录的优先级就非常清晰了。Devin Desktop 的规则发现章节直接指出：
"Devin Desktop 自动从多个位置发现规则，以提供灵活的组织方式。.devin/目录是首选位置并具有优先级，而.windsurf/则作为向后兼容的备用方案保留。"
这只有一句话，却解答了标题中的核心问题。问题在于它周围的一切。
发现规则并不止于一个文件夹。它涵盖了“当前工作区及其子目录中的所有 .devin/rules（以及遗留的 .windsurf/rules）目录”，对于 git 仓库，它“还会向上搜索至 git 根目录，以查找父目录中的规则”。当同时打开多个文件夹时，“规则会被去重，并以最短的相对路径显示”。
在工作区范围内，还有第三个文件，大多数团队已经完全遗忘了它：
"工作区根目录下的遗留单文件 .windsurfrules 仍会被读取。"在工作区之上，还有一个拥有自己规则的全局文件：~/.codeium/windsurf/memories/global_rules.md，被描述为“单文件，应用于所有工作区。始终开启。限制为 6,000 个字符。”工作区规则文件有它们自己的上限——每个 12,000 个字符。
然后是 AGENTS.md，它根本不是一个独立的系统。它的文档明确阐述了这种关系：
"当您创建AGENTS.md文件（或agents.md）时，Devin Desktop 会自动发现它，并将其输入到驱动.devin/rules/（以及遗留的.windsurf/rules/）的同一个规则引擎中——只是激活模式是根据文件的位置推断出来的，而不是通过 frontmatter 声明。"
根目录级别意味着“始终开启”。子目录意味着“一个通配符 (glob)规则，其自动生成的模式为 <directory>/**”。
对于企业，还有一个系统层，由 IT 部门部署且对用户只读，它具有相同的新旧组合：macOS 上的 /Library/Application Support/Devin/rules/（以 Windsurf 作为遗留备用），Linux 上的 /etc/devin/rules/（以 /etc/windsurf/rules/ 作为备用），以及 Windows 上的等效组合。系统规则“与工作区和全局规则合并，为 Cascade 提供额外的上下文，而不会覆盖用户定义的规则”。
盘点一下这些层面：.devin/rules、.windsurf/rules、.windsurfrules、任意数量的 AGENTS.md 文件、global_rules.md 以及两个系统目录。每一个都是生效的。其中两对之所以存在，仅仅是因为发生了重命名，且不允许破坏任何现有功能。
还有一个细节使得规则很容易发生偏差。新规则并不会保存在您以为的地方：
"当您创建新规则时，它将保存在当前工作区的 .devin/rules 目录中，而不一定在 git 根目录下。"因此，在单体仓库（monorepo）中，当您恰好在某个包（package）内创建规则时，该规则会保存在该包中，而不是在最顶层。
人们尝试的其他方法
立即删除遗留文件夹。 这很诱人，但通常为时过早。旧文件夹仍会被读取，这意味着任何仍在使用旧客户端的人，或者任何尚未拉取代码的队友，都可能依赖它。请在确认内容已在新位置中体现之后再删除它，而不是在此之前。
假设最新的文件会生效。 事实并非如此。优先级是按位置决定的，而不是按修改时间。您今天早上在 .windsurf/rules 中编写的规则，会输给 .devin/rules 中一条过时的规则。
将所有内容放入 global_rules.md 以避免文件夹问题。 这用一个问题换来了一个更糟糕的问题。全局文件始终开启，适用于每个工作区，且上限为 6,000 个字符。对于特定项目的规范来说，它是错误的容器，并且它将是第一个达到上限的东西。
假设 AGENTS.md 不受此争议影响。 它并非如此。它通过相同的规则引擎运行，并且根目录级别的 AGENTS.md 是始终开启的——因此它会与您的始终开启的规则文件竞争相同的上下文预算，其激活方式是根据其所在位置推断出来的，而不是声明出来的。
将自动生成的记忆视为持久层。 文档对此异乎寻常地直接，这值得引用，因为这是厂商在告诉您他们自己的功能是干什么用的：
"对于您希望 Cascade 可靠地重复使用的知识，请将其编写为规则或添加到仓库中的 AGENTS.md 中，而不是依赖自动生成的记忆。规则是版本控制的、可与团队共享的，并且能让您对激活进行显式控制。"自动生成的记忆也是本地的：它们保存在 ~/.codeium/windsurf/memories/ 下，并且“在一个工作区中生成的记忆在另一个工作区中不可用，而且它们不会提交到您的仓库中”。如果导致您来到这里的原因是会话之间丢失上下文，为什么 Cascade 会丢失上下文 直接涵盖了这一方面。
解决方案：统一到 .devin/rules 并使每次激活都显式化
三个步骤。按顺序执行——盘点是确保第二步安全进行的前提。
步骤 1：在移动任何内容之前盘点每个层面
遍历所有七个层面，并记录每个层面中的内容。具体包括：工作区中以及向上至 git 根目录的父目录中的每个 .devin/rules 目录，相同位置的每个 .windsurf/rules 目录，工作区根目录下的 .windsurfrules 文件（如果存在），任何级别的每个 AGENTS.md 或 agents.md，global_rules.md，以及——如果您的组织部署了它们——系统目录（包括当前的和遗留的）。
每条规则需要记录两件事：它的激活模式以及其他地方是否已经存在等效规则。激活模式很重要，因为它是通过 trigger 字段在 frontmatter 中声明的，这四个值的使用成本差异很大。文档详细说明了这种权衡：always_on 会在每条消息的系统提示词中放入完整规则；model_decision 仅在提示词中放入 description（描述），并在 Cascade 判定该描述相关时读取完整文件；glob 在 Cascade 读取或编辑匹配该模式的文件时应用规则；manual 则将其完全排除在提示词之外，直到您输入 @rule-name。
在盘点时请注意两个例外：“全局规则文件（global_rules.md）和根目录级别的 AGENTS.md 文件不使用 frontmatter——它们始终开启。”这两个文件无法限制范围。其中的任何内容都会出现在每条消息中。
步骤 2：将每条规则移动到 .devin/rules 并手动解决冲突
将每个遗留规则复制到它实际所属级别的 .devin/rules 目录中——对于大多数规范来说，这应该是 git 根目录，而不是您创建它时恰好所处的某个包。
如果您在两个文件夹中发现了相同的规则，请在选择其中一个之前阅读这两个版本。这是规则偏差变得显而易见的步骤，而且它通常不是一个干净的重复：遗留版本可能包含新版本丢失的细节，或者新版本包含遗留版本从未获得的修正。请谨慎合并，然后删除遗留副本。
.windsurfrules 需要单独做决定。它是一个没有 frontmatter 的单文件，因此其中的所有内容都表现为一个无差别的整体。在移动它时，请将其拆分为具有声明触发器的单个规则文件——这正是新格式的全部优势所在。
对于 AGENTS.md 文件，决定每一个是否真的适合作为“始终开启”的内容。根目录级别的 AGENTS.md 无法限制范围，因此其中任何仅适用于部分目录树的内容，都应该变成子目录中的 AGENTS.md（该目录会自动获取通配符）或具有显式 glob 触发器的规则文件。
⚠️ 在修改这些文件时，请注意一个跨工具警告。Devin Desktop 对名称比较宽容——“不区分大小写：AGENTS.md 和 agents.md 都能被识别。”其他工具则不然。Kilo Code 的文档明确指出：“文件名必须是大写（AGENTS.md），不能是小写（agents.md）。”如果您的仓库与使用其他智能体的成员共享，请使用大写。这在这里不需要任何成本，却决定了文件是被读取还是在其他地方被默默忽略。当规则在不同厂商之间迁移时，也会出现同类的不匹配问题——将 Cursor 规则移至 Windsurf 涵盖了 frontmatter 方面的内容。
步骤 3：为所有可以拥有激活模式的内容声明激活模式
统一之后，检查 .devin/rules，确保每个文件的 trigger 都是深思熟虑的选择，而不是默认值。
真正的检验是针对每条规则问一个问题：这是否需要出现在每条消息的提示词中？大多数规则不需要。关于测试文件的规范是一个 glob 规则。发布操作手册是 manual。对数据模型的冗长解释是 model_decision，其中只有其描述始终存在，而主体内容按需读取。
这一步可以收回七个重叠层面悄然上下文预算，并且只有在消除重复之后才有可能实现——当同一条规则存在三次时，您无法合理评估激活成本。
在 MemoryLake 中进行设置
统一解决了文件夹的问题。但它并没有解决您无法快速解决冲突的原因：当同一条规则以两种不同的表述存在于两个地方时，没有任何东西记录哪个版本是当前的，或者它们之间发生了什么变化。
MemoryLake 将该记录完全保存在规则层之外，并通过 MCP 或 API 提供给任何请求它的智能体。您的 .devin/rules 文件保留在原处，并继续完全按照文档工作；而这里保存了规则引擎从未被设计用来存储的部分——每条规则的用途、它替换了什么以及何时替换。
步骤 1：创建 API 密钥
生成密钥并在大约三十秒内发出您的第一次请求。在统一的步骤 2 之前执行此操作，以便在解决冲突时捕获决策。
步骤 2：上传您的第一批记忆
在合并每个重复对时，记录您保留了什么、丢弃了什么以及原因。添加源自特定事件的规则——这些规则的措辞没人敢改动，因为没人记得原因。文档和其他文件也放在同一个地方。
步骤 3：连接您的 AI 和智能体
让 Claude、Codex、OpenClaw 以及您的 Devin Desktop 会话能够通过 MCP 或 API 进行访问。连接后，规则背后的推理可以按需检索，这使得规则文件本身能够保持足够简短，从而合理使用 always_on 触发器。
这在实践中改变了什么
最直接的变化是，“哪条规则实际上在生效”可以在一个地方得到解答。一个文件夹，每条规则一个文件，每个文件都有声明的激活模式。
第二个变化是上下文预算。七个重叠的层面，加上未知数量的始终开启的文件，意味着大量的提示词被浪费在仅适用于一小部分工作的指导上。去重然后声明触发器是降低这一消耗的唯一方法，而且它通常能回收比人们预期更多的空间。
第三个变化是下一次重命名将变得索然无味。这种情况还会发生——厂商合并、产品重命名、路径移动，而对厂商来说，负责任的做法是继续读取旧路径。如果您的规则已经统一，且您的推理存在于文件夹之外，那么下一次路径更改只是一个复制操作，而不是另一个考古项目。
单一规则层面的最佳实践
统一到 .devin/rules，因为这是文档中记录的首选位置，也是具有优先级的路径。 不要与优先级顺序对抗；移动到胜出的一方。
将项目范围的规则放在 git 根目录下。 新规则保存在当前工作区目录中，“不一定在 git 根目录下”，这就是单体仓库最终导致规范被埋在某个包内部的原因。
拆分 .windsurfrules，而不是整体移植。 单个无差别的文件无法表达激活模式，而这正是新格式带给您的主要好处。
使用大写的 AGENTS.md。 Devin Desktop 接受任一种大小写；共享仓库中的其他智能体可能需要大写。
仅将 global_rules.md 用于真正的个人、跨项目偏好。 它始终开启，适用于所有地方，且上限为 6,000 个字符。
仅在验证内容已移动后删除遗留副本。 旧路径仍会被读取，这意味着半途而废的统一比任何一种极端情况都更糟糕。
不要将自动生成的记忆作为您团队的记录。 文档建议使用规则或 AGENTS.md 来存储持久、可共享的知识，并指出自动生成的记忆是工作区本地的且不会被提交。对于该拆分的后半部分——什么内容属于智能体查询的存储库，而不是规则文件——适用于 Windsurf 用户的记忆工具 涵盖了这些选择。
结论
Devin Desktop 读取七个规则层面，其中两对之所以存在，仅仅是因为发生了重命名并保留了向后兼容性。.devin/ 的优先级高于 .windsurf/，两者都会被读取，在此之上 .windsurfrules 仍会被读取，并且 AGENTS.md 文件会将内容输入到同一个引擎中，其激活方式根据位置推断。
这一切都没有损坏。但所有这些都极易导致规则偏差，尤其是因为新规则会保存到您恰好所处的工作区目录中。
盘点所有七个层面，在合适的级别统一到 .devin/rules，拆分遗留的单文件，为所有可以拥有激活模式的内容声明激活模式，并将每条规则背后的推理保存在规则引擎不拥有的地方。这样，对于“哪一个会胜出”的回答就很简单了：只有一个。