问题出现得很突然，日志倒是留得挺全。qwen-max 的提示词里放了 12 个 few-shot 例子，每条 400 字，接口没报错但回答只覆盖最后两个例子，日志里 prompt_tokens 是 7800，模型上下文是 8192。
刚开始盯着「system 和 few-shot 顺序混乱，重要指令被挤到前面」，折腾了半个多小时，排掉了。
真正麻烦的地方在于，几个原因的现象几乎一样。输入接近窗口上限，服务端按策略截断且不报错。少数情况下是例子没有按相关度筛选，全都塞进去。
还有一种情况，没有记录实际 prompt_tokens，问题被掩盖。
第一件事是把每次请求的 usage 打出来
python -c "import json;print(json.load(open('resp.json'))['usage'])"随后按问题相似度只保留 3 条例子
python -c "print('top3 by bge-m3 similarity')"再往下把每条例子压到 150 字以内
python -c "print(len(open('examples.txt').read()))"等前面都确认过，再在客户端加一条 prompt_tokens 超过 7000 的告警
python -c "u=7800;print('alert' if u>7000 else 'ok')"怎么算真的好了，看的是同一批现象。prompt_tokens 降到 3200 左右，回答能覆盖全部三个例子，抽样 50 条里格式遵循率从 62% 升到 94%。
容易忽略的是，上下文超限经常是静默截断，服务端不报错不代表没丢内容，把 usage 打进日志是最便宜的兜底。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。