CCSwitch 流式输出显示不完整怎么办？模型接口兼容性排查
切换模型后，聊天窗口只显示半句话、一直转圈、内容重复或等到最后才一次性出现，通常不是模型“变笨”，而是流式协议、代理缓冲和客户端解析没有对齐。
适用场景：同一客户端，不同 profile 表现不同
如果 CCSwitch 中一个模型能正常逐字显示，另一个模型却空白或截断，先不要直接判断模型服务异常。不同上游可能返回不同的事件字段、结束标记和内容分片；代理还可能把事件缓冲后再转发，浏览器端则可能只识别其中一种格式。模型调用管理的第一原则是把“上游返回什么”和“客户端显示什么”分开观察。
这类问题常发生在 Codex 或开发者工具切换 profile 后。接口地址、模型名、stream 参数、请求头和超时配置只要有一项不一致，就会出现“非流式正常、流式异常”的假象。永沃云枢建议先用固定请求复现，再逐层替换变量，而不是同时改五个配置。
操作步骤：从原始响应到界面渲染逐层定位
第一步确认 profile 的接口地址、模型标识和是否开启流式，保存一份脱敏后的配置快照。第二步用同一个请求分别测试 stream=false 和 stream=true，记录 HTTP 状态、响应头、首字节时间、结束时间和正文片段。非流式成功而流式失败，说明认证和模型基本可用，问题范围缩小到协议链路。
第三步检查原始事件格式。常见差异包括事件前缀、换行分隔、JSON 字段名、结束标记和空内容事件。不要用“按每个换行 split”这种脆弱解析处理所有上游。第四步检查代理是否启用了响应缓冲、压缩或超时，必要时用本地直连与经过 CCSwitch 的请求做对照。
第五步检查客户端渲染器：是否把增量片段重复追加，是否收到结束事件后仍等待，是否遇到空 delta 就误判为结束。第六步为每个 profile 建一条最小验收样本：短文本、长文本、中文、代码块和工具调用各一条。切换模型后只看这五条，不要凭一段聊天印象判断兼容性。
常见问题/避坑：不要把 timeout 当成唯一答案
流式输出一直转圈可能是没有收到结束事件，也可能是客户端在等待完整 JSON；显示重复可能是代理重试，也可能是前端把已消费的缓冲再次绘制。先看原始响应和请求次数，再改超时。把超时从 60 秒改到 300 秒，可能只是把错误延后。
FAQ：非流式能返回，是否代表流式一定支持？不代表，必须实测协议和结束标记。FAQ：能否让 CCSwitch 自动把所有格式转换成一种？可以考虑适配层，但要记录转换失败和原始片段，不能静默吞错。FAQ：为什么只在中文时截断？可能是字节流与字符边界处理错误，或代理压缩解压不完整，应测试中文、emoji 和代码混合文本。
排错路径：记录四个时间点和三份样本
每次复现记录请求发出、收到首字节、收到最后一段、界面完成渲染四个时间点。再保留上游原始响应、CCSwitch 转发响应和客户端解析后的事件三份样本。若第一份正常、第二份异常，看代理和 profile；若第二份正常、第三份异常，看客户端解析；若第一份就异常，回到接口协议和模型配置。
还要排查环境混用：测试 profile 是否使用了正式 Key，桌面端和 CLI 是否读取同一个配置文件，是否有旧进程缓存模型名。可以给每个 profile 增加显式名称和启动时日志，打印地址、模型、stream 模式和配置版本，但不要打印 Key。修复后重复五条固定样本，确认没有引入非流式回归。
如果问题只在公司网络、代理软件或某台电脑出现，还要加入网络层对照。可以用同一账号在另一台机器测试，也可以临时绕过中间代理，只保留 CCSwitch 到上游的最短链路。不要一边换模型、一边换网络、一边升级客户端；一次只改一个变量，才能判断是哪一层修复了问题。
验收时建议把成功样本保存成 profile 说明的一部分。以后团队成员修改模型名、接口地址或超时参数时，先跑这组样本，再决定是否发布配置。这样流式输出问题不会每次都从用户反馈开始排查。
检查清单
是否保存了 profile 配置快照；是否对照测试 stream true 和 false；是否检查响应头、事件字段和结束标记；是否排除了代理缓冲、压缩和证书问题；是否确认客户端不会重复渲染；是否记录四个时间点；是否使用脱敏日志；是否用固定样本做切换验收；是否保留失败原始样本。完成后，CCSwitch 才能作为稳定的 AI 模型接口管理层服务于 Codex 和自动化办公。