AI工具错误排查时，阅读说明应保留哪些细节？

遇到AI工具或写作API报错，先别急着重试。阅读错误说明时，保留能还原问题的信息，才能判断故障发生在哪一步，也能避免把重复请求当成解决办法。 第一步，记录错误原文和出现位置。区分问题发生在本机、网站后端、网络传输，还是服务端返回结果之后；同时记下发生时间、操作步骤和受影响的功能。不要只写“接口不能用”，也不要把密钥、个人资料或完整敏感内容复制到记录里。需要

遇到AI工具或写作API报错，先别急着重试。阅读错误说明时，保留能还原问题的信息，才能判断故障发生在哪一步，也能避免把重复请求当成解决办法。

第一步，记录错误原文和出现位置。区分问题发生在本机、网站后端、网络传输，还是服务端返回结果之后；同时记下发生时间、操作步骤和受影响的功能。不要只写“接口不能用”，也不要把密钥、个人资料或完整敏感内容复制到记录里。需要保留请求内容时，可以整理成脱敏摘要。

第二步，核对请求是否符合你实际采用的说明。留意必填字段、输入格式、认证配置和请求目标，并记下所依据的说明版本或页面日期（如果有）。这些要求因工具而异，不能把某个API的参数要求当成通用规则。密钥应保存在服务端或受保护的本机配置中，不要放进网页、正文或日志。

第三步，按故障发生的阶段逐步检查：先看本地配置和输入，再确认请求是否发出、响应是否收到，最后核对返回内容是否符合预期。遇到超时，不能据此断定请求没有处理或没有计费。先查已有响应、任务状态或服务端记录，再决定是否重试。

第四步，整理复现问题所需的信息：发生时间、任务编号、脱敏后的请求摘要、错误原文和已尝试的操作。自有系统可以用任务编号与内容摘要识别重复入库，避免重试后重复保存同一结果。若没有任务编号或状态查询能力，就只能根据现有日志谨慎判断，不能假定产品提供了这些功能。

模型生成的文字不等于事实核验。排查记录可以帮助说明请求为何失败，却不能证明输出内容准确；涉及事实的内容仍需另行核对。