请求日志记录哪些信息：故障排查与隐私边界

整理 AI 工具或写作 API 的请求日志，重点不是复制全部请求内容，而是留下定位问题、判断处理状态所需的信息，同时避免暴露敏感数据。记录字段应根据自有系统和接口实际返回内容设置，不能把某个项目的格式当成所有厂商的通用参数。 先记录任务编号、发起时间、实际使用的功能或模型标识、请求状态，以及系统收到的错误信息。任务编号可关联调用、重试和后续入库；时间应注明

整理 AI 工具或写作 API 的请求日志，重点不是复制全部请求内容，而是留下定位问题、判断处理状态所需的信息，同时避免暴露敏感数据。记录字段应根据自有系统和接口实际返回内容设置，不能把某个项目的格式当成所有厂商的通用参数。

先记录任务编号、发起时间、实际使用的功能或模型标识、请求状态，以及系统收到的错误信息。任务编号可关联调用、重试和后续入库；时间应注明时区，或统一采用一种时间标准，方便对照服务端与本地记录。模型标识按请求中实际使用的值填写，不要猜测版本参数。

再保留必要的输入摘要和输出处理结果，例如内容类型、字符数、结果是否通过应用端校验，以及是否写入自有系统。摘要应能区分任务，但不必照抄提示词和用户材料。确需保存原文时，先确认业务必要性、访问权限和保留期限，并避免记录个人信息及其他不应进入日志的内容。

发生失败时，可记录错误类别、等待时长、重试次数和最终状态。接口若返回请求标识，可按实际情况一并保存。超时只表示客户端未在预期时间内拿到结果，不能据此认定请求未处理或未计费。重试前先核对已有响应、任务编号和入库记录；自有系统可用任务编号及内容摘要检查重复，降低重复写入风险，但这不代表接口必然支持去重。

密钥只应保存在服务端或受保护的本机配置中，不要写进网页、正文或日志。日志也不要记录完整认证头、密钥或无关用户数据。调试完成后，根据排查需要控制敏感内容的留存范围，并限制查看权限。模型生成的文本仍需单独核验：日志能帮助追踪请求过程，不能证明输出内容真实。