请求日志排查顺序：超时、报错与结果缺失的区别

遇到写作 API 或其他 AI 接口的请求日志异常，先别立刻重试。日志用于区分请求是否发出、服务是否返回，以及本地程序是否保存结果。单看一条错误信息，往往无法确定问题出在哪个环节。 如果记录显示连接失败或请求未发出，先检查本机网络、服务端连通性和请求地址，再确认程序是否生成了请求。如果请求已经发出，但等待时超时，不能因此断定任务没有处理或没有计费。先用任务

遇到写作 API 或其他 AI 接口的请求日志异常，先别立刻重试。日志用于区分请求是否发出、服务是否返回，以及本地程序是否保存结果。单看一条错误信息，往往无法确定问题出在哪个环节。

如果记录显示连接失败或请求未发出，先检查本机网络、服务端连通性和请求地址，再确认程序是否生成了请求。如果请求已经发出，但等待时超时，不能因此断定任务没有处理或没有计费。先用任务编号查找已有响应、回调记录或保存结果；如果没有可核对的信息，再根据系统设计决定是否重试，避免重复执行或重复入库。

收到明确的错误响应时，保留状态码、错误正文、发生时间和关联任务编号，并检查请求格式、认证配置及目标服务状态。具体错误含义应以所用接口的文档和返回内容为准，不要把某个产品的参数规则套用到所有 API。密钥只保存在服务端或受保护的本机配置中，日志则应遮蔽密钥等敏感内容。

如果接口返回成功，但网页或后台没有显示结果，接着检查本地处理链路：响应是否解析成功、数据库写入是否完成、页面读取是否指向正确记录。可以用任务编号关联请求与结果；内容摘要也能帮助识别重复记录。不过，摘要相同不一定说明两次请求完全等价，还需结合任务上下文判断。

排查时，记录必要的时间、任务编号、脱敏后的请求摘要、响应状态和处理结果即可，不要记录完整密钥或不必要的敏感文本。模型输出不等于事实核验；日志能说明处理过程，不能单独证明内容正确。不同系统的字段和重试机制并不统一，应以自身代码和接口说明为准。