要回答“这条请求最终发给了哪个模型”，判断顺序应当是：先在调用记录里拿到实际模型标识，再回到规则列表按展示顺序找出第一条完全匹配的规则，两者对上，才算确认了命中路径。反过来从设置页的默认模型或“当前选择”往下猜，很容易把请求模型当成实际模型。需要提醒的是，Cursor Router 的界面和配置字段在不同版本间可能有差异，下面提到的入口名称和键名请以你当前环境的实际显示为准；规则是顺序短路还是一次性匹配，也不建议在主规则上直接试验。

判断一条请求发给哪个模型，应先看调用记录里的实际模型字段，再回到规则列表按从上到下的展示顺序找第一条完全匹配的规则，而不是从设置页的默认项反推。记录入口与字段名以当前界面为准；规则是顺序短路还是一次性匹配，需要先在测试规则上用最小配置验证，不要直接改线上规则去试。

从调用记录里读出实际使用的模型标识

先拿到事实。可查看的位置通常有这几处，按可靠性从高到低排列：

• 请求详情或会话日志里的模型字段：多数客户端会把一次调用的请求参数和响应元信息留在会话详情中，展开单条记录即可看到模型名。入口名称各版本不一，以你界面里的“详情”“请求”“日志”这类标签为准。
• 响应体或返回头里的 model 字段：如果调用经过脚本或 SDK，把原始返回打印出来，看响应里标注的模型名。
• 中间层日志：如果请求经过自建网关或代理脚本，网关侧记录的上下游模型名是最直接的证据。
• 界面上的状态栏或模型角标：最方便，但也最容易只显示“当前默认”而非单次实际值，建议只作辅助。

需要重点看的是两类字段：请求模型和实际模型。请求模型是客户端发起时填写的值，可能是一个别名、一个占位名，也可能就是具体模型名；实际模型是服务端最终调用并返回的那个标识，通常出现在响应元信息里。两者一致时，说明这条请求没被路由改写；两者不一致时，说明命中了某条改写的规则，或者发生了回退。此时再看记录里有没有规则编号、路由名、回退标记之类的附加字段——有，就直接拿去和规则列表对照；没有，就靠模型名反查规则。

还有一种容易误判的情况：客户端缓存了上一次的模型显示，或者同一个会话里中途切换过规则。核对时以单条请求的时间戳为准，不要用会话级汇总值。

把规则列表的顺序与条件逐条对齐

拿到实际模型之后，回到规则列表。首先要确认的不是规则写了什么，而是顺序怎么读：

• 纯展示顺序：列表没有优先级数字，靠拖拽或上下移动决定先后，此时“从上到下”就是判定顺序，越靠上越先被检查。
• 显式优先级：每条规则带一个数值或序号，此时以数值为准，列表的视觉顺序可能只是排序结果。改完顺序后是否立即生效，需要以保存后的记录行为确认。
• 分组嵌套：如果规则按组展示，先确认是组间优先还是组内优先，这一点不同实现的处理不一致，建议标注为待验证。

条件项要逐条读语义，常见的有：模型名精确匹配、模型名前缀或通配匹配、上下文长度阈值、请求来源或客户端类型、是否带某个能力开关。同一条规则内的多个条件是“同时满足”还是“满足其一”，跨规则之间是“先匹配先返回”还是“全部评估后取最优”，这两点直接决定命中结果，而它们在界面上往往不写清楚。在没验证之前，按最保守的假设处理：规则从上到下、第一条完全满足的规则生效，然后用下节的最小配置去证实或推翻。

遇到两条规则条件并列的情况，比如两条都用前缀匹配且都能覆盖同一个模型名，此时先看优先级，优先级相同则看位置，位置也相同就是配置冲突，应当合并或删除其中一条，而不是靠调整顺序去赌。

写一条最小配置复现命中过程

验证顺序判断是否正确的办法，是造一个能被两条规则同时覆盖的请求，看它落在哪一条上。骨架如下，键名仅为占位，请替换成你配置里的实际字段名：

# 仅为结构示意，键名请按实际配置替换
rules:
  - name: rule-A-special
    priority: 10
    when:
      model: "<同一个模型别名>"
      context_tokens: "<大于等于 某个值>"
    then:
      model: "<模型甲>"
  - name: rule-B-generic
    priority: 20
    when:
      model_prefix: "<同一个模型别名前缀>"
    then:
      model: "<模型乙>"

请求内容的设计原则是只保留一个可区分特征：把模型别名固定成两条规则都能覆盖的那个值，其他条件（上下文长度、来源、能力开关）先保持默认，这样命中的差异只可能来自顺序和条件语义。第一步，按上面的顺序发一次请求，记录实际模型和命中的规则编号；第二步，把两条规则的顺序对调或优先级互换，再发一次同样内容；第三步，把上下文特征改到只满足其中一条，再发一次。

验证点有三个：每次记录里的实际模型是否随之改变；改变是否与列表顺序一致；当只有一条规则能被满足时，是否稳定命中该条。如果顺序对调后实际模型不变，说明判定不是顺序短路，而是按优先级或一次性匹配，此时应以优先级为准重新整理对照表。测试请在单独的测试规则或测试分组里做，验证完及时删除，避免残留规则影响真实请求。

把命中顺序整理成团队可查的对照表

验证通过后，把结果固化成一张表，让不接触配置的人也能自查“为什么这次用了这个模型”。表至少包含四列：

“影响范围”这一列容易被省掉，但对排查很关键：同一条规则可能只对某类请求或某个分组生效，写清楚之后，成员能先判断自己的请求是否落在该范围内，再去怀疑配置错误。

更新时机建议定为三个：规则新增、删除或调序的同一个变更里更新；路由配置版本升级后重新核对一遍顺序语义；出现“实际模型与预期不符”的反馈时，先更新表再改配置。放置位置优先选与配置同仓的文档目录，让表格和配置在同一个变更请求里评审，其次是团队共享文档；无论放哪里，都要写明最后核对时间和核对人，避免表格比配置旧。