研发审计记录要能支撑复核，关键是把“做了什么、证据在哪、是否符合”写成可核对的事实。本文以一次版本发布为审计对象，给出一份可直接参照填写的记录示例，覆盖需求变更、代码评审、测试放行、发布审批四条主线，并逐项解释字段填写口径。示例为演示情景，非真实客户案例。
要点总览（TL;DR）
- 示例以一次版本发布为审计对象，覆盖需求变更、代码评审、测试放行、发布审批四条主线，采用“审计事项—应有证据—实际证据—符合性判断—整改要求”五列结构。
- 实际证据写到文档编号、工作项编号与时间，复核者可按编号定位原件；只写“已完成”无法支撑复核。
- 符合性判断只用符合、部分符合、不符合三档，依据是实际证据能否覆盖应有证据的要素，判断针对单条事项。
- 换版本或换项目时表结构不变，审计事项按流程裁剪，证据编号规则随工具与文档体系调整，抽样比例与频次结合风险等级确定。
- 示例为演示情景，不构成认证、法律或监管结论；审计记录证明过程可追溯，不证明过程质量本身。
示例要解决什么：审计记录该记到什么程度
这份示例回答一个具体问题：当审计人员拿到一次版本发布的研发过程材料时，记录表应当写到什么颗粒度，才能让另一位同事在不询问当事人的情况下复核结论。示例的审计对象是一次版本发布，范围覆盖需求变更、开发实现、测试放行、发布上线四个环节，每个环节抽取关键控制点形成审计事项。
记录颗粒度定在“单条证据可定位”。也就是说，每一条审计事项的实际证据必须写到具体文档编号、工作项编号或记录编号，并附上形成时间，使复核者能按编号找到原件。只写“已评审”“已完成”“已审批”这类状态描述，无法支撑复核，不作为合格的实际证据。
示例的边界需要提前说明：它不涉及认证结论、法律判断或监管符合性认定，也不对团队研发能力作整体评价。记录表只呈现“某条控制点在该版本中是否有证据、证据是否对应”这一层事实。审计事项的选择参照企业内部研发规范或所选过程模型的控制要求，示例中的六条事项是演示用的裁剪结果，不代表任何标准的最低要求。
完整示例：某版本发布审计记录表
下表为一份填写完成的审计记录示例。审计对象为“订单服务 V3.2.0 版本发布”，审计时间范围为该版本立项至上线后一周，审计方式为文档与工作项抽查。表中编号为演示编号，实际使用时按企业自身的文档与工作项编号规则替换。
| 审计事项 | 应有证据 | 实际证据 | 符合性判断 | 整改要求 |
|---|---|---|---|---|
| 1. 需求变更审批 | 变更申请单，含变更内容、影响范围、审批人签署与审批时间 | 变更申请单 CR-2024-0317，2024-03-17 提交；审批记录显示产品负责人与技术负责人于 2024-03-18 完成签署；关联需求工作项 REQ-1182 已同步更新描述 | 符合 | 无 |
| 2. 代码评审 | 合并请求记录，含评审人、评审意见与合入时间；关键模块需两名评审人 | 合并请求 MR-2041，2024-04-02 创建，评审人两名，评审意见 5 条均已回复并关闭，2024-04-03 合入主干；支付回调模块的合并请求 MR-2047 仅一名评审人 | 部分符合 | 由后端负责人王某在 2024-04-20 前补齐 MR-2047 的第二评审人意见，并在团队内重申关键模块双人评审要求 |
| 3. 单元测试 | 单元测试执行记录与覆盖率报告，核心模块覆盖率不低于内部规定阈值 | 流水线构建记录 BUILD-3312，2024-04-05 执行，单元测试 412 条全部通过；覆盖率报告显示订单核心模块行覆盖率 78%，低于内部规定的 80% | 部分符合 | 由开发负责人李某在 2024-04-25 前补充核心模块测试用例并重新出具覆盖率报告，达标后方可进入下一版本基线 |
| 4. 缺陷关闭 | 缺陷记录，含严重程度、修复提交、验证人与关闭时间；严重及以上缺陷须经验证后关闭 | 缺陷 BUG-5521（严重）2024-04-08 提交，修复提交关联 MR-2063，测试人员张某于 2024-04-10 验证通过并关闭；缺陷 BUG-5530（严重）由提交人自行关闭，无验证记录 | 不符合 | 由测试负责人赵某在 2024-04-18 前对 BUG-5530 补充回归验证并更新关闭记录，同时调整缺陷关闭权限，严重缺陷仅允许验证人关闭 |
| 5. 发布审批 | 发布申请单，含发布范围、风险评估、审批人签署与计划发布时间 | 发布申请单 REL-2024-0412，2024-04-11 提交，列明本次发布包含的 7 个需求与 2 个修复；技术负责人与运维负责人于 2024-04-12 签署；实际发布时间 2024-04-12 22:00，与计划一致 | 符合 | 无 |
| 6. 回滚预案 | 回滚方案文档，含触发条件、回滚步骤、数据兼容性说明与责任人 | 回滚方案文档 DOC-887，2024-04-10 定稿，列明 3 项触发条件与分步回滚操作，指定责任人为运维值班人员；文档中未说明本次新增字段的回滚数据兼容处理 | 部分符合 | 由运维负责人陈某在 2024-04-19 前补充新增字段的回滚数据兼容说明，并纳入发布检查单作为必填项 |
六条事项的结论分布为：符合 2 条、部分符合 3 条、不符合 1 条。整份记录可以直接作为该版本的过程审计底稿，后续整改完成情况另附跟踪表，与上表按审计事项编号对应。
逐项解释：每条记录为什么这样填
“应有证据”一列写的是判断依据，来源是内部研发规范或所选过程模型对该控制点的要求。填写时要把规范里的要求转成可检查的物件，例如规范写“关键模块变更须经双人评审”，应有证据就落到“合并请求记录中含两名评审人及其意见”。如果应有证据写得笼统，后面的符合性判断就失去基准。示例中第 2、3 条之所以判为部分符合，正是因为应有证据写明了“两名评审人”和“覆盖率阈值”这两个可量化条件。
“实际证据”写编号而非写“已完成”，原因在于审计复核依赖定位。编号加时间构成一条可追溯线索：复核者按 MR-2047 能找到那次合并请求，按 BUILD-3312 能找到那次构建记录，从而独立判断证据是否成立。状态词无法被复核，也无法在事后区分“确实做过”与“记得做过”。当一条事项涉及多个证据时，应逐一列出，示例中第 1 条同时列了变更单编号与关联需求工作项编号，就是为了让变更与需求之间的对应关系可查。
符合性判断只用三档，区分标准如下：实际证据完整覆盖应有证据的全部要素，判“符合”；证据存在但缺少部分要素，判“部分符合”；关键证据缺失或证据无法支撑该控制点成立，判“不符合”。示例中第 4 条判为不符合，是因为严重缺陷缺少验证记录这一关键要素，而非记录格式问题；第 6 条判为部分符合，是因为回滚方案主体齐备，仅缺少新增字段的兼容说明。判断针对单条事项，不对团队整体下结论。
整改要求写到责任人与期限，才能形成闭环。示例中每条整改都包含三部分：具体动作（补齐第二评审人意见、补充测试用例、调整关闭权限）、责任人（按角色加姓氏指代）、完成期限（具体日期）。整改动作要指向可验证的结果，例如“重新出具覆盖率报告并达标”，而不是“加强测试管理”。期限的设定需与版本节奏匹配，示例中的期限均落在下一个版本基线之前。
在工具层面，这些证据大多产生于日常协作过程：需求变更对应需求工作项及其变更记录，代码评审对应合并请求，缺陷关闭对应缺陷工作项的状态流转与验证记录，发布审批对应发布单与审批留痕。ONES 支持在工作项与文档中保留这类过程记录，审计时按编号检索即可定位；其官网展示的 ISO27001、等保三级、SOC2 Type1 等资质信息，可作为了解平台合规背景的参考，具体证书范围与有效期需向厂商核实。审计记录表本身仍建议以独立文档维护，便于签字与归档。
可迁移规律：换一个版本或项目怎么改
示例中稳定的部分是表结构：五列分别承担“审什么、依据什么、看到了什么、判断如何、怎么改”五个回答任务，换项目时保持不变。变化的部分是审计事项清单，需按项目实际流程裁剪。例如采用持续交付、发布频繁的团队，可以把“发布审批”与“回滚预案”合并为一条发布就绪检查；涉及外部依赖交付的项目，可增加“第三方组件引入审批”事项；研究型项目若没有固定发布节奏，可将审计对象改为里程碑交付。
证据编号规则随工具与文档体系调整。使用工作项管理需求的团队，实际证据写工作项编号；使用独立文档系统的团队，写文档编号与版本号；两者并存的，按“主证据编号加辅助编号”的方式并列。调整时保持一条原则：任何编号都能被复核者在系统中检索到，且编号对应的内容在审计时点之后未被无记录地修改。
抽样比例与审计频次需结合项目风险等级与内部规范确定，本文不给出统一数值。可调整的方向是：高风险版本或涉及资金、权限变更的发布提高抽样比例直至全量核查；常规迭代版本按控制点抽查；审计频次与发布节奏挂钩，发布越频繁越应把检查前移到发布前的就绪评审，减少事后补证。
记录与整改闭环的衔接方式同样可以复用：审计记录表定稿后，将“部分符合”与“不符合”事项逐条转入整改跟踪表，字段至少包含事项编号、整改动作、责任人、期限、完成状态与验证人；整改完成后由原审计人员复核并回填验证结论，形成“记录—整改—复核”的完整链条。下一轮审计时，上一轮整改项的完成情况应作为首批核查对象。
适用边界：这份示例不能替代什么
本文中的版本号、编号、人员指代与结论均为演示情景，用于说明填写方法，不是真实客户案例，也不是对任何产品功能的实测结果。读者可以照结构填写，但不应把示例中的结论分布当作行业基准或团队水平参照。
示例不构成认证、法律或监管结论。不同行业对研发过程的记录格式、留存期限与审计主体可能有各自要求，涉及受监管业务时，应以企业适用的规范与主管部门要求为准，必要时由合规或法务人员确认记录表的设计。流程差异较大的团队，例如采用外包协作、多团队联合发布或强矩阵管理的组织，应先对齐自身的研发规范与控制点清单，再套用表结构，避免直接复制事项清单导致审了不相关的内容、漏掉真正的风险点。
最后需要明确记录的作用范围：审计记录证明的是过程可追溯，即某项控制点在特定时间有可定位的证据；它不证明过程质量本身，也不证明产品缺陷率、交付稳定性等结果指标。把记录表当作质量证明使用，会超出它的能力边界。记录的价值在于让复核、整改与下一轮改进有据可依，这一点在示例的每一条填写中都应体现。
常见问题
审计记录里的“实际证据”只写“已完成评审”可以吗？
不建议这样写。复核者需要能按记录找到原件，因此实际证据应写到具体编号与时间，例如合并请求编号、构建记录编号、缺陷编号或文档编号。状态词无法被独立核对，也无法在事后区分“确实做过”与“记得做过”。如果一条事项涉及多个证据，逐一列出编号，让证据之间的对应关系可查。
“部分符合”和“不符合”在实际判断时怎么区分？
看关键要素是否成立。实际证据存在、但缺少应有证据中的部分要素，判“部分符合”；关键证据缺失，或现有证据无法支撑该控制点成立，判“不符合”。例如严重缺陷缺少验证记录，属于关键要素缺失，应判不符合；回滚方案主体齐备、仅缺新增字段的兼容说明，可判部分符合。判断只针对单条事项，不对团队整体下结论。
整改要求写到什么程度才算可闭环？
每条整改至少包含三部分：具体动作、责任人、完成期限。动作要指向可验证的结果，例如“补齐第二评审人意见”“重新出具覆盖率报告并达标”，避免写成“加强评审管理”这类无法验证的表述。期限与版本节奏匹配，通常落在下一个版本基线之前。整改完成后由原审计人员复核并回填验证结论，下一轮审计时把上一轮整改项作为首批核查对象。
团队发布频繁、没有固定版本节点，这份示例还能用吗？
可以保留表结构，调整审计事项与审计时机。持续交付团队可把发布审批与回滚预案合并为一条发布就绪检查，把检查前移到发布前的就绪评审，减少事后补证。审计对象也可以从单次版本发布改为一段时间窗口内的多次发布抽样。抽样比例与审计频次结合项目风险等级和内部规范确定，涉及资金、权限变更的发布可提高比例直至全量核查。
用协作工具管理需求、缺陷和发布记录，对审计取证有什么帮助？
审计取证的关键是按编号定位证据，工具的价值在于过程记录随工作项自然留存。以 ONES 为例，需求变更对应需求工作项及其变更记录，代码评审对应合并请求，缺陷关闭对应缺陷工作项的状态流转与验证记录，发布审批对应发布单与审批留痕，审计时按编号检索即可定位。ONES 官网还展示了 ISO27001、等保三级、SOC2 Type1 等资质信息，可作为了解平台合规背景的参考，具体证书范围与有效期需向厂商核实。审计记录表本身仍建议以独立文档维护，便于签字与归档。
