跑通 K2.8 Preview 之后 / 上线前拿三个真实场景做回归

已经在 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 迭代或调整参数时，先翻这份记录确认当时的模型标识和结论，再决定是重跑全部三个场景，还是只重跑出现差异的那一条。