# 4.2 的拒审值得记一笔，因为它是最难复盘的一种：没有任何东西坏掉

> 4.2 的拒审值得记一笔，因为它是最难复盘的一种：没有任何东西坏掉。 一个 1.0 的首提收到 Guideline 4.2 – Design – Minimum Functiona

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

4.2 的拒审值得记一笔，因为它是最难复盘的一种：没有任何东西坏掉。

一个 1.0 的首提收到 Guideline 4.2 – Design – Minimum Functionality，意见的实质只有一句：app 的用途被过少的功能限制住了。没有崩溃、没有缺失的资源、没有元数据问题——每一项工程检查都可以是绿的。

这正是它不可见的机制：你的检查度量的是"与规格一致"——构建、测试、界面还原度；而 4.2 是一个范围判决，审核员把 app 和用户设备上已经存在的一切放在一起读。"一个清单"这件事，系统自带的备忘录和提醒事项已经在一次点击以内做到了。任何以你自己写的规格为基准的门禁，都会原样继承规格的盲区；唯一以整个市场为基准的检查，就是审核本身。

修复的顺序（顺序是承重的）：

1. 先把它当定位判决读，不要当 bug 找。没有 defect 可修，"改进视觉设计"移动不了 4.2。
2. 重放审核员的前 60 秒：全新安装、空数据、第一屏。判决发生在那里，不在功能清单里。
3. 诚实回答"替代品问题"：这个 app 做了什么自带工具做不到的事——一句话，而且是陌生人能复述的一句话。有答案，就把它做成第一屏上的状态（进度、数字、下一步动作），而不是教程；没有答案，修复是能力而非打磨：把同一个用户在同一场景里紧接着要做的下一件事也纳入进来，让核心循环变厚。
4. 回复审核时用平实的语言写具体的、用户可见的能力：加了什么、在哪个界面、解决哪一步。"我们改进了设计"这种话读起来像回避。

一分钟自检：干净设备装上你的 build，用陌生人的眼睛看 60 秒，然后回答"为什么不用自带的备忘录？"如果答不出一句可复述的话，4.2 的暴露度就在那里，与内部有多少绿灯无关。

本地的质量分从来不是真人评审的代理指标，在 4.2 上这一点最纯。