审核规则对交互与文案有实际约束
别名: 审核约束交互 · store review constraint · 上架规则约束
概念解释
应用商店把「能不能上架」写成一套审核员可执行的规则。这些规则直接限制按钮怎么写、价格在哪出现、权限何时询问、外链能不能绕开付费——它们不是法务附录，而是交互与文案的硬边界。被挡住的不是品牌调性，而是陌生人在审核设备上走得通的路径。这个约束叫审核约束的交互（review-constrained interaction）：团队以为自己在设计体验，实际上同时在设计一份给审核员核对的可达界面。
它和「上架之后用户会不会投诉」不是一回事。投诉发生在已经进入货架的产品里；审核发生在二进制还进不了货架的时候。因此文案夸大、价格藏进二级页、按钮把连续扣费说成一次性购买，在审核语境里首先是交互失败。
机制
审核员拿到的是安装包、截图和一份检查清单，不是产品需求文档。清单上的条目只能落到看得到、点得到的东西上：屏幕上的句子、按钮标签、标价、系统权限对话框、跳转是否真的离开商店支付。交互一旦把关键信息推迟、藏进设置、或用含糊动词带过，清单就对不上，驳回就发生。
约束之所以「实际」，是因为发布通道是单点的：过不了审核，流程再自洽也不进入用户设备。设计决策因此被分成两类——审核员走得到的，和走不到的。走不到的内部实现、服务器开关、灰度实验，对审核不构成证据。走得到的每一句文案和每一步跳转，都在替产品承担规则风险。文案是承诺，按钮是承诺，空状态也是承诺。
边界
不经过商店分发的内部包、企业签名应用、纯网页产品没有这套闸门；它们仍可能受别的合规约束，但机制不同。已经上架、仅热更新文案的产品，若通道允许跳过二进制审核，约束会变弱，但不能假设所有商店都允许。游戏、流媒体、面向儿童的应用往往另有清单，不能把消费级工具应用的经验直接搬过去。同一产品在不同商店面对不同清单，通过一家推不出另一家也安全。
怎么落地
- 把付费、账号、权限、外链、用户生成内容这些路径当成审核员会走的主路径，而不是「设置里的细节」。
- 每个会说话的按钮和标题，核对其字面意思与下一步真实行为是否同一件事；不能用「立即开始」去启动扣费。
- 提交前用未登录、无购买记录、权限全关的设备把首次会话走一遍，只看屏幕，不看后台配置。
- 验证：找一个没读过需求文档的人，按商店公开的审核说明走完核心任务；任何「其实后台不是这样」的解释，都记为可见界面与规则对不上。