接口变慢可能来自网络、限流、输入增长、模型服务或自己的队列，不能凭感觉直接更换模型。先把目标、资料和责任拆清楚，往往比立刻调整提示词更能改善结果。 下面这份小清单可以直接用于启动讨论： 1. 记录请求开始、连接、首字和完成时间。 2. 检查单次输入输出长度是否异常增长。 3. 查看限流、超时、重试和队列积压。 4. 用最小请求分别测试网络与供应商端。 本题最需要警惕的是：多个客户端同时自动重试，会在短暂故障时形成请求风暴，让恢复更加困难。如果没有记录，团队之后甚至无法确认错误从哪里开始。 如果不同人员对结果理解不一，就说明验收规则还不够清楚。比较正常与异常时段的同类请求，确认瓶颈位置后再调整并发、超时或模型。除了顺利完成的常规样本，还应加入资料不全、输入矛盾、权限不足或服务异常等边界情形。经过确认的失败样本要加入回归集，确保修复不会在下次更新中消失。 当收益已经低于维护成本时，也应允许有计划地下线，而不是无限保留。分段计时和完整日志能把一句接口很慢，变成可以定位和验证的问题。 本文在提纲整理和初稿撰写中使用了AI辅助，发布前已人工复核事实与表达。