AI工具错误排查：记录观察与推测

排查 AI 工具或写作 API 出错时，先记录“实际发生了什么”，再单独写“可能是什么原因”。如果把两者混在一起，容易把猜测当成结论，也可能让后续检查偏离问题。 先写可以复核的信息：操作时间、使用的功能或接口、请求的大致内容、页面或程序显示的完整错误信息，以及问题是否每次都会出现。查看请求日志时，可保存必要的请求和响应摘要，但不要记录密钥、完整敏感内容或个

排查 AI 工具或写作 API 出错时，先记录“实际发生了什么”，再单独写“可能是什么原因”。如果把两者混在一起，容易把猜测当成结论，也可能让后续检查偏离问题。

先写可以复核的信息：操作时间、使用的功能或接口、请求的大致内容、页面或程序显示的完整错误信息，以及问题是否每次都会出现。查看请求日志时，可保存必要的请求和响应摘要，但不要记录密钥、完整敏感内容或个人资料。密钥应保存在服务端或受保护的本机配置中，不能写入网页正文或日志。

接着记录操作环境和条件，例如请求是从网页、脚本还是自有网站发起，问题发生前做过哪些改动，以及同一任务是否已有结果。接口字段和错误含义应以实际产品说明及返回信息为准，不能把某个工具的规则当成所有 API 的通用规则。暂时无法确认的信息，标为“待核实”，不要写成确定事实。

可以记录推测，但要与观察分开，并注明依据和验证办法。例如，“请求等待较久”是观察；“服务端没有处理”是推测。单凭超时不能得出这个结论，也不能据此判断是否计费。重试前应先核对已有结果，避免重复执行或重复入库。

如果任务会进入自有系统，可记录任务编号和内容摘要，用来检查是否已有相同任务结果。摘要不是错误原因，也不能代替原始问题描述。记录的信息应足以帮助他人复现问题或判断下一步；涉及隐私或密钥时，应删减或脱敏。资料不完整时，明确写出缺少什么，比用猜测填补更利于排查。