模型菜单只剩一个自动选项：用户侧丢了选择权，要换回三样东西
一、选择权消失之后，责任并没有一起消失
据公开报道，有厂商正在把一个模型系列从”可以挑的模型”改造成”不用挑的入口”：免费账号的模型菜单收成一个自动选项，旗舰型号只对某个计划的少数成员开放，面向企业的形态则是把模型选择埋进流程里。厂商名称、计划名称与成员数量只作转述，不作为本篇的判断依据，本篇也不讨论这家厂商为什么这么做。
本篇讨论的是接受这件事之后要面对的东西。把模型选择交出去，对客户侧的直观好处是省心：不用追型号、不用比参数、不用在版本之间做取舍。但责任结构没有变——输出错了还是客户在解释，成本超了还是客户在付款，审计来了还是客户在提供材料。于是就出现一个不对称：决定是别人做的，后果是自己担的。
这个不对称可以接受，前提是把丢掉的东西用另一种形式换回来。我们认为要换回来的只有三样：看到、复现、追责。三样都不是事前选择权，全是事后能力。少了任何一样，自动路由就从一种省心变成一种失控。
二、换回第一样：响应里必须回带实际后端与配置指纹
自动路由下最容易丢的是”我刚才用的是哪个”。所以第一条要求是每次响应都带上服务侧的真实信息，而且要落在结构化的位置上，而不是藏在展示层。
最少要包含四项：实际后端标识，即这一条请求由哪个模型或哪一档处理；配置指纹，一个能区分推理配置的稳定串，权重变了、量化变了或后端参数变了它应当变；路由决策的可见理由，例如”输入长度超过阈值”或”命中代码任务分类”，用枚举码而不是自由文本；以及时间戳与请求标识，用来把同一会话里的多条响应串起来。
有人会觉得这些是内部实现细节，服务方没有义务暴露。我们的立场相反：只要调用方不再指定模型，这些字段就从实现细节升格为接口契约的一部分。你不告诉我选了谁，我就无法把任何一次输出与任何一个配置联系起来，后面两样能力全部落空。对多轮会话，还要求服务方承诺同一会话内的后端粘性或者显式提示切换，否则用户会在一次对话里遇到两种脾气，而日志里看不出来。
这四项里配置指纹最关键，因为后端标识可能只是一个粗粒度名称，真正能区分两次请求是否同源的往往是它。指纹缺失时我们的处理是把该批次全部标记为不可比较，宁可让数据断档，也不把它接进趋势里。
三、换回第二样：可重放的通道，以及回归测试的三种失效模式
第二样是复现。自动路由下，”同样的输入再跑一次得到同样的结果”不再是理所当然的事，必须把它做成一条可申请的通道：同一个输入、同一个时间窗、指定回到原来那个后端与配置去执行。有的服务方提供带指纹重放的接口，有的不提供，这本身就是采购时要问清的一项能力。
没有重放通道，回归测试会出现三种典型的失效模式。第一种是基线漂移：你的期望输出是在某个配置下建立的，配置无声变化之后，测试失败到底是被测代码坏了还是基线过期了，没人能分开。第二种是失败无法归因：同一个用例今天过明天不过，检查后发现路由把两次分派给了不同后端，缺陷单只能挂在”不稳定”上，长期无人处理。第三种是灰度不同源：验收环境抽到的配置和生产环境不是同一批，于是验收结论对生产没有覆盖力。
对应的三个动作。一是自带影子端点：在业务侧保留一条固定的、不经过自动路由的调用通道，回归用例一律走影子通道，让基线与生产解耦；影子通道不承接流量，只承接验证。二是按周固化基线：每周把通过用例的输入、输出、当时的后端标识与配置指纹一起归档，形成一份可追溯的快照，比对时先确认指纹同源再谈差异。三是把漂移本身写进缺陷单：只要出现同一输入跨后端结果不同，就按缺陷记录，哪怕两个结果都算可接受——因为真正的问题是可复现性丢了，不是某一次结果不好。
这三条和”模型名带日期后缀被静默替换”那套流程不一样，那套的前提是版本号存在、只是变了；这里的前提是根本不给版本号，所以第一步不是比对版本，而是先争取让版本出现。
四、换回第三样：追责，落到条款字段与留痕
第三样是追责，它靠合同和日志，不靠沟通。我们先分清一个容易混淆的概念：能指定版本和能指定档位是两件事。指定版本是对具体模型实现的锁定，指定档位是对一类能力的锁定，例如”这一档必须能处理长上下文并满足某个延迟区间”。自动路由的形态下，服务方往往不愿给版本承诺，但档位承诺是可以谈的，而且档位承诺对我们更有用——我们要的是行为可预期，不是某个名字永远不变。
| 条款项 | 该写的形式 | 为什么不能省 |
|---|---|---|
| 路由结果可见性 | 响应必须回带后端标识、配置指纹、决策原因码 | 没有它，追责没有对象 |
| 档位承诺 | 按能力档位与延迟区间承诺，不承诺具体名称 | 名称会变，档位可验 |
| 变更通知 | 生效范围、生效比例、是否影响已在跑的会话 | 灰度不同源会让验收失效 |
| 重放与留证 | 是否提供同配置重放、留证保存期、可调取的格式 | 复现能力是合同权利不是善意 |
| 锁定与例外 | 哪些业务可要求固定后端，锁定是否有额外计费 | 判断线的落地依赖这一条 |
| 退出协助 | 数据与提示资产的可迁出格式、迁移期支持 | 退出路径要提前写好 |
企业侧的留痕字段则是另一份东西，它要能提交给第三方。我们要求至少四类：请求侧留痕（输入摘要与哈希、业务标签、发起人与时间、会话标识）；响应侧留痕（后端标识、配置指纹、决策原因码、输出摘要与哈希、拒绝或降级标记）；成本侧留痕（计量单位与花费、是否命中限流、重试次数）；人工侧留痕（谁复核、结论、是否触发覆盖）。四类都按请求标识关联，输出本身是否全文保存由业务性质决定，但至少要有能证明”当时确实生成了这个内容”的摘要与时间戳。审计要的从来不是你能说出用了哪个模型，而是能证明某个结果在某个时间由某个流程产生。
五、退出路径：把选择权外包之后要留的后手
把模型选择交给上游，不等于把系统架构交给上游。三条后手要在接入第一天就搭好，等出问题再补代价很大。
第一条是抽象层。业务代码只调用自己内部定义的能力接口，例如”生成结构化摘要””按规则判定”，不出现任何具体模型名称；后端与档位的映射集中在一处配置里。抽象层的价值不在于以后能省钱，而在于上游改动时你的改动面可控。第二条是备选后端。至少要有一个经过验证的第二来源，即使平时不接流量；备选后端需要定期演练，只在真出事时第一次启用等于没有。第三条是提示与工具定义的可移植性。系统提示、工具 schema、评测用例都属于可迁移资产，要放在自己的版本库里，写成不依赖某家私有语法的形态，并记录每条提示当初是在哪个后端上调出来的——换后端时这些提示的行为会变，没有这条记录就无法解释变化。
这三条不构成”所有企业都该自建路由”的结论。自建路由是一套需要持续投入的系统，多数团队不该做；需要保留的是接口与资产的可迁移性，而不是自己再造一个调度器。
六、判断线：什么业务可以自动，什么必须锁定
不是所有场景都要争锁定。我们的分法很简单：看一次错误结果的代价能不能被事后修正。
可以让上游决定的，是那些错误代价低、可以被用户当场发现并重来一次的场景，比如内部草稿、头脑风暴、格式转换、非正式问答。这些场景里自动路由确实省心，锁定后端反而浪费钱。必须锁定的有四类。合规与法务相关的输出，结果要能对应到确定的处理条件，追溯不了就是问题；医疗相关的辅助判断，同一输入跨后端给出不同结论会直接影响处置；财务与对账，数值类任务对精度路径敏感，不接受”两次不一样”；对外承诺效果的产品，你在合同或宣传里给了质量承诺，而承诺的达成依赖具体后端行为，这时选择权不是偏好问题而是履约问题。
洹拓在项目立项表里把这一判断做成一个问题：这个功能出错后，是用户重跑一次就能解决，还是需要向外部解释。前者放行自动路由，后者进入锁定流程，锁定流程走不通就不上线。这个问句看起来简单，但它比任何技术指标都更早暴露风险，因为它逼着业务方说清楚自己承担的是什么后果。
菜单收成一个选项这件事，本身是产品形态的演化，不必当作倒退。只是对企业侧来说，省心的代价是把控制点从”我选”移到了”我看见、我复现、我追责”。这三样在接入前一句都没谈，接入后一句都补不回来。