研发审计记录模板按“一次审计一条主记录、一个审计发现一条子记录”组织：主记录固定审计对象、期间、依据、范围、执行人与结论，发现明细逐条登记问题、证据、风险等级、整改责任人与验证结果。本文先给出可直接复制的空白表，再说明字段口径、必填规则和一份完整填写示例，最后讲模板随流程调整与长期维护的方法，适合研发过程审计、节点评审和专项检查使用。
要点总览（TL;DR）
- 模板采用“一次审计一条主记录、一个发现一条子记录”的结构，两张表通过主记录编号关联，可直接复制到文档或表格工具使用。
- 主记录必填编号、名称、类型、对象、期间、依据、范围、执行人、结论和状态；发现明细必填编号、描述、证据位置、风险等级、整改措施、责任人、期限和状态。
- 必填字段缺失时记录停留在“草稿”，补齐后再变更状态；过程审计、节点评审、专项检查可按需调整必填项。
- 填写示例展示三条发现从登记、整改到验证关闭的完整闭环，主记录发现数量与明细逐条对应。
- 模板调整需升版本号并记录变更原因，归档后按编号、对象、期间和风险等级检索，每季度抽查记录完整性。
可复制空白模板：审计主记录表与发现明细表
模板由两张表组成。主记录表一次审计填一行，负责界定“审了什么、依据什么、谁执行、结论如何”；发现明细表一条发现填一行，负责记录“发现了什么、证据在哪、谁来改、改完怎么验证”。两张表通过主记录编号关联，明细表中的每条发现都指向唯一一次审计。
审计主记录表（空白）
| 字段 | 填写内容 |
|---|---|
| 主记录编号 | |
| 审计名称 | |
| 审计类型 | |
| 审计对象 | |
| 所属项目/产品 | |
| 审计期间 | |
| 审计依据 | |
| 审计范围 | |
| 审计执行人 | |
| 配合人员 | |
| 审计开始日期 | |
| 审计结束日期 | |
| 发现数量（高/中/低） | |
| 审计结论 | |
| 结论审批人 | |
| 记录状态 | |
| 备注 |
审计发现明细表（空白）
| 字段 | 填写内容 |
|---|---|
| 发现编号 | |
| 主记录编号 | |
| 发现描述 | |
| 对应审计依据条款 | |
| 证据位置 | |
| 风险等级 | |
| 影响说明 | |
| 整改措施 | |
| 整改责任人 | |
| 整改期限 | |
| 整改状态 | |
| 验证人 | |
| 验证日期 | |
| 验证结果 | |
| 备注 |
关联方式很直接：明细表的“主记录编号”填主记录表中对应的编号，例如主记录编号为“AUD-2024-014”，则该次审计下的每条发现都填这个编号。编号建议采用“前缀+年份+流水号”的格式，前缀区分审计类型，流水号按年度连续编排，避免不同项目重号。
复制到文档或表格工具时有几点格式提示：主记录表保持一行一次审计，不要在同一行里塞多次审计；明细表保持一行一条发现，发现描述较长时允许单元格内换行，但不要合并单元格，否则后续筛选和统计会失效；两张表放在同一文档的不同工作表或不同章节中，主记录表在前，明细表在后；表头行建议冻结，字段名不要随意改写，便于跨项目汇总时按列对齐。
字段说明：每个字段记录什么、取值怎么定
字段说明的作用是让不同执行人填出的记录可以横向比对。以下逐项解释主记录与发现明细的字段含义，并给出建议取值口径。
主记录字段说明
| 字段 | 记录内容 | 取值口径建议 |
|---|---|---|
| 主记录编号 | 本次审计的唯一标识 | 前缀+年份+三位流水号，如AUD-2024-014 |
| 审计名称 | 概括本次审计主题 | 对象+类型+期间，如“订单服务V2.3迭代过程审计” |
| 审计类型 | 区分审计性质 | 枚举：过程审计、节点评审、专项检查 |
| 审计对象 | 被审计的团队、项目或流程环节 | 写到可定位的层级，如“订单服务研发组” |
| 所属项目/产品 | 审计对象归属 | 与组织内项目命名保持一致 |
| 审计期间 | 被检查活动发生的时间段 | 起止日期，精确到日 |
| 审计依据 | 判断合规与否所依据的制度、规范或计划 | 写文件名称与版本号，如“研发过程管理规范V2.1” |
| 审计范围 | 本次覆盖的活动与交付物 | 列明纳入与排除项，如“覆盖需求评审至提测，不含上线发布” |
| 审计执行人 | 实施审计的人员 | 姓名，多人时列主执行人 |
| 配合人员 | 被审计方对接人 | 姓名及角色 |
| 审计开始/结束日期 | 审计工作实际起止 | 与审计期间区分，指执行动作的时间 |
| 发现数量 | 按风险等级统计的发现条数 | 高/中/低三档分别计数，与明细表核对一致 |
| 审计结论 | 对本次审计的整体判断 | 枚举：符合、基本符合、不符合、有条件通过 |
| 结论审批人 | 对结论负责的审核人 | 姓名及角色 |
| 记录状态 | 记录当前所处阶段 | 枚举：草稿、待审批、已归档 |
| 备注 | 补充说明 | 记录特殊情况，如范围临时调整 |
发现明细字段说明
| 字段 | 记录内容 | 取值口径建议 |
|---|---|---|
| 发现编号 | 单条发现的唯一标识 | 主记录编号+两位序号，如AUD-2024-014-01 |
| 主记录编号 | 关联的审计主记录 | 必须与主记录表一致 |
| 发现描述 | 客观陈述观察到的事实 | 写“什么时间、什么活动、缺了什么或做了什么”，不写评价性结论 |
| 对应审计依据条款 | 该发现违反或偏离的具体条款 | 引用依据文件的章节号，便于整改时对照 |
| 证据位置 | 支撑该发现的材料所在位置 | 写清系统、文档名、版本或记录编号，保证他人可复核 |
| 风险等级 | 发现的影响程度 | 枚举：高、中、低，按对质量、进度或合规的影响判定 |
| 影响说明 | 该发现可能造成的后果 | 简述受影响的交付物或环节 |
| 整改措施 | 计划采取的纠正动作 | 写具体动作与产出物，避免“加强管理”一类表述 |
| 整改责任人 | 对整改结果负责的人 | 姓名，一人一条，避免多人共担 |
| 整改期限 | 完成整改的目标日期 | 具体日期，与风险等级匹配 |
| 整改状态 | 整改进展 | 枚举：待整改、整改中、待验证、已关闭 |
| 验证人 | 复核整改结果的人 | 建议由审计执行人或其指定人员担任 |
| 验证日期 | 完成验证的时间 | 具体日期 |
| 验证结果 | 整改是否有效 | 枚举：通过、部分通过、不通过 |
| 备注 | 补充信息 | 记录延期原因、复验情况等 |
字段之间存在明确的引用关系：明细表的“主记录编号”引用主记录表；“对应审计依据条款”引用主记录“审计依据”所指文件中的具体条款；“发现数量”由明细表按风险等级汇总得出，填写主记录时应与明细表逐条核对。保持这些引用一致，记录才能在主记录与明细两个层面互相印证。
必填与选填：哪些字段缺失会导致记录不可用
必填字段决定记录能否成立。缺少主记录编号、审计对象、审计期间、审计依据、审计范围、执行人和结论中的任何一项，这条记录都无法说明审了谁、依据什么、结论如何，应视为不可用。选填字段用于补充说明，缺失不影响记录的基本效力。
| 表 | 必填字段 | 选填字段 |
|---|---|---|
| 主记录 | 主记录编号、审计名称、审计类型、审计对象、审计期间、审计依据、审计范围、审计执行人、审计结论、记录状态 | 所属项目/产品、配合人员、审计开始/结束日期、发现数量、结论审批人、备注 |
| 发现明细 | 发现编号、主记录编号、发现描述、证据位置、风险等级、整改措施、整改责任人、整改期限、整改状态 | 对应审计依据条款、影响说明、验证人、验证日期、验证结果、备注 |
必填字段缺失时，记录状态应停留在“草稿”，不得进入“待审批”或“已归档”。若审计已实际完成但某项必填信息暂时无法取得，应在备注中写明缺失原因和补录计划，并在补录完成后再变更状态。发现明细缺少证据位置或整改责任人的，该条发现不能标记为“待验证”，避免整改无人承接或无法复核。
不同审计类型可以调整必填项。过程审计通常需要完整的审计期间和范围，因为要覆盖一段持续活动；节点评审的期间往往就是评审节点当天，可弱化期间精度，但必须保留评审对象和评审依据；专项检查范围较窄，可把“所属项目/产品”提升为必填，便于按主题归集。调整时遵循一个原则：凡是影响结论成立和整改追踪的字段保持必填，仅用于描述背景的字段可设为选填，并在模板版本记录中注明调整原因。
填写示例：一次迭代过程审计的完整记录
以下示例为演示情景，展示各字段如何落地，数据仅用于说明填写方式。
主记录示例
| 字段 | 填写内容 |
|---|---|
| 主记录编号 | AUD-2024-014 |
| 审计名称 | 订单服务V2.3迭代过程审计 |
| 审计类型 | 过程审计 |
| 审计对象 | 订单服务研发组 |
| 所属项目/产品 | 订单服务 |
| 审计期间 | 2024-05-06 至 2024-05-31 |
| 审计依据 | 研发过程管理规范V2.1、迭代准入准出检查表V1.3 |
| 审计范围 | 覆盖需求评审、技术方案评审、编码与自测、提测四个环节，不含上线发布 |
| 审计执行人 | 质量保证组 李某 |
| 配合人员 | 订单服务研发组 王某（技术负责人） |
| 审计开始日期 | 2024-06-03 |
| 审计结束日期 | 2024-06-07 |
| 发现数量（高/中/低） | 1 / 1 / 1 |
| 审计结论 | 基本符合 |
| 结论审批人 | 研发管理部 张某 |
| 记录状态 | 已归档 |
| 备注 | 范围临时排除上线发布环节，原因见变更记录 |
发现明细示例
| 字段 | 发现一 | 发现二 | 发现三 |
|---|---|---|---|
| 发现编号 | AUD-2024-014-01 | AUD-2024-014-02 | AUD-2024-014-03 |
| 主记录编号 | AUD-2024-014 | AUD-2024-014 | AUD-2024-014 |
| 发现描述 | 5月14日技术方案评审记录缺少数据库变更影响评估章节 | 5月20日提测版本的自测记录未覆盖异常分支用例 | 5月27日需求变更未同步更新评审结论 |
| 对应审计依据条款 | 规范V2.1 第4.2条 | 检查表V1.3 第3.1条 | 规范V2.1 第5.4条 |
| 证据位置 | 评审文档《订单服务V2.3技术方案》V1.0，第3节 | 测试管理记录 自测单 TC-0520-07 | 需求变更单 CR-20240527-02 |
| 风险等级 | 高 | 中 | 低 |
| 影响说明 | 数据库变更缺少评估，可能影响上线回滚方案 | 异常分支覆盖不足，提测后缺陷可能回流 | 评审结论与需求不一致，后续验收依据不清 |
| 整改措施 | 补充数据库变更影响评估并更新技术方案至V1.1 | 补充异常分支用例并重新执行自测，更新自测单 | 更新评审结论并通知相关评审人确认 |
| 整改责任人 | 王某 | 测试负责人 赵某 | 需求负责人 陈某 |
| 整改期限 | 2024-06-14 | 2024-06-12 | 2024-06-11 |
| 整改状态 | 已关闭 | 已关闭 | 已关闭 |
| 验证人 | 李某 | 李某 | 李某 |
| 验证日期 | 2024-06-13 | 2024-06-12 | 2024-06-11 |
| 验证结果 | 通过 | 通过 | 通过 |
| 备注 | V1.1已归档 | 补充用例12条 | 评审人已确认 |
对照第二节的字段说明可以看出：主记录中的“审计依据”指向两份文件，明细中的“对应审计依据条款”分别引用这两份文件的具体条款；“发现数量”1/1/1与明细表三条发现的风险等级一一对应；“审计结论”为“基本符合”，与存在高等级发现但已完成整改的情况相符。三条发现都走完了“发现—整改—验证—关闭”的闭环，验证结果均为通过，记录状态才进入“已归档”。
当审计发现较多、整改跨多轮时，记录会从一张静态表变成持续流转的工作项。ONES 的工作项与文档能力可以承接这一过程：审计主记录作为文档归档，每条发现建成工作项，指派整改责任人、设置期限，整改完成后由验证人更新验证结果并关闭工作项，主记录中的发现数量可按工作项状态汇总核对。这样记录与整改动作保持同一份数据来源，减少表格与实际情况脱节。
调整与维护：让模板随流程和审计范围变化
模板需要随流程演进而调整，但调整应有判断标准，避免字段越加越多、填写负担超过记录价值。
新增或合并字段的判断标准
出现以下情况时考虑新增字段：同一类信息反复写在“备注”里且需要筛选统计；审计结论的判定需要一项当前模板没有的依据；整改追踪中反复出现同一类缺失信息。新增前先确认该字段有稳定的取值口径，否则容易变成自由文本。出现以下情况时考虑合并字段：两个字段长期同值；某字段填写率很低且不影响结论与整改；字段含义被其他字段覆盖。合并或删除字段前，应确认历史记录仍可读，必要时保留旧字段并标注停用。
模板版本与变更记录
| 版本号 | 变更日期 | 变更内容 | 变更原因 | 影响范围 | 批准人 |
|---|---|---|---|---|---|
| V1.0 | 初始版本 | ||||
| V1.1 | |||||
| V1.2 |
每次调整模板都升一个次版本号，并在变更记录中写明改了什么、为什么改、从哪个日期起的新审计适用。已归档的记录保留其填写时的模板版本号，不随模板升级而回溯修改，保证历史记录可追溯。
记录归档、留存期限与检索方式
审计结束后，主记录与明细表一并归档，归档时确认记录状态为“已归档”、发现数量与明细一致、所有发现均有验证结果。留存期限按组织制度或合同要求确定，没有明确要求时至少覆盖一个完整的项目周期，便于后续复盘和外部检查调取。检索方式建议以主记录编号、审计对象、审计期间和风险等级为主要检索维度，明细表保留主记录编号列，确保从任一发现都能回溯到所属审计。
定期抽查记录完整性
建议每季度抽查一次已归档记录，检查项包括：必填字段是否齐全；发现数量与明细条数是否一致；每条发现是否都有整改责任人和验证结果；记录状态与实际整改进展是否相符；模板版本号是否填写。抽查发现的问题按类型汇总，若同类缺失反复出现，回到字段设计层面判断是口径不清还是字段设置不合理，再决定是否调整模板。抽查结果可作为下一版模板变更的依据，形成“使用—抽查—调整”的循环。
常见问题
审计期间和审计开始/结束日期有什么区别，容易填混吗？
两者记录的对象不同。审计期间指被检查活动实际发生的时间段，例如某迭代从5月6日到5月31日的研发活动；审计开始/结束日期指审计人员执行检查动作的时间，例如6月3日到6月7日。填写时先确定审计期间，再记录实际开展检查的日期。节点评审类审计中两者可能接近，但仍建议分开填写，便于后续按被检查活动的时间范围检索记录。
一次审计中发现的整改跨越多轮，记录应该怎么更新？
发现明细保持一条发现一行，不因多轮整改拆成多行。每轮整改后在“备注”中记录本轮动作和日期，整改状态按“待整改—整改中—待验证—已关闭”推进，验证结果记录最近一次复核结论。若首轮验证不通过，状态回到“整改中”，验证日期和验证结果更新为最新一次。主记录的发现数量按风险等级统计条数，不随整改轮次变化。
审计结论为“不符合”时，记录还能归档吗？
可以归档，但归档前要确认每条发现都有整改责任人和期限，未完成整改的发现状态应明确为“待整改”或“整改中”，并在备注中说明后续跟踪安排。审计结论反映本次检查的整体判断，归档表示记录本身完成，不代表问题已关闭。后续整改验证结果继续更新在发现明细中，必要时另开一次跟踪审计记录验证情况。
多个项目共用一套模板时，编号怎么避免重复？
建议在编号中加入能区分审计类型的固定前缀，再按年度统一编排流水号，由同一角色集中分配编号，而不是各项目自行编号。发现编号在主记录编号后追加两位序号，天然跟随主记录。若组织内存在多个审计归口部门，可在前缀中体现部门代码，并在模板版本记录中写明编号规则，避免不同来源的记录出现重号。
记录归档后还需要保留多久，按什么确定？
留存期限优先按组织制度、合同约定或行业监管要求确定。没有明确要求时，至少覆盖一个完整的项目周期，保证后续复盘和检查时能调取到对应期间的记录。归档时同步确认记录状态、发现数量与明细一致、每条发现均有验证结果，检索维度以主记录编号、审计对象、审计期间和风险等级为主。
