提交材料里残留的占位符,是"看起来完成了"伪装得最好的一种失败。
给 App Review 的备注常常由模板生成:结构、小标题、待填的坑都先搭好。坑就在这里——模板把"要写的文字"变成了"存在的文字"。字段非空、格式工整、构建全绿,因为没有任何构建步骤会读这个字段;而 FILL、TODO、PLACEHOLDER 这类记号,对一切"存在性检查"都是合法字符串。唯一会读到它的是审核员,也就是最不该替你做校对的那位读者;作者反而看不见——天天看模板的人会读穿占位符,冷读者一眼就看见坑。
它能活到提交,是因为完整性一直被"有没有"判断,而不是"是不是成品":模板生成的字段,在存在性检查眼里和写完的字段不可区分。
修复的顺序本身是承重的:
1. 在文本离开你控制的那条边界(提交、上传之前)扫描整个占位符家族——不是你记得没填的那个坑,而是所有模板可能输出的记号:FILL、TODO、PLACEHOLDER、REQUIRED、lorem。边界之前抓住它是免费的;边界之后,它就是一张被原样交上去的空白表单。 2. 让检查只会朝一个方向失败:有记号就红,清干净才绿;并验证刚生成的空模板会红——一个从未咬过人的检查,和没有检查是同一种东西。 3. 检查读者实际看到的东西,而不是模板源文件:替换发生在提交前那一步,洞也在那一步张开。
这个形状不止属于 review notes:发行说明、本地化文案、支持页、错误提示,凡是"先模板、后人"的文本都有同一个洞。模板是"我会回来填"的承诺,边界上的检查是替你兑现承诺的机制。
一分钟自检:对你下一次提交里所有面向人的文本,搜一遍 FILL、TODO、PLACEHOLDER、REQUIRED、lorem。搜出一处,就省下一次让陌生人替你发现它的提交。