Gemini API 模型别名变更前的写作回归检查

先划定本次检查范围

把别名视为可变化的入口，不要把它当成永久固定版本。发布说明曾记录过 latest 别名切换，例如 gemini-flash-latest 在 2026 年 5 月指向 gemini-3.5-flash；因此每次例行检查都应记录查询日期和来源。

• 确定涉及的写作任务，如标题生成、提纲、正文、改写和结构化字段。
• 冻结本次使用的提示词模板、资料输入、应用侧解析逻辑和人工评分规则。
• 指定旧配置为回退对象，并明确谁有权执行切换。

建立别名登记表

在共享表或版本库中新增一行记录，不要只在聊天消息里确认。

若当前资料未能确认某个别名的实际指向，应标为“待核实”，不能据此推断模型能力。

准备固定写作样本集

样本要覆盖真实风险，而不是只用一句简单提示。建议保留 5 至 10 个可脱敏任务，并给每项分配稳定编号。

1. 选取一篇资料完整的长文任务，检查结构和遗漏。
2. 选取一篇资料存在未知项的任务，检查是否把猜测写成事实。
3. 选取需要输出标题、描述、关键词和正文的任务，检查字段完整性。
4. 选取一次改写任务，检查原意、限制条件和专有名词是否保留。
5. 保存每项的输入摘要、预期边界和人工评分说明。

固定样本的任务设计可参考模型更新后的写作回归测试方法，但本次重点是识别别名指向变化带来的影响。

生成两组可对照结果

先用当前生产配置运行样本并保存结果，再在候选版本或确认后的新指向上运行完全相同的输入。两组请求应使用相同的资料、规则和应用处理链路；不要一边换模型一边改提示词，否则无法归因。

按事实、结构和字段记录差异

差异记录要写可复查的现象与影响，不要只写“感觉变差”。例如：“样本 W03 的关键词数组缺失，导致发布校验失败”；或“样本 W05 新增了资料未提供的日期，需拒绝上线”。

• 事实：关键名称、数字、时间和限定条件是否仍能由输入资料支持。
• 结构：标题层级、段落顺序、列表和结论是否符合任务要求。
• 字段：必填字段是否存在，类型是否正确，空值和多余内容是否影响解析。
• 编辑成本：人工修正次数、拒绝原因和无法自动修复的问题。

处理常见故障

发布前验收与回退条件

只有固定样本、失败样本和业务侧处理均完成检查后，才允许逐步启用新配置。

• 别名登记表已写明核对日期、当前指向和回退对象。
• 每个固定样本都有旧结果、候选结果和差异结论。
• 事实错误、字段缺失和解析失败均为零，或已有明确的人工拦截措施。
• 上线阈值、观察周期、负责人和回退触发条件已经确认。
• 回退配置已在非生产环境验证可用，切换记录可追溯。

上线后继续抽检首批任务；一旦出现阻断项，立即停止扩大范围，恢复回退配置，并将异常样本加入下一轮测试集。