同一个仓库、同一类任务，两个人最后拿到的模型不同，通常不是仓库本身有差异，而是请求在离开编辑器时携带的成员身份、用量状态或任务上下文不同，被路由规则分到了不同分支。判断顺序建议是：先把两人在成员属性上的可变量摆齐，再回到规则条件里找与成员相关的判据，最后用同仓库、同类提示做一次对照请求，确认差异是否由成员身份单独造成。整个过程只在能通过页面、配置、日志或命令观察到的事实上推进，猜不出来的项标为待验证，不要先下结论。

同仓库出现模型差异时，优先怀疑三处：账号所属组织与成员角色、个人偏好或覆盖配置、规则中与用量和任务类型相关的条件。可执行的路径是先列成员属性差异表，再读规则条件与优先级，然后用同一条提示在相近时间窗内各发一次，采集返回的模型标识与请求标识做比对。边界在于：若两人用量档位或客户端版本不同，对照结果不能直接归因于成员身份。

先列出两人在成员属性上的差异

不要先看代码，先看账号。把两个人当成两个输入变量，凡是可能进入路由判断的成员属性都写进一张对照表，写不全就标待验证，比凭印象争论有用得多。

建议对比的属性项至少包括：所属组织或工作区、成员角色（管理员 / 普通成员）、席位或套餐类型、所在用户组或团队、个人偏好里是否手动指定过模型、是否开启过自动选择、客户端版本与登录方式、当前用量档位、是否存在针对个人的覆盖配置、以及网络出口是否不同（企业出口与家庭出口可能落到不同策略，需结合环境确认）。

其中属于管理员才能改的范围通常是：组织级路由规则、成员角色与用户组归属、席位与许可、组织级模型白名单、针对个人的覆盖配置。普通成员自己能改的一般只有个人偏好和客户端侧设置。区分这一点很关键，否则会把“我改不了”误判成“配置不存在”。

无法确认的项不要留空，按“待验证 + 找谁确认 + 用什么方式确认”的格式标注。例如“席位类型待验证，找管理员在成员列表页确认”，或“是否命中个人覆盖待验证，看请求日志里是否带覆盖标记”。

在规则条件里找出与成员相关的判据

规则通常由“条件 + 动作”组成，读法是逐行念成一句话：当条件 A 成立（或 A 与 B 同时成立）时，选择模型 X。不要跳读默认规则，默认规则往往就是两个人结果不同的真正原因。

识别与成员身份相关的字段，看字段名即可初筛：出现 user、member、role、group、team、seat、plan、tier、domain 这类词的，多半和成员身份有关；出现 usage、quota、token、request_type、task_type、context_length 这类词的，属于用量与任务维度。两类混在一行时，要判断是“且”还是“或”，这决定了一个普通成员是否会被用量条件二次改写。

并列条件的优先级需要单独确认：有的实现是自上而下首个命中即返回，有的是全部命中后取优先级数值最高者。可以先在测试账号上构造一组互相冲突的条件，观察最终落到哪个模型，再回头读配置，通常比单纯读文档更快确认。

# 通用规则骨架，字段名以实际配置页为准
rules:
  - name: admin-default
    when:
      member.role: admin        # 与成员身份相关
    then:
      model: <model-a>
  - name: heavy-task
    when:
      task.type: refactor       # 与任务类型相关
      usage.tier: standard      # 与用量相关
    then:
      model: <model-b>
  - name: fallback
    when: {}
    then:
      model: <model-default>

把每条规则的“条件、优先级、动作”抄成三列表格，再对照两人实际拿到的模型，基本能看出是哪一条在起作用。若配置页只显示规则名不显示条件，就用请求日志里的命中字段反推。

用同一仓库同一类提示做对照请求

这一步的目的是排除干扰变量，只留下成员身份。做法是两人在同一个仓库、同一分支、打开同一批文件，输入内容完全一致的提示，各自发起一次请求，然后比对返回结果。

提示内容保持一致的要求：同一条文本，不改写、不加“请帮我”、不调整长度，附带的上下文文件数量和范围也要相同。一个人写“重构这段”，另一个人写“解释这段”，任务类型判据就会被触发，对照就失效了。

时间间隔建议控制在相近的时间窗内，例如两人先后在几分钟内完成，避开额度统计窗口切换的时段，也不要在月初月末额度边界上做对照。用量档位发生变化时，结论需要重新测一次。

需要采集的结果字段包括：返回的模型标识、请求标识或追踪 ID、请求时间戳、发起请求的账号、是否出现规则命中信息、客户端版本。可以通过请求日志或响应头取得，取不到的字段同样标待验证。

# 对照记录模板，逐字段填空
repo:      <仓库名>/<分支>
account:   <成员账号>
time:      <发起时间>
model:     <返回模型标识>
request_id:<请求标识>
rule_hit:  <命中规则名，无则写未知>
client:    <客户端版本>

两次结果一致，说明差异来自用量、任务类型或客户端，而不是成员身份；两次结果不同且其他变量已固定，才可以把成员身份列为主要怀疑对象，再回到规则表确认具体条件。

把分流结论写成团队内的说明

结论要让其他成员看完就知道自己为什么拿到这个模型，而不是只留一句“路由不一样”。说明里应包含判据：哪条条件、优先级多少、命中后选择哪个模型，以及这条判据依据的是成员角色、用量档位还是任务类型。判据写具体到字段，别人才能自行核对。

边界也要写清楚，哪些情况会例外：用量档位变化后可能落到另一条规则；任务被识别成不同类型时结果会变；客户端版本不同可能走不同分支；个人偏好里手动指定过模型的成员不受通用规则约束；管理员临时调整规则期间结论会失效。把这些列成短条目，比一句“以实际为准”更有用。

遇到不一致时的自查入口，建议按固定顺序走：先确认自己账号的角色与用户组，再看个人偏好是否覆盖了模型，然后按前面的模板再发一条同条件请求，最后把请求标识和规则名一起交给管理员。自查顺序固定下来，讨论就不会反复回到“是不是仓库配置不一样”这个起点上。