Gemini API 模型更新后写作结果怎么做回归测试

准备

先建立一份不会频繁变化的回归样本集，建议覆盖标题生成、文章提纲、资料改写和摘要等实际任务。每条样本都保存原始输入、资料、旧模型名称、请求参数、输出结果和测试日期。

Google Gemini API 的更新记录会出现模型进入 GA、预览版本停用、模型别名切换以及请求或响应结构变化等情况。因此测试时要把模型 ID 和接口版本明确记录，不能只写“Gemini 最新版”。

• 准备 10 至 30 条具有代表性的写作输入，包含简单、正常和边界案例。
• 固定系统指令、用户提示、资料内容、输出格式和安全设置。
• 记录旧模型与新模型的完整模型 ID，不要使用无法追溯的“latest”作为唯一记录。
• 确定验收指标：格式通过率、事实错误数、结构完整度、人工修改时间和单条成本。

如果程序还会解析模型返回结果，可将格式检查放到人工评审之前。

分步操作

1. 锁定基线。用当前线上模型重新执行样本，保存原始响应和清洗后的文章。对随机性敏感的任务，固定请求参数；如果参数已因版本更新而变化，必须在记录中注明。
2. 建立迁移分支。只替换模型 ID 或确实需要迁移的接口字段，暂时不要同时修改提示词、资料切片、后处理代码和发布规则。
3. 批量执行同一批输入。新旧模型使用完全相同的样本和任务说明。每条结果至少记录样本编号、模型 ID、请求时间、响应状态、输出文本和错误信息。
4. 先做程序检查。检查是否成功返回、必需字段是否存在、标题和正文是否为空、HTML 或 JSON 是否可解析、列表层级是否完整，以及是否出现额外解释。
5. 再做内容对比。逐项检查关键事实、数字、条件、时间、禁用表述、标题相关性和提纲覆盖范围。不要因为新文本更流畅，就忽略事实边界变化。
6. 统计差异并分级。把差异分为阻断问题、需要人工修改的问题和可接受的表达变化。阻断问题包括格式无法解析、事实新增、任务跑题和关键要求遗漏。
7. 做小流量复测。只有在离线样本通过后，才用少量真实任务验证耗时、失败率、编辑时间和发布流程是否正常。保留旧模型作为回退方案。

可复制模板或示例

可以用下面的测试记录模板保存每次结果：

样本编号：title-001
任务类型：生成文章标题
输入资料：同一份产品资料
系统指令版本：writing-v3
用户提示版本：title-v2
旧模型：线上固定模型 ID
新模型：待验证模型 ID
固定参数：按实际请求完整记录
检查项目：格式、事实、相关性、长度、修改时间
结果：通过 / 人工修改 / 阻断
差异说明：
结论：迁移 / 继续观察 / 暂不迁移

例如，标题任务可以固定要求“输出 5 个标题，每行一个，不添加序号和解释”。比较时统计五个标题是否都满足数量、长度、主题和禁用词要求，而不是只挑一个看起来最好的标题。

对于提纲任务，可以把验收表写成：是否包含指定章节、是否覆盖全部资料要点、是否把未知信息写成确定事实、是否混入资料外结论。对于改稿任务，则额外检查原文中的数字、专有名词、条件和语气是否被保留。

翻车怎么改

常见故障：新模型输出内容看起来更完整，却加入了资料中没有的结论。原因通常是模型迁移后表达倾向发生变化，或者提示词只强调“写得完整”，没有明确事实边界。修正时，在系统指令中加入“仅使用输入资料；资料没有说明时标记为未知，不补充推测”，并增加至少两条资料缺失样本，重新执行回归测试。

常见故障：程序突然解析失败。原因可能是响应字段、输出格式配置或接口结构发生变化。修正动作是先保存完整原始响应，再对照当前接口文档确认字段变化；随后在解析器中增加明确的字段校验和错误日志，不要用静默兜底把异常结果送进发布流程。

常见故障：同一提示词每次结果差异很大。原因可能是请求参数没有固定，或模型版本使用了不稳定的别名。修正动作是记录完整请求配置，使用明确模型 ID 做重复运行，并把“重复运行差异”纳入测试指标。

完成前检查

• 发布前确认每条样本都保存了旧模型、新模型、输入、参数和完整输出。
• 确认新模型的标题、提纲和改稿结果均通过格式校验。
• 确认关键数字、时间、条件、专有名词和资料边界没有新增错误。
• 确认阻断问题已清零，并记录人工修改成本是否可接受。
• 确认线上配置已固定模型 ID，且保留可执行的旧模型回退方案。