R4.07.3store-rule drift设计
规则变化需要纳入设计的更新周期
别名: 审核规则漂移 · guideline drift · 商店政策更新
概念解释
商店写的规则会自己往前走。产品一个字没改，去年能过的付费墙、登录、权限开口，今年可能过不了。这种外部文本相对产品冻结版本的错位叫规则漂移（store-rule drift）。它要求设计像对待组件接口那样对待审核文本：有版本、有订阅、有人在周期里打开受影响的流程，而不是等驳回信当需求来源。
它回答的不是「哪些主题最常被拒」，也不是「规则会不会约束文案」——那两件事在规则静止时也成立。这里成立的是：规则是活的外部依赖，设计更新周期若不订阅它，交互会在沉默中过期。
机制
商店、支付通道和隐私立法不按产品发版日历行动。一条新解释、一次对「外部购买」的收紧、一次对追踪说明的改写，会让旧界面的字面承诺突然不合格。漂移的杀伤在于它不产生内部缺陷单：界面还是那几屏，测试还是绿的，唯一变了的是闸门另一侧的清单。
设计周期通常由视觉改版、功能需求和缺陷驱动。这三类信号都来自团队内部。规则漂移的信号来自商店发布说明、开发者邮件和公开的审核案例。若不把这路信号接进同一条更新管道，设计系统会继续迭代圆角，同时让付费墙带着过期承诺去排队。组件库有废弃公告，是因为调用方必须跟着迁；审核文本对交互的作用相同，只是发布方不是你们。
边界
不是每条商店新闻都值得改设计。纯属元数据、截图尺寸、加密算法的变更，交给工程与运营即可。已停止提交的产品没有周期可纳入。预览版或测试通道上的规则，在正式生效前当作观察项，不要把猜测写进主路径。不同商店的漂移日历互相独立：只盯一家会漏掉另一家已经改过的开口。漂移解释常有争议窗口，窗口期内用保守的可见承诺，而不是赌审核员站在宽松一侧。
怎么落地
- 指定一个角色订阅各目标商店的规则更新，把「可能碰到界面」的条目转成设计待办，而不是只开工程评估。
- 在设计日历里给付费墙、首次会话、权限开口留定期复查，即使当季没有功能需求。
- 规则文本一改，先标出仍在使用旧承诺的屏幕，冻结这些屏幕的视觉改版，直到文案与路径对齐新清单。
- 验证：把最近一次商店规则更新的日期写进设计变更记录，列出受影响的流程与是否已改。若更新发生在上次发版之后、列表却是空的，说明周期还没接上。用一次模拟提交核对：旧文案的屏幕是否仍出现在当前构建里。