Bugbot 规则与上下文

Bugbot 使用自己的 review rules。Cursor .cursor/rules/*.mdc 项目规则不适用于 Bugbot 评审，不能只在编辑器规则里声明评审政策。

规则来源

团队管理员可创建作用于启用仓库的 Team Rules。评审合并顺序为 Team Rules、项目 .cursor/BUGBOT.md（含嵌套）、learned rules、manual rules。该顺序是包含顺序，不应自行解释成后者总能推翻前者。

根 .cursor/BUGBOT.md 始终包含；对于变更文件，再向上查找祖先目录内的 .cursor/BUGBOT.md。

project/
  .cursor/BUGBOT.md
  backend/
    .cursor/BUGBOT.md
    api/
      .cursor/BUGBOT.md

例如 backend/api 下变化会带上相关祖先规则，不需要把全部目录规则复制到根文件。

Learned 与 manual

在 repository rules 启用组织和仓库 learning 后，可从 GitHub 活动自动学习、回填历史，也可在 PR 评论 @cursor remember [fact] 保存后续使用的规则。系统会随活动调整 learned rules 的启用状态。

manual rules 同样要求组织和仓库 learning 已开启。每条含名称、正文和可选 scoped paths glob，空路径范围适用于整个仓库。Azure 等服务商的自动学习支持以集成限制为准，不能推广 GitHub 行为。

长度与实际生效

每条包含时截断到 30,000 字符，合并规则最多 100,000 字符，超限可能遗漏部分；required team rules 优先于非 required。

在支持评论触发的平台使用：

bugbot run verbose=true

返回的规则表会标注被截断或遗漏项。规则 analytics 可查看 findings、相关 PR、accepted issues 与 acceptance rate；指标反映报告与反馈，不是规则形式化执行证明。

编写边界

规则写明适用路径、具体缺陷条件和需要提供的证据。自然语言规则可以指导检查，但不要从官方示例中“blocking Bug”或“License Scan”等措辞推断已经配置了强制 CI 阻断；合并状态仍由Bugbot 检查结论及仓库策略决定。