让 Cursor 少犯旧错：规则与自动检查配合

在聊天里纠正 Cursor，它当场认错，下次却继续犯，问题未必出在提示词写得不够狠。原文的核心判断是：先确认规则有没有进入当前对话；如果已经进入却仍被违反，就该把要求交给 hook、linter 或测试执行。

这篇值得读的地方，是把「模型忘了」拆成了几种能排查的故障，也解释了 Agent 和 Bugbot 为什么未必共享经验。不过，作者整理的是文档和论坛案例，没有实测功能，也没有规则遵循率数据。

先查规则有没有送到，再改规则怎么写

聊天里的纠正，首先只属于那段聊天。原文引用的用户案例很典型：告诉 Agent 用 make test 测试后，它在当前线程里通常会照做，换个线程却又失效。

长对话也不保险。Cursor 会在上下文接近满载时压缩早期内容，工作人员承认，摘要可能丢掉部分指令。继续往线程里追加提醒，不能保证之前的纠正一直完整存在。

第一步是把反复出现的纠正写进规则。Agent 中的 /create-rule 可以创建规则；规则文档也提到，可以在 GitHub issue 或 PR 里标记 @cursor，让 Agent 更新规则文件。

但文件存在，不等于当前任务读到了它。

原文引用了两个发生在同一则支持回复里的案例：放在 infra/.cursor/rules/ 的规则，即使设置 alwaysApply: true，也只在聊天涉及 infra/ 时加载；指针文件则只传递路径，不会自动传递规则正文。另一条要求只用 GitLab 的规则已经进入上下文，却输给了其他内置指导，再加一条「不要用 gh」也未必有效。

规则没送到和模型没遵守，是两种故障，需要两种修法。

前一种要检查存放位置和匹配条件。Apply Intelligently 是否有 description，Apply to Specific Files 的文件模式是否匹配引用文件，规则所在文件夹是否属于当前任务范围，都比加重语气更有用。

后一种才涉及模型如何处理约束。原文引用的工作人员解释是：规则是注入提示词的强指导，并非违规就自动阻断的运行时保护。Agent 说「下次不会了」，也不能证明问题已经解决。

已经读到还违反，就让检查真正运行

如果短的新对话里已经带着规则，Agent 还是违反，就不宜继续围绕措辞打转。

原文给出的方向是，把可验证的要求放到 hook、linter 或测试里。hook 可以理解为工具执行前后自动运行的程序。它不需要等模型主动想起检查，而是在指定时机直接执行。

这里最容易误读的是触发时机。工作人员曾建议，通过 afterFileEdit 在每次编辑后运行 Ruff 和模块大小检查；但另一则回复明确补充，afterFileEdit 发生在文件写入之后。如果希望在写入前阻止操作，避免 Agent 基于违规修改继续开发，应关注作用于 Write 工具的 preToolUse。

检查发生在前还是后，决定了它能拦住什么。

原文还保留了一个关键限制：按 hooks 文档，hook 崩溃或超时时，默认会放行动作。因此，「配了 hook」不能直接等同于「违规绝不可能通过」，还要确认检查正常运行，并理解失败时的行为。

规则本身则应该减负。工作人员建议，把必须遵守的约束写得短、具体，使用 Always Apply 或放进 AGENTS.md；在 .mdc 中给出简短的 BAD、GOOD 示例，比抽象长文更容易被 Agent 采用。通用代码风格交给 linter，类型问题和行为要求分别交给类型系统、测试，也是原文引用的官方建议。

能交给程序判定的要求，不必全部依赖模型自觉。

这不代表任何要求都能写成检查。命名是否贴合业务、设计是否过度，往往仍需规则表达和人工审查。原文没有提供一种能把所有自然语言约束自动变成可靠检查的办法。

Agent 和 Bugbot 的经验，要分开核对

Cursor 里没有一个原文已经证实、所有功能都会读取的统一经验库。

最明确的边界是：.cursor/rules/ 下的项目规则 *.mdc 不适用于 Bugbot。Agent 的 Team Rule 与 Bugbot Automations 中的团队规则，也出现在不同设置里。作者查阅的页面没有说明两份列表会互相同步。

同一要求既要约束编码，又要约束审查，就需要分别确认入口：Agent 使用项目规则或 Team Rule；Bugbot 使用 .cursor/BUGBOT.md、Bugbot 团队规则，以及 dashboard 中的仓库规则。

Bugbot 确实有学习机制。2026 年 4 月 8 日的更新说明，它可以从 PR 反馈中形成 learned rules。信号包括对 Bugbot 评论的回复、表态，以及人工审查者指出的漏检问题；文档说，学习发生在 PR 合并或关闭时。

在 PR 中评论 @cursor remember [fact]，也能保存供后续审查使用的 learned rule。但这和前面提到的 @cursor 更新 Agent 规则文件，是两件事。

另一个容易漏掉的开关是 Automatically Learn Rules。原文引用的文档说明，在存在该开关的设置中，dashboard 仓库规则页面手动创建的 manual rules 也依赖学习开关；关闭学习，会让这些规则停止生效。这里的 manual rules 不是 .cursor/BUGBOT.md。

至于 Bugbot 学到的规则是否进入 Agent 聊天，作者没有找到说明。可以通过 /review-bugbot 或 /review 从 Agent 发起审查，但相关页面没有交代这种运行具体包含哪些规则，不能据此推断经验已经共享。

旧经验也可能反过来干扰任务。工作人员报告，部分使用过旧 Memories 的账号，Customize 页面可能漏显仍在加载的账号规则；Memories 已在 Cursor 2.1 退役。原文提供的排查办法是打开一个没有文件夹的新窗口，再进入 Customize、Rules 查看。

社区 Memory Bank 模板也需要核对读取链路。作者发现，reflect 会记录经验，但 plan 命令列出的读取文件不包括 reflection 和 archive 文件。这个观察只覆盖命令文件，不能据此断言整个模板都读不到经验。

我的判断

我赞同先检查传递路径，再讨论提示词质量。这和排查普通程序故障很像：配置写进去了，运行进程是否加载、条件是否匹配、加载后是否执行，是不同层面的问题。

原文最实用的取舍，是让规则负责表达意图，让工具负责验证确定性条件。和不断补充「必须」「绝对禁止」相比，这种分工能提供更具体的失败证据；但检查覆盖不到的设计判断，仍需审查。

证据边界也要保留。作者没有测试 Cursor 功能，没有运行 hook，也没有给出 Agent 或 Bugbot 的遵循率。论坛工作人员的回复针对具体案例，不能全部当成稳定产品契约。文章依据的是 2026 年 11 月 4 日和 5 日查阅的页面，后续行为还可能变化。

原文提到，Ofer Shapira 尝试把人工审查意见转成项目规则，两条候选规则达到他的证据门槛，最终只有一条通过真实代码测试。这支持「新增规则也要验证」的谨慎态度，但只是个人实验，没有足够对照数据证明某种规则写法普遍有效。

作者所属公司 Mnemoverse 提供 agent memory API，不过文章没有测试它。不能把对 Cursor 经验存储分散的分析，进一步当成购买另一套记忆产品的依据。

能拿来做什么

• 遇到重复错误时，先在新聊天里重做一次任务，并要求 Agent 逐字引用相关规则，再核对规则文件、类型、description 和文件匹配条件。模型的复述可以辅助定位，但不应当作完整的加载日志。
• 对前端或 Node 项目中反复出现、能够自动判断的问题，把格式和静态约束放进 linter，把行为要求放进测试，再根据需要配置 preToolUse 或 afterFileEdit。同时验证 hook 超时、崩溃时会发生什么。
• 团队同时使用 Agent 和 Bugbot 时，分别维护并核对两边的规则入口。在 PR 评论 bugbot run verbose=true，可按原文所引文档查看本次包含的规则，以及被截断或遗漏的规则。
• 每次新增规则后，拿真实代码验证一次，检查它能否纠正目标错误、是否影响正常修改。对于旧 Memories 用户，还应排查界面未显示但仍被加载的账号规则。