研发审计记录要回答的是“谁在什么时间、对哪个研发对象、做了什么动作、依据什么规则、结果如何、由谁复核”。一份可用的记录至少保留唯一编号与时间戳、操作人及角色、研发对象标识与所处阶段、动作类型与前后状态、审批或评审意见、关联依据单据、结果与例外说明、复核人和归档位置。把需求、任务、代码提交、构建、测试、发布各阶段的记录用统一关联键串起来，才能形成从需求到发布的证据链，而不是零散截图。
要点总览（TL;DR）
- 研发审计记录至少保留唯一编号与时间戳、操作人及角色、研发对象标识与阶段、动作类型与前后状态、依据文件版本、关联单据、结论与例外说明、复核人、归档位置与保留期限。
- 记录采集嵌入需求评审、开发提交、构建测试、发布变更各阶段，以需求编号为主键、发布版本号为反向索引，把零散记录串成证据链。
- 操作人与复核人分离，研发执行人填写、评审人给结论、质量接口人抽查、归档责任人管理目录与期限，责任落到岗位。
- 审计前用字段完整性、证据链可追溯、权限控制、归档与例外处理五项检查判断记录是否可用，关联键缺失、例外无理由、归档与台账不符是常见阻断项。
- 保留期限按项目合同与所属行业要求核验，本文不给出统一年限，也不提供认证或法律结论。
研发审计记录的核心字段清单
字段设计的目标是让第三方在不询问当事人的情况下，仅凭记录就能还原一次研发动作的来龙去脉。下表按信息组给出字段名、说明与必填建议，可直接作为记录模板的骨架。必填项是形成证据链的最低要求，选填项按项目风险等级和审计范围决定是否启用。
| 信息组 | 字段名 | 说明 | 是否必填 |
|---|---|---|---|
| 记录标识 | 记录编号 | 全局唯一，建议采用“项目代号-阶段-流水号”格式，便于检索与引用 | 必填 |
| 记录标识 | 记录时间 | 动作发生的实际时间，精确到分钟，统一时区 | 必填 |
| 记录标识 | 记录类型 | 评审记录、变更记录、测试记录、发布记录等，用于分类归档 | 必填 |
| 操作人 | 操作人姓名与账号 | 实际执行动作的人，账号用于与系统日志比对 | 必填 |
| 操作人 | 角色 | 开发、测试、评审人、审批人、发布负责人等 | 必填 |
| 研发对象 | 对象标识 | 需求编号、任务编号、代码提交号、构建号、缺陷单号、发布单号 | 必填 |
| 研发对象 | 所属阶段 | 需求、设计、开发、测试、发布、运维 | 必填 |
| 动作与状态 | 动作类型 | 创建、提交、评审通过、驳回、变更、关闭等 | 必填 |
| 动作与状态 | 状态变化 | 动作前后的状态值，如“待评审→评审通过” | 必填 |
| 依据与关联 | 依据文件 | 所遵循的流程文件、检查项、编码规范或评审准则的编号与版本 | 必填 |
| 依据与关联 | 关联单据 | 上游需求、关联缺陷、变更申请、测试用例等单据编号 | 必填 |
| 结果 | 结论 | 通过、有条件通过、不通过，以及对应的判断说明 | 必填 |
| 结果 | 例外说明 | 偏离流程的原因、风险影响、补偿措施与批准人 | 有例外时必填 |
| 复核 | 复核人 | 对记录内容进行确认的人，与操作人分离 | 必填 |
| 复核 | 复核时间与意见 | 复核完成时间及确认或退回的理由 | 必填 |
| 归档 | 归档位置 | 记录所在的文档库、目录路径或系统模块 | 必填 |
| 归档 | 保留期限 | 按项目合同、行业要求或组织制度确定的留存年限 | 必填 |
字段填写有两条实用原则。第一，状态变化要写“前后值”，只写“已评审”无法证明动作确实发生；第二，依据文件要带版本号，流程文件改版后旧记录仍能对应到当时执行的规则。保留期限属于组织与合同层面的约定，具体年限应结合所属行业监管要求和项目合同核验，本文不给出统一数值。
按研发阶段串联记录的操作步骤
记录采集应嵌入研发流程本身，在每个阶段结束时完成本阶段记录的填写与关联，而不是在审计前集中补录。以下步骤按阶段展开，每步说明输入、动作、输出与完成标志。
需求与评审阶段
- 输入：需求提案、评审通知、参会人名单。
- 动作：为需求分配唯一编号；记录评审时间、参与角色、评审意见与结论；将评审依据的准入检查项编号写入记录。
- 输出：需求评审记录，含需求编号、评审结论、遗留问题清单。
- 完成标志：需求状态由“待评审”变为“评审通过”，且每条遗留问题都有责任人与关闭时间。
开发与代码提交阶段
- 输入：开发任务、代码仓库提交记录、代码评审单。
- 动作：将任务编号与需求编号关联；记录每次提交的提交号、提交人、关联任务；记录代码评审人、评审意见与合入结论。
- 输出：任务与提交的关联记录、代码评审记录。
- 完成标志：每个合入主干的提交都能回溯到任务与需求，评审意见均有处理结果。
构建与测试阶段
- 输入：构建任务、测试用例、缺陷单。
- 动作：记录构建号、构建时间、构建结果与所用代码版本；记录测试执行范围、通过率、缺陷编号及修复验证结论。
- 输出：构建记录、测试执行记录、缺陷闭环记录。
- 完成标志：构建号与提交号可对应，测试结论明确，阻断级缺陷全部关闭或有批准的例外说明。
发布与变更阶段
- 输入：发布申请、变更单、上线检查表。
- 动作：记录发布版本、发布时间、发布负责人、审批人及审批意见；记录发布后的验证结果与回滚预案是否触发。
- 输出：发布记录、变更审批记录、发布后验证记录。
- 完成标志：发布单状态为“已发布”，审批链完整，验证结果已回填。
阶段间关联键的设置
关联键是证据链的连接点。建议以“需求编号”为主键贯穿全程，任务、提交、构建、测试、发布记录都携带该需求编号；同时保留“发布版本号”作为反向索引，便于从一次线上问题倒查涉及的提交与测试记录。关联键一经确定应写入记录模板，避免各团队自行命名导致无法拼接。
当记录分散在工作项、文档和代码仓库中时，可以在同一研发管理平台内完成采集与关联。ONES 研发管理 + ASPICE 解决方案支持汽车软件研发全生命周期流程活动，并支持跨域协作全过程的可追溯性，适合把需求、任务、评审与发布记录放在统一工作项体系中维护；具体字段配置与日志留存能力需结合所选版本确认。
角色分工与各阶段交付物
记录能否持续可用，取决于责任是否落到具体角色。下表按角色列出主要动作与交付物，组织可据此在项目启动时明确分工。
| 角色 | 主要动作 | 交付物 |
|---|---|---|
| 研发执行人（开发、测试） | 在完成任务或提交代码时同步填写对象标识、动作类型与状态变化；处理评审意见并回填结果 | 任务记录、提交记录、测试执行记录 |
| 评审与审批人 | 依据流程文件给出结论，写明通过条件与例外理由；确认记录中的依据版本正确 | 评审意见、审批记录、例外批准说明 |
| 质量或审计接口人 | 抽查各阶段记录完整性，核对关联键是否贯通，汇总缺失项并推动整改 | 记录抽查报告、缺失项清单、整改跟踪表 |
| 归档管理职责人 | 按项目与阶段整理记录，确认归档位置、访问权限与保留期限，执行到期处置 | 归档目录、权限清单、留存台账 |
分工中需要守住一条边界：操作人与复核人应分离，评审人不能同时是唯一复核人。对于小型团队人员重叠的情况，至少保证复核动作由另一角色执行并留痕。归档职责可以挂在项目管理办公室或质量部门，但需明确到岗位而非笼统的“相关同事”。
一个需求从提出到发布的记录示例
以下为演示情景，用于说明字段如何填写与关联，不代表真实项目数据。
示例背景：某项目提出需求“登录页增加短信验证码”，需求编号 REQ-0215，计划随版本 V1.4.0 发布。
- 需求评审记录：记录编号 REQ-0215-RV01，时间 3 月 4 日 10:20，操作人为产品负责人，角色为需求提出人；对象 REQ-0215，阶段为需求；动作“提交评审”，状态“草稿→评审通过”；依据为《需求准入检查表 V2.1》；结论“通过”，附两条遗留问题及责任人；复核人为质量接口人，归档至项目文档库“需求评审/2024Q1”。
- 开发记录：任务 T-1187 关联 REQ-0215；提交号 a3f9c2 由开发人员提交，动作“提交代码”，状态“开发中→待评审”；代码评审记录写明评审人、两条修改意见及合入结论；复核人确认提交号与任务关联正确。
- 构建与测试记录：构建号 B-20240312-03 对应提交 a3f9c2；测试记录写明执行用例 42 条、通过 40 条、缺陷 DEF-330 与 DEF-331，其中 DEF-331 为一般缺陷，经批准延期修复并记录例外说明与批准人。
- 发布记录：发布单 REL-0140 关联版本 V1.4.0，发布时间 3 月 15 日，发布负责人与审批人分别填写，结论“发布成功”，发布后验证项全部通过。
证据链呈现方式：以 REQ-0215 为线索，可依次查到评审记录、任务 T-1187、提交 a3f9c2、构建 B-20240312-03、缺陷 DEF-330/331、发布单 REL-0140；反向从 REL-0140 也能定位到本次发布包含的全部需求与提交。示例中的例外处理（DEF-331 延期修复）保留了原因、风险判断与批准人，这是审计时最容易被追问的部分，应在记录中单独成段而非夹在测试结论里。
记录留存与归档的完成检查
审计前可用以下清单逐项核对，任一项不通过即视为记录不可用，需先整改再提交。
| 检查项 | 通过标准 | 负责人 |
|---|---|---|
| 字段完整性 | 必填字段无空缺；状态变化写明前后值；依据文件带版本号 | 研发执行人自查，质量接口人抽查 |
| 证据链可追溯 | 随机抽取三个需求，均能从需求编号查到发布记录，反向亦可定位 | 质量或审计接口人 |
| 权限与访问控制 | 记录对审计相关人员可读，对无关人员按最小权限控制；修改留痕 | 归档管理职责人 |
| 保留期限与归档 | 归档位置与台账一致；保留期限有书面依据；到期处置有流程 | 归档管理职责人 |
| 例外处理 | 每条例外均有原因、风险说明、补偿措施与批准人 | 评审与审批人 |
阻断项通常集中在三类：关联键缺失导致记录无法拼接、例外说明只有结论没有理由、归档位置与台账不符。整改方式分别是补录关联编号并由复核人确认、补充例外审批记录、按台账重新归位并更新目录。记录存放在统一平台时，权限与修改留痕可借助平台的账号体系与操作记录实现；ONES 安全与合规页面介绍其通过传输加密、分布式存储、数据备份等技术措施保障数据安全，并列出可信云、CMMI3、ISO、等保三级等资质，这些信息可作为归档环境选型时的核验参考，具体认证范围与有效期以官方证书为准，不构成对记录留存合规性的结论。
常见问题
研发审计记录和系统操作日志有什么区别，两者都要保留吗？
两者记录的内容层次不同。系统操作日志由平台自动生成，记录账号在系统中的点击、修改与登录行为，适合做技术层面的行为核对；研发审计记录由人填写，说明动作的业务含义、依据的规则、评审结论和例外理由，回答“为什么这样做、谁批准的”。
实践中建议两者都保留并互相引用：审计记录中写明操作人账号与关联单据编号，需要时用系统日志验证记录时间与操作真实性。只保留日志，第三方难以理解业务判断；只保留人工记录，缺少客观时间与操作痕迹佐证。
小团队人员少，操作人和复核人难以分离，怎么处理？
复核的核心是让另一个人独立确认记录内容，人员重叠时可以调整复核对象而非取消复核。例如开发人员填写提交与测试记录后，由项目负责人或质量接口人复核；评审结论由未参与该需求实现的成员确认。若团队确实只有一人负责某环节，可引入上级或跨项目同事做抽查复核，并在记录中写明复核人身份与复核方式。
需要避免的是同一人既填写又确认且无任何外部检查，这会让记录失去独立验证价值。复核动作本身要留痕，写明复核时间与确认或退回的理由。
流程文件改版后，旧项目的审计记录需要按新版本重新填写吗？
不需要重填。审计记录证明的是动作发生时执行了当时的规则，因此依据文件字段应保留动作发生时有效的版本号，例如《需求准入检查表 V2.1》。流程改版后，新产生的记录引用新版本，旧记录保持原样。
如果改版涉及追溯要求变化，可在归档台账中注明版本切换时间点，便于审计人员理解同一项目内不同阶段引用不同版本的原因。切忌用新版本号覆盖旧记录，那会破坏记录与当时执行规则的一致性。
记录分散在工作项、文档和代码仓库里，怎么保证能拼成完整证据链？
关键是统一关联键并在各环节携带。以需求编号作为主键，任务、代码提交、构建、测试用例、缺陷单和发布单都填写对应需求编号；同时保留发布版本号作为反向索引，便于从线上问题倒查涉及的提交与测试记录。关联键的命名规则应写入记录模板，避免各团队自行命名。
如果使用研发管理平台承载工作项与文档，可以在同一体系内维护需求、任务、评审与发布记录，减少跨系统手工拼接。ONES 研发管理 + ASPICE 解决方案支持汽车软件研发全生命周期流程活动，并支持跨域协作全过程的可追溯性，具体字段配置与日志留存能力需结合所选版本确认。
审计时发现记录缺失，应该补录还是说明情况？
先区分缺失类型。属于关联编号漏填、归档位置错误等可由原始数据核实的信息，可以补录并由复核人确认，同时在整改记录中注明补录原因与时间。属于当时未执行评审、未记录例外批准等过程缺失，补录会制造虚假记录，应如实说明缺失情况、影响范围与已采取的补救措施。
两类情况都建议纳入整改跟踪表，由质量或审计接口人确认关闭。审计关注的是记录能否真实反映研发过程，掩盖缺失带来的风险通常大于缺失本身。
