已经在 K2.8 Preview 上跑通主流程只能说明这条链路能出结果不能说明它能直接对外。预览形态的模型标识、默认参数和输出风格都可能调整建议把上线前的工作收成四件事摸清所有调用点、拿三个真实场景做回归、留一组旧模型基线、写死回退触发条件与切换入口。这四件事做完即便上线后模型侧有变化你也能判断是模型变了还是自己的业务代码变了。适用场景内部已用 K2.8 Preview 跑通流程、但尚未对外提供服务。操作动作按客户端、脚本、内部工具列出调用点挑三个直接影响用户的场景做回归同时保存旧模型输出作为基线确认客户端或控制台里的模型切换位置。验证方式用同一份输入样本分别跑 Preview 与旧模型逐字段比对输出形态。风险边界回归通过只代表这三条路径在当前配置下可用不代表所有输入都安全参数、提示词或模型标识变动后需要重跑。列出现在依赖 K2.8 Preview 的调用点先按「谁在调用」把调用点列全客户端、脚本、内部工具三类。每个点写清用途、调用位置、影响人群。不必追求格式好看一份能被搜索到的纯文本清单就够用关键是每一条都能定位到文件或配置路径。# 调用点清单骨架示例字段按实际情况替换 # name 用能直接搜到的字符串location 写文件/配置路径owner 写能叫得动的人 [客户端] - chat-main 用途用户提问走 Preview 生成回答 影响人群外部用户 - summary-btn 用途长文提炼摘要 影响人群外部用户 [脚本] - batch-preclean 用途夜间批量内容预处理 影响人群内容运营 [内部工具] - ticket-classify 用途客服后台工单分类 影响人群内部客服 - eval-runner 用途离线评测跑分 影响人群研发本人列完之后再做一次分档面向外部用户的调用点全部进回归范围只在内部使用、失败也不影响用户可见内容的可以先放一档。这个分档直接决定下一步三个场景从哪里挑。挑出三个直接影响用户的场景做回归三个场景优先覆盖风险最高的路径通常是对外问答主链路、结构化输出被程序解析、边界输入这三类。每个场景都要写清输入样本、期望输出形态和判定标准否则回归做完也说不清算不算通过。场景一对外问答主链路。输入样本从真实用户问题里抽覆盖短问句、带错别字或口语化的问句、需要追问才说得清的问题。期望输出是完整自然语言回答不出现空回复、截断、模型自我说明。判定标准每条样本都有回答且没有明显答非所问。场景二结构化输出被下游解析。输入样本取真实请求要求返回固定字段的结构化结果。期望输出字段齐全、类型稳定、能被程序直接解析。判定标准解析不抛异常必填字段不缺失枚举值不越界。场景三边界输入。覆盖超长输入、空输入、纯符号或重复字符。期望是超长给出截断或明确提示空输入返回可理解的提示而不是崩溃任何情况下都不把内部错误信息吐给用户。判定标准不报未捕获异常用户侧看到的是可读文案。# 输出形态校验放在回归脚本里不要塞进业务代码 # 字段名按你们实际的返回结构替换 def check_shape(resp): assert resp.get(text), 空输出 assert resp.get(finish_reason) ! error return True留一组旧模型的输出作为基线保存旧模型输出不是为了证明谁更好而是出现差异时能判断是谁变了。保存方式建议以文本存档为主同一份输入把旧模型输出和 Preview 输出按样本 ID 存成成对文件截图只能当补充因为截图没法做 diff也难以长期检索。baseline/ 001_short_question.input.txt 001_short_question.old.output.txt 001_short_question.preview.output.txt diff_log.csv 字段 sample_id, input_digest, old_out, preview_out, diff_type, acceptable, owner比对方法是先看格式再看语义格式差异结构化字段缺失、Markdown 结构变化优先处理因为下游代码会直接报错语义差异需要人工判断可以标注为暂时接受并转入遗留问题。差异记录字段至少包含样本 ID、差异类型、是否可接受、处理人缺一个后面就会变成「这条当时是谁看的」。写清回退触发条件与切换入口回退条件要提前落成文字别等出事再临时商量。触发阈值结合你们自己的监控基线定下面是几类可观察的示例。触发条件任一满足即考虑回退 - 输出格式崩结构化解析连续出现失败 - 拒答异常原本应当正常回答的样本出现拒答或空回复 - 延迟明显升高P95 相对旧模型基线出现明显抬升以你们自己的基线为准 - 错误集中同类超时或 5xx 在短时间内聚集出现切换入口通常有两处服务端或客户端的模型配置项以及控制台或网关侧的模型路由设置。上线前把这两处的路径写进值班文档并确认改动后多久生效、是否需要重启进程。# 配置骨架字段名按你们实际的来不要照抄 model: name: k2.8-preview fallback: enabled: true model: 旧模型标识 # 按实际可用的模型标识替换 switch: manual # 先手工切换确认回退路径真的可用回退动作建议手工演练一次把模型标识改回旧值跑一遍上面三个场景的样本确认输出形态恢复。只写文档不演练真出问题时容易卡在找不到入口这一步。记录本次回归的模型标识与时间点这份记录的作用是让一个月后的自己能对得上号。模型标识要抄全预览形态的标识可能带后缀只写简称在后续对比时容易对不上。# 回归记录 模型标识k2.8-preview写完整标识不要只写 K2.8 调用方式接口名或控制台入口 回归日期YYYY-MM-DD 参与人发起人 / 验证人 样本来源三个场景各若干条样本 ID 见 baseline/ 结论通过 / 有条件通过 / 不通过写明哪几条没过 遗留问题场景三超长输入表现待观察格式校验脚本尚未接入 CI 回退入口服务端配置路径 控制台路径记录建议跟着代码仓库走不要只留在聊天记录里。后续 K2.8 迭代或调整参数时先翻这份记录确认当时的模型标识和结论再决定是重跑全部三个场景还是只重跑出现差异的那一条。