如何让 Continue 根据刚刚的对话编写规则（2026 指南）

指令文件是提前编写的，由某些人想象智能体需要什么。这是一个合理的做法，它捕获了稳定的内容——构建命令、样式、评审步骤。但它系统性地遗漏了其他所有内容，因为真正让智能体绊倒的事情在它绊倒之前是无法预知的。

Continue 明确了规则的用途：规则“为智能体模式、聊天和编辑请求向模型提供系统消息指令”，并且“为了形成系统消息，规则会按照它们在工具栏中出现的顺序用换行符连接起来”。规则是提示词级别的配置，每次请求都会重新发送。这种框架是准确的，它解释了为什么凭空想象编写的规则会显得单薄。你是在猜测系统消息的内容。

修正则不同。它到来时已经附带了一条好规则所需的一切：错误的具体行为、正确的行为，以及——如果你大声说出来（人们在生气时通常会这样做）——原因。“不要使用批量端点进行对账，因为超过一万行时它会超时。”最后这个从句是让规则在未来的决策中存活下来的关键。一个单纯的禁止在第一次遇到不便时就会被推翻。

问题从来不是人们不知道这一点。而是把它写下来是第二项任务，而且是在你最不想做第二项任务的时刻执行的。这正是工具调用（tool call）的用武之地。

在每个会话中重新输入约束。 这是默认做法，而且确实有效，因为代码最终是正确的。但代价是该约束的半衰期等同于你对它的记忆，并且团队中的其他人都看不到它。这个问题的大致轮廓在如何停止向 AI 重复解释上下文中有所提及。

一个始终启用的超大规则文件。 所有学到的东西都放入一个带有 alwaysApply: true 的单一规则中。它永远不会缺席，而这正是问题所在——几个月后，模型在每次请求时都会收到数千字累积的修正，其中大部分与当前任务无关，而重要的修正会与不重要的修正竞争。让模型面前保留更少的内容通常是更好的权衡，我们在智能体记忆与保留更少内容中论证过这一点。

将其写入 README 或设计文档。 直觉正确，但容器错了。Continue 从 .continue/rules 读取规则；除非有东西把 README 放进去，否则它不会出现在系统消息中。这些知识对人类保留了，但对智能体来说却缺失了。

信任对话。 修正就在聊天记录中，所以模型肯定知道。确实，在当前会话中是这样。Continue 的规则之所以存在，是因为这就是边界——指令是按请求重新提供的，而聊天并不是一个存储库。我们在为什么智能体会忽略你的指令文件中深入探讨了原因。

求助于技能（Skill）。 技能打包了一个过程。修正不是一个过程，它是关于你代码库的一个事实，这两者之间的区别比听起来更重要——参见为什么智能体技能不是记忆。

步骤 1：开启规则创建，并在进行修正的同时使用它

create_rule_block 是智能体调用的工具，Continue 的文档指出它在“启用时”工作——因此在依赖它之前，请确认它在你的智能体模式工具列表中可用。Continue 还提供了一个“添加规则”按钮用于手动创建规则，这是当你想要从头开始编写规则而不是从对话中编写规则时的备用方案。

行之有效的使用模式是一步到位地进行修正和捕获。不要只说“不，这里使用流式解析器”然后就继续，而是说“不，这里使用流式解析器——批量端点在超过一万行时会超时。为此创建一条规则。”智能体会根据刚刚进行的对话在 .continue/rules 中写入一条规则，这意味着它既包含了原因，也包含了指令。

生成的文件有两点需要检查，因为它们决定了步骤 2 中的一切。Continue 的文档指出，规则“应该是带有正确 YAML 前置元数据（frontmatter）的 .md 文件”，并且文件夹必须是 .continue/rules/——而不是 .continue/rule/，这是他们的故障排除部分特别指出的一个拼写错误。然后阅读智能体编写的前置元数据。它会代表你对 globs、description 和 alwaysApply 做出选择，而这个选择只是一个猜测。

Continue 并不是唯一提供此功能的工具；Cursor 也有一个 /create-rule 命令可以做类似的事情。Continue 文档记录得更清楚的是检索端，这正是决策的有趣之处。

步骤 2：刻意选择检索行为

Continue 的三个前置元数据字段相互作用，产生三种不同的行为，文档中对此进行了详细说明。

设置 alwaysApply: true 时，规则“始终被包含”。仅将此用于无论你修改什么都成立的约束。关于对账端点的修正显然不属于此类。

设置 alwaysApply: false 时，规则“如果存在 globs 且与文件上下文（context）匹配，或者智能体根据其描述决定将规则拉入上下文中，则会被包含”。这是大多数捕获的修正所需要的模式，它有两个独立的触发器。如果你知道该约束管辖哪些文件，请设置 globs——Continue 的文档将 globs 描述为“当文件作为上下文提供时”进行匹配。如果约束是关于一个概念而不是路径，请依赖 description，并将其写成检索查询而不是摘要。Continue 明确指出，“当 alwaysApply 为 false 时，智能体可能会阅读此描述，以确定是否应将规则拉入上下文中”。一个写着“对账约束”的描述在你在处理夜间结算任务时不会触发。而一个写着“对批量端点、对账、结算以及任何对大行数进行分页的约束”的描述则会触发。

完全省略 alwaysApply 会给你默认行为：“如果不存在 globs，或者存在 globs 且匹配，则包含”。这意味着一个没有 globs 且没有 alwaysApply 的规则会一直启用——这是一个合理的默认设置，但也是一个糟糕的意外。如果智能体生成了一个没有前置元数据的文件，你就无意中创建了一个始终启用的规则。

值得了解的一个顺序细节：“规则文件按字典顺序（lexicographical order）加载，因此你可以为它们添加数字前缀以控制它们的应用顺序”，例如使用 01-general.md and 02-frontend.md 这样的名称。由于规则会被合并为一个系统消息，因此在实践中顺序就是优先级。捕获的修正通常应该放在后面，在你的通用约定之后，这样它们读起来就像是细化，而不是被后面更通用的内容所矛盾。

步骤 3：在文件夹填满之前，将规则与事实分开

捕获几周后，阅读你的 .continue/rules 文件夹，并询问每个文件：这是一个约定还是一个事实？

约定说明了这里的工作是如何完成的——命名、错误处理形式、使用哪个测试运行器。它是稳定的，适用广泛，这正是系统消息的用途。保留它。稳定但庞大的领域知识是第三种情况，它应该放在存储库中而不是提示词中，如赋予 Claude 永久的领域知识中所述。

事实说明了发生了什么。“在 7 月发生内存（RAM）回归后，我们放弃了流式解析器。”“供应商沙箱需要 fixture 服务器，因此支付测试使用不同的命令。”“我们对不稳定的集成测试尝试了两种修复方法；两者都因相同的原因失败。”这些具有约定所不具备的属性：它们无限制地累积，它们被取代而不是被编辑，并且其中大多数在每个季度仅与少数任务相关。

作为规则存储的事实会隐性地过时。没有东西会告诉你某条规则描述的是一个在 8 月被撤销的决定，而将一个被撤销的决定作为系统消息指令呈现，比根本没有规则还要糟糕。这与导致评审历史系统发生漂移的失败是相同的，我们在从反馈中改进的智能体中讨论过这一点。

Continue 文档中记录的机制——带有这三种检索模式的规则——很好地覆盖了约定。在它们之中，没有文档记录的对应物来作为一个存储库，保存团队建立的、不断累积且可被取代的记录。这是对规则系统适用范围的陈述，而不是对它的批评；在任何工具中，系统消息对于这项工作来说都是错误的表现形式。

MemoryLake 是存放事实那一半的地方：一个位于代码库之外的存储库，保存已确立的决策，支持取代而不是默默过时，并且可以通过 MCP 或 API 从你运行的任何智能体中读取。

步骤 1：创建 API 密钥

生成密钥并在大约三十秒内发出你的第一次请求。相同的密钥适用于 Continue、同事的编辑器以及 CI。

步骤 2：上传你的第一批记忆

放入已经保存了项目决策的文档、图像和文件——当前重试策略背后的事件报告、没人想重复的设计评审，以及你刚刚确定为事实而非约定的规则文件。

步骤 3：连接你的 AI 和智能体

通过 MCP 或 API 授予 Claude、Codex、OpenClaw 和其他智能体访问权限。在 Continue 中，这意味着已确立的事实在相关时才会被检索，而不是永久存在于你的系统消息中。

你的规则文件夹不再无限制地增长。一旦事实有了其他去处，.continue/rules 就会稳定在实际约定的规模——对于大多数代码库来说，这个规模很小、可读，并且可以在拉取请求（pull request）中进行评审。

描述是为检索而写，而不是为归档而写。当 description 唯一需要做的事情是帮助智能体决定是否拉入规则时，你的写法就会有所不同，而你保留的规则就会在应该触发的时候开始触发。

修正的生命周期比代码库更长。规则存在于一次检出（checkout）中。而在其外部捕获的事实，在隔壁服务中出现相同约束时仍然可用，而隔壁服务往往是大多数重复解释实际发生的地方。

并且捕获习惯的成本变得足够低，得以坚持下去。这就是 create_rule_block 真正的释放：写下某些内容的成本降到了寥寥数语。它能否正确地被检索回来是一个独立的决定，现在你可以刻意地做出这个决定。

始终包含原因。 “不要使用 X”会被推翻。“不要使用 X，因为 Y”则不会。

绝不让前置元数据听天由命。 阅读智能体生成的内容。一个没有 globs 且没有 alwaysApply 的文件在每次请求时都会启用。

将描述写成查询，而不是标签。 当 alwaysApply 为 false 时，描述就是检索信号。包含你实际会输入的词汇。

为你的规则文件编号。 字典加载顺序就是实际的优先级。约定在前，细化在后。

首选 Markdown 文件。 Continue 指出规则最初是用 YAML 定义的，但现在推荐使用 Markdown 格式；保持单一格式使文件夹易于评审。

每月重新阅读该文件夹。 不是为了修剪约定，而是为了捕获那些悄悄变错的事实。

create_rule_block 解决了一个大多数工具都留给纪律去解决的真实问题：它消除了注意到约束与记录约束之间的摩擦。说一句“为此创建一条规则”，修正就会变成一个附带推理的文件，这比大多数手写规则能做到的还要多。

留给你的另一半是检索，而 Continue 为你提供了正确执行此操作的组件——用于路径范围约束的 globs、用于概念范围约束的 description、用于少数无条件事项的 alwaysApply，以及用于优先级的字典排序。刻意地使用它们，特别是在智能体生成的文件上，因为一个永远不触发的规则和一个永远不停止触发的规则会向相反的方向失败，而且两者看起来都像是一个装满规则的文件夹。

然后进行能保持整个系统健康的分类。约定属于系统消息。事实属于可以保存不断增长、可纠正的记录，并仅返回重要部分的地方。理清这个边界，才能防止捕获习惯变成一个无人阅读的目录。