用着用着感觉某个站没以前顺了：偶尔超时、回答变敷衍、账单对不上，但说不清是哪天开始的。这篇不给你一个「好坏」结论，而是给一套能自己跑的观察方法——四个维度、各自的观察窗口与阈值思路、以及先排除网络、缓存、模型名写错这些自身原因的顺序，避免把一次偶发当成整体恶化。
用着用着感觉某个站没以前顺了：偶尔超时、回答变敷衍、账单对不上，但说不清是哪天开始的。这种「说不清」本身就是问题——没有观察方法，你只能靠记忆和情绪下判断，而记忆最容易骗人。
这篇不给结论，只给一套能自己跑的观察方法：把模糊感受拆成四个可观测维度，各自配观察窗口和阈值思路，再补一套先排自己、再排站点的排查顺序。目标只有一个——别把一次偶发当成整体恶化，也别把持续恶化当成偶发。
先定义：什么叫「变差」
「变差」这个词太糊，糊到没法验证。先把它拆成四个可观测维度：可用率、延迟、回答质量、扣费口径。不在这四个里的抱怨，比如「感觉客服态度不好」「界面看着旧」，先放一放，它们不能帮你判断服务本身是否退化。
- 可用率
- 请求能不能成功返回，失败时失败在哪种错误上
- 延迟
- 一次请求的时间花在了哪一段，是排队、首字节还是出字
- 回答质量
- 在固定任务上，输出的稳定性、格式遵守度和完整度有没有变化
- 扣费口径
- 请求数、token 用量、实扣金额三者的对应关系有没有变
什么情况下不适用：单次体验差不构成恶化，一次超时、一次回答敷衍，都可能是上游抖动或你自己的网络问题。只有跨多个时间点重复出现、方向一致的偏移，才值得立案观察。
维度一：可用率——看失败的类型，不只看次数
很多人统计可用率只记「今天失败了几次」，这个数没有信息量。同样是失败，401/404 说明你的配置或权限出了问题，429/5xx 才是站点或上游的锅。不先把错误类型分开，你会把自己的配置错误算成站点变差。
- 先按错误类型分类再计数，鉴权类、参数类、限流类、服务端类分开记；
- 短窗口看突发：连续几次请求里有没有集中失败，用来发现当下故障；
- 长窗口看趋势：按天或按周统计各类失败占比，用来发现缓慢退化；
- 两个窗口都要跑，只用一天的数下结论，大概率是误判。
阈值思路写成「相对基线的偏移」而不是绝对数字：比如某类失败的占比连续几个观察周期高于你自己基线的一个固定比例，才值得细查。具体偏移幅度到 /tools/quality-monitor 看你当前基线再定，写死的数字对别人没意义。
容易误判的情况有两种：一是自己的网络抖动，会让一批请求同时失败，看着像站点大面积故障；二是客户端自动重试，把偶发的 429 放大成「大面积失败」，实际原始请求只有一次。
维度二：延迟——先分清时间花在哪一段
- 拆段把一次请求拆成首字节时间、总时长、出字速度三段，分别记录，不要只记一个总耗时。
- 固定变量同一时段、同一模型、同一提示词反复跑，参数和客户端保持一致，结果才可比。
- 建立基线到 /tools/speed-test 跑一轮，存下你自己的延迟基线，后面所有比较对着它做。
- 对照历史把当前结果和 /ai-status 上的历史表现对照，区分是站点问题还是上游整体波动。
三段里最容易被误读的是首字节时间。它包含了排队等待，高峰期排队会让首字节时间明显拉长，但出字速度可能完全正常——这种情况不该算站点质量下降，算环境因素更合适。
不适用场景：上游官方整体波动、你所在区域网络绕路、客户端做了流式改非流式，这些都会让延迟数字变化，但和站点本身的服务能力无关。分不清时，先换一家同时段对照。
维度三：回答质量——用固定任务而不是感觉去比
「感觉回答变差了」是最不可靠的判断方式，因为你的提示词、上下文、期待值每次都在变。可靠的办法是准备一组固定测试题，每次用同样的问法跑一遍，跑完留档。
| 测试方向 | 看什么 | 常见退化表现 |
|---|---|---|
| 指令遵循 | 是否按指定步骤和约束执行 | 开始跳步、自行简化要求 |
| 格式返回 | JSON、字段名、结构是否稳定 | 字段缺失、多出解释文字 |
| 长文连贯 | 长输出的结构完整度和前后一致 | 长度明显缩短、后段跑题 |
| 工具调用 | 该调用时是否调用、参数是否合法 | 该调不调、参数格式出错 |
质量下滑最常见的两种形态是「换模型」和「降档路由」，表现为长文变短、格式开始不守、拒答变多。遇到这类信号，先到 /tools/quality-check 跑一轮，再和 /benchmarks/crowd-radar 里的多人判断思路交叉验证，比单人主观可靠得多。
不适用场景：你自己改了提示词、换了客户端参数、开了新功能开关，这些都会影响输出。做质量对比前先把变量控制住，否则比出来的差异全是噪音。
维度四：扣费口径——账单比质量更早暴露问题
账单异常通常比质量下滑更早出现，因为它是数字对数字，不靠主观感受。固定看三个数：请求数、token 用量、实扣金额。三者对不上，就是信号。
- 请求数涨、token 没涨：看是不是有请求被重复计费；
- token 没涨、金额涨了：看倍率或计费口径是不是变了；
- 三个数同比例变：大概率是你自己的用量变了，不是站点问题；
- 单次调用金额突增：先查是不是开了缓存或走了带思考链的调用。
口径变化不只是涨价，还包括倍率调整、缓存计费改动、最小计费单位变化。相关读法可以参考 token-cost 与 markup-group-pricing-columns 两篇的说明，具体数字到 /price-watch 核对当期公开口径。
不适用场景：自己开了缓存、换了模型、用了带思考链的调用，这些都会让单价看起来「变了」，但实际口径没动。对账前先把自己这边的变更日志翻一遍。
排查顺序：先排自己，再排站点
发现异常后的第一反应不该是「站点变差了」，而是按固定顺序排除自身原因。这个顺序不能跳，跳着排查最容易得出错误结论。
- 换环境复测换网络、换设备各跑一次，两次都失败再往下走。
- 清缓存换客户端清本地缓存、换一个客户端或直接换调用方式，排除封装层问题。
- 核对配置核对模型名、base URL、鉴权方式是否写错，拼写和多一个斜杠都会导致失败。
- 打原始接口用最小请求直接打原始接口，绕开客户端封装，确认问题是否还在。
- 换一家对照同一时间换另一家服务商跑同样的请求，两边都差说明是上游整体问题，不是单个站点。
留证与上报：怎么把观察变成能用的证据
观察的价值在于能变成证据。随手记和规范记录的区别，在于前者只能支撑情绪，后者能支撑一次迁移决策或者一次客服沟通。
| 记录字段 | 为什么记 | 怎么验证 |
|---|---|---|
| 时间 | 区分突发还是长期 | 精确到分钟，标上时区 |
| 接口与模型名 | 排除配置错误 | 原文照抄，不要简写 |
| 请求参数 | 判断是否自己改了变量 | 保留关键参数即可 |
| 返回状态与耗时 | 对照基线看偏移 | 按错误类型分类记录 |
| token 数与扣费额 | 对账用 | 和账单导出逐条核对 |
连续记够一个观察周期再判断，不要当天就下结论。观察周期怎么定，取决于你的调用频率和业务容忍度：调用密集的团队可以按天看，低频调用的按周看更稳。需要找客服或者走迁移时，这份记录就是你的材料，流程可以参考 stop-loss-and-migrate 的思路。
数据边界仍然按 key-safety 的原则来：日志里别留完整 Key 和敏感业务内容，脱敏后再存档，别为了排查把安全问题一起带进来。
下一步先把基线量出来，再去核对当期公开口径，你的判断才有参照物。→常见问题
感觉站点变差了，第一步该做什么？
先别改配置，也先别换站。从换网络、换客户端、核对模型名和 base URL 开始复测一轮，确认不是你这边的问题；然后拿固定测试题和固定脚本连续跑几天，把可用率、延迟、用量、扣费四组数记下来，有记录再判断。
多久才能判断一个站是真的在变差？
看的是跨多个时间点的一致性，不是单次结果。短窗口用来抓突发，长窗口用来确认趋势，两个窗口的结果都偏向同一方向才立案。具体跑多少天取决于你的调用频率，低频用户要拉更长周期才有统计意义。
延迟变高一定是站点的问题吗？
不一定。上游官方整体拥堵、你所在网络的路由变化、客户端重试、并发打满，都会让延迟看起来变差。先做同一时段同一请求的对照测试，并把首字节和出字速度分开看，能区分是排队还是限速。
回答质量下降怎么证明不是我的错觉？
用固定测试题、固定参数、固定模型名去跑，把每次返回留档再横向对比。典型恶化信号是格式不再守约、长文明显变短、拒答增多、工具调用变乱。多人多时段交叉验证比单人主观感觉可靠得多。
扣费对不上就是被掉包了吗？
先自查三件事：有没有开缓存、有没有换模型、调用里有没有隐藏的额外 token。排除后仍然对不上，再拿用量日志和站内公开计费口径逐项核，把差额算清楚再去找客服，比直接质问有效。
