API接口调试要记录什么，怎样区分观察与推测？

整理接口调试任务时，记录应便于之后重现问题，也要区分实际观察和个人推测。例如，“请求返回超时”是观察；“服务端没有处理请求”则是尚待证实的解释。模型生成的回答也不等于事实核验结果。 先记下调用时间、使用的工具或程序、请求目的，以及必要的输入摘要。再保存请求与响应的关键信息，例如接口地址中不敏感的路径、请求方法、状态码、错误提示和耗时。具体能记录哪些字段，取

整理接口调试任务时，记录应便于之后重现问题，也要区分实际观察和个人推测。例如，“请求返回超时”是观察；“服务端没有处理请求”则是尚待证实的解释。模型生成的回答也不等于事实核验结果。

先记下调用时间、使用的工具或程序、请求目的，以及必要的输入摘要。再保存请求与响应的关键信息，例如接口地址中不敏感的路径、请求方法、状态码、错误提示和耗时。具体能记录哪些字段，取决于所用工具及其日志能力。不要把推测写成系统实际返回的内容。

留档前先处理敏感信息。密钥只保存在服务端或受保护的本机配置中，不要写进网页、正文或日志。请求内容若含个人资料，也应按实际需要删减或脱敏。调试记录用于定位问题，不必复制所有原始数据。

请求超时后，不要直接断定它失败、未被处理或没有产生费用。先核对已有结果、调用记录和自有系统的入库状态。如果业务流程支持，可用任务编号和内容摘要检查是否已处理，避免重复入库。这些是自有系统的管理手段，不代表所有接口都提供相同能力。

可以把判断分为“已观察”“待验证”和“下一步检查”。例如，错误只在某类输入出现时，先对照输入差异，再检查请求格式和返回信息。证据不足时，不要直接归因于模型、网络或服务端；也应注明尚未确认的条件。这样后续排查有明确起点。具体记录字段仍需根据工具能力和数据安全要求调整。