请求日志记录哪些信息，才能方便排查

整理 AI 工具或写作 API 的请求日志，重点不是把所有内容都存下来，而是记录足以还原处理过程、又不泄露敏感信息的字段。日志应服务于定位问题和管理任务，不能替代对模型输出的事实核验。 可以先记录任务编号、提交时间、调用的功能或模型标识，以及请求的发起位置。如果服务会把结果写入网站或其他系统，也应记录目标环节和当前处理状态。任务编号能关联请求、响应和后续入

整理 AI 工具或写作 API 的请求日志，重点不是把所有内容都存下来，而是记录足以还原处理过程、又不泄露敏感信息的字段。日志应服务于定位问题和管理任务，不能替代对模型输出的事实核验。

可以先记录任务编号、提交时间、调用的功能或模型标识，以及请求的发起位置。如果服务会把结果写入网站或其他系统，也应记录目标环节和当前处理状态。任务编号能关联请求、响应和后续入库记录；内容摘要则可供自有系统判断是否重复处理。摘要应尽量避免包含完整提示词或用户原文。

排查时还需要了解请求的大致输入类型、关键参数是否齐全、响应状态和错误信息。发生失败时，记录问题出现在哪一步、是否收到响应，以及系统之后采取了什么动作。参数名称取决于具体服务和自有程序，不应把某个产品的字段当成通用 API 标准。确需保存请求或响应正文时，应先明确用途、访问权限和保存范围，并去除个人信息及其他敏感内容。

超时不能直接证明请求未被处理，也不能据此判断是否产生费用。先用任务编号核对已有响应、后台状态或结果记录，再决定是否重试。如果程序可能重复入库，可利用任务编号和内容摘要去重，不要看到超时就无条件重发。

密钥只应保存在服务端或受保护的本机配置中，不能写入日志、网页正文或前端代码。日志也应限制访问，并按排障需要控制记录内容。开发接口时，可先记录状态、错误、任务编号和必要的时间信息；如果这些信息不足以定位问题，再逐项增加字段。