AI工具错误排查记录：适用范围与例外如何区分

排查 AI 工具或写作 API 的错误时，记录应回答三个问题：发生了什么、在什么条件下发生、哪些情况尚未确认。先写明任务目标、操作步骤和实际结果，例如请求后超时、返回错误，或页面没有显示结果。不要把推测当作故障原因。 接着记录必要的请求背景，包括调用时间、使用的功能、输入内容摘要、关键请求设置，以及供自有系统查找的任务编号。信息应足以支持复现或比对，但不必

排查 AI 工具或写作 API 的错误时，记录应回答三个问题：发生了什么、在什么条件下发生、哪些情况尚未确认。先写明任务目标、操作步骤和实际结果，例如请求后超时、返回错误，或页面没有显示结果。不要把推测当作故障原因。

接着记录必要的请求背景，包括调用时间、使用的功能、输入内容摘要、关键请求设置，以及供自有系统查找的任务编号。信息应足以支持复现或比对，但不必复制整段敏感内容。密钥只保存在服务端或受保护的本机配置中，不得写入网页、正文或日志。若要保留请求与结果，应根据实际用途限制访问范围和保存内容。

适用范围要写清边界，例如问题是否只在某类输入、某个操作步骤或特定网络环境下出现。只有经过重复检查的条件，才适合标注为“目前可在这些条件下复现”。一次异常不足以证明所有请求都会失败。尚未验证的环境、输入类型或操作应标为未知，不要直接归入故障范围。

例外是指与主要现象不同、可能影响判断的情况，例如同一操作有时成功、有时失败，页面未显示结果但系统中已有结果，或重试后出现重复记录。请求超时不能直接证明任务未处理或未计费，应先核对已有结果。自有系统可用任务编号和内容摘要检查任务是否已处理，避免重复入库；这不能判断服务端的计费状态。

最后，将观察、推断和待确认事项分开，并注明各项结论对应的证据。模型生成的解释只是输出，不等于事实核验。如果日志缺少时间、请求上下文或结果状态，应先补齐能够安全取得的信息，再判断问题属于输入、调用流程还是展示环节。不同工具提供的日志字段并不相同，记录格式应按实际可获得的信息调整。