这个坑值得记一笔。让 gpt-4o 分析一次线上故障，把 3 万行 nginx 日志整体贴进 user，回答只提到最后 200 行，问它开头时间段有没有 502 时说没有，实际前面有两个峰值。
刚开始盯着「关键错误行与噪声行格式完全一样」，折腾了半个多小时，排掉了。
真正麻烦的地方在于，几个原因的现象几乎一样。中段内容落在长上下文的注意力低谷；日志没有时间标记 模型建立不了顺序；单条消息过长 被服务端按截断策略处理。
先按状态码过滤 只留非 200 的行
awk '$9!=200' access.log | head -2000 > err.txt再往下按分钟聚合出错误峰值
python agg.py --by minute --status 5xx --out peaks.csv接着把每个峰值前后各一百行单独拼成一段
python slice_log.py --peaks peaks.csv --before 100 --after 100末了让模型先复述时间线再给结论
python ask.py --file prompt_log.txt --require timeline怎么算真的好了，看的是同一批现象。回答里能准确说出三个 502 时间窗口，与本地聚合的 peaks.csv 完全一致。
容易忽略的是，先聚合再喂比一味加大上下文有效，日志这种同构数据模型很难自己看出分布。报错文案容易误导，真正的原因往往在相邻那一层的日志里。