AI工具错误排查：记录哪些信息便于核对

整理 AI 工具或写作 API 的错误排查任务时，先记录请求发生的条件和实际表现。写下操作时间、使用入口、任务编号，以及问题出现前的操作；再对照预期结果和实际结果，例如是否收到响应、页面显示了什么提示。任务编号和内容摘要可帮助自有系统查找记录、避免重复入库，但摘要不能替代完整请求内容。 阅读接口说明时，保留与当前问题直接相关的要求：请求需要哪些字段、哪些字

整理 AI 工具或写作 API 的错误排查任务时，先记录请求发生的条件和实际表现。写下操作时间、使用入口、任务编号，以及问题出现前的操作；再对照预期结果和实际结果，例如是否收到响应、页面显示了什么提示。任务编号和内容摘要可帮助自有系统查找记录、避免重复入库，但摘要不能替代完整请求内容。

阅读接口说明时，保留与当前问题直接相关的要求：请求需要哪些字段、哪些字段必填、输入和输出采用什么格式，以及错误说明中列出的处理条件。如果说明区分不同请求场景，应注明本次属于哪一种，不要把某个场景的规则套用到所有接口。说明没有明确的参数或行为时，标记为待确认，不要自行补齐。

调试时记录必要的请求结构和响应信息，同时遮盖密钥、个人资料等敏感内容。密钥只保存在服务端或受保护的本机配置中，不要写入网页、正文或日志。分享日志前，检查其中是否含有凭证、用户输入或可识别信息；排查问题不代表可以公开原始数据。

遇到超时，先核对已有响应、任务状态和本地处理记录。超时不能证明请求没有处理或没有计费。若系统保存了任务编号和内容摘要，可先查找是否已有对应结果，再决定是否重试；如果没有查询能力，就记录已采取的检查步骤，并依据接口说明确认下一步，避免盲目重复提交。

最后，把证据和判断分开记录：原始提示、响应片段和复现条件属于证据，原因推测则标为待验证。模型输出不等于事实核验，涉及事实的内容还需另行查证。这样的记录便于复现和交接，也能避免把猜测当成接口规则。