面向「视频模型做 caption 质检」的裁判环节。前提锁定：不训练模型、纯推理期优化（System Prompt + 工程链路）、内部提效工具。以下方法按投入产出比从高到低排序 —— 先做前四条，多半在触碰模型能力之前就能拿到大部分收益。
先确认裁判模型的采样温度。若 > 0，降到 0 再跑。
温度 > 0 时同一条样本每次判定可能不同，本身就在贡献随机错误；降到 0 后结果可复现，后续所有实验才有干净的对照基准。这是所有其他优化的前提，不做这一步，后面每一轮都在跟噪声较劲。
用同一套 prompt 把 12% 错误样本连跑 5 轮，切成两部分：每轮都错的稳定错误集（约 5%、35–40 条），和时错时对的波动集。再从做对的 88% 里分层抽样 150–200 条作为保护集。
此后每轮迭代只跑这约 200 条，2–4 分钟出结果，而非全量 20 分钟。指标也换成更灵敏的两个：开发集修好几条（基线 0%，改好 8 条就是实打实 8 条，无噪声）、保护集掉了几条（基线近 100%，掉 3 条立刻可见）。只有开发集真涨、保护集没掉，才跑一次 734 全量做最终确认。
±7.6% —— 真值 88% 能测出 92%，真值 90% 能测出 84%，根本分不清「生效」还是「运气好」。加速要靠换灵敏指标（数条数），不是靠缩小样本估百分比。把稳定错误的每一条按两个维度归类：方向（假阳=该判不可用却判可用 / 假阴=反之）+ 根因。根因通常落在这三类：
① 判定标准理解不一致（漏个次要细节算不算错、数量说错算不算、语义等价但措辞不同算不算）—— prompt 问题；
② 视觉没看清 / 被被测 caption 带偏（锚定偏差） —— 链路问题；
③ 逻辑对齐失误（看清了、标准也懂，但比对时判断出错）—— prompt / 拆链路都能治。
每个 prompt 版本存独立文件，配一行记录：版本号 | 改了哪一条 | 开发集分 | 保护集分 | 全量分。
「改完反而下降、想退回上一版」是常态。光复制粘贴能退回文件，却退不回「当时那版跑了多少分」—— 于是你永远说不清到底哪一改动带来了那 1.2 个点。有了这份记录，任何时候都能精准回滚到最优版本。
prompt_v1 / v2 … 目录 + 一张 CSV/表格，每跑一版补一行。成本几分钟，是整个迭代的安全绳。「删掉现有 few-shot 后准确率没变」证明的是当前这批 few-shot 无效，不是 few-shot 手段无效。原因通常是：这些例子举的是模型本来就判得对的场景。
真正该进 few-shot 的，是模型稳定判错的那类（正好来自第 2 步的稳定错误集）—— 那才是它确实不会的东西。原则不变：few-shot 只放项目独有、非通识的内容，通识（「北京是中国首都」这类）模型预训练早就会，写进去等于噪声。
把稳定错误集打包（视频/标准答案 + 被测caption + 裁判判定 + 正确判定 + 人工归因）丢给一个强 LLM，让它诊断规律、提出 system prompt 修改建议。prompt 不必人肉逐字写。
AI 擅长从一批错例里归纳共性并转成规则表述，比人凭感觉改更系统。但它一次会给一堆建议 —— 必须约束。
若第 3 步归因发现大量错误集中在①「标准理解不一致」，那准确率上不去的根子不在模型能力，而在判定标准本身没有成文、粒度模糊。
漏一个次要细节算不算错？说「两个人」实际三个人算不算错？措辞不同但语义等价算不算错？只要这些边界没定义清楚，人和模型、甚至标注员之间都会不一致 —— 这种分歧无论怎么改 prompt 都消不掉。
把裁判的两件事拆开：视频模型只看视频出结构化描述（且不喂被测 caption，避免锚定偏差），再由一个纯文本 LLM 比对「独立描述 vs 标准答案 vs 被测 caption」做逻辑判定。
拆链路真正能治的是锚定偏差（裁判带着被测 caption 去看视频，注意力被牵着走）和不可归因（一步出 0/1，分不清错在看不清还是判不准）。但若第 3 步归因显示错误大头是「标准理解不一致」，拆链路一点用没有。