团队里同事的模型对不上 / Cursor Router 是不是先被别的规则截住了？

同事说“今天拿到的模型和昨天不一样，自己没改过设置”，这类反馈最该先排除的不是模型端变更，也不是账号归属突然变了，而是请求在到达 Cursor Router 之前已经被别的规则命中。个人偏好、仓库级配置、团队默认规则、组织策略，只要有一条的范围覆盖到当前请求，Router 拿到的目标就已经被改写，Router 只是照做。建议的排查顺序是：先把两次请求的可比条件对齐，再在规则列表里找命中的那条，然后用单条禁用做对照实验，确认因果之后才去改配置顺序。

如果同事的账号、仓库、触发方式都没有变化，拿到的模型却变了，通常意味着规则层先命中了一条范围更大的条件（例如“全部仓库”“所有模型”这类通配），Router 只是执行了这个结果。可行做法：记录两次请求的时间、账号、仓库、触发方式与实际模型标识，只保留真正可比的字段；从规则列表顶部向下逐条核对条件是否覆盖当前请求；禁用单条规则重放同一请求，看模型标识是否回到预期。禁用属于临时验证手段，验证完必须恢复；组织级规则和模型白名单的改动通常需要管理员权限，成员自己改不了。

先把两次请求的时间、成员、仓库记下来

没有固定的变量，后面所有判断都不成立。同事说“昨天是 A 模型、今天是 B 模型”，如果两次分别发生在不同仓库、不同触发入口下，那这个对比本身就没有意义。建议在动手改任何配置之前，先把两次请求按同一张表填一遍，字段名可以按你们控制台的叫法替换。

时间(含时区)      : 2026-xx-xx 10:12 +08:00
成员/账号         : alice@example.com  (member_id: ...)
仓库与分支        : org/repo @ feature/login
工作目录/路径     : src/api/
触发方式          : Chat / Agent / Tab 补全 / CLI
客户端与版本      : ...
个人设置是否改动  : 否（改动过就写明改了什么）
提示内容特征      : 首条消息的简短摘要，不要贴密钥或业务数据
实际模型标识      : 从响应头、客户端显示或日志里读到的模型名
预期模型标识      : 团队约定值
规则版本/导出时间 : 控制台显示的版本号或导出文件的时间

判断两次请求是否可比，看这几项是否完全一致：账号、仓库加分支、工作目录、触发方式、客户端版本；提示内容不需要一模一样，但特征要相近，避免一条是长上下文补全、一条是短问答，落入不同的规则分支。时间不必精确到分钟相同，但要落在同一条规则的生效区间内，跨了发布窗口的两条记录不能直接对比。实际模型标识必须是读出来的，不要用“感觉像”推断。

在规则列表里找出优先级更高的那条

规则列表的阅读顺序要以控制台展示顺序、文档标注的优先级或者导出文件里的数组顺序为准，不要先入为主地认定“条件越具体越优先”。不少实现的匹配方式是首条命中即返回，只要宽条件排在前面，后面的窄条件根本没机会生效。下面是一段结构示意，字段名以你们实际配置为准，重点看顺序和 match 的写法。

rules:
  - id: org-default
    scope: organization
    match: { members: '*', repos: '*', paths: '*' }
    action: { model: team-default-model }
  - id: repo-legacy
    scope: repository
    match: { repos: 'org/legacy-*' }
    action: { model: legacy-model }
  - id: personal-alice
    scope: personal
    match: { members: 'alice@example.com' }
    action: { model: alice-preferred }

条件项的写法差异很容易被忽略：通配符单段和跨层语义不同；仓库名是精确匹配还是前缀匹配要看清；模型名的大小写、版本后缀、带不带命名空间都会影响命中；正则如果没加锚点，匹配范围往往比作者以为的大。判断某条规则是否包含当前请求，就把记录表里的成员、仓库、路径、触发方式逐项对到那条规则的 match 上，四项全部成立才算命中，任一项不成立就跳过。不要因为“看起来相关”就把一条规则认定为拦截点，这一步只做筛选，因果留给下一小节的对照实验。

临时禁用一条规则做对照实验

改配置靠猜代价太高，最小改动的验证方式是只停用一条可疑规则，重放同一请求。禁用之前先把规则导出为文件保存到仓库之外，记录导出时间；同时截图控制台当前顺序，写下待禁用规则的 id。这三样是后面恢复的依据，缺一样都可能把顺序搞乱。

团队里同事的模型对不上 / Cursor Router 是不是先被别的规则截住了？

一次只动一条规则，禁用而不是删除，也不要顺手调整别的规则或模型映射。
用同一账号、同一仓库、同一工作目录、同一触发方式重放请求，提示内容保持相近。
记录本次读到的实际模型标识，与预期值对比。
实验结束立即重新启用该规则，核对顺序与备份一致，再跑一次确认状态回到原样。

判读标准可以按下面四种情况处理：禁用后模型回到预期，说明这条规则就是拦截点，进入改写顺序环节；禁用后完全没变化，说明这条规则没有命中当前请求，恢复后换下一条；禁用后出现了第三种模型，说明还有别的规则在更前面或更后面生效，继续往下排；禁用后请求报错或无响应，立刻恢复，检查这条规则是否承担了兜底作用。禁用会影响同组成员，建议选低峰时段并提前打招呼，不要在工作时间直接停掉组织级规则。

确认原因后改写顺序并复验

找到拦截点之后，改的是规则顺序或条件范围，不是把规则一删了事。常见做法是把条件更窄的规则前置，把兜底规则放到最后，示意如下，具体顺序仍要结合你们的匹配语义确认。

rules:
  - id: repo-legacy
    match: { repos: 'org/legacy-*', paths: 'src/legacy/**' }
    action: { model: legacy-model }
  - id: repo-default
    match: { repos: 'org/*' }
    action: { model: team-default-model }
  - id: org-fallback
    match: { members: '*', repos: '*' }
    action: { model: team-default-model }

复验用同一条请求：同一账号、同一仓库、同一路径、同一触发方式，重放后读实际模型标识，判据就是与预期模型标识完全一致，而不是“差不多”。同时抽一个相邻场景（另一个仓库或另一位成员）跑一遍，确认改动没有把别人的路由带偏。如果控制台不支持拖拽排序，用规则 id 前缀或分组名固定顺序，避免下次编辑又被打乱。把改动前后的规则 id、顺序和复验时读到的模型标识写进变更记录，后续有人再问有据可查。

把这次排查结论同步给团队

这类问题重复出现的根源，通常是结论只留在排查人的脑子里。同步内容建议包含：现象和首次发现时间；命中的规则 id 与它的条件；实际改动是禁用验证还是调整顺序；复验方式和读到的模型标识；影响范围，即哪些仓库、哪些成员会受影响；回滚方式，即恢复顺序或重新启用哪条规则。

边界要写清楚：组织级规则、团队默认模型、模型白名单通常只有管理员能改，成员自己只能在个人偏好范围内调整，而且个人设置一般覆盖不了组织策略；仓库内以配置文件形式落地的路由规则，改动要走代码评审，不能直接推主干。下次自查的入口也一并说明：先看自己账号下实际拿到的模型标识，再看规则列表里排在前面且条件较宽的那几条，怀疑被截住时带上第一节的记录表找管理员，而不是先随手改设置。把记录模板和规则导出方式放到团队文档里，比事后口头解释省事得多。