Gemini API缓存机制深度解析：缓存设置为系统提示词是不是更好？目录Gemini API缓存机制深度解析：缓存设置为系统提示词是不是更好？一、这里**没有用** Gemini 原生的"系统提示词"无缓存路径（`cache-off`）：整段拼成一条 user 消息缓存创建时：也是 user role缓存调用时：只发GD对话二、"系统 / 用户提示词" 的概念在这里是**功能性划分**，不是 API 层三、GD内容是"用户提示词"吗？—— 是"追加的第二段 user 内容"请求真实拼接顺序图解一下四、显式缓存机制的完整流程五、如果换用 `system_instruction` 会不会更好？一、这里没有用Gemini 原生的"系统提示词"Gemini API 本身有两个概念：system_instruction—— 真正意义的系统提示词，独立字段contents—— 对话消息数组，每条有role(user/model)但这个脚本从头到尾都没用system_instruction，一切都塞进了contents的 user 消息里。看代码就明白：无缓存路径（cache-off）：整段拼成一条 user 消息config = types.GenerateContentConfig(temperature=0.0, top_p=0.95, top_k=4) contents = f"{prompt_template}\n\n【GD对话数据】：{dialog_data}"contents
