请求日志记录哪些信息：用任务编号与摘要排查重复处理

整理 AI 工具或写作 API 的请求日志，重点不是照抄全部请求内容，而是保留足以还原处理过程、判断是否需要重试的信息。以下做法适用于自有应用或受控的本机调试环境；具体记录哪些字段，要看系统实际支持什么。 先记录任务编号、提交时间、所用功能或模型标识，以及请求来源的内部标记。任务编号应能关联请求和后续结果；如果系统没有现成编号，可以由自己的程序生成。时间格

整理 AI 工具或写作 API 的请求日志，重点不是照抄全部请求内容，而是保留足以还原处理过程、判断是否需要重试的信息。以下做法适用于自有应用或受控的本机调试环境；具体记录哪些字段，要看系统实际支持什么。

先记录任务编号、提交时间、所用功能或模型标识，以及请求来源的内部标记。任务编号应能关联请求和后续结果；如果系统没有现成编号，可以由自己的程序生成。时间格式和时区尽量统一，方便对照应用日志。模型标识只记录实际发送的值，不要根据界面名称推测接口参数。

接着记录请求摘要、处理状态和返回结果摘要。摘要可以帮助识别任务内容，例如记录文本长度、内容类别或脱敏后的短摘要；没有必要时，不保存整段用户原文。状态可标为已提交、收到响应、报错或等待核对，并保留不含敏感内容的错误信息。模型输出不等于事实核验，因此日志只能说明系统收到了什么，不能证明答案正确。

请求超时后，先按任务编号查找是否已有结果，再决定是否重试。超时不能单独证明请求未处理或未计费。如果重试可能导致自有系统重复入库，可以用任务编号和内容摘要比对已有记录，帮助识别重复任务；但这不能完全排除把不同内容误判为同一任务的风险。

还要检查日志是否泄露凭据或隐私。密钥只保存在服务端或受保护的本机配置中，不写入网页、正文或日志。用户原文和个人信息也应按排错需要尽量少存，并限制访问。日志保留期限和字段没有适用于所有 API 的统一答案，应结合用途、系统安全要求和实际配置确定。