Gemini API 写作模型停用前怎么迁移

准备

先建立一份迁移清单，列出每个写作任务当前使用的模型 ID、调用位置、提示词版本、生成参数、输出格式、日均请求量和负责人。官方更新记录会公布部分模型的弃用或关闭信息，也可能明确替代模型；应以对应模型的官方生命周期与更新说明为准，不要只根据模型名称猜测替代关系。

• 保存一组真实且已审核的样本，至少覆盖文章、FAQ 和营销文案中的实际任务类型。
• 为每条样本保留输入材料、系统规则、模型 ID、参数、原始输出、人工修改稿和生成时间。
• 明确验收标准，例如字段是否完整、事实是否越界、语气是否符合品牌、编辑修改量是否可接受。
• 给旧模型设置停止新任务的时间点，并在停用日前预留测试和回退时间。

分步操作

1. 核对停用范围。在官方发布说明中确认受影响的准确模型 ID、弃用状态和关闭日期。不要把同一系列的其他模型自动视为一起停用。
2. 确定候选模型。优先从官方针对该停用模型给出的替代建议中选择候选项。候选模型是否适合写作，还需要用自己的任务验证。
3. 冻结对照样本。从近期已发布或已通过审核的内容中挑选样本，冻结输入、提示词和参数。测试期间不要一边改提示词一边换模型，否则无法判断差异来自哪里。
4. 双跑并记录结果。对同一输入分别调用旧模型和候选模型，保存请求配置、输出、耗时、失败状态和人工评分。回归对比的具体做法可参考Gemini API 模型更新后写作结果怎么做回归测试。
5. 先迁移低风险队列。先切换可人工复核、可延迟发布的少量任务，例如内部草稿或小比例 FAQ。确认稳定后，再按任务类型逐批扩大范围。
6. 保留可回退开关。将模型 ID 配置化，让任务可按队列或百分比选择旧模型、候选模型。旧模型仍可用时，异常任务可以临时切回；模型已关闭后，则应改为暂停任务并进入人工处理。
7. 完成全量切换与归档。所有队列通过验收后，更新默认模型配置，并归档旧模型的调用记录、对照结果和迁移结论，方便下一次模型生命周期变更复用。

可复制迁移模板

迁移任务名称：产品 FAQ 批量生成
当前模型 ID：{old_model_id}
候选模型 ID：{new_model_id}
计划停用日期：{shutdown_date}

固定输入：
- 提示词版本：{prompt_version}
- 输入样本编号：{sample_id}
- 生成参数：{generation_config}
- 输出格式：{expected_format}

对比记录：
- 格式完整：通过 / 不通过
- 事实范围：通过 / 不通过
- 品牌语气：通过 / 不通过
- 编辑修改量：低 / 中 / 高
- 调用失败或异常：无 / 有，说明：{issue}

迁移决定：继续灰度 / 修正后复测 / 暂停迁移
负责人：{owner}
复核日期：{review_date}

例如，FAQ 任务应重点检查答案是否只回应问题、是否加入材料外承诺、JSON 或表格字段是否仍能被下游程序读取。营销文案则应额外检查禁用词、品牌口吻和长度限制。

翻车怎么改

常见故障：切换后生成结果仍有正文，但下游批处理报字段缺失。

原因：新模型对输出格式的遵循方式不同，或团队只比较了文字质量，没有验证机器读取所需的字段、类型和空值规则。

修正动作：将输出结构要求写入固定提示词，并在应用侧对返回内容做字段校验。先让失败样本在小批量队列中重跑；未通过校验的内容进入人工复核，不要直接发布。确认结构稳定后，再扩大迁移比例。

常见故障：新模型的内容更长，编辑时间反而增加。

原因：旧模型的长度表现不能自动继承到候选模型，原有提示词缺少明确的篇幅和交付边界。

修正动作：固定输出字段和字数范围，使用同一批样本重新测试；把“是否减少编辑量”列为迁移门槛，而不是只看单次生成是否通顺。

完成前检查

• 已核对受影响模型 ID、弃用状态和关闭日期，且记录了官方来源。
• 每类写作任务都有冻结样本，并保存旧模型与候选模型的完整对照记录。
• 候选模型已通过格式、事实边界、语气和人工编辑量验收。
• 低风险灰度任务运行正常，异常内容不会自动发布。
• 模型 ID 已从代码中抽离为配置，默认值、灰度范围和暂停策略均已更新。
• 发布前验收项：随机抽取本次迁移后的内容，确认下游字段可读取、正文无缺段且人工审核状态正确。