研发过程审计的准备阶段，核心交付物是三张表加一份提纲：审计范围与检查项清单、证据清单、责任与阻断项表，以及分角色访谈提纲。准备完成的判定标准是四类材料齐备并通过预审，每项检查项都能对应到可核验的证据和明确的通过标准。本文按准备顺序给出可直接填写的表格结构和使用方法，适用于年度审计或专项研发过程审计的现场检查前阶段。
要点总览（TL;DR）
- 准备阶段的核心交付物是检查项清单、证据清单、分角色访谈提纲和责任与阻断项表，四类材料齐备并通过预审才可进入现场审计。
- 检查项按需求、设计、编码、测试、发布、配置六个阶段组织，每条写成可判断的陈述，通过标准落到有记录、有审批、时间顺序正确、角色符合授权四类判定条件。
- 证据清单与检查项编号一一对应，写清证据名称、来源、关键字段、时间范围和提供人；证据无法调取时提供书面替代说明并进入预审。
- 访谈提纲按角色分工设计，先看记录再问流程，用交叉验证比对回答与系统记录是否一致，访谈记录由受访人签字确认。
- 阻断项未关闭时，要么补充材料重新预审，要么转为审计发现；两类处理都需预审人签字，准备阶段才算结束。
谁在什么时点使用这份准备清单
这份清单服务于审计准备阶段，不替代现场审计的执行程序。使用对象和各自职责需要先界定清楚，否则容易出现被审计团队自行收集材料、审计方到现场才发现证据与检查项对不上的情况。
| 角色 | 在准备阶段的职责 | 主要产出 |
|---|---|---|
| 审计组织方 | 下发审计通知，确定审计范围、检查项清单和抽查比例，组织预审 | 检查项清单、访谈提纲、预审结论 |
| 被审计研发团队接口人 | 按证据清单调取材料，协调各角色接受访谈，对证据完整性负责 | 证据包、访谈安排、缺失说明 |
| 质量或流程负责人 | 确认检查项的通过标准与内部流程文件一致，参与预审判定 | 标准确认意见、预审问题清单 |
启动时点是审计通知下发之后、现场检查之前。通知中应明确审计覆盖的时间范围、涉及的项目或产品线、检查项清单版本，被审计方据此启动证据调取。准备与执行的分界建议设在预审通过：预审通过前，工作重心是补齐材料、澄清标准；预审通过后，现场检查只做核验、抽样和访谈，不再大规模补充材料。
准备完成的判定节点包括四项：检查项清单已定稿并标注必查与抽查；证据清单中每项检查项都有对应证据或经批准的替代说明；访谈提纲已按角色分发并约定时间；责任与阻断项表中无未关闭的阻断项。四项同时满足，才可放行进入现场审计。
审计范围与检查项清单怎么列
检查项清单按研发阶段组织，每个阶段列出检查内容与通过标准两列。检查内容写成可判断真假的陈述句，通过标准写成可核验的判定条件，常见判定维度有四类：有记录、有审批、时间顺序正确、执行角色符合授权。
| 阶段 | 检查内容（示例） | 通过标准 | 必查/抽查 |
|---|---|---|---|
| 需求与立项 | 需求进入开发前已完成立项审批 | 存在立项审批记录，审批时间早于首个开发任务创建时间，审批人具备对应权限 | 必查 |
| 设计与评审 | 关键设计变更经过设计评审 | 存在评审记录，含评审结论与参与人，评审时间早于变更实施时间 | 必查 |
| 编码与代码评审 | 合并请求在合入前完成代码评审 | 存在评审记录与审批状态，评审通过时间早于合入时间，评审人非提交人本人 | 必查 |
| 测试与缺陷 | 发布前完成规定级别的测试执行 | 存在测试用例与执行结果记录，覆盖范围符合项目测试要求，执行时间在发布之前 | 必查 |
| 发布与变更 | 生产发布经过变更审批 | 存在变更单或发布审批记录，含审批人、发布时间、发布内容，与实际上线记录一致 | 必查 |
| 配置与基线 | 发布版本对应明确的基线 | 存在基线或版本标签记录，可追溯到该版本包含的代码与配置项 | 抽查 |
必查项覆盖每个阶段至少一条关键控制点，抽查项用于验证执行的一致性，抽样比例在清单中写明，例如按项目数或发布次数抽取。检查内容避免写成“流程规范”“管理到位”这类无法判断的表述；通过标准避免只写“有记录”，应同时写明记录应包含的字段、时间关系和角色条件，否则现场无法判定通过与否。
证据清单：每项检查项对应什么材料
证据清单的作用是把检查项翻译成可调取的材料，做到一条检查项对应一条或一组证据，并写清来源、字段、时间范围和提供人。清单条目与检查项编号一一对应，便于预审时逐项核对。
| 检查项编号 | 证据名称 | 来源 | 关键字段 | 时间范围 | 提供人 |
|---|---|---|---|---|---|
| R-01 立项审批 | 立项审批单及流转记录 | 研发管理系统或审批系统 | 审批人、审批结论、审批时间、关联需求 | 审计覆盖期内全部立项 | 项目经理 |
| D-02 设计评审 | 设计评审记录 | 文档系统或评审工具 | 评审结论、参与人、评审时间、被评审文档版本 | 覆盖期内关键设计变更 | 技术负责人 |
| C-03 代码评审 | 合并请求评审记录 | 代码托管平台 | 提交人、评审人、评审结论、合入时间 | 覆盖期内全部合并请求 | 开发负责人 |
| T-04 测试执行 | 测试用例与执行结果 | 测试管理系统 | 用例编号、执行结果、执行人、执行时间、关联版本 | 覆盖期内各次发布对应版本 | 测试负责人 |
| P-05 发布审批 | 变更单与发布记录 | 发布平台或工单系统 | 审批人、发布时间、发布内容、回滚记录（如有） | 覆盖期内全部生产发布 | 发布或运维接口人 |
| B-06 基线 | 版本标签与配置项清单 | 代码托管或配置管理工具 | 版本号、标签时间、包含的代码与配置项 | 抽查版本 | 配置管理员 |
常见证据类型还包括缺陷闭环记录（缺陷从发现到关闭的状态流转与验证人）、变更单（含影响评估与回退方案）。证据以系统导出记录为主时，应保留导出时间与导出人，避免只提供截图而无法核对字段。证据确实缺失或无法调取时，要求提供书面替代说明，写明缺失原因、可佐证的其他材料、以及该检查项是否因此无法判定，替代说明由团队接口人签字后进入预审。
当工作项流转、评审与审批记录集中在同一研发管理平台时，证据调取可以按项目、时间范围和记录类型直接筛选导出。ONES 的工作项流转记录与评审、审批记录可作为此类证据的来源之一，具体字段以实际配置为准，导出前需与审计方确认字段口径。
访谈提纲按角色怎么设计
访谈用于验证记录与实际执行是否一致，问题应围绕流程执行、审批权限、异常处理和记录留存四类展开，并按角色分工设计，避免所有角色问同一套问题。
| 访谈对象 | 问题方向（示例） | 交叉验证点 |
|---|---|---|
| 研发负责人 | 关键节点的审批权限如何设定，谁有权批准发布；例外情况如何处理 | 回答的审批人是否与审批记录中的审批人一致 |
| 项目经理 | 需求到发布的流转路径；哪些环节必须留记录；记录保存在哪里 | 描述的流转路径与工作项状态流转记录是否吻合 |
| 开发人员 | 代码合入前需要谁评审；紧急修复时是否仍走评审 | 回答与合并请求评审记录的时间关系是否一致 |
| 测试人员 | 测试执行结果如何记录；未通过用例如何处理 | 回答与测试执行记录、缺陷闭环记录是否对应 |
| 发布或运维接口人 | 发布前需要哪些审批；回滚由谁决定、如何记录 | 回答与变更单、发布记录、回滚记录是否一致 |
交叉验证问题的设计方法是：先看记录，再问流程，比对两者。例如记录显示某次发布审批人为A，访谈中询问“这次发布由谁批准”，若回答与记录不符，需要进一步核实是记录失真还是执行偏差。访谈记录应现场整理，由受访人确认内容并签字，作为审计工作底稿的一部分。
责任分工、证据提交时点与阻断项
准备阶段需要一张责任矩阵，把每项准备工作的负责人、提交时点和预审人固定下来，使进度可跟踪、放行可判定。
| 工作项 | 负责人 | 提交时点 | 预审人 |
|---|---|---|---|
| 检查项清单定稿 | 审计组织方 | 审计通知下发后3个工作日内 | 质量或流程负责人 |
| 证据包提交 | 被审计团队接口人 | 现场检查前5个工作日 | 审计组织方 |
| 访谈提纲确认与排期 | 被审计团队接口人 | 现场检查前3个工作日 | 审计组织方 |
| 补充材料 | 对应证据提供人 | 预审问题发出后2个工作日内 | 审计组织方 |
阻断项是未关闭即不能进入现场审计的条件，典型示例包括：关键阶段（如发布审批）无任何审批记录；发布记录缺失且无经批准的替代说明；证据与检查项无法对应，无法判断该检查项是否通过。阻断项未关闭时，处理方式有两种：由被审计方补充材料并在预审中重新判定；或由审计组织方记录为审计发现，在报告中说明该控制点无法验证。完成条件是阻断项表中所有条目状态为“已关闭”或“已转为审计发现”，二者都需预审人签字确认。
准备完成前的自查与预审
预审是准备阶段的收尾动作，目标是确认清单可以直接用于现场检查。自查按以下顺序进行：
- 逐项核对检查项清单，确认每条检查项都有对应证据条目和明确的通过标准，无空项。
- 抽查证据的时间范围与字段完整性，重点核对审批时间与执行时间的先后关系、审批人是否具备授权。
- 按角色核对访谈提纲与排期，确认交叉验证问题已覆盖主要控制点。
- 汇总预审发现的问题，形成问题清单，逐条指定整改人和关闭时限。
放行判定标准：检查项、证据、访谈提纲、责任人四类材料齐备；预审问题清单中的问题全部关闭或已明确转为审计发现；阻断项表无未关闭条目。满足后由预审人出具放行结论，准备阶段结束，进入现场检查。现场检查阶段如发现证据与记录不一致，按审计程序记录，不再返回准备阶段补材料。
常见问题
审计覆盖期内项目很多，证据不可能全部调取，怎么确定抽样范围？
抽样范围在检查项清单定稿时就应写明，而不是等证据收集时临时决定。常见做法是按项目数或发布次数抽取，必查项在每个阶段至少覆盖一条关键控制点，抽查项用于验证执行一致性。抽样时优先纳入高风险项目，例如涉及生产变更频繁、跨团队协作多或近期出现过重大缺陷的项目。抽样清单和比例需经审计组织方确认后写入检查项清单，被审计方按此调取证据，避免范围反复变动。
证据只有截图、没有系统导出记录，能否作为审计证据？
截图可以作为辅助材料，但单独使用时难以核对字段完整性和时间关系。更稳妥的做法是提供系统导出记录，并保留导出时间与导出人，便于审计方核对数据口径。如果系统确实无法导出，需要提供书面说明，写清无法导出的原因、截图对应的系统页面与查询条件，以及可佐证的其他材料。这类替代说明由团队接口人签字后进入预审，由预审人判断该检查项能否据此判定。
访谈中发现员工回答与系统记录不一致，应该怎么处理？
先区分是记录失真还是执行偏差。可以调取同一控制点的其他证据交叉核对，例如审批记录、工作项流转日志、相关邮件或会议纪要。若记录本身有误，要求被审计方说明原因并补充更正依据；若记录准确而实际执行偏离流程，则作为审计发现记录，写明偏差发生的环节、涉及范围和可能影响。两种情况都不在现场直接下结论，统一进入预审问题清单，由预审人确认后续处理方式。
阻断项在预审截止时仍未关闭，审计还能不能按期开始？
能否按期开始取决于阻断项的性质和审计组织方的判定。通常有两种处理：一是由被审计方在约定时限内补充材料，预审重新判定后关闭；二是由审计组织方将该控制点记录为审计发现，在报告中说明无法验证，现场检查按原计划进行。两种处理都需要预审人签字确认，并在阻断项表中更新状态。若阻断项涉及关键控制点且影响审计结论的可靠性，建议推迟现场检查，先完成材料补充。
准备清单在专项审计和年度审计中的用法有什么区别？
清单结构相同，差别在范围和深度。年度审计覆盖时间范围长、涉及项目多，检查项以全阶段必查项为主，抽查比例按项目数设定；专项审计聚焦特定主题，例如发布变更或代码评审，检查项可在对应阶段细化，证据时间范围收窄到专项涉及的版本或时间段，访谈对象也集中在相关角色。无论哪种审计，检查项与证据的对应关系、通过标准的判定条件、阻断项的处理规则保持一致，便于跨年度比较审计结果。
