AI工具错误排查要记录哪些信息，才能判断问题

用AI工具或写作API排查错误时，先把单次请求整理成可复核的记录。只写“失败了”或复制报错，通常不足以判断问题；还要记下请求发生的条件、实际返回结果，以及之后做过哪些操作。以下方法适用于有权限查看请求信息的个人或团队，不要求所有工具提供相同字段。 先记发生时间、操作入口和任务编号，并注明使用的是网页、应用还是自建接口。再写明输入内容摘要、目标任务和必要上下

用AI工具或写作API排查错误时，先把单次请求整理成可复核的记录。只写“失败了”或复制报错，通常不足以判断问题；还要记下请求发生的条件、实际返回结果，以及之后做过哪些操作。以下方法适用于有权限查看请求信息的个人或团队，不要求所有工具提供相同字段。

先记发生时间、操作入口和任务编号，并注明使用的是网页、应用还是自建接口。再写明输入内容摘要、目标任务和必要上下文；涉及隐私时应脱敏，不必保存完整提示词。记录工具或接口名称，以及当时实际选择的模型或配置。产品没有提供某项信息，就标记为未知，不要推测版本、额度或内部状态。

接着区分结果类型：请求是否发出、页面或程序显示了什么错误、是否收到部分内容，以及内容是否符合预期。记录状态码、错误文本和时间信息前，先确认它们确实来自客户端或服务端记录；不能仅凭错误提示判断故障来源。模型生成的答案也不等于事实核验结果。若问题是内容不准确，应另记具体错误点和核对依据。

遇到超时，先查已有结果，再决定是否重试。超时不能直接证明请求未处理或未计费。若任务可能写入自有系统，可用任务编号和内容摘要核对是否已经入库，避免重复保存；这只能帮助检查自己的处理记录，不能替代服务端状态确认。

最后逐项记录改动，例如是否调整了输入、网络环境或本地配置，并注明改动后的结果。这样可以比较前后条件，避免一次改动多个地方后难以判断原因。密钥只应保存在服务端或受保护的本机配置中，不能写进网页、正文或日志。记录不必追求字段齐全，重点是留下足以复核问题的信息，区分已知事实与猜测，并保护敏感内容。