走查清单
功能、体验、数据、安全，上线前逐条过。一份可以复用的走查清单和它的用法。
功能、体验、数据、安全，上线前逐条过。清单是给赶工的那个自己准备的——那时候你只会点自己最熟的那条路，而用户会在你上线的第一个小时里发现那个你从来没点过的按钮会白屏。
你会遇到的现象：
- 上线一小时内用户就发现了一个你从来没点过的按钮会白屏
- 发完才想起来空态没做，新用户进去看到的是一片空白
- 自测一直用同一个老账号，全新用户的第一步早就跑不通了
- 回滚了两次，两次的原因都在上一次说过「下次记得看」
四类，一份清单
把清单固定成四类，顺序也固定：功能 → 体验 → 数据 → 安全。前面塌了后面不用看，最后一类一票否决。
| 类别 | 逐条检查 | 怎么算过 |
|---|---|---|
| 功能 | 主流程从头到尾走通；每个异步位置的四态都在；失败之后能重试且不丢已填内容；超长内容和零条数据各跑一遍 | 不用你解释就能走完 |
| 体验 | 用全新账号完整走一次；窄屏看一遍；提示语说清了发生什么和下一步；危险操作可撤销；没有「测试」「TODO」这类占位文案漏在线上 | 陌生人不问你也知道该干什么 |
| 数据 | 关键事件都上报了；失败事件带原因；属性里有能关联的 id；看板或查询语句已经准备好 | 上线第一天就能看到曲线 |
| 安全 | 密钥和令牌不在前端代码里；换个账号试访问别人的数据；权限判断后端也做了一遍；用户输入在展示前做了转义 | 试着越权，试不成功 |
清单要短到你愿意每次都过。二十条以内、十五分钟能走完，才有可能变成习惯；写到五十条，第三次就没人看了。
怎么走这一遍
- **换一个全新账号。**老账号有历史数据，天然绕开了空态和首次引导，而这两个地方恰好是新用户最先看到的。
- **把窗口拉窄一次。**不需要真机，把浏览器拉到手机宽度，大部分布局问题会立刻暴露。
- **把网络调慢一次。**浏览器开发者工具里限速到 3G，加载态和超时处理有没有做，一眼就看出来。
- **走一次「错的路」。**故意填错、故意留空、故意连点两次提交，看它怎么回应。
- **边走边记，不要边走边改。**发现问题先记下来，走完再统一排。中途开始改代码，这一遍就废了。
哪些不过就不发
清单不是每条都同等重要。分两档，判断只需要几秒：
- **阻塞项 · 不过不发：**会丢数据、会扣错钱；能看到别人的数据；密钥泄漏在前端；主流程走不通；出错之后没有任何提示。
- **记进待办 · 可以先发：**窄屏下某个间距偏挤；空态的插画还没画；文案还能更顺一点；加载态是转圈不是骨架屏；埋点少了一个次要事件。
左边这五类的共同点：出了事用户会受损失，而且事后补不回来。右边的共同点：难看，但可以下一版再说。通用体验层面对照常用的十条可用性启发式过一遍，能覆盖大部分「忘了看」的情况；nng-heuristics安全那一类再单独对照 OWASP 的常见风险清单自查。owasp
交给 AI 先自查
如果代码是 AI 写的，让它先照着清单自查一遍，你再走一遍。它擅长发现「这里没处理错误分支」这类结构性遗漏，不擅长判断「这个提示语用户看不看得懂」。
PROMPT · 上线前自查
对照下面的清单检查刚才这个功能，逐条给结论，不要改代码。
## 功能
- 主流程能否走通；每个异步位置是否都有空、加载、出错、正常四态
- 失败之后能否重试，已填内容会不会丢
- 零条数据和超长内容各会怎样
## 体验
- 全新用户第一次进来看到什么
- 窄屏下布局是否还成立
- 出错时的提示是否说清了发生什么、下一步做什么
## 数据
- 关键事件是否已上报，失败是否带原因
## 安全
- 是否有密钥硬编码在前端
- 权限判断是否只做在前端
- 用户输入展示前是否转义
输出格式：每条给「过 / 不过 / 不确定」，不过的给出文件和行号。
不确定的单独列出来，我来人工看。
这份清单适合直接沉淀进项目的约束文件，让它每次交付前自己跑一遍，不用你每次重复。