工作中的任务突然失败，很容易让人想把配置全部重来。但一次改动太多地方，也会让最初的问题更难被理解。更有效的起点，是先说明哪里失败、保留现场，再决定需要改变什么。
记录任务在哪里停止
区分问题发生在连接模型、调用工具，还是执行任务的过程中。记录当时使用的模型、错误提示，以及最近是否调整过配置。
这些信息帮助您避免把不同问题混在一起。记录用于自己排查时保留必要上下文；需要对外分享时，先移除凭据与敏感项目内容。
让 Doctor 检查相关环境
Doctor 将与 AI 工具有关的环境、配置、连接和运行状态放到一起检查。它的用途是提供诊断线索，帮助您了解哪些环节需要继续查看。
检查结果需要结合实际任务判断。一次环境检查不能代替对任务内容或远端服务状态的确认，也不应被理解为所有问题都能自动修复。
结合会话与请求记录
日志和会话记录能够补充问题发生的过程。先找到对应时间和任务，再查看相关请求，有助于区分配置问题与某次调用的异常。
如果调整了模型或供应商，确认记录对应的是新的配置。对于成本问题，也应结合请求、会话和项目范围查看，避免只凭一个局部数字判断。
一次验证一个变化
根据已有线索，选择最相关的一项配置进行检查或调整，然后用简单任务验证。能确认变化的影响之后，再继续下一项。
如果需要反馈给团队或支持人员，可以整理最小复现步骤、已经检查的项目和仍然出现的现象。这样的反馈比一整段未经整理的日志更容易被理解。