从一次模型退化审计到可复现实验：重构游戏 UI 图标分类器

前两篇实验先后测试了两件事：第一篇让通用视觉 embedding 在整张截图上做 sliding-window 搜索；第二篇只用 390 张 catalog 素材训练图标身份和裁剪质量。它们证明 catalog 很有价值，也暴露出 localization、真实游戏域差异和评估样本太小的问题。第三步不再继续堆 detector，而是把问题缩小成一个更可控的问题：给定一个已经裁好的图标区域，我们能否可靠地判断它是否有效，并在有效时识别出类型和具体身份？

这篇文章记录的不是一条漂亮的最终准确率，而是一次研究基础设施重建：我们把仍在探索的 classifier 从主 Perception 系统移出，冻结一份只包含人工确认样本的数据快照，设计三个可公平比较的模型阶段，并把每一次抽样、checkpoint、阈值和逐样本变化都变成可审计产物。

图 1。稳定的 Perception 核心负责采集和真值；B04 只读取冻结数据并研究 crop-level classification 与 rejection。

1. 研究问题与结论边界

游戏里选择英雄、主技能、宝物和生物时，候选内容出现在相对固定的位置。对这些页面，最经济的生产方案不一定是再运行一个通用 object detector：普通代码可以按屏幕布局裁出 1–3 个固定区域，神经网络只需要判断每个 crop 是什么。

B04 的输入只有一张 crop 的 RGB 像素。理想输出按顺序包含三件事：

1. 这张 crop 是有效图标，还是应该拒绝的无效内容？
2. 如果有效，它属于 Hero、Main Skill、Creature 还是 Artifact？
3. 在对应类型的 catalog 中，它是哪一个具体 identity？

这里的“拒绝”不是第五种图标。它表示 crop 里可能是文字遮挡、空白区域、错误页面、tooltip，或者未来还没见过的无效画面。这个集合视觉上非常杂，不能再像旧 V5 那样简单追加成一个与所有英雄竞争的 softmax 行。

本文当前能够支持的结论只有：

我们已经建立一份冻结、可验证的数据集，以及一套能公平比较 catalog-only、verified-gameplay adaptation 和 learned validity rejection 的实验代码。工程链路已经跑通，但模型效果尚未经过正式训练与未见测试集验证。

2. 从前两篇实验走到 B04

第一篇实验使用 ImageNet 预训练 ConvNeXt 的通用特征，在整张截图上尝试成千上万个候选框，再与已知图标做 cosine similarity。它经常能猜对 identity，却不一定选出最贴合图标的框。这说明“认得像什么”和“框得好不好”是两个不同问题。

第二篇实验进一步用 390 张 catalog 图训练身份表示和 crop-quality head。在一个只有 18 个真实目标、且被反复查看过的开发集上，catalog-only detector 的代表方案达到 13 TP、3 FP、5 FN；后续方案在该开发集上更高，但没有在 sealed test 上确认。更重要的是，这一整条实验不允许 gameplay screenshot 更新模型权重，因此没有真正回答人工确认的真实 crop 能否缩小 catalog-to-gameplay domain gap。

B04 刻意切断 localization：

• 不从整张屏幕搜索位置；
• 不训练 box regression；
• 不研究 battle scene；
• 不把 OCR、scene classifier 或视频上下文送入模型；
• 只研究已经由稳定 crop extraction 产生的局部图像。

这样做不是否认 detector 的价值，而是让当前最急迫的问题变成一个清楚的受控实验。固定位置页面的生产瓶颈其实更接近 classification 与 rejection，而不是 object detection。

3. V1/V5 退化到底发生了什么

建立 B04 之前，我们先审计了一个反直觉现象：为什么加入更多人工审核 gameplay crop 的 V5 candidate，反而比 V1 差？审计首先纠正了三个长期混在一起的名字。

对象	实际训练与状态	Validation	Safety validation
V1 production	B02 的 354 类 catalog-only seed；117 个 gameplay crop 的 adaptation 没过 gate，因此没有上线	208/213 = 97.65%	72/72 = 100%
Rejected V5 full-head candidate	1,055 个去重 Hero/Skill gameplay crop；更新整个 identity head；未上线	205/213 = 96.24%	66/72 = 91.67%
Old-weights-safe V5	旧 354 行恢复为 V1；新增 reject 行 gate 失败	208/213 = 97.65%	72/72 = 100%

图 2。真正退化的是从未上线的 full-head candidate；production 的旧 354 类并没有变差。

更具体的退化模式

在 285 个相同 evaluation crop 上，rejected V5 相对 V1 有 10 个 regression、1 个 improvement。Safety validation 的 6 个 regression 全部来自同一个 human_hero_16、同一个录像条件，而这个英雄没有来自训练录像的 gameplay positive。

最有解释力的假设不是一句模糊的“domain shift”，而是不对称的 gameplay 支持：

• 有 gameplay positive 的英雄在训练中同时得到正梯度与来自其他英雄的负竞争；
• 没有 gameplay positive 的英雄仍会在其他英雄样本上不断作为 softmax competitor 收到负梯度；
• 它们却没有自己在 gameplay 域里的正梯度抵消这种压力。

V5 的 1,055 个 gameplay crop 只覆盖 75 个 identity，真正的 train partition 只覆盖 68 个，而输出空间有 355 行。因此“样本更多”并不等于“每个类别都有更多真实样本”。

审计确认的四个工程问题

1. Sampler 没有消费完整数据。 历史 balanced sampler 在 770 个真实训练 crop 中只用到 545 个，225 个永远没有进入 optimizer；修复后通过跨 epoch 轮换覆盖 770/770。
2. 一张 synthetic negative 主导 checkpoint selection。 较早 epoch 的旧类整体更好，但因为 synthetic 类是 0/1，直到 epoch 11 记住这一张图才赢得 lexicographic selection。
3. Gate 失败没有完全 fail closed。 旧实现会恢复旧 354 行，却仍把未经验证的第 355 行留在 production output 中。现在 gate 失败会恢复原始输出形状和 taxonomy。
4. 历史产物不够可复现。 配置会继续变化，V1 没保存逐样本 manifest，Markdown 与 JSON 还曾经描述不同 run。现在每个 run 保存 resolved config、逐 batch sample records、consumption 和每个 epoch checkpoint。

这些发现解释了为什么不能直接把旧 V5 当作“更多数据有害”的证据，也说明为什么新的实验必须从命名、数据和代码边界重新开始。

4. 为什么先重构再训练

以前 icon classifier 同时存在于主 Perception 代码、production wrapper、实验脚本和报告工具里。继续在这里修改架构会产生两个风险：研究代码可能意外刷新 production 结果；稳定的数据采集系统也可能因为模型重构而损坏。

这次重构按“职责是否稳定”划线，而不是按代码行数划线。

继续留在主 Perception	移入 B04 的实验能力
Video/frame loading	模型结构与预训练 backbone 选择
固定位置 crop extraction	Icon-specific training loop 与 loss
Annotation store、review UI、corrections	M0/M1 identity-domain sampler
Catalog/reference reader	M2 validity-balanced sampler
OCR 和 OCR quality audit	Checkpoint selection 与 experimental inference
Scene Classification 系统	Icon metrics、paired comparison、report generation
Battle class-agnostic detector	Confidence rejection 与 learned validity rejection
通用 snapshot/export 与 manifest schema	实验配置与模型绑定测试

重构后，主 pipeline 仍能生成固定 crop 或 class-agnostic battle boxes，但不会自动加载 B04 classifier，也不会把新的预测写回 annotation state。已有 production checkpoint、已有分类结果、原始视频、人工审核记录和 Scene Classification 数据都没有覆盖。

B01 和 B02 保持冻结。B03 仍然是历史 detector 实验，只把旧 V1 classifier 的 import 机械地指向一个只用于兼容的 legacy copy；B03 的模型配置、数据、指标和结果没有重新训练。

5. 冻结数据怎样产生

实验训练不能每次启动时查询 all_current_user_confirmed_samples()。如果用户今天又审核了 80 张图，同一个 config 明天就会读到另一份训练集，旧结果便无法解释。

因此 B04 新增了一个模型无关的 snapshot exporter。它从 Golden Dataset 读取已经存在的审核记录，执行 fail-closed eligibility 规则，再把每张 crop 物理复制到一个新目录。目标目录如果已存在，导出直接失败，不能静默覆盖。

一张 gameplay crop 进入 snapshot 需要满足：

• bounding box 是 USER_CONFIRMED；
• VALID crop 还必须有 USER_CONFIRMED identity；
• identity 必须存在于 canonical catalog，并与页面视觉类型一致；
• REJECT crop 必须有用户确认的 invalid reason；
• 模型建议、OCR 建议、correction draft 和未审核记录都不能变成 ground truth。

旧数据里的 英雄选择界面里的非英雄 曾经表现成 synthetic identity。导出时它被明确迁移为 REJECT / HERO_SELECTION_NON_HERO，不会再与 77 个具体英雄一起竞争。

每条记录保存普通可读字段：sample ID、录像名、frame、时间戳、object ID、box 坐标、crop 路径、类型、identity 或 reject reason、review authority、partition 和 duplicate-group 信息。Snapshot 同时带有 resolved export config、taxonomy、统计、source state 和可独立验证的文件清单。

一个 VALID 样本如何走完整条链路

以一张用户确认的 chain-mail artifact crop 为例：

1. Annotation 中的 box 和 artifact:chain_mail_artifact identity 都是用户确认；
2. Exporter 将 crop 复制到 gameplay/valid/artifact/...，根据录像把它放入 validation；
3. M1 若在 train partition 看到同类样本，会为它产生 validity=1、type=artifact 和 artifact-head 内部的 identity index；
4. Loss 计算 type cross entropy 和 artifact identity cross entropy；
5. Evaluation 保存预测的 type、routed identity、confidence、validity probability 与逐样本正确性。

如果同一个固定 slot 被 tooltip 完全遮住，则 validity=0，type 和 identity target 都写成 −1。它只能更新 validity head，绝不会被迫训练成某个错误英雄。

6. 2,136 个样本的完整构成

冻结 snapshot 名为 verified-gameplay-crops-2026-08-31。独立验证覆盖 2,136 个样本和 2,148 个受管理文件。

图 3。真实监督高度集中在 Hero 和 Main Skill；Artifact 与 Creature 目前只能支持谨慎的探索性结论。

数据来源	数量	训练角色
Catalog visual	390	M0/M1 的 canonical identity supervision
Catalog identity	354	动态定义四个 type-specific identity head
User-confirmed VALID gameplay	1,552	M1 的真实正样本；M2 的 validity positive
User-confirmed REJECT gameplay	194	M2 的 validity negative
Gameplay identities with confirmed positives	112	只覆盖 catalog identity 的一部分
Source videos	16	按录像隔离 train/validation/safety-validation

Gameplay 按类型

类型	Crop 数	占 1,746 个 gameplay crop
Hero	921	52.75%
Main Skill	738	42.27%
Artifact	57	3.26%
Creature	30	1.72%

REJECT 按人工原因

原因	数量	这类图意味着什么
OCR_TEXT_OCCLUDED	84	固定位置被大段文字覆盖，主体不可安全识别
SCENE_MISMATCH	63	Scene classifier 或时间段把错误页面送到当前 crop layout
HERO_SELECTION_NON_HERO	34	英雄选择页面的 slot 没有形成可识别英雄 crop
TOOLTIP_OCCLUDED	13	Tooltip 覆盖目标区域

Annotation database 里其他 scene、unknown、transition 和 empty 记录仍然保留。它们没有被删除；只是当前这份 icon-crop snapshot 中，满足本次 USER_CONFIRMED export contract 的 reject crop 最终落在上面四个原因。

7. VALID 与 REJECT 实际长什么样

下面八张图直接来自冻结 snapshot。它们不是为了展示模型效果，而是让审阅者确认任务定义。

VALID Hero	VALID Main Skill	VALID Artifact	VALID Creature
Hero crop 不只是干净立绘，还包含圆框、背景和等级。	主技能比 hero 小，压缩与边框更明显。	Artifact 的真实图标与透明 catalog 素材有明显 domain gap。	Creature crop 更大，包含地台、数字和动态背景。

文字遮挡	场景不匹配	英雄页非英雄	Tooltip 遮挡
OCR/text overlay 已经淹没身份像素。	固定坐标本身没错，但当前根本不是目标页面。	它不应该被硬分类成 77 个英雄之一。	Tooltip 是一种可重复出现的 validity failure。

这也解释了为什么单纯使用“最大 softmax 概率低于阈值”可能不够：有些纯文字或空白区域仍可能碰巧让某个英雄类别非常自信。Validity head 的任务是直接学习“这是不是一个可用图标 crop”。

8. 数据拆分与重复审计

Snapshot 以 source video 为最小隔离单位：来自同一录像的相邻 frame 不会被随机打散进 train 和 validation。

Partition	Crop 数	Source video	用途
Train	1,297	14	M1/M2 训练
Validation	348	1	checkpoint 与 threshold selection
Safety validation	101	1	固定 operating point 的开发安全检查
Final test	0	0	被明确阻塞

旧 V5 所谓的 holdout 已经被多次人类查看并影响开发决策，因此在 B04 中改名为 safety_validation。它仍然有价值，但不再冒充无偏的 publication test。

为什么 final test 是空的

当前 16 个本地 reviewed video 都在 V1–V5、数据标注或人工故障分析中被看过。把其中任意一个重新命名为 final test 只会制造一种形式上的干净。B04 选择显式失败：没有新录像，就没有 final-test metric。

重复样本审计

• 发现 21 个 exact duplicate groups；没有 exact duplicate 跨 partition。
• 发现 146 个 perceptual-near-duplicate groups；其中 38 个跨 partition。
• Perceptual audit 使用 dHash，它可能把不同 UI crop 错当成近重复，因此不会自动删掉人工确认图像。

这 38 组是正式训练前必须处理的风险：如果它们确实是同一视觉事件，validation 会过于乐观；如果只是 dHash 对深色 UI 的 false merge，自动删除又会损失真实多样性。正确动作是产生一份人工可看的 duplicate review，而不是让脚本替人做标签判断。

9. 模型为什么拆成三个 head

科学配置使用 ImageNet-1K 预训练 ConvNeXt-Tiny，输入为 224×224 RGB。Backbone 输出共享视觉 embedding，后面有三种责任不同的 head。

图 4。Validity、type 和 identity 是分开的任务；不存在把 REJECT 当第 355 个身份的 global softmax。

1. Validity head 输出一个 logit，回答 VALID 还是 REJECT。
2. Type head 输出四个 logits，回答 Hero、Skill、Creature 或 Artifact。
3. Type-specific identity heads 每个类型一个，输出数目由 snapshot taxonomy 动态决定。

推理时先取得 type 概率，然后只在预测类型对应的 identity head 内取最大概率。分类 confidence 定义为 type confidence 与 routed identity confidence 的乘积；learned rejection 使用 validity probability。

Masked loss

对一个 batch，目标可能包含 −1，表示这个任务不应计算 loss：

• VALID crop：可以计算 validity、type 和对应 identity head 的 loss。
• REJECT crop：只计算 validity；type/identity target 都是 −1。
• M0/M1：λ_valid=0，validity head 不训练。
• M2：λ_type=λ_id=0，只有 validity head 的 weight 与 bias 两个 tensor 可训练。

这让 reject data 无法移动旧 identity boundaries，直接避免了旧 V5 的核心风险。

10. M0、M1、M2 分别回答什么

M0：Catalog-only classifier

M0 使用 catalog 生成视图训练 type 和 identity。Catalog 图先按 alpha 裁紧，放到随机深色或中性色背景，再加入轻微旋转、位置偏移、亮度、对比度、饱和度和 blur。它建立一个不使用 gameplay training pixels 的基线。

M1：加入人工确认的 VALID gameplay

M1 从与 M0 完全相同的初始化开始，保持同一 taxonomy、optimizer-update budget、learning-rate schedule 和 identity batch schedule。唯一核心变化是：当某个 identity 有 confirmed gameplay crop 时，采样器可以按 50% 目标比例从真实池抽图。

因此 M0→M1 的 paired change 才有资格回答：在已经覆盖的 identity 上，真实 gameplay positives 是否帮助 domain transfer？

M2：只训练 learned validity gate

M2 从 validation 选中的 M1 checkpoint 初始化，然后冻结 backbone、type head 和全部 identity heads，只训练 validity head。Batch 在 VALID/REJECT 之间平衡，并轮换 reject reason 与 source video。

M2 不负责“修正具体 identity”。它只比较两种拒识方式：

• G1：使用 M1 的 classification confidence 设阈值；
• G2：使用 M2 的 learned validity probability 设阈值。

控制项	M0	M1	M2
Backbone	ConvNeXt-Tiny	与 M0 同初始化	从最佳 M1 读取并冻结
Catalog	使用	使用	作为 validity positive 可采样
VALID gameplay	不训练	训练	validity positive
REJECT gameplay	不训练	不训练	validity negative
Type/identity loss	开启	开启	关闭
Validity loss	关闭	关闭	开启
研究问题	Catalog baseline	Real positives 是否提高分类	Learned gate 是否提高拒识

11. 怎样保证 M0 与 M1 比较公平

历史 V5 的一个实际 bug 是：每个 identity 总取真实池的前 12 张，导致 225 个可用 crop 永远不被看见。B04 的 sampler 因此把“模型到底吃过什么”当成一级实验产物。

Identity-first schedule

M0/M1 先生成完全相同的 identity 序列，再各自从对应数据池取图。每个 epoch 会对 identity 做 deterministic shuffle；catalog 和 gameplay pool 都按 epoch 与 draw count 轮换。M1 的 gameplay_fraction 决定当前 identity occurrence 是否从 gameplay pool 抽样，但不会改变这个 batch 应该训练哪个 identity。

每个 epoch 保存：

• 每个 batch 的 sample IDs、identity IDs、domain 与 validity；
• 每个 domain 的总 draw 与 unique sample 数；
• 每个 identity 的 draw 数；
• 未被消费的 gameplay sample IDs；
• replacement draw count。

固定 optimizer updates，而不是只固定 epoch

正式配置让 M0 与 M1 都运行 12 × 356 = 4,272 个 optimizer updates，每个 batch 32 张。这样不会因为 M1 数据池更大就顺便获得更多更新次数。

Nested small-vs-large 输入

额外构建了一份尚未训练的单变量清单：

Arm	Crop 数	Identity	Identity-video cells
Small	118	44	59
Large	472	44	59

Small 是 Large 的严格子集；两边使用相同 identity 和相同 source-video cells。正式 ablation 还必须固定 optimizer updates 与 identity schedule。这样测试的是“同一支持范围内每个 identity 有更多样本是否有帮助”，而不是把数据量、类别覆盖和视频多样性同时改变。

12. 怎样评价分类与拒识

只报告一个 overall accuracy 会重复旧审计的问题。B04 输出四层指标。

分类指标

• Type accuracy：四种视觉类型是否预测正确。
• Within-type identity accuracy：假设类型已知，在正确 identity head 内是否预测正确。
• Joint accuracy：预测类型和最终 routed identity 都正确。
• Macro identity accuracy：先对每个 identity 算准确率，再平均，避免大量重复 crop 支配总体数字。
• Macro video accuracy：先按录像计算，再平均，用来发现某段录像集中失败。
• Covered vs catalog-only：分别报告有 gameplay train positive 和只有 catalog supervision 的 identity。
• Confusion tables：保存 type 与 identity 的具体混淆方向。

Validity 指标

• AUROC 与 AUPRC：不固定阈值时，VALID 是否总体排在 REJECT 前面。
• Balanced accuracy：VALID accept recall 与 REJECT recall 的平均值。
• False accept rate：无效 crop 被放行的比例。
• False reject rate：有效 crop 被错误拒绝的比例。
• 按 reject reason 与 source video 分组的 operating point。

Threshold 只在 validation 上选择：先最大化 balanced accuracy；平手时优先更高 VALID recall，再优先更高阈值。这个阈值随后冻结到 safety validation，不允许根据 safety 结果回头改。

End-to-end 指标

一个样本只有在以下两种情况之一才算最终正确：

• REJECT 被拒绝；
• VALID 被接受，而且 type 与 identity 都正确。

报告同时给 coverage、valid coverage、被接受 VALID 中的 selective identity accuracy 和 overall end-to-end accuracy。M0 与 M1 还按 sample ID 做 paired comparison，逐张列出 improvement 与 regression，而不是只看两个总体百分比。

13. Smoke run 实际证明了什么

Smoke run 使用 64×64 输入、测试专用 tiny CNN、一个随机种子，并且每个 M0/M1/M2 阶段只有一个 batch、一次 optimizer update。它在 RTX 5080 上总计数秒完成。

它成功验证的工程不变量

• M0 与 M1 的初始 state 完全一致；
• M0 实际读取 catalog sample；
• M1 同时走过 catalog 和 gameplay sampling path；
• M2 只有 validity head 的 weight 与 bias 两个 tensor 可训练；
• 每个 epoch checkpoint 都写出 model、optimizer、scheduler、resolved stage config 和 trainable parameter names；
• sample records、consumption、validation selection、逐 partition predictions 与 metrics 都成功落盘；
• report generator 成功产生 Markdown 与 SVG loss curve；
• final test 为空时，report 明确输出 blocked，而不是显示一个虚假的 0%。

为完整审计而列出的 smoke 数值

Stage / gate	Partition	Joint identity	Balanced validity	VALID recall	REJECT recall	E2E accuracy
M0 / confidence	Validation	0.0000	0.5907	0.2340	0.9474	0.0517
M0 / confidence	Safety validation	0.0000	0.7043	0.4086	1.0000	0.0792
M1 / confidence	Validation	0.0000	0.5644	0.2340	0.8947	0.0489
M1 / confidence	Safety validation	0.0000	0.7043	0.4086	1.0000	0.0792
M2 / learned validity	Validation	0.0000	0.5076	0.0152	1.0000	0.0546
M2 / learned validity	Safety validation	0.0000	0.5000	0.0000	1.0000	0.0792

这些数字很差，而且应该很差：一个随机 tiny CNN 只更新一次，不可能学会 354 个 identity。把 0% joint accuracy 公开列出来，是为了让审阅者验证 report 的字段和数据流，而不是暗示这个模型方案失败。

14. 代码与数据验证

这次重构完成后的验证分层如下：

验证层	结果	它证明什么	它不能证明什么
Core Perception tests	149 passed	Annotation、crop、snapshot 等主系统没有新增 Python regression	不能证明网页所有交互在真实浏览器中正确
B04 tests	13 passed	Loss mask、routing、sampling、threshold、protocol 与 nested manifest 符合代码契约	不能证明模型在真实数据上泛化
B03 compatibility	11 passed	历史 detector 仍能加载 legacy V1 classifier	不能改写 B03 的历史科学结论
Python compile check	Passed	主 core、B03 compatibility 与 B04 都能 import/compile	不等于端到端训练正确
Snapshot independent verify	2,136 samples / 2,148 files	冻结目录完整、可读、manifest 与物理文件一致	不证明人工标签本身绝对无误
Review UI test baseline	56 passed / 19 pre-existing failures	重构没有增加既有 UI test failure	19 个旧失败仍需要独立清理

B04 tests 特别覆盖以下易错点：

• REJECT 不产生 type/identity loss；
• routed prediction 使用预测 type 对应的 identity head；
• M2 冻结除 validity head 外的所有参数；
• M0/M1 identity schedule 相同；
• gameplay pool 会跨 epoch 轮换；
• M2 batch 同时覆盖 validity、reason 和 video；
• threshold tie-breaker 符合预定义顺序；
• small manifest 是 large 的严格子集；数据不足时 fail closed。

每次正式 run 会留下什么

每个随机种子、每个阶段都保存：

• resolved config 与环境信息；
• 每个 epoch checkpoint；
• optimizer 与 scheduler state；
• 初始模型状态标识和 trainable parameter names；
• 每个 batch 的 sample records；
• sampler consumption；
• validation selection score；
• validation、safety-validation、final-test 的逐样本 prediction；
• classification、validity 与 end-to-end metrics；
• M0→M1 的 paired improvements/regressions；
• 自动生成的 Markdown report 与 loss curve。

机器可读的本篇审阅数据包含本文所有聚合数字、配置、smoke 指标、风险和外部审阅问题：

下载 Experiment 4 review data（JSON）

原始视频、完整 annotation database、2,136 张 snapshot 图片和模型 checkpoint 没有上传到公开站点。本文公开的是实验统计、代表 crop、协议和结果数据；这既足够让 GPT 审查实验逻辑，也避免把大型本地数据与私人工作目录当成网页附件。

15. 已知限制与风险

1. 正式实验还没有运行

experiment.json 定义五个随机种子、ImageNet ConvNeXt-Tiny 和完整训练预算，但当前状态仍是 IMPLEMENTED_SMOKE_ONLY_FINAL_BENCHMARK_NOT_RUN。本文没有 M0/M1/M2 的均值、方差、confidence interval 或 winner。

2. 没有 untouched final test

这是最重要的发布限制。Validation 用于 checkpoint 与 threshold；safety validation 已经被开发过程观察过。正式论文式结论需要一组新录制、训练前封存的视频。

3. Gameplay identity coverage 不完整

1,552 个 VALID crop 只覆盖 112/354 identity，而且 Hero/Main Skill 占 95%。如果全量训练让有真实 positive 的类别变强，却让 catalog-only 类别退化，overall accuracy 可能掩盖这种不对称。因此报告必须分别给出 gameplay-covered 与 catalog-only identity 的 macro 指标。

4. Artifact 与 Creature 太少

Artifact 只有 57 个 gameplay crop，Creature 只有 30 个。即使 overall joint accuracy 上升，也不能立即声称四种类型都得到稳定改善。第一轮正式结论可能应只对 Hero/Main Skill 成立，把另两类保留为探索性结果。

5. Perceptual duplicate policy 尚未人工确认

38 个 near-duplicate group 跨 partition。直接保留可能泄漏；直接删除可能因 dHash false merge 损失多样性。正式 run 前应先生成可视化审阅页面并冻结处理决定。

6. M2 的表示可能仍然太弱

只训练 linear validity head 的优点是不会破坏 identity，但它也假设 M1 embedding 已经把“有效图标”和“复杂 reject”分开。如果结果不够好，下一步可以比较小 adapter、low-rank update 或带 distillation 的 joint training；不能未经验证就解冻整个 backbone。

7. 统计单位不是独立 crop

相邻 frame 的 crop 高度相关。即使去重以后，不能把 348 个 validation crop 当成 348 次完全独立实验。正式报告应按 video 或连续 track 做 clustered bootstrap，并同时报告 micro crop、macro identity 和 macro video。

16. 下一轮正式实验与希望 GPT 审阅的问题

在运行完整训练之前，建议按下面顺序继续：

1. 录制至少一批完全未看过的本地视频，并在任何训练前冻结为 final test；
2. 对 38 个跨 split near-duplicate groups 做人工审阅；
3. 冻结最终 dataset version、taxonomy 与 full config；
4. 跑 M0/M1/M2 的五个预定义随机种子；
5. 先根据 validation 选择 checkpoint 和 threshold；
6. 在 safety validation 上做开发安全分析，但不反向调参；
7. 最后一次性打开 final test；
8. 自动生成 paired regressions、per-identity/per-video 指标与 clustered uncertainty；
9. 再决定是否把 B04 模型变成 production classifier。

这份第一版特别希望外部 GPT 审阅以下问题：

1. M0/M1 是否已经足够严格地隔离“加入 verified gameplay positives”的因果效应？
2. 除 identity schedule 外，是否还应该预先固定 augmentation random stream？
3. M2 只训练 linear validity head 是否过于保守？如果增加 adapter，怎样证明不会损害 identity？
4. 38 个跨 split perceptual groups 应采用什么人工审阅和排除规则？
5. 对相邻录像 crop，哪一种 clustered bootstrap 或 hierarchical confidence interval 最合适？
6. 新 final-test 至少需要多少录像、identity 和 reject reason，才能支持 Hero/Main Skill 结论？
7. Artifact 与 Creature 是否应该暂时排除在第一轮 headline claim 之外？

可复现命令

以下命令从 repository root 执行。它们使用普通可读的 snapshot 和 run 名称；目标目录存在时会失败，不会覆盖旧实验。

$env:PYTHONPATH = "perception/src"
.\.venv\Scripts\python.exe perception/scripts/export_verified_crop_snapshot.py `
  --config perception/experiments/b04_verified-gameplay-icon-classifier/configs/snapshot-verified-gameplay-2026-08-31.json `
  --snapshot-id verified-gameplay-crops-2026-08-31 `
  --dry-run

.\.venv\Scripts\python.exe perception/scripts/export_verified_crop_snapshot.py `
  --snapshot-id verified-gameplay-crops-2026-08-31 `
  --verify

完整训练命令已经准备好，但在获得全新 final-test video 与完成 duplicate review 之前不应执行：

$env:PYTHONPATH = "perception/experiments/b04_verified-gameplay-icon-classifier/src"
.\.venv\Scripts\python.exe -m verified_icon_classifier.cli train `
  --config perception/experiments/b04_verified-gameplay-icon-classifier/configs/experiment.json `
  --run-id full-five-seed-after-final-test-freeze `
  --device cuda:0

结论

B04 没有试图用一个新模型名字掩盖旧 V1/V5 的混乱。它先把稳定的数据系统和仍在研究的 classifier 分开，再把 390 张 catalog 素材、1,552 张人工确认 VALID crop 和 194 张人工确认 REJECT crop 冻结成一份可审计 snapshot。模型也不再使用一个 global softmax 同时承担 identity 与 rejection，而是把 validity、type 和 type-specific identity 分成明确责任。

当前最重要的结果不是 accuracy，而是实验终于能够回答一个清楚的问题：在相同初始化、更新预算和 identity schedule 下，verified gameplay positives 是否改善真实 crop 分类；在不改变 identity heads 的前提下，learned validity 是否优于 confidence rejection。

工程链路已经通过测试与 smoke verification。科学答案仍然欠缺两个条件：人工处理跨 split near duplicates，以及一组真正未见过的新录像。在这两个边界解除之前，拒绝宣布 winner 比给出一个看似完整的百分比更有价值。

附录：16 个录像在冻结 snapshot 中的 crop 数

Source video	Crop 数	Partition
QQ20260804-151259	348	Validation
QQ2026730-14939	101	Safety validation
QQ2026730-1273	109	Train
QQ2026730-202130	159	Train
QQ2026730-204448	75	Train
QQ2026730-211354	93	Train
QQ2026730-21210	117	Train
QQ2026730-213736	78	Train
QQ2026730-221734	201	Train
QQ2026730-2322	66	Train
QQ2026731-23122	108	Train
QQ202683-22543	225	Train
Recording-2026-08-30-155825	24	Train
ScreenRecording-2026-08-22-214131	3	Train
ScreenRecording-2026-08-26-214535	12	Train
ScreenRecording-2026-08-30-151540	27	Train