请求日志应记录什么，才能分清观察与推测？

整理 AI 工具或写作 API 的请求日志时，要把系统实际记录到的现象与对原因的判断分开。否则，排查人员可能把一次超时直接写成“请求失败”，再重复提交，造成重复处理或入库。 先记录可核对的信息：任务编号、发起时间、使用的功能或接口、请求是否发出、收到的状态或错误信息，以及是否取得响应。若需记录请求内容，只保存必要字段或脱敏后的摘要。密钥和令牌等凭据不能写进

整理 AI 工具或写作 API 的请求日志时，要把系统实际记录到的现象与对原因的判断分开。否则，排查人员可能把一次超时直接写成“请求失败”，再重复提交，造成重复处理或入库。

先记录可核对的信息：任务编号、发起时间、使用的功能或接口、请求是否发出、收到的状态或错误信息，以及是否取得响应。若需记录请求内容，只保存必要字段或脱敏后的摘要。密钥和令牌等凭据不能写进日志，只应保存在服务端或受保护的本机配置中。

还要记录请求与结果的对应关系。任务编号可帮助自有系统识别同一任务，内容摘要可辅助判断两条记录是否涉及相同内容。但摘要不能证明任务完全相同，也不能代替对实际结果的检查；核对时还应查看时间和已有响应。

观察与推测最好分栏或明确标注。例如，“等待响应超过设定时间”是观察；“服务端没有处理请求”则是推测。超时不能证明请求未处理，也不能证明没有计费。遇到超时，先检查已有结果和本地任务状态，再决定是否重试；如果能查询服务端记录，也应以可核实的信息为依据。

日志应服务于排查，不必收集所有内容。只保留判断故障所需的信息，并留意请求文本可能包含个人或业务敏感内容。不同工具和接口提供的状态信息可能不同；若没有可查询的服务端结果，就注明无法确认，不要把模型输出或日志中的猜测当作事实。