AI工具与API报错时，应该怎样按顺序排查？

遇到AI工具或API报错，先别急着重复提交。排查应从现象和影响范围入手，再检查请求、网络、服务端和结果处理；不同环节的问题，判断方法也不同。记录报错原文、发生时间、操作步骤和受影响范围，区分是网页操作失败、单次请求异常，还是多个请求都无法完成。记录时不要包含密钥或不必要的个人信息。 如果只是网页操作异常，先确认输入是否完整、页面是否提示必填项，再尝试重新载

遇到AI工具或API报错，先别急着重复提交。排查应从现象和影响范围入手，再检查请求、网络、服务端和结果处理；不同环节的问题，判断方法也不同。记录报错原文、发生时间、操作步骤和受影响范围，区分是网页操作失败、单次请求异常，还是多个请求都无法完成。记录时不要包含密钥或不必要的个人信息。

如果只是网页操作异常，先确认输入是否完整、页面是否提示必填项，再尝试重新载入，或在条件不变的情况下复现问题。同一操作持续失败时，记下具体步骤和页面提示，避免连续点击造成重复提交。页面显示失败，不一定表示后台任务没有开始；如果提交后一直没有响应，应先查已有结果。

如果问题出在API请求，依次核对请求地址、方法、必要的请求头和正文格式，并对照自己使用的接口说明。密钥应保存在服务端或受保护的本机环境中，不要写进网页代码、正文或日志。随后查看请求日志中的时间、状态信息和脱敏后的错误内容。确认配置和输入无误后，再判断问题是否出在网络或服务端。不同接口的字段与错误含义可能不同，不要套用未经核实的参数规则。

请求超时不能直接证明任务未处理或未计费。先用已有的任务编号或内容摘要查询结果；自有系统可以用这些信息识别重复任务，避免重复入库。如果没有可查询的标识，先检查日志和本地状态，再决定是否重试，并记录重试时间与结果。

拿到模型输出后，还要检查格式是否符合后续流程、内容是否完整。模型回答不等于事实核验，涉及事实的内容应另行核对。如果排查到某一步仍无法判断，保留定位问题所需的请求信息、错误提示和复现条件，但不要公开密钥或敏感数据。