# 2.3.3:截图逐尺寸审核,与审核设备无关

> 一条 2.3.3(Accurate Metadata)的拒审,后来解决了。值得记的不是这次提审,而是它暴露的盲区:审核在 iPad 上进行,被点名的却是 6.7 英寸 iPhone

- Canonical page: https://obelisk.club/blog/build-log-3030
- Author: Peter Zhang
- Published: 2026-10-11
- Tags: build-log

一条 2.3.3(Accurate Metadata)的拒审,后来解决了。值得记的不是这次提审,而是它暴露的盲区:审核在 iPad 上进行,被点名的却是 6.7 英寸 iPhone 那组截图——那组图没有展示应用实际使用的画面。

这件事能一路活到人工审核才被看见,机制上有三层:

一,上传只校验尺寸与格式,不校验内容。一张比例正确、内容却不是真实界面的图,机器层全绿;"是否真实在用"只有人能判。
二,截图是按尺寸分组的元数据,每组独立成立。非主力尺寸那组常常不是专门截的,而是从主力尺寸复用、拉伸、套框来的——尺寸检查能过,"准确"过不了。
三,自查的天然盲区:你反复看的是主力那组。而审核逐组看,与审核员手里拿的是哪台设备无关。

修复模式,顺序是承重的:

1. 先钉死"真实在用"的标准:该尺寸上应用真实运行的界面。可以有文案与说明,不能是营销拼图、启动画面或空内容占位。
2. 每个必需尺寸原生生成,不从母版缩放;逐组校验,和逐 locale 校验是同一条纪律——源对了,不等于每个镜像都对。
3. 提交前逐组打开图看内容。"导出跑完了"不等于"每组都对",正如"截图接口调用成功"不等于"截到的画面正确"——验证永远落在产物本身。
4. 留一份尺寸到来源的清单。必需尺寸会更新,下一轮要求变了,清单在手是一次重新生成,不是一次考古。

一分钟自检:打开截图管理页,对每个尺寸组问三个问题——比例是该尺寸原生的吗?画面是应用真实运行的样子吗?今天要重截,拿得出来吗?哪一组答不上,哪一组就是元数据里最弱的一环,而审核恰恰是逐组看的。

截图不是营销物料,是逐尺寸的元数据;每组各自对"准确"负责,这是 2.3.3 真正教人的那部分。