一次请求其实经过多个阶段
打开AI工具时，浏览器先取得页面资源，再完成账号验证、建立会话、提交提示，最后等待服务端生成结果。文字迟迟不出现，可能是排队或模型处理；图片和附件上传缓慢，才更接近本地上行或跨区路径问题。
判断时先观察哪个阶段停止。网页都打不开与网页正常但回答很慢，不应使用同一套处理方法。前者检查DNS、浏览器和连接，后者还要查看服务状态、账号额度与任务复杂度。
用小任务建立对照
不要一开始就反复提交同一个大型任务。先发送一条短文本，再尝试小文件，最后恢复原任务。若短文本正常而大附件失败，问题更可能在上传、文件限制或超时；若所有任务都慢，则需要结合服务公告和其他网络进行比较。
可以先保留原设备和账号，只切换网络观察结果；随后恢复网络，再更换浏览器。每次变化都有前一轮结果可比较，恢复后也能知道是哪一环真正产生影响。
保留可用于判断的现场信息
有效记录包括发生时间、设备系统、浏览器、目标服务、任务类型和提示原文。不要发送密码、验证码、完整对话或无关个人资料。支持人员需要的是能定位阶段的信息，而不是越多越好的截图。
如果问题只在晚间固定时段出现，可连续数日记录同一任务的开始与完成时间。长期样本比一次测速更能说明是否存在稳定的时段规律。
用实际任务区分等待阶段
浏览器网络面板可以观察页面请求，但普通使用者不必解读所有字段。先留意主页面是否返回、附件是否持续上传、错误是否来自服务自身，已经能缩小范围。
公司网络可能对文件类型、域名或长连接设置策略。个人热点正常而办公网络失败时，应交给管理员核对，不建议自行关闭终端防护。
短问答、长文分析、图片生成和大型文件解析使用的处理资源不同。比较时应使用相同模型与相近输入，否则快慢差异没有直接意义。
恢复后补充哪一种任务恢复、是否更换网络、服务公告是否结束。这样的记录能帮助团队区分偶发排队与持续连接问题。
排查可以回答什么
设想同一办公室三位成员同时使用AI服务：一人只做短文本问答，一人上传长篇PDF，另一人生成图片。短文本立即返回，PDF停在解析阶段，图片任务显示排队。此时线路并没有一个统一的“快或慢”结论。先用相同账号在同一网络提交短文本，可以确认基本会话可用；再换一个小附件，观察上传是否完成；最后查看服务状态是否提到文件解析或图像队列。若只有公司网络阻止附件，而手机热点正常，应由管理员核对上传策略。若所有网络都在相同处理阶段等待，则更接近服务端负载。保存任务类型、时间和提示，比连续刷新页面更有帮助，也不会因为更换太多条件而失去判断依据。
这套排查方式用于区分连接、浏览器和服务处理阶段，不能据此推断某个模型的能力或保证服务随时可用。登录异常还可能来自账号状态、地区政策或组织权限，这些情况应回到平台公告和管理员说明。测试输入应避免真实客户资料；需要上传文件时，可先使用不敏感的小样本验证流程。排查过程中一次只更换一个条件，并在恢复后撤销临时设置，才能避免把偶然成功误认为永久解决。
团队若经常使用同一类AI任务，可以保留一份不含敏感资料的测试样本。出现异常时先跑这份样本，便能快速判断基础会话、附件上传和服务处理是否与平时不同，也方便成员用同一标准交流。