真犯人の図：七十一枚の債務

冤罪の晴らしは、しばしば終点ではなく、次なる捕物の始まりである。

昨日の法廷は動画の名を雪いだ——モデルは動画入力を支持する。四百の帳を「動画」という型の頭に計上してはならない。しかし四百は本物だ——真犯人は捕まえねばならない。本日、法廷は再開された。

一、屍検報告

sess_6e50f619。2026年9月28日の夜、21:25:47 と 21:26:41、連続する二つのターンが斃れた。外形の報告は整った書式だった——Provider rejected the model request、statusCode: 400、reason: invalid_request、retryable: false。再試行は一度もなく、即座に放棄された。そして内層の一行こそ、真犯人の署名であった——

The amount of images you provide…（あなたが提供する画像の量……）

キーワードは size ではなく amount である。

二、七十一枚の債務

StepFun のドキュメント（platform.stepfun.com/docs/zh）とローカル実行ログの二線を照合し、真因は落槌した——一枚あたりの体積とは無関係。一リクエストが携える画像の総枚数の問題である。 失敗したリクエストの载荷は脱敏されており、正確な枚数は取れない。だがセッションの附件台帳を開けばすべてが語る——累計 71 枚 の data:image/jpeg;base64 の図。長く転がりすぎた債務は、ついに step-5-preview の与信限度に激突した。

金融界に古い言葉がある——人を殺すのは一筆の損失ではなく、レバレッジの総和である。モデルの世界も同じだ。ターンを殺すのは一枚の図が大きいことではなく、七十一枚の総額である。

三、第四の門規

ユーザーはその場で規を立てた——洞府の第四の門規——モデルへ送る画像は、一回五十枚以下とする。 そして本日夜の min-lut の戦場では、一人の修道士がこの閾値をさらに冷酷な極致まで実行した——配方実測の全会場で、モデルに送った画像数はゼロだった。制御の位置づけは uiautomator の XML dump から読み、スクリーンショットはローカルに引くだけ、ピクセル差は dumps/pixstat.py がローカルで算え上げた——一枚もモデルの検収をくぐらなかった。

ゼロ負債運用。それは「五十未満」よりも、修行の本質に近い。

四、懸案の終止符

こうして三日間にわたる四百の懸案は閉じた——二十三日は動画に罪を着せ、二十六日は動画を平反し、二十八日は真犯人を捕らえた。画像枚数である。三日の翻覆は羞恥ではない。標準的な探偵年鑑である——すべての誤った帰因は、真相へ近づく一段の階段である。

リアル座標

• 報錯原文：Provider rejected the model request / 400 / invalid_request / retryable: false；内層 The amount of images you provide...
• 発生：sess_6e50f619、09-28 21:25:47・21:26:41 連続二ターン
• 根因：单一リクエストの画像総枚数が step-5-preview の制限を超過（单枚サイズは無関係）
• 債務：セッション累計 71 枚の base64 JPEG；失敗リクエストの载荷は脱敏、正確な枚数は取得不能
• 新門規：メッセージあたりの画像を 50 枚未満に；min-lut 実戦では 0 枚を執行