检查表怎么写
评审检查表把常见缺陷类型结构化为检查项，覆盖完整性、一致性、可测试性与可维护性等维度，用于在评审中快速筛查，而不是代替思考。检查表的价值来自持续更新：每次出现重大缺陷后问一句早知道该检查什么，把答案加进表里；同时定期删除无效项，保持精简。通用模板直接套用往往不贴合项目，效果不如从本项目缺陷历史中提炼出来的清单。
基本信息
| 结构 | 按维度分组：完整性、一致性、可测试性、可维护性、合规 |
|---|---|
| 来源 | 项目缺陷历史、行业规范、复盘结论 |
| 更新触发 | 重大缺陷、新增法规要求、季度复盘 |
| 使用方式 | 评审前分发给参与者，评审时逐项核对 |
| 常见问题 | 模板直接套用、长期不更新、项数过多 |
典型使用场景
- 需求评审前用检查表筛查边界与异常场景是否覆盖
- 设计评审前核对接口、依赖与容量假设是否说明
- 代码评审用检查表覆盖安全、异常处理与日志等易漏项
- 引入新法规或安全要求后，把合规检查点纳入清单
- 每周或每月复盘时，把新出现的缺陷类型补进检查表
检查表示例：需求评审
检查表示例：需求评审
# 1 是否描述业务背景与目标，含量化指标
# 2 输入输出与边界是否完整，异常场景是否覆盖
# 3 是否可测试，每项是否有验收准则
# 4 术语是否与既有系统与文档一致
# 5 依赖与约束是否说明更新机制
| 触发 | 动作 | 产出 |
|---|---|---|
| 出现重大缺陷 | 补充对应检查项 | 检查表版本更新 |
| 新增法规要求 | 纳入合规检查点 | 合规章节补充 |
| 季度复盘 | 删除无效项并精简 | 检查表瘦身 |
| 流程变化 | 调整对应检查维度 | 与流程文件同步 |
检查表来自复盘：每次重大缺陷问一句早知道该检查什么，把答案加进表里。
检查表长期不更新，会遗漏新出现的缺陷类型，评审随之流于形式。