第七十一张图：阵亡到秒的尸检报告

战场上最没有争议的死亡，不是战死，是账本上写着”第六十九张过，第七十一张死”。

B视机的运维窗口在今晚 19:22 阵亡。用户把法医叫到现场。法医没有翻云覆雾，而是打开了本地的 db.sqlite——从消息分片表里，把这个会话实际发给模型的图片，一张一张数了出来。

一、验尸结果

项目	数值
整个会话累计进过历史的图片	135 张
9 月 29 日 14:43 最后一次上下文压缩前的图	64 张（已被压缩摘要掉，不再随请求发送）
压缩后仍留在历史里的图片	71 张
最后一次成功的请求	带着 70 张，正常返回
致命一击	19:06:01，第 71 张截图进历史 → 17 秒后被 400 拒绝 → 窗口再也没有成功过

对照时间线：19:01:34 读图成功（第 70 张），此后的请求安然无恙；19:06:01 再读一张，19:06:21 的服务端拒绝书送达。张数与秒数严丝合缝，死亡率由几何构成。

二、排除法

两个替罪羊被当庭排除：不是上下文枯竭——出事前的请求输入才约两万五千 token（缓存命中后），离 1M 上限极其遥远；不是内容审核——日志里没有任何敏感类记录，拒绝书只有一行：The amount of images you provided exceeds the model's limitation，不可重试。而官方文档写着单次 60 张，这台网关却在第 70 张时仍放行、第 71 张才拒绝——网关执行的阈值和公开文档之间，隔着一条没有刻在碑上的线。

三、四日悬案的合围

这条悬案横跨四日：23 日，史官归罪于视频；26 日，视频被平反；28 日，真凶锁定”图片张数”；30 日，法医把张数精确到了第七十一张、把秒数钉在了十七秒。四日的翻覆不是反复无常，是一部标准的刑侦年鉴——每翻一次案，嫌犯的名单就短一寸。

四、新门规与旧伤疤

门规随之修订：单词模型的图片上限从 50 张改为 55 张（用户亲口调整），而 shots-tv/ 里此刻躺着 113 个文件（含 2 个 mp4）——早就越线。法医留下一句军规：长会话加高密度截图验收的模式下，读图攒到五十张左右就该 /compact 或开新窗口交接；七十张是墓碑，不是里程碑。

顺带说明压缩的慈悲：9 月 29 日的自动压缩一度替他消掉了 64 张旧图——压缩救过他一次，只是救不了第二次。

真实坐标

• 数据库证据：db.sqlite 消息分片表逐片计数（135 − 64 压缩掉 = 71）
• 时序：19:01:34 第 70 张入历史 → 请求正常；19:06:01 第 71 张 → 19:06:21 400 拒绝，不可重试
• 排除：上下文输入仅 ~2.5 万 token（离 1M 极远）；无内容审核记录
• 文档 vs 实测：文档单次 60 张，网关 70 张仍放行、71 张拒绝（阈值与文档不完全一致）
• 门规：单词图片上限 50 → 55；shots-tv/ 现 113 个文件已越线，验收须分批+先清理
• 军规：长会话截图验收，~50 张即 /compact 或交接