改完 Cursor Router 的默认模型却不生效，先不要怀疑路由逻辑坏掉了。按经验，新会话仍走旧模型，多数是三种情况之一：改动没保存、改动只对旧会话可见但旧会话不会重新读取、或者默认值被更高优先级的规则盖住。判断顺序建议是：先排除刷新与会话继承，再排除规则覆盖，最后只改一处做最小验证，并用前后两次真实请求留档对比。这样做的边界是：只能证明“这条请求命中了哪条规则”，不能据此推断整体流量行为是否改变。

Cursor Router 的默认模型改完不生效，先确认三件事：配置页是否显示已保存、新开会话是否重新读取默认值、请求实际命中的是不是那条默认规则。建议用一条真实请求做对照：改前发一次、改后发一次，只动一处配置，记录实际模型标识与命中规则。如果两次请求命中同一条规则，说明改动没有进入生效路径，应回到保存状态和规则优先级排查，而不是继续叠加新规则。

先确认改动已保存并作用于新会话

保存状态要在配置页本身判断，而不是凭“我点过保存”来判断。常见界面上会有保存按钮置灰、出现“已保存”提示、或者配置列表里的默认模型字段回显成新值，这三者任意一项都可能滞后。建议直接刷新一次配置页再回看默认模型字段：刷新后仍显示新值，才算写入了服务端可读的配置；刷新后跳回旧值，说明保存动作没有真正落盘，问题不在这里往下走。

旧会话是否继承新设置，需要单独验证。多数 Router 类工具会在会话创建时读取一次默认模型，之后按会话保存上下文，因此已经打开的会话通常不会因为默认值改了而切换。判断是否需要重开会话，可以看两点：在旧会话里触发一次请求，看命中的模型标识是否变化；或者直接新建一个会话，发同样的请求，比较两者的模型标识。如果旧会话不变、新会话变了，说明改动本身有效，只是旧会话不继承，需要重开一次会话再测。

需要重开会话的判据可以定得简单些：默认模型字段刷新后为新值、旧会话命中仍是旧模型、新会话命中为新模型，满足这三条就按“旧会话不继承”处理，不必再动规则。反之，如果新会话也还是旧模型，才进入下一节查规则优先级。

检查是否被更高优先级的规则覆盖

默认值不等于最终生效值。Router 类配置通常会按顺序或按匹配条件挑选规则，越具体的匹配条件优先级越高，默认规则往往排在最后作为兜底。覆盖的表现形式一般分两种：一种是配置列表里默认规则明明写了新模型，但请求明细中命中规则的名字是另一条；另一种是你在默认规则上改的字段，被一条同样能匹配该请求的规则先命中了。前者看命中规则名，后者看规则排序和匹配条件。

被覆盖时页面上可观察到的差异，主要集中在请求记录或调用日志的明细里。建议摘录这几个字段做对照：实际模型标识、命中规则名称或规则 ID、规则匹配条件、请求时间。如果命中规则名称不是默认规则，那么无论默认模型改成什么都不会体现出来，这时候应该去改那条实际命中的规则，或者调整规则顺序，而不是反复修改默认值。

这一步的边界要说明：只凭页面回显判断覆盖关系并不可靠，尤其是多条规则条件相近时。可以先不做任何修改，只发一条请求，把命中的规则名记下来，作为后面最小验证的基准。

只改一处做最小验证

把变量压到最少，结果才可解释。原则是：一次只动一条规则、只动一个字段，其他规则和匹配条件保持不变。如果怀疑被覆盖，就先只改那条实际命中的规则上的模型字段，而不是同时改默认值和规则顺序。以下是一个最小配置骨架，字段名以实际界面为准，这里只表达结构：

rules:
  - name: <实际命中的规则名>
    match:
      <匹配条件字段>: <保持原值不变>
    model: <新模型标识>

default:
  model: <保持原值不动>

请求设计上要保证改动前后可比：同一个会话或同一类新建会话、同样的输入内容、尽量接近的时间点各发一次。不要在一次对照里同时改模型和改匹配条件，否则命中变化会被误读成模型生效。改完一处后，先不急着扩大范围，用下节的对比方式确认这次改动到底落在哪条规则上。

用前后两次请求对比并留档

把“看起来生效”变成可复查的结论，靠的是同口径对比。对比项建议固定为三项：实际模型标识、命中规则名称、请求时间。改前一次、改后一次，两次请求的输入保持一致，把这三项并排记录。如果实际模型标识变了、命中规则也确实是刚改的那条，说明改动进入了生效路径；如果实际模型标识没变、命中规则仍是别的一条，说明问题在规则优先级而不是保存环节。

留档形式不必复杂，请求记录页的截图、复制出来的请求明细、或者记录到一张对照表里都可以，关键是把“时间 + 命中规则 + 实际模型”三列放在一起，便于事后复查。判定失败时的后续处理入口建议按顺序回到上一节：先确认保存与刷新，再确认新会话是否继承，最后回到规则优先级，确认实际命中的规则名是否仍是旧的那条。不要在结论不明确时继续叠加新规则，那只会让后续对照失去基准。