交付前质量核对
报告交付前要做一次系统性核对：摘要数字与正文是否一致、每条发现能否回指证据编号、哈希清单与附件是否一一对应、敏感信息是否脱敏、版本号与修订记录是否吻合、签章与声明是否齐全。核对通过后再冻结交付件。
基本信息
| 核对项 | 数字一致、证据回指、哈希对应、脱敏抽查、版本一致、签章齐全 |
|---|---|
| 核对范围 | 正文、附表、附录与附件全部纳入 |
| 冻结方式 | 对交付件计算哈希并与版本号绑定 |
| 抽查方式 | 敏感信息按条目比例随机抽查 |
| 责任 | 核对人签字确认核对结果 |
| 归档 | 核对清单随报告一并归档 |
典型使用场景
- 交付前的最终质量把关
- 多人协作时统一检查口径
- 回应委托方对报告细节的质询
- 归档时确认材料齐全无缺项
- 复盘时定位常见错误类型
最小示例
最小示例
# 冻结交付件并计算哈希
ls /case/2026-001/deliverables/
sha256sum /case/2026-001/deliverables/report-v2.0.pdf | tee /case/2026-001/deliverables/report.sha256
# 核对附件数量与哈希清单条目数
ls /case/2026-001/deliverables/attachments | wc -l
wc -l /case/2026-001/deliverables/report.sha256
# 抽查是否残留未脱敏信息
grep -nE '[0-9]{11}|@[a-z0-9.-]+\.[a-z]{2,}' /case/2026-001/deliverables/report-v2.0.txt | head核对项与后果
| 核对项 | 检查方式 | 不通过的后果 |
|---|---|---|
| 摘要与正文数字 | 逐项比对 | 读者按摘要引用后与正文矛盾 |
| 发现与证据回指 | 核对编号 | 结论无法追溯 |
| 哈希清单 | 与附件逐一对应 | 无法证明材料未被替换 |
| 脱敏情况 | 按比例抽查 | 泄露个人信息与凭据 |
| 版本与修订记录 | 比对版本号 | 交付版本无法确认 |
| 签章与声明 | 核对是否齐全 | 文件形式要件不合格 |
冻结哈希的用途是确认对方收到的确实是同一份文件；交付件冻结后如需修改，必须升版本并重新计算哈希。
核对清单本身也要归档，它是质控过程的记录，可在被质询时说明检查范围与执行人。
附件补充或替换后要同步更新哈希清单，否则清单与实际交付件会脱节。
核对过程中不要把正文反复复制到临时目录编辑：容易产生多个近似版本，最终发错文件。