清单怎么用才对
评审清单的作用是把注意力固定在容易漏掉的地方：错误路径、权限检查、迁移回滚这类平时不看、出事才痛的项。它是防遗漏的辅助工具，不是流程形式主义，也不替代对代码的理解。团队应当按自己的技术栈把清单裁剪成短小可执行的一页，并定期回顾失效条目。
基本信息
| 定位 | 防遗漏的辅助工具，不是形式化勾选流程 |
|---|---|
| 维护 | 按技术栈裁剪，定期回顾并删除失效项 |
| 分工 | 机器能查的（格式、静态检查）从清单里删掉，交给工具 |
| 使用方式 | 新手用完整清单，熟手用关键项兜底 |
写好清单的要点
- 条目要可检查：能回答是或否，而不是「注意保持良好设计」这类口号。
- 条目要短：一页以内，超出就会被跳过。
- 优先放高频且容易被忽略的项，例如错误处理与权限校验。
- 把已经交给工具的项删掉，清单只留需要人判断的部分。
- 每次出问题后回看清单：漏检的那一项该不该补进去。
有效清单与无效清单
| 特征 | 有效 | 无效 |
|---|---|---|
| 条目形式 | 可回答是或否的具体问题 | 口号式要求 |
| 长度 | 一页以内，按技术栈裁剪 | 几十条照抄通用模板 |
| 维护 | 随问题类型更新 | 长期不变，新风险一直漏检 |
| 用法 | 专注高风险项 | 逐格打钩但不看代码 |
短清单示例
短清单示例
# 按技术栈裁剪后的评审清单示例
# [ ] 错误分支是否被处理并留下可定位的信息
# [ ] 新接口是否挂了鉴权，能否访问他人的数据
# [ ] 配置与开关的默认值是否安全
# [ ] 数据迁移脚本能否重复执行
# [ ] 测试在改错实现时会不会失败清单的价值在于降低注意力波动，而不是证明「已按清单评审」。
删掉不适用于本项目的条目，比为了完整而强行保留更有价值。
团队可以把线上事故的根因转成清单条目：每一条清单背后最好都有一个具体教训或明确风险。