请求日志记录哪些信息，才能更好排查接口问题

整理 AI 工具或写作 API 的请求日志，重点不是保存所有内容，而是留下定位问题、核对结果所需的信息，同时保护密钥和用户内容。具体记录哪些字段，要看自有系统的用途和数据保护要求；接口并没有统一的日志格式。 可以先记录请求时间、任务编号、调用环节和处理状态。统一系统内部的时间记录方式，便于对应同一任务的提交、等待和结果。任务编号可用于检查结果是否已入库，减

整理 AI 工具或写作 API 的请求日志，重点不是保存所有内容，而是留下定位问题、核对结果所需的信息，同时保护密钥和用户内容。具体记录哪些字段，要看自有系统的用途和数据保护要求；接口并没有统一的日志格式。

可以先记录请求时间、任务编号、调用环节和处理状态。统一系统内部的时间记录方式，便于对应同一任务的提交、等待和结果。任务编号可用于检查结果是否已入库，减少重复处理。状态要区分请求已发出、已收到响应、处理失败和结果待核对，不能把它们混为一谈。

请求摘要和响应摘要也有助于排查，例如记录所选功能、输入的大致类型、返回内容是否为空，以及错误信息。若要保存原始提示词或完整响应，应先确认必要性，并限制访问权限和保存范围。内容摘要可以帮助识别任务，但不能代替原文核验；模型输出也不等于事实已核实。不要为了方便把整段用户材料长期写入普通日志。

遇到超时，先根据任务编号和时间查找已有响应、处理状态及入库记录，再判断是否需要重试。超时不能直接证明请求未处理或未计费。如果重试可能造成重复写入，应先确认自有系统能否按任务编号识别已处理任务；没有这类机制时，先人工核对结果再操作。

最后检查日志的存放位置和访问权限。密钥只保存在服务端或受保护的本机配置中，不要写入网页、正文或日志；必要时也要避免记录可能还原密钥的请求头。实用的日志应能回答：何时发起、对应哪个任务、处理到哪一步、结果是否存在，以及排查时是否可能暴露敏感信息。