Gemini API 长文写作怎么使用上下文缓存

准备

上下文缓存适合“同一批稳定资料会被多次使用”的场景，例如一份产品手册要生成多个章节、同一知识库要回答多组问题。不要把每次都不同的草稿、临时反馈和无关聊天记录一并放入缓存。

• 准备稳定资料：产品事实、术语表、禁用表述、引用规则。
• 为资料设定版本号，例如 knowledge-v3，并记录来源与更新时间。
• 将写作任务拆成章节或文章单元，每次只传入本次主题、受众、篇幅和输出要求。
• 确认当前使用的模型仍可调用；模型生命周期变化时，先按Gemini API 模型更新后写作结果怎么做回归测试保留样本再迁移。

分步操作

1. 先清洗资料。删除重复段落、过期说明和无法核对的推测，把事实、限制条件与写作规则分区保存。
2. 创建缓存时，只放入可长期复用的资料与固定规则，并在自己的任务表中保存缓存标识、资料版本、创建时间和对应模型。
3. 生成每个章节时，引用缓存，再单独提交本次任务。例如第一章只要求介绍问题背景，第二章只要求给出操作步骤，避免一次要求输出整篇长文。
4. 保存每次请求的任务编号、缓存标识、输入要求和生成结果。资料更新后创建新缓存，不要把新旧资料混用。
5. 合并章节前，统一检查标题层级、术语、事实范围和重复内容；发现冲突时回到资料版本修正，不要只让模型自行猜测。

可复制模板或示例

下面是可放入应用配置中的任务模板。方括号内容由程序替换；缓存创建和引用的具体字段请以当前 Gemini API 文档与所用 SDK 为准。

稳定资料版本：[knowledge-v3]
缓存内容：
- 已确认产品资料
- 术语表
- 禁止编造规则
- 固定写作风格要求

本次任务：
请基于已引用的稳定资料，撰写“[章节主题]”。
读者：[目标读者]
目标：[本章要解决的问题]
只使用资料中能确认的信息；资料未说明时写“资料未提供”。
输出结构：
1. 小标题
2. 操作说明
3. 示例
4. 检查项
篇幅：[字数范围]

例如，产品资料不变而要生成五篇 FAQ 时，缓存中保留产品资料和回答边界；每次请求只替换一个问题、适用人群和答案格式。这样更容易定位某条内容究竟使用了哪一版资料。

翻车怎么改

常见故障：更新产品资料后，生成内容仍出现旧价格或旧功能。

原因：应用仍在引用旧缓存，或任务记录没有区分资料版本与缓存标识。

修正动作：停止将新任务发送到旧缓存；用更新后的资料创建新缓存，将新缓存标识绑定到新版本任务。随后抽查至少一个旧章节和一个新章节，确认它们引用的资料版本正确。

常见故障：每篇内容都带入前一篇的结论，导致章节重复或跑题。

原因：缓存中混入了临时草稿和单次任务指令。

修正动作：把缓存缩减为稳定事实与固定规则；将章节目标、读者、格式和本次修改意见移回单次请求。

完成前检查

• 发布前验收：抽查正文中的关键事实是否能在当前资料版本中找到依据。
• 确认每条生成记录都保存了模型、缓存标识、资料版本和任务输入。
• 确认缓存中没有临时草稿、用户隐私信息或已废弃资料。
• 确认章节之间没有互相矛盾的术语、功能描述或时间状态。
• 确认资料更新时已创建新版本流程，而不是覆盖旧记录。

官方更新记录显示，Gemini API 曾推出上下文缓存，并在后续为 Gemini 2.0 Flash 增加相关支持。实际可用模型、接口字段与限制可能变化，因此上线前应以当前官方文档和控制台信息为准。