AI工具与API错误排查：按情境记录关键信息

排查 AI 工具或写作 API 错误时，先记下问题表现、发生步骤，以及哪些信息可以安全保留。不同情境需要记录的内容不同，不能只写“请求失败”；也不要把密钥、完整个人资料或敏感内容放进日志。 使用网页端工具时，记录操作步骤、问题出现的大致时间、页面提示，以及问题能否重复出现。如果问题只发生在某个任务中，可以保存不含敏感信息的输入摘要，并注明预期结果和实际结果

排查 AI 工具或写作 API 错误时，先记下问题表现、发生步骤，以及哪些信息可以安全保留。不同情境需要记录的内容不同，不能只写“请求失败”；也不要把密钥、完整个人资料或敏感内容放进日志。

使用网页端工具时，记录操作步骤、问题出现的大致时间、页面提示，以及问题能否重复出现。如果问题只发生在某个任务中，可以保存不含敏感信息的输入摘要，并注明预期结果和实际结果。页面没有显示错误，不代表输出已经通过事实核验；模型回答仍需根据用途检查。

调试 API 时，区分请求是否发出、服务是否返回响应，以及响应内容是否符合预期。可以记录请求路径、功能类别、非敏感参数摘要、响应状态和错误文本。具体字段以实际接口说明和现有日志为准，不要假设不同服务使用相同参数。密钥只保存在服务端或受保护的本机配置中，不写入网页、正文或日志。用于复现问题的请求内容，应先删去个人信息和其他敏感资料。

遇到超时，先核对是否已有响应、任务结果或后续状态，再决定是否重试。超时不能证明请求未处理，也不能据此判断是否计费。自有系统可以记录任务编号和内容摘要，用于核对结果、避免重复入库；这不代表所有平台都支持相同的任务查询机制。

如果问题出在网站接入环节，还要记录影响范围：是单个页面、单项功能，还是多个页面，并注明近期相关配置改动。整理时可依次记录复现步骤、请求与响应、影响范围和已有结果，以便区分输入、接口与站点处理问题。记录应服务于定位和复现；未经核实的猜测不要写成原因。