值班记录：同一提示词连跑三次，先记差异再改参数

交班前，同一条提示词连续运行三次，得到三个不同答案。先别急着判断模型不稳定，也别直接挑最顺眼的一份。值班台需要留下的是一条可复查的证据链：输入是否相同、参数是否变化、差异是否影响业务。下面按实际操作顺序走一遍。

先把这次告警摘要变成固定试题

• 第一步，准备一条边界清楚的提示词。例如：“根据以下记录生成交班摘要：支付接口在十点零二分出现超时，十点零八分恢复；原因尚未确认。请分别写出现象、已知事实、待核查事项，不得推断根因。”三次运行都使用完全相同的文字，不补充解释，也不延续上一轮对话。
• 第二步，固定请求条件。记录模型标识、系统提示词、温度、输出长度上限，以及工具、检索和历史消息是否启用。可以选用 Gemini 2.5 Flash 进行这轮练习，但不要在三次运行之间换模型。界面上看起来相同的提问，不代表底层请求一定相同。
• 第三步，独立发送三次请求，分别保存原始响应、时间和可用的请求标识。不要只保存整理后的摘要，否则会丢掉遗漏、截断或格式偏移等线索。如果使用脚本，先确认它没有在失败后自动更换模型或悄悄补发请求；三次尝试可能并不等于三次成功输出。

把三个答案拆成措辞变化和事实变化

• 第四步，逐项核对答案，而不是凭整体观感评分。以下只是示意，不是实测结果：第一份写“接口超时后恢复”，第二份按时间排序，第三份增加“可能由数据库拥塞引起”。前两份可能只是表达不同；第三份则加入了记录中没有的根因猜测，应标记为事实风险，而不是更详细的答案。
• 第五步，使用同一张检查清单验收。三份答案是否都保留了两个时间点，是否明确原因未确认，是否包含要求的三个部分，是否出现无依据的处置建议？三次都通过，只能说明这三个样本满足当前规则，不能据此推导长期可靠性。三份答案一致，也不代表事实一定正确。

一次只动一个采样旋钮

模型生成文本时，通常会从下一步的候选词元中选择输出。温度会影响选择分布，因此相同输入可能产生不同措辞，甚至走向不同推理路径。它不是“正确率旋钮”，降低温度也不会自动修复缺失证据。

• 第六步，如果目标是交班摘要，可以在接口支持的范围内降低温度，再用原来的试题运行三次；其余条件保持不变。不要同时修改温度、提示词和模型，否则难以判断哪项改动产生了影响。即便温度设为零，也不应承诺每次输出完全一致；若接口提供随机种子，还要核实具体模型是否支持，以及它的复现限制。

对于这道题，比单纯降温更直接的改进，是把边界写进要求：缺失的信息必须写“未确认”，每个结论都要能对应输入记录。需要严格字段时，可以采用接口支持的结构化输出，并在应用侧校验字段与内容。格式合规和事实可靠仍是两件事。

把复跑记录交给下一班

• 第七步，把提示词版本、实际模型、参数、三份原始答案、检查结果和下一步动作放进同一条值班记录。再次修改提示词后，重新跑完整组样本，不要只保留改好后最漂亮的一份。涉及真实告警时，先脱敏；每轮也应设置输出上限和试验预算，避免排查过程变成无边界调用。

如果值班台已经使用开放人工智能软件开发工具包，并需要通过统一接入点试验不同模型，Relay365 的按量付费中转服务可以作为接入选择。接入前应核实所选模型的参数支持、计费方式和数据处理要求，不要假定统一接口意味着所有行为一致。需要实际复跑时，可以创建一个 Relay365 账户，从这组三次请求开始。

交班结论应写成“本轮三份答案中出现一份无依据推断，已收紧提示词并安排复测”，而不是“模型偶尔发疯”。前者能指导下一班继续排查，后者只留下情绪。