CCSwitch 切换模型后效果不稳，怎么建验收样本库？

CCSwitch 调整模型或路由策略后，应用固定样本库、评分表、延迟成本记录和回退条件验收，避免只凭一次体验判断。

• 站内相关：ccswitch multi provider smoke test
• 站内相关：ccswitch model quality regression
• 站内相关：codex model reasoning effort audit
• 站内相关：ai model output sample audit
• Codex 安装与插件专题
• AI API 接入专题
• CCSwitch 配置专题
• AI 自动化办公专题

适用场景：模型能调用成功，但结果质量忽高忽低

CCSwitch 配置完成后，很多团队只做连通性测试：能返回、状态码正常、Key 没报错。真正进入 AI API 接入和 AI 自动化办公场景后，问题才出现：客服回复变啰嗦，合同摘要漏风险点，代码解释不按格式，知识库回答引用不足。此时不能只凭一两次主观体验判断模型好坏。

永沃云枢在 https://ai.jn83.com 的模型调用管理建议里，会把 CCSwitch 切换模型后的验收拆成样本库、评分表、延迟成本和回退记录。这样开发者 AI 调用既能比较效果，也能知道什么时候该回到上一版配置。

操作步骤：用固定样本覆盖真实业务

第一步整理样本库。每类业务至少准备 5 条：客服问答、长文摘要、JSON 抽取、代码解释、表格清洗、拒答边界。样本要来自真实任务的脱敏版本，不要只写理想化短句。第二步设置评分项：准确性、格式稳定性、引用完整度、响应长度、延迟、成本和是否触发人工复核。

第三步用同一批样本跑旧模型和新模型，记录 CCSwitch profile、模型名、base_url、时间、结果摘要和评分。第四步定义回退条件，例如关键字段错误超过两条、拒答边界失效、平均延迟超过可接受范围或成本超出预算。第五步把结论写进配置变更记录，避免下次只知道“换过模型”，不知道为什么换。

常见问题/避坑：冒烟测试不等于质量验收

冒烟测试只能证明 AI 模型接口能通，不能证明业务可用。CCSwitch 多模型路由尤其容易出现“默认模型改了但没人知道”的情况。建议每次调整 profile、默认模型、备用路由或代理地址后，都跑同一套样本，至少保留结果摘要和评分。

另一个坑是样本库长期不更新。业务变了，样本还停留在旧客服话术或旧文档格式，评分就会失真。可以每月从失败工单、人工退回记录和用户投诉中补 5 条样本，让验收库逐渐贴近真实使用。

检查清单：切换前后都要留记录

检查 CCSwitch profile 名称是否清晰；检查测试和正式 Key 是否隔离；检查样本库是否包含结构化输出、长文本和拒答边界；检查评分表是否有人工判定列；检查回退条件是否写明；检查最终配置是否同步给相关同事。

FAQ：样本库要不要很大？初期不必，20 到 30 条高质量样本比 200 条随意样本更有用。FAQ：能否让 Codex 帮忙评分？可以让 Codex 做初筛和差异摘要，但关键业务样本仍应人工复核，特别是合同、财务、客服承诺和权限判断。

排错路径：评分下降时不要马上换回去

样本库跑完发现新模型评分下降时，先看下降发生在哪类场景。长文摘要变差，可能是上下文预算或提示词结构问题；JSON 抽取变差，可能是结构化约束不够；客服回复变差，可能是语气和长度要求没有写清；代码解释变差，可能是样本里缺少项目背景。只有定位到场景，才能判断是模型不适合，还是 CCSwitch 路由和提示词需要调整。

同时要把延迟和成本放进同一张表。某个模型回答质量略好，但延迟翻倍，可能不适合实时客服；某个模型成本更低，但在合同和财务样本上错误更多，也不能直接用于高风险任务。开发者 AI 调用不是单项分数比赛，而是准确性、速度、成本和人工复核成本的综合取舍。

验收结论应写清楚“保留、灰度、回退或分场景使用”。例如客服草稿继续用新模型，合同摘要保留旧模型，JSON 抽取进入灰度一周。这样 CCSwitch 配置就不只是一个技术开关，而是模型调用管理的一部分。下次 Codex 协助排查时，也能根据记录判断当时为什么这样选。

补充一个维护动作：每次调整 CCSwitch 配置后，把样本库结果和配置文件版本对应起来。否则两周后只看到输出变化，很难判断是模型、路由还是提示词造成的。

最后保留一次人工确认记录，说明当前模型适合哪些场景，不适合哪些场景。