模型没有按预期切换，通常不是某一个页面的问题，而要分成两层来看：规则层决定“这次请求应该被路由到哪个模型”，成员层决定“这个成员是否在规则的生效范围内”。只要有一层不成立，最终行为往往都会回到默认模型，界面上看到的现象几乎一样，所以只盯着规则页反复调整，通常看不到变化。建议按“先确认改动属于哪一层 → 核对成员是否被覆盖 → 用对照账号复验 → 记录两层对应关系”的顺序处理，每一步都以可观察的结果作为判断依据，而不是凭印象。

模型没换，先分两层定位：规则层看条件是否命中、改动是否已保存并生效到目标环境；成员层看账号是否落在规则的覆盖范围内，包括分组、角色、套餐和单独排除项。两层都确认后再调参数，能避免在错误的页面反复试错。若两层看起来都正常，再用同分组、同角色的对照账号发同一条请求，把差异收敛到单一变量；记录每次改动的规则名、覆盖范围和验证时间，便于后续比对。具体优先级和下发方式因实现而异，需要结合自己的环境确认。

判断这次改动落在规则层还是成员层

先看入口。规则层通常位于路由规则、模型映射、默认模型这一组配置页；成员层通常在成员管理、分组、策略分配或套餐这一类页面。两者一般不在同一个表单里，如果改了规则页而成员页没动，或者反过来，就很容易出现“保存成功但没效果”。

再看影响对象。规则层影响的是“满足条件的请求走哪个模型”，成员层影响的是“哪些人受这条规则约束”。同一条模型选择有时在两处都能设置，取舍依据是“谁更具体谁先赢”：成员或分组级的设置一般比全局规则更具体，但不同实现的优先级并不一致，需要结合环境确认。不确定时，建议先把两处改成同一个值做一次验证，再逐层撤回对比；同时改两层会让结果无法归因。

# 规则层与成员层的对应关系（示意，字段按实际环境替换）
规则名:  default-route / team-a-route
覆盖范围: 全部成员 | 分组 A | 指定账号列表
命中条件: 客户端、模型别名、请求路径、上下文长度阈值等
实际模型: 规则最终指向的模型标识
成员侧属性: 账号、分组、角色、套餐、是否被单独排除

核对成员是否落在规则的覆盖范围里

规则写对了但人没被覆盖，是最常见的一类误判。需要逐项核对的成员属性包括：账号标识是否与规则里写的一致、所属分组或团队、角色、套餐或授权状态，以及是否被单独加入排除名单。任何一项对不上，规则都不会作用到这个账号上。

范围匹配的判定方式建议做“数量对照”：规则里写了覆盖 10 个账号，就回到成员列表数一遍实际命中几个。数量对不上，通常是分组发生过变更、成员被移出，或者规则修改后没有重新下发到目标环境；这时优先查成员的当前属性，而不是继续改规则条件。新加入的成员需要单独确认：新账号常常落在默认分组，不会被历史规则覆盖，建议在成员加入后单独发一次请求验证，而不是默认它自动继承。

用对照账号做一次复验

对照账号的选取条件是“除待验证变量外尽量一致”：同分组、同角色、同套餐、同客户端；一个是被改动的账号，一个保持未改动。两次请求需要保持一致的内容包括模型名或别名、客户端与入口、鉴权方式、请求路径、时间窗口，以及提示内容的长度量级——长度差异过大时，可能触发基于上下文长度的不同处理，结果就不能直接对比。

结果分支可以这样处理：

• 被改账号生效、对照账号不生效：改动属于成员层，回到成员属性与分组范围继续查。
• 两个账号都不生效：改动属于规则层，检查命中条件是否写错、规则是否已保存并下发到当前环境。
• 两个账号都生效：改动是规则级或全局级，重点确认是否有其他规则覆盖了它，以及优先级顺序。
• 两个账号表现不一致但都不符合预期：先固定请求内容再重测一次，排除客户端缓存或会话残留的影响。

把两层配置的对应关系记录下来

排查过程如果没有记录，下一次仍然会从零开始。建议用一张表维护规则层与成员层的对应关系，列至少包含：规则名、覆盖范围、实际模型、修改人、验证时间；可以再加一列“验证方式”，写明是用对照账号还是单账号验证的。

存放位置建议放在团队可访问的共享文档或配置仓库里，和实际配置放在同一个可追溯的地方，避免只存在个人笔记中。更新频率上，规则变更、成员分组调整、套餐变动这三类操作后都应更新一次；如果成员流动频繁，可以按固定周期做一次例行核对，把表里的覆盖账号数与实际成员列表对一遍。