研发过程证据留存要解决的是“做过什么、谁确认、结果如何”能被复核。做法可以拆成五步：按阶段列证据清单，把采集动作嵌入需求、设计、编码、测试、评审和发布活动，明确每类证据的责任人与复核人，统一命名和归档规则，最后用检查清单定期核对。本文适用于需要应对内外部审计或客户过程审查的研发团队，清单范围应结合组织适用的合规要求和项目实际裁剪。
要点总览（TL;DR）
- 证据留存从一张按研发阶段组织的清单开始，每类证据写明采集时点、责任人、存放位置和保留期限，范围按合规要求与项目风险裁剪。
- 采集动作要写进各环节的完成定义：需求与变更留评审和批准记录，设计与开发留评审意见和提交关联，测试与发布留执行、缺陷闭环和审批记录。
- 留存与复核分开：项目成员和评审人负责产生记录，质量或合规负责人维护清单、组织抽查，项目负责人对缺口整改负责。
- 统一命名结构、目录和关联编号，让每条证据都能通过需求编号反查全过程；保留期限到期前统一评估续存或销毁。
- 用清单完整性、采集及时性、签核有效性、归档可检索性四类检查项自检，阻断项全部通过且一般缺口有整改计划，才算本轮达标。
先定证据清单：留存哪些、留到什么程度
证据清单是整套机制的起点。清单不追求覆盖所有活动，而要覆盖审计时会被追问的关键节点。建议按研发阶段划分证据类别，再为每类证据定义六个字段，形成一张可以直接填写的表。
按阶段划分时，需求阶段关注需求来源、评审和基线；设计阶段关注方案评审与接口约定；开发阶段关注代码提交、分支策略和代码评审；测试阶段关注用例、执行记录和缺陷闭环；评审阶段关注各类评审的参与人、意见和结论；发布阶段关注发布审批和上线记录；变更阶段关注变更申请、影响分析和批准。每个阶段挑出二到五项核心证据即可，过多会让采集动作难以持续。
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 证据名称 | 使用团队统一术语，避免同一类记录多种叫法 | 需求评审记录 |
| 对应活动 | 指向具体研发活动，便于定位采集时点 | 需求评审会 |
| 采集时点 | 活动完成时、当日或规定时限内 | 评审结束后一个工作日内 |
| 责任人 | 填写岗位或角色，不写个人姓名 | 需求负责人 |
| 存放位置 | 具体到目录或系统模块 | 项目文档库/需求/评审 |
| 保留期限 | 依据组织适用要求确定，注明依据来源 | 按合同约定或内部制度 |
清单中要区分过程记录和结论性记录。过程记录随活动自然产生，例如提交记录、测试执行日志、讨论意见；结论性记录是对活动的正式确认，例如评审结论、审批意见、发布批准，这类记录必须明确签核人和签核时点，缺少签核的记录在审计中通常只能证明“发生过”，难以证明“被认可”。
裁剪清单时，先确认组织适用的合规要求、客户合同条款和内部制度分别要求哪些证据，再对照项目规模和风险等级取舍。高风险项目保留完整评审链，低风险内部项目可以合并部分评审记录，但合并规则要写进清单，避免执行时各自解释。
把采集动作嵌进研发流程：四个关键环节的做法
证据留存失败最常见的原因是事后补录。补录的记录时间戳与活动时间不一致，内容也容易失真。可行做法是把采集动作写进各环节的完成定义，让证据随活动产生。下表按环节给出输入、动作、输出和完成标志。
| 环节 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 需求与变更 | 需求说明、变更申请 | 组织评审并记录参与人、意见和结论；变更申请附影响分析，由有权人批准 | 需求评审记录、变更批准记录 | 评审结论已签署，变更单状态为已批准 |
| 设计与开发 | 设计方案、代码提交 | 设计评审记录归档；代码评审在合并前完成并留下意见；提交信息关联需求或任务编号 | 设计评审记录、代码评审意见、提交与分支记录 | 合并请求已通过评审，提交可追溯到需求 |
| 测试与发布 | 测试用例、缺陷单、发布计划 | 记录用例执行结果；缺陷从发现到验证关闭全程留痕；发布前完成审批 | 测试执行记录、缺陷闭环记录、发布审批记录 | 缺陷全部关闭或有明确遗留说明，发布审批已签署 |
| 评审与签核 | 各环节待确认事项 | 明确签核人、签核时点和签核方式，签核结果落到对应记录上 | 签核记录 | 签核人、时间、结论三项齐全 |
需求与变更环节的关键是让变更“有申请、有分析、有批准”。变更申请单要写明变更内容、影响范围和受影响的需求与测试项，批准人按变更等级确定。设计与开发环节的关键是让代码提交与需求建立关联，评审意见在合并前完成，避免合并后补评审。测试与发布环节的关键是缺陷闭环，未关闭的缺陷要有遗留说明和风险接受记录。评审与签核环节的关键是签核时点前移，签核发生在活动结束时，而不是审计前集中补签。
在工具承载上，ONES ALM 研发管理方案以数字线程贯通需求、开发、测试、变更与发布，把测试用例、缺陷、版本和发布过程关联到需求链路中，评审与状态变更随工作项和文档产生。团队按上述环节配置工作项状态和评审节点后，证据的采集时点与活动完成时点一致，后续追溯时可以从需求直接查到对应的测试和发布记录。这一方式适用于已在该平台内持续记录各环节数据的团队，追溯完整性取决于记录是否连续。
角色与交付物分工：谁负责留、谁负责查
证据留存的责任要落到角色上，并且把“留”和“查”分开。留的人对记录的真实性和及时性负责，查的人对完整性和一致性负责，两者由同一人承担时容易失去校验作用。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 项目成员 | 在活动完成时提交本环节记录，保证内容真实、关联正确 | 提交记录、测试执行记录、缺陷记录 |
| 评审人 | 参加评审并给出明确结论，对结论负责 | 评审意见与签核记录 |
| 质量或合规负责人 | 维护证据清单，定义命名与归档规则，组织定期抽查 | 证据清单、抽查报告、缺口整改清单 |
| 项目负责人 | 确认本项目证据范围，对缺口整改的资源和时限负责 | 项目证据范围确认、整改计划 |
每类证据指定第一责任人和复核人。第一责任人通常是产生该记录的活动执行者，复核人通常是评审人或质量角色。归档责任单独归属，一般由质量或合规负责人牵头，项目成员按规则提交。定期抽查建议按项目里程碑或固定周期执行，抽查结果形成记录，作为下一轮改进的输入。职责矩阵可以用“证据类别×角色”的表格表达，格内填写负责、复核、知会等标识，避免用文字描述造成理解分歧。
命名、版本与归档：让证据可检索、可追溯
证据存下来却找不到，等于没有留存。命名和归档规则要在项目启动时确定，并写入证据清单的存放位置字段。
命名规则建议采用固定结构，例如“项目代号-阶段-证据类型-关联编号-版本-日期”。结构固定后，检索时按字段组合即可定位。目录结构可以按项目加阶段组织，也可以按证据类型组织，选择一种并在组织内统一，不要混用。
项目代号/
01-需求/
评审记录/
变更记录/
02-设计/
03-开发/
04-测试/
05-发布/
版本管理要解决两个问题：同一证据多次修订时保留历史，证据与需求、任务、缺陷之间建立关联。关联方式可以是在记录中填写关联编号，也可以借助工具的对象关联能力。ONES 方案围绕需求、基线、版本和变更建立统一管理对象，支撑需求变更影响分析、过程状态追踪和交付结果回溯，适合需要从需求出发反查全过程记录的团队。
集中存放要求所有证据进入统一位置，避免散落在个人电脑和聊天工具中。权限控制按“可读范围最小化、可写范围明确化”设置，审计人员需要只读访问权限。保留期限依据组织适用要求确定，到期前统一评估是续存还是销毁，销毁要有审批记录，不能由个人自行删除。
示例：一个需求从提出到发布的证据链
以下为演示情景，用于说明证据如何串联，不代表任何具体项目的真实记录。
某团队收到一条“增加登录失败锁定”的需求。需求负责人在需求管理工具中创建需求条目，编号 REQ-1024，附需求说明和来源。需求评审会结束后一个工作日内，评审记录归档，记录参与人、提出的两条修改意见和“修改后通过”的结论，需求负责人签核，需求进入基线。
开发阶段，设计评审记录关联 REQ-1024，记录接口设计和锁定策略；开发人员提交代码时在提交信息中引用 REQ-1024，合并请求由两名评审人完成代码评审，意见和结论留在合并请求中。测试阶段，测试用例关联 REQ-1024，执行记录显示三轮执行结果，发现的两个缺陷从提交到验证关闭全程留痕。发布前，发布审批单列出本次发布包含的需求清单和遗留问题说明，由项目负责人签核。上线后，发布记录回填到需求条目，形成从需求到发布的完整链路。
这条证据链体现了前文的规则：清单规定了每类证据的采集时点和责任人，角色分工让评审人和项目负责人各自签核，命名和关联规则让所有记录都能通过 REQ-1024 检索到。可迁移的规律是“一个需求一个主编号，所有证据挂在这个编号下”。适用边界在于：跨多个系统的需求需要在各系统中分别建立关联，关联关系本身也要作为证据维护。
完成检查：证据留存是否达标的核对项
检查的目的是在审计前发现缺口。建议按四类设置检查项，每项给出通过标准和所需证据，并区分阻断项与一般缺口。阻断项未通过时不能进入审计或交付环节。
| 检查类别 | 检查项 | 通过标准 | 所需证据 | 类型 |
|---|---|---|---|---|
| 清单完整性 | 清单覆盖各阶段核心证据 | 每个阶段至少有一项结论性记录，且均有责任人 | 证据清单表 | 阻断项 |
| 采集及时性 | 记录时间与活动时间一致 | 抽查样本中记录时间不晚于活动结束后规定时限 | 记录时间戳、活动记录 | 阻断项 |
| 签核有效性 | 结论性记录有明确签核 | 签核人、时间、结论三项齐全，签核人有权签核 | 评审记录、审批单 | 阻断项 |
| 归档可检索性 | 证据可按规则定位 | 随机抽取一个需求编号，能查到全过程关联记录 | 目录结构、关联记录 | 一般缺口 |
常见缺口有三类：记录存在但缺少签核，通常发生在评审结论只写在会议纪要里；记录时间晚于活动时间，通常是事后补录；关联断裂，通常是提交信息未引用需求编号。补救方式分别是补签并说明原因、补充说明补录情况并加强后续时点控制、建立关联编号规则并回溯补齐。阻断项全部通过、一般缺口有整改计划并明确完成时限，可以视为本轮证据留存达标。检查结果应形成记录，作为下一轮清单裁剪和流程调整的依据。
常见问题
项目规模小、人手紧，证据清单可以精简到什么程度？
可以精简，但要保留每个阶段至少一项结论性记录，并保证签核人、时间、结论三项齐全。低风险内部项目可以合并部分评审记录，例如把需求评审和设计评审合并为一次评审会，合并规则要写进清单，明确合并后由谁签核、记录存放在哪里。过程记录可以依赖工具自动产生，例如提交记录和测试执行日志，减少人工整理。精简的底线是：审计时被追问的关键节点仍能拿出可复核的记录。
评审已经在会上口头通过，会后补一份纪要算有效证据吗？
会议纪要可以作为过程记录，但要成为有效的结论性记录，需要补充明确的签核信息：参与人、评审意见、结论，以及签核人和签核时间。补记的纪要要如实标注形成时间，避免把会后补写的内容写成会议当天的记录。更稳妥的做法是把结论当场记录在评审工具或工作项中，由评审人直接确认，让记录时间与活动时间一致。审计关注的是记录能否证明“被认可”，而不只是“开过会”。
证据分散在多个系统里，关联关系怎么维护？
先确定一个主编号，通常用需求编号作为主线，其他系统中的记录都引用这个编号。跨系统时，在每个系统中保留关联字段，并在证据清单中登记该证据所在的系统和访问路径。关联关系本身也要作为证据维护，例如在需求条目中列出对应的设计、测试和发布记录链接。如果团队使用 ONES ALM 研发管理方案，需求、基线、版本、变更、测试与发布可以在同一平台内建立关联，减少跨系统手工维护的工作量；已有系统较多的团队则需要明确哪个系统作为主记录源。
保留期限应该定多长，到期后怎么处理？
保留期限依据组织适用的合规要求、客户合同条款和内部制度确定，不同证据类别可以不同。做法是在证据清单的保留期限字段注明依据来源，例如某类合同要求交付记录保存若干年，就按合同执行。到期前由质量或合规负责人统一评估是续存还是销毁，销毁需要审批记录并留存销毁清单，避免个人自行删除。资料中未给出具体年限，团队应结合自身适用要求确定，不宜照搬其他组织的期限。
审计前发现部分记录缺少签核，怎么补救？
先区分缺口性质。如果活动确实发生过、只是签核缺失，可以请原评审人或有权签核人补充确认，并在记录中说明补签原因和时间，保留补签痕迹。如果记录本身缺失，需要补充说明情况并评估该环节结论是否仍然成立，必要时重新组织评审。补救之后要分析原因：是签核时点没有前移，还是评审结论只写在会议纪要里。把签核动作固定到工作项状态流转或评审节点上，能减少同类缺口再次出现。阻断项缺口未闭环前，不建议进入正式审计环节。
