值班交接：同一条告警问了三遍，先别急着改提示词

交接现场：三份回答不等于三次故障

假设值班台收到一条告警：接口延迟升高，错误率暂时没有明显变化。你把监控摘要交给模型，请它列出优先检查项。第一遍建议查看下游依赖，第二遍先查连接池，第三遍则提醒核对最近的发布记录。同一条提示词，为什么没有得到同一张检查清单？

先不要认定提示词失效，也不要直接挑最长的那份。模型生成文字时，通常不是从抽屉里取出一份固定答案，而是在多个可能的后续内容之间逐步选择。采样就是这种选择过程中的一部分。它能让表达更灵活，也会让同一个问题出现不同回答。

生成下一小段文字时，会有不止一个候选

可以把生成过程想成写交接记录。写到“建议先检查”时，后面既可能接“数据库”，也可能接“下游接口”。模型根据已有内容，为可能接上的文字分配不同的概率，再按照生成设置继续往下写。

实际处理的单位不一定是完整的汉字或词语，也可能是更小的文字片段。你不必先理解这些片段怎样切分，只要记住：回答通常是一步步生成的。前面一步换了方向，后面的说明、排序和结论也可能随之变化。

因此，三次回答不只是把同一份答案换几个近义词。它们可能沿着不同的生成路径展开。不同路径都有可能说得通，但“说得通”不代表已经得到监控数据的证实。

温度调低，是收紧选择，不是锁定真相

温度是常见的采样设置。通俗地说，温度较低时，选择通常更集中在概率较高的候选上；温度较高时，其他候选更容易获得机会。值班摘要需要稳定措辞，通常更适合从较低温度开始测试；需要探索排查方向时，则可以容许更多变化。

另一个常见设置叫核采样。它按累计概率圈定一组候选，再从中选择。它和温度影响选择的方式不同。新手没有必要同时调整所有设置，否则回答变了，也很难判断是哪一次改动产生了影响。

这些设置控制的是生成方式，不是事实正确率。低温度下，模型仍可能稳定地给出错误判断。也不要把温度设为零理解成跨环境、跨时间必定逐字复现的承诺。可重复性需要测试，不能只凭一个参数认定。

值班台先分清措辞变化和判断漂移

检查三份回答时，先看变化发生在哪一层。“先查依赖”与“优先检查下游服务”可能只是表达差异；把排查顺序调换，可能影响操作效率；一份建议继续观察，另一份却要求立即回滚，则已经涉及决策变化。

• 如果只是措辞不同，就检查关键事实、限制条件和行动建议是否一致。
• 如果检查顺序不同，就要求每项建议说明依据，并标出哪些证据仍然缺失。
• 如果处置结论冲突，就回到监控、日志和变更记录，不要用三次回答的多数票替代核实。

重复运行适合暴露不稳定之处，却不是独立证据。三份回答都推荐回滚，也不能证明故障一定由最新发布引起。

交接记录要固定的不只是提示词

重新测试前，确认三次请求真的拿到了相同材料。聊天历史、系统要求、检索结果和工具返回内容，都可能影响答案。表面上复制了同一句问题，并不代表模型看到的全部上下文一致。

值班记录至少应保留模型名称、请求时间、完整输入、采样设置和原始输出。如果接口支持种子，也可以一并记录，但不要把它当作通用的复现保证。测试时一次只改一个条件，才能知道差异从哪里来。

对告警分诊这类任务，还可以把要求写得更明确：“先摘录已知事实，再列待验证假设，最后给出检查步骤；证据不足时不要直接建议回滚。”固定输出结构能够方便检查，但结构整齐仍不等于内容可靠。

交班前，把接入便利和结果验收分开

如果团队需要在不同模型之间重复同一组测试，Relay365 这类按量付费的多模型中转服务可以减少接入切换工作。它可配合 Claude Code、Codex、Gemini CLI 和 OpenAI SDK 使用，适合把测试入口集中起来。不过，统一入口不会让不同模型拥有完全相同的参数含义或输出行为，仍需逐项验证。

如果这符合你的工作方式，可以创建一个 Relay365 账户，从一条不含敏感信息的测试告警开始。先保持输入和设置不变，连续运行三次，把差异记进交接表，而不是急着接入自动处置。

这班留下的结论很简单：允许解释有不同写法，但不能放任关键事实和高风险行动随意变化。采样可以帮助寻找排查方向，真正决定是否执行的，仍应是证据、操作规则和人工确认。