请求日志记录哪些信息，哪些结论不能由此推出

整理 AI 工具或写作 API 的请求日志，重点不是尽量多存，而是留下定位问题所需的信息，同时避免泄露敏感内容。先明确记录用途：排查失败、核对任务状态，还是追踪内容入库。用途不同，所需字段也不同，不必默认保存完整请求和回复。 基础记录可包括任务编号、发起时间、调用环节、目标服务或模型标识、请求状态，以及错误信息或响应状态。如果系统记录了耗时，也可用来判断请

整理 AI 工具或写作 API 的请求日志，重点不是尽量多存，而是留下定位问题所需的信息，同时避免泄露敏感内容。先明确记录用途：排查失败、核对任务状态，还是追踪内容入库。用途不同，所需字段也不同，不必默认保存完整请求和回复。

基础记录可包括任务编号、发起时间、调用环节、目标服务或模型标识、请求状态，以及错误信息或响应状态。如果系统记录了耗时，也可用来判断请求是否迟迟未返回。具体字段取决于自建程序和接口实际提供的内容；某个网站或栏目里的任务字段，并不是通用 API 参数。

排查内容问题时，可保存必要的输入或输出摘要，也可在受控条件下保存完整内容。摘要有助于识别任务，但不能代替原文核对。涉及用户隐私或敏感材料时，应减少留存范围并限制日志访问。密钥只保存在服务端或受保护的本机配置中，不要写入网页、正文或日志，避免日志变成另一份缺乏保护的内容仓库。

发生错误后，先用任务编号查找已有记录和结果，再判断是否需要重试。超时只表示在等待期限内没有得到预期响应，不能证明服务没有处理请求，也不能证明没有计费。任务可能已经完成时，盲目重发会带来重复处理的风险。自有系统可用任务编号和内容摘要协助防止重复入库，但这不代表所有接口都会自动去重。

日志能说明系统记录了什么，却不能单独证明模型回复真实、准确或符合要求；模型输出仍需依据可靠资料核验。没有记录到结果，也不能断定请求从未发出。整理日志时，应分开标注可观察到的事实、系统推断和人工核验结论，并按实际用途留存必要信息。