研发过程审计准备阶段，证据目录的作用是把散落在需求、设计、代码、测试、发布各环节的记录，整理成可逐条核对的清单。本文提供一套可直接复制使用的空白表格，包含证据编号、检查项、流程阶段、来源、责任人、时间、存放位置、版本校验和完整性判断等字段，并按六类材料给出归集范围、必填规则和一条完整填写示例，帮助研发与质量角色在审计前统一口径。
要点总览（TL;DR）
- 证据目录按“一条证据一行”组织，核心字段包括证据编号、检查项编号、审计检查项、流程阶段、证据名称与类型、来源系统或文档、产生时间、责任人、存放位置、版本或校验值、完整性判断和有效性判断。
- 材料按需求与立项、设计与评审、编码与代码评审、测试与缺陷、发布与变更、问题与整改六类归集，每类保留原始记录和审批痕迹。
- 影响定位和判断的字段设为必填；无法取得的必填信息填“待补”并写明原因，证据缺失时在完整性判断中显式标注，不用空白代替。
- 目录随需求评审、设计关闭、代码合入、测试报告出具、发布完成、整改验证等节点更新，审计前做完整性自查和版本冻结。
可复制空白证据目录模板
证据目录按“一条证据一行”组织，主表用于登记每条证据的标识、定位、责任与质量信息；分阶段材料清单用于按流程阶段规划应归集的材料范围。两张表配合使用：先按材料清单确定每个阶段要收什么，再逐条登记到主表。
主表：证据目录登记表
| 证据编号 | 检查项编号 | 审计检查项 | 流程阶段 | 证据名称 | 证据类型 | 来源系统或文档 | 产生时间 | 责任人 | 归档时间 | 存放位置 | 版本或校验值 | 完整性判断 | 有效性判断 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EV-____-___ | CHK-___ | 完整／部分缺失／缺失 | 有效／待确认／失效 | |||||||||||
证据编号建议采用“阶段代码-检查项序号-流水号”的结构，例如“DES-03-002”表示设计阶段第3个检查项的第2条证据。阶段代码可自行约定，如REQ（需求与立项）、DES（设计与评审）、COD（编码与评审）、TST（测试与缺陷）、REL（发布与变更）、FIX（问题与整改）。编号一经分配不再复用，作废证据保留编号并在备注中说明。
分阶段材料清单（空白）
| 流程阶段 | 应归集材料 | 材料形式 | 是否已归集 | 对应证据编号 | 缺口说明 |
|---|---|---|---|---|---|
| 需求与立项 | 文档／系统记录／审批单 | 是／否 | |||
| 设计与评审 | 文档／会议记录／审批单 | 是／否 | |||
| 编码与代码评审 | 系统记录／评审意见 | 是／否 | |||
| 测试与缺陷 | 系统记录／测试报告 | 是／否 | |||
| 发布与变更 | 审批单／发布记录 | 是／否 | |||
| 问题与整改 | 问题单／整改报告 | 是／否 |
字段说明：每个字段记录什么、怎么填
字段口径需要在模板中先定义清楚，再由不同角色按同一规则填写。下表按标识、定位、责任与时间、质量四组说明各字段的含义、填写口径和常见错误。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 证据编号 | 证据在目录中的唯一标识 | 按约定规则生成，一条证据一个编号，不复用 | 多条证据共用一个编号；补录时重新编号导致前后不一致 |
| 检查项编号 | 对应审计检查清单中的条目编号 | 与审计方案中的检查项一一对应，便于按检查项汇总证据 | 只写检查项名称不写编号，汇总时无法对齐 |
| 审计检查项 | 该证据要支撑的具体检查要求 | 摘录检查项原文或概括为一句可判断的表述 | 写成笼统的“过程规范”，无法判断证据是否支撑 |
| 流程阶段 | 证据产生于研发流程的哪个阶段 | 从需求与立项、设计与评审、编码与代码评审、测试与缺陷、发布与变更、问题与整改中选一 | 一条证据跨多个阶段时随意填写，未在备注中说明 |
| 证据名称 | 材料的具体名称 | 写可识别的名称，如“支付模块详细设计说明书” | 只写“设计文档”，同名材料无法区分 |
| 证据类型 | 材料的形态类别 | 文档、系统记录、审批单、会议记录、测试报告、问题单等 | 类型与来源不匹配，如系统记录标注为审批单 |
| 来源系统或文档 | 证据从哪个系统或哪份文档取得 | 写系统名称加模块，或文档名称加章节 | 只写“系统里”，审计时无法定位 |
| 产生时间 | 证据原始形成的时间 | 取记录创建或文档定稿时间，精确到日 | 用归档时间代替产生时间，掩盖补录情况 |
| 责任人 | 对该证据真实性负责的角色 | 写具体岗位或姓名，与审批记录中的角色一致 | 统一写部门名称，无法追溯到人 |
| 归档时间 | 证据纳入目录或归档库的时间 | 按实际归档日期填写，补录时如实标注 | 与产生时间混用，或统一填审计前日期 |
| 存放位置 | 证据的物理或系统路径 | 写目录路径、系统模块或档案盒编号 | 写“见附件”但附件未编号 |
| 版本或校验值 | 区分证据版本、验证文件未被替换 | 文档写版本号，系统导出文件写哈希值或导出批次号 | 只写“最新版”，无法确认审计时看到的是哪一版 |
| 完整性判断 | 证据是否齐备 | 完整、部分缺失、缺失三选一，部分缺失在备注写明缺什么 | 缺失也标“完整”，审计现场被推翻 |
| 有效性判断 | 证据是否在有效期内、是否经审批 | 有效、待确认、失效三选一，待确认注明待核实事项 | 把未审批的草稿标为有效 |
| 备注 | 补充说明 | 记录跨阶段情况、缺失原因、替代证据等 | 留空导致异常情况无解释 |
必填与选填：哪些字段不能空
必填字段的划分依据是“审计人员能否凭该行信息独立找到并判断证据”。凡是影响定位和判断的字段都应必填；用于补充说明的字段可按项目裁剪，但裁剪规则要事先写明。
| 类别 | 字段 | 理由或适用场景 |
|---|---|---|
| 必填 | 证据编号、检查项编号、审计检查项 | 没有编号和检查项，证据无法与审计方案对应，也无法汇总 |
| 必填 | 流程阶段、证据名称、证据类型 | 决定证据归入哪类材料，是分类归集和检索的基础 |
| 必填 | 来源系统或文档、存放位置 | 审计人员据此调取原始记录，缺一不可 |
| 必填 | 责任人、产生时间 | 确认证据归属和时间顺序，判断是否在流程节点内形成 |
| 必填 | 完整性判断、有效性判断 | 明确证据状态，避免把缺失或失效材料当作有效证据 |
| 选填 | 归档时间 | 证据即时登记时可与产生时间合并；集中补录时必须填写 |
| 选填 | 版本或校验值 | 文档类证据建议填写；系统记录若可凭记录ID定位，可只在关键证据上填写 |
| 选填 | 备注 | 无异常情况可留空；存在跨阶段、缺失、替代证据时必须填写 |
字段留空要遵循两条规则。第一，必填字段确实无法取得信息时，填“待补”并在备注写明原因和补录计划，不用空白代替。第二，证据本身缺失时，完整性判断填“缺失”，有效性判断填“失效”或“待确认”，同时在分阶段材料清单的“缺口说明”中登记，形成缺口台账。审计前应确保目录中不存在无说明的空白必填项。
填写示例：一条完整证据记录
以下示例为演示情景，用于说明字段之间的对应关系，不代表任何真实项目。
| 字段 | 填写内容 |
|---|---|
| 证据编号 | DES-03-002 |
| 检查项编号 | CHK-07 |
| 审计检查项 | 详细设计文档是否经过评审并留有审批记录 |
| 流程阶段 | 设计与评审 |
| 证据名称 | 支付模块详细设计说明书及评审记录 |
| 证据类型 | 文档＋审批单 |
| 来源系统或文档 | 项目文档库“支付模块/设计”目录；评审审批单编号 RV-2024-031 |
| 产生时间 | 2024-03-12 |
| 责任人 | 设计负责人（岗位） |
| 归档时间 | 2024-03-15 |
| 存放位置 | 文档库/支付模块/设计/v1.2；审批单存于流程系统归档区 |
| 版本或校验值 | 文档版本 v1.2；审批单导出文件校验值 a1b2…（示例） |
| 完整性判断 | 完整 |
| 有效性判断 | 有效 |
| 备注 | 评审意见中的2项修改已在v1.2中关闭，关闭记录见同一目录 |
逐字段核对时注意三点：证据类型“文档＋审批单”与来源中的文档库、审批单编号对应；产生时间早于归档时间，符合先形成后归档的顺序；完整性判断为“完整”的前提是设计文档与评审记录同时存在，若只有文档没有审批记录，应改为“部分缺失”并在备注写明缺审批记录。这条记录同时应出现在分阶段材料清单“设计与评审”一行，对应证据编号填 DES-03-002。
证据材料的分类归集与目录维护
材料按六个流程阶段归集，每类保留可追溯的原始记录和审批痕迹。归集范围可参考下表，具体材料名称按项目实际裁剪。
| 流程阶段 | 典型材料 | 需保留的痕迹 |
|---|---|---|
| 需求与立项 | 需求说明书、需求评审记录、立项审批单、需求变更单 | 评审结论、审批人、变更前后版本 |
| 设计与评审 | 概要设计、详细设计、设计评审记录、技术方案审批 | 评审意见及关闭情况、审批时间 |
| 编码与代码评审 | 代码提交记录、合并请求、代码评审意见、静态检查报告 | 提交人、评审人、合入时间、问题关闭记录 |
| 测试与缺陷 | 测试计划、测试用例、测试报告、缺陷单及修复记录 | 执行结果、缺陷状态流转、回归验证记录 |
| 发布与变更 | 发布申请、变更审批单、发布记录、回滚预案 | 审批链、发布时间、变更范围 |
| 问题与整改 | 审计或检查问题单、整改计划、整改验证记录 | 问题责任人、整改期限、验证结论 |
目录更新应跟随流程节点，而非等到审计前集中补录。需求评审通过、设计评审关闭、代码合入、测试报告出具、发布完成、整改验证通过，这些节点都是登记或更新证据的时机。每次更新记录归档时间，保留历史版本，避免覆盖式修改。
审计前自查分三步。第一步按分阶段材料清单逐项核对“是否已归集”，把未归集项转入缺口台账。第二步检查主表必填字段是否有无说明的空白，完整性判断为“部分缺失”或“缺失”的记录是否都有备注和补录计划。第三步做版本冻结：对目录和关键证据导出快照，记录冻结日期和校验值，冻结后新增证据单独登记并标注补录时间，保证审计人员看到的是同一份证据集合。
当研发工作项本身在项目管理系统中流转时，需求、任务、测试、发布记录会自然形成时间、责任人和状态痕迹，证据目录可以从这些记录中取数登记，减少手工整理。ONES 的项目与工作项记录可用于承载这类过程留痕，具体字段和导出方式需结合团队实际配置确认。目录字段和归集规则确定后，建议先在下一个研发节点试填一轮，再根据填写中的歧义修订字段口径，形成团队通用的版本。
常见问题
证据目录里的证据编号可以重复使用吗？
不建议重复使用。编号是证据在目录中的唯一标识，作废或替换的证据应保留原编号，在备注中说明作废原因和替代证据的编号。补录证据时按规则生成新编号，避免同一编号对应两份材料，导致审计时无法判断看到的是哪一份。
审计前发现某个必填字段确实拿不到信息，怎么处理？
填“待补”，并在备注中写明缺失原因和补录计划，同时把该记录转入缺口台账。必填字段用空白代替会让审计人员无法区分“没有这项信息”和“漏填”，两种情况在审计现场的处理方式不同，显式标注更便于后续跟进。
系统记录类证据需要填版本或校验值吗？
版本或校验值属于选填字段。文档类证据建议填写版本号；系统记录如果能凭记录ID或导出批次号稳定定位，可以只在关键证据上填写校验值。判断标准是审计人员能否确认自己看到的就是登记时的那份记录，能确认即可简化。
证据目录应该多久更新一次？
跟随流程节点更新，而不是审计前集中补录。需求评审通过、设计评审关闭、代码合入、测试报告出具、发布完成、整改验证通过，这些节点都是登记或更新证据的时机。每次更新记录归档时间并保留历史版本，避免覆盖式修改掩盖补录情况。
多个项目共用一套证据目录模板时要注意什么？
先统一下字段口径和编号规则，再分发使用。不同项目对“流程阶段”的取值、证据类型的分类容易各自发挥，导致汇总时无法对齐。建议在模板中固定阶段代码和证据类型选项，项目只填写具体内容；字段口径修订时统一发布新版本，并注明适用起始时间。
