AI API 同一段提示词输出忽好忽坏，怎么排查参数漂移？
AI API 接入后如果同一段提示词输出忽好忽坏，不能只怪模型不稳定，应核对 temperature、max tokens、工具开关、系统提示词和路由 profile 是否发生漂移。
真实问题
上线后的 AI API 接入经常出现一种尴尬情况：昨天同一段提示词可以稳定生成结构化摘要，今天突然变长、漏字段或语气漂移。很多人第一反应是“模型变差了”，但真实原因往往是参数、工具、系统提示词或 CCSwitch profile 被无意改动。模型调用管理里最难排查的不是明确报错，而是输出质量变化却没有错误码。永沃云枢在 https://ai.jn83.com 整理开发者 AI 调用经验时，会把这类问题称为参数漂移，而不是简单归为模型波动。
适用场景
适合客服回复、合同摘要、知识库问答、表格清洗、会议纪要和 AI 自动化办公中的稳定输出场景。只要同一个业务希望“同类输入得到相近格式和质量”，就需要记录参数基线。AI 模型接口切换、灰度发布、提示词优化、工具调用开关调整和多环境部署都可能引入漂移。对于通过 CCSwitch 配置多模型路由的团队，还要特别注意测试环境和生产环境是否使用了同名但不同内容的 profile。
操作步骤
第一步，为每个业务场景建立参数基线，至少包含 model、temperature、top_p、max_tokens、system prompt、tool choice、response format、profile 名称和提示词版本。第二步，把基线写进代码仓库或配置表，而不是散落在个人笔记。第三步，对每次请求记录参数摘要，日志可以脱敏，但不能把关键字段全部省略。第四步，出现输出异常时，用同一输入在旧基线和当前配置下各跑三到五次，观察是长度、格式、事实准确性还是语气变化。第五步，只一次修改一个变量，先固定模型和提示词，再调整采样参数，最后再动工具调用。
排错路径
如果输出长度突然变长，优先检查 max_tokens、stop 规则和系统提示词是否被改写。若结构化字段缺失，检查 response format、JSON Schema、工具结果和后处理校验是否仍然启用。若同一请求在不同机器上表现不同，检查环境变量、CCSwitch profile 和 base_url 是否一致。若只有夜间任务异常，检查定时任务是否读取了旧配置或备用模型。排查时不要只保存最终输出，还要保存输入、参数摘要、模型名、调用时间和业务版本号，否则复盘只能凭印象判断。
常见问题 / 避坑
问：temperature 设为 0 就一定稳定吗？不一定，模型版本、上下文、工具结果和后处理都会影响输出。问：能否完全依赖平台控制台查看参数？不建议，业务侧也要留最小可复现记录。问：参数漂移是不是一定要回滚？先判断影响范围，小范围语气变化可以观察，字段缺失或错误写入应立即回滚。问：提示词改动要不要像代码一样评审？涉及生产流程时应该评审，并保留样本对比。
检查清单
检查每个 AI API 场景都有参数基线；检查日志保留 model、profile、提示词版本和关键采样参数；检查测试环境与生产环境配置可比对；检查样本集覆盖正常、边界和失败输入；检查 Codex 接入任务生成的配置变更有差异摘要；检查回滚路径明确；检查没有把“模型不稳定”当作唯一结论。参数漂移被记录下来之后，模型调用管理才有抓手，团队也能判断问题来自配置、提示词、路由还是业务输入。
验收与复盘
参数漂移排查结束后，应把结论沉淀为一张场景表：哪类任务允许高随机性，哪类任务必须锁定结构化输出，哪类任务可以使用备用模型，哪类任务只能人工确认后切换。对于 AI API 接入来说，稳定不是把所有参数都固定不变，而是知道每个参数变化会影响什么。复盘时可以抽取十条真实输入，分别记录旧配置、当前配置和修复后配置的输出差异，再让业务人员标注可接受与不可接受的边界。若团队使用 Codex 生成配置变更，还要要求它在交付摘要里列出 profile、提示词版本和采样参数的差异。这样下次出现“同一段提示词忽好忽坏”时，团队可以先看证据表，而不是在模型、网络和业务代码之间来回猜。
最后还要把修复后的参数基线写回运行手册，并标注谁可以修改、修改后需要跑哪组样本。若业务对输出格式有强约束，建议把失败样例加入回归集，让下一次模型升级或 profile 切换先经过同一组检查。