# 商店描述必须与送审包逐句对账

> 第一次送审,1.0 的包,撞上 Guideline 2.3.2(Accurate Metadata):审核意见说,商店元数据里提到了付费内容,而这和送审包实际提供的东西对不上。审核

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

第一次送审,1.0 的包,撞上 Guideline 2.3.2(Accurate Metadata):审核意见说,商店元数据里提到了付费内容,而这和送审包实际提供的东西对不上。审核设备是一台 MacBook Air——这些细节不重要,重要的是这类拒审的共同结构:文案描述的是"计划中的产品",送审的是"当下的包",中间没有任何东西在核对。

为什么它能一路隐形:商店文案活在提审表单里,不活在代码库里。构建系统验证的是二进制,没有任何自动化检查会去读 description,更不会把每一句承诺和包里的功能、可购买项逐条对上。所以"功能还在路上、描述先写好"的文案可以顺利活到审核那天,最后由一位真人审核员替你发现。这和"镜像悄悄失去同步"是同一类失败:description 本质上是二进制的镜像,而镜像的失败方式从来不是报错,是悄悄偏移。

修法按这个顺序做,顺序本身有讲究:
1. 先把 description 当合同看,不是营销材料——每一句都是对"这个包"的承诺,不是对路线图的承诺。心态不对,后面的对账做不下去。
2. 提审前逐句对账:功能型句子的界面要在包里找得到;付费型句子的内购项要已挂上、在这个版本里可买;对不上的删掉或推迟,而不是指望"下个版本就有了"。
3. 把重跑对账挂在每次版本号变更上。元数据漂移不是一次性事故,是每次发版都会重新长出来的东西。

一分钟自检:把商店描述和送审包并排放着。每一句承诺了某个能力或某笔购买的句子,在包里指出它的位置——一个界面,或一个能走完的购买项。任何一句只能匹配到"下个版本"的,改文案,别赌审核:审核的对象是包,不是计划。