研发审计证据清单用于回答一个具体问题：审计人员或内审对接人能否在有限时间内，按阶段找到足以支撑“过程符合要求”的记录。本文按立项与需求、设计与开发、测试与发布、变更与缺陷、上线后运维五个阶段组织检查项，每项写明检查内容、通过标准、证据形式、负责人和检查时点，并给出阻断项与整体通过规则。清单只覆盖研发过程符合性证据，平台权限与数据安全治理、认证结论与法律意见不在范围内。ONES 可作为承载工作项流转与评审记录留存的平台之一，后文在证据留存环节说明其衔接方式。
要点总览（TL;DR）
- 清单按立项与需求、设计与开发、测试与发布、变更与缺陷、上线后运维五个阶段组织，每项写明检查内容、通过标准、证据形式、负责人和检查时点。
- 通过标准要写成可核验的事实条件，例如记录存在、审批人齐全、时间顺序合理，并按完全符合、部分符合、不符合三档判定。
- 关键评审缺失、变更无审批、高风险缺陷未闭环、发布记录无法追溯属于阻断项，全部清零才判定通过；非阻断项需有整改计划、责任人与复检时点。
- 证据留存位置应能按项目、版本、时间定位，采用提供、复核、确认三段分工，降低自查自判风险。
- 清单只覆盖研发过程符合性，平台权限与数据安全治理、认证结论与法律意见不在范围内。
谁在什么时点使用这份清单
这份清单服务于“检查与判定”，与日常研发流程文档承担不同任务。流程文档告诉团队怎么做，清单告诉检查人看什么、看到什么程度算通过。因此它适合在固定节点集中使用，而非每天逐条对照。
使用对象包括四类角色：研发负责人对阶段交付物的完整性负责；质量负责人判断测试与缺陷证据是否充分；项目经理组织材料、协调提供人；内审或合规对接人执行独立核查并出具结论。四类角色在检查中的分工不同，同一人兼任多个角色时，建议在检查记录中分别标注，避免自查自判。
使用时点主要有四个：阶段门评审前，确认本阶段应留存的记录已齐备；季度内审时，抽取在研项目做符合性核查；项目结项前，汇总全过程证据；外部审计前，按清单做一轮自查并提前补齐缺口。四个时点的检查深度不同，阶段门偏重本阶段，结项与外部审计前自查覆盖全阶段。
| 使用对象 | 主要使用时点 | 在检查中的职责 |
|---|---|---|
| 研发负责人 | 阶段门评审、结项 | 确认设计、代码、发布相关记录完整，指定提供人 |
| 质量负责人 | 阶段门评审、季度内审 | 核查测试计划、用例、缺陷闭环证据 |
| 项目经理 | 季度内审、结项、外部审计前自查 | 组织材料、汇总证据位置、跟踪整改 |
| 内审或合规对接人 | 季度内审、外部审计前自查 | 独立核查、判定三档结论、出具通过意见 |
范围边界需要在使用前说明：清单核查的是研发过程是否按既定规则留下记录，不评价平台权限配置是否合理，也不对数据安全治理水平下结论；检查结论是组织内部的过程符合性判断，不替代认证机构的审核结论或法律意见。若审计目标包含安全治理，应另设检查表，避免两类问题混在同一份清单里互相稀释。
分阶段检查项：从立项到上线后运维
以下检查项按五个阶段分组，每项给出检查内容与证据形式。检查内容描述“看什么”，证据形式描述“以什么材料证明”。判定口径在下一节统一说明，本节只解决查什么。
立项与需求阶段
- 需求评审记录：检查内容为关键需求是否经过评审、参与角色是否齐全；证据形式为评审会议记录或评审单，含参与人、结论与日期。
- 需求变更审批：检查内容为基线确定后的需求变更是否走审批；证据形式为变更单及其审批记录，需能关联到原需求。
- 范围基线：检查内容为项目范围是否有明确基线及版本；证据形式为基线版本记录或需求清单快照。
设计与开发阶段
- 设计评审：检查内容为关键模块设计是否评审、评审意见是否有回应；证据形式为设计文档及评审记录。
- 代码评审记录：检查内容为合入主干的代码是否经过评审；证据形式为合并请求中的评审意见与批准记录。
- 分支与提交规范：检查内容为分支策略与提交信息是否符合团队约定；证据形式为仓库分支记录与提交日志抽样。
测试与发布阶段
- 测试计划与用例：检查内容为测试计划是否覆盖本次发布范围、用例是否执行；证据形式为测试计划文档与用例执行记录。
- 缺陷记录：检查内容为测试阶段发现的缺陷是否登记并分级；证据形式为缺陷工作项列表，含状态与处理人。
- 发布审批与回滚预案：检查内容为发布是否经审批、是否附回滚方案；证据形式为发布单及审批记录、回滚预案文档。
变更与缺陷阶段
- 变更单与关联工作项：检查内容为上线前后的变更是否登记并关联需求或缺陷；证据形式为变更单及其关联关系记录。
- 高风险缺陷闭环记录：检查内容为高等级缺陷是否完成修复、验证与关闭；证据形式为缺陷工作项的状态流转记录与验证结论。
上线后运维阶段
- 监控告警处置记录：检查内容为线上告警是否有响应与处置记录；证据形式为告警工单或事件记录，含处置时间与结果。
- 线上问题复盘：检查内容为影响较大的线上问题是否完成复盘；证据形式为复盘文档，含原因、改进项与责任人。
- 版本追溯：检查内容为线上运行版本能否对应到发布记录与代码版本；证据形式为发布记录与版本号对照表。
每项检查的通过标准怎么写
通过标准的作用是让两名检查人对同一份材料得出相同结论。写法上要落到可核验的事实条件：记录是否存在、审批人是否齐全、时间顺序是否合理、内容是否与检查对象对应。避免“评审充分”“记录较完整”这类无法判断的表述。
建议每条标准包含三个要素：对象（哪份记录）、条件（满足什么）、可观察结果（看到什么算满足）。例如“需求变更审批”的通过标准可写为：变更单存在，审批人包含需求负责人与技术负责人，审批时间早于变更实施时间。三个条件都能在系统中直接看到，检查人无需再做主观判断。
判定分三档：完全符合指全部条件满足且证据可直接定位；部分符合指记录存在但缺少个别要素，如审批人缺一位或时间顺序存疑；不符合指记录缺失或关键要素无法证明。部分符合不能直接视为通过，需进入整改流程，由责任人补齐后复检。
| 检查项 | 通过标准示例 | 典型不合格情形 |
|---|---|---|
| 需求评审记录 | 评审记录存在，参与人覆盖需求、开发、测试三方，结论明确 | 仅有会议通知，无评审结论与参与人签字 |
| 代码评审记录 | 合并请求含至少一名非作者的批准记录，评审意见有回应 | 直接合入主干，无评审痕迹 |
| 发布审批 | 发布单存在，审批完成时间早于发布时间，附回滚预案 | 先发布后补审批，或回滚预案缺失 |
| 高风险缺陷闭环 | 缺陷状态为已关闭，含修复提交与验证记录 | 缺陷标记为已修复但无验证结论 |
典型不合格的共同特征是“有动作、无记录”或“有记录、无闭环”。前者说明过程执行了但未留痕，后者说明记录停留在中间状态。两类情形在判定上都应归入部分符合或不符合，不能因为团队口头说明而放行。
证据形式、留存位置与负责人
证据能否被审计使用，取决于三件事：形式是否可读、位置是否可定位、责任是否明确。形式可读指记录包含时间、人员、结论等基本要素；位置可定位指能按项目、版本、时间三个维度检索到；责任明确指每类证据都有提供人、复核人和签字确认人。
| 证据类别 | 留存形式 | 定位要求 | 提供人 | 复核人 |
|---|---|---|---|---|
| 评审记录 | 评审单或会议记录 | 按项目与评审日期 | 需求或设计负责人 | 质量负责人 |
| 审批单 | 变更单、发布单 | 按项目与版本号 | 项目经理 | 研发负责人 |
| 工作项流转记录 | 需求、任务、缺陷的状态历史 | 按项目与工作项编号 | 项目成员 | 项目经理 |
| 测试报告 | 测试计划与执行记录 | 按版本与测试轮次 | 测试负责人 | 质量负责人 |
| 发布记录 | 发布单与版本对照表 | 按版本与发布时间 | 发布负责人 | 项目经理 |
分工上建议采用“提供—复核—确认”三段式：提供人负责在检查前把材料放到约定位置；复核人按通过标准逐项核对并标注三档结论；确认人（通常是研发负责人或内审对接人）对整体结论签字。三段分离可以降低自查自判的风险，也让整改责任落到具体人。
留存位置应统一约定，避免同一类证据分散在聊天记录、邮件和本地文件中。约定内容至少包括：存放的系统或目录、命名规则（含项目名与版本号）、保留期限。检查前由项目经理发布一次材料索引，检查人按索引逐项定位，可显著缩短核查时间。
阻断项与整体通过条件
阻断项指一旦缺失或失效，整体结论直接判定不通过的情形。它与普通不符合的区别在于：普通不符合可以带整改计划通过，阻断项必须清零。设置阻断项的目的是守住过程证据的底线，防止用整改承诺替代已发生事实的证明。
建议列入阻断项的情形包括：关键评审缺失，如需求评审或设计评审无任何记录；变更无审批，即已实施的变更找不到审批痕迹；高风险缺陷未闭环，缺陷处于修复中或已修复未验证状态；发布记录无法追溯，线上版本对应不到发布单与代码版本。这四类情形分别对应需求、变更、质量和发布四个关键控制点，任一失守都会使审计结论失去支撑。
非阻断项的整改需要三个要素：整改时限、责任人和复检方式。时限按问题影响面设定，一般问题可在两周内补齐，涉及跨团队协调的可适当延长；复检由原复核人执行，复检通过后更新判定结论。整改计划本身也应作为证据留存，证明问题已被识别并在处理。
| 结论类型 | 判定条件 | 后续动作 |
|---|---|---|
| 通过 | 阻断项全部清零，非阻断项无或已整改完成 | 出具通过意见，归档证据索引 |
| 有条件通过 | 阻断项清零，非阻断项存在但有整改计划、责任人与时限 | 按计划复检，复检通过后转为通过 |
| 不通过 | 任一阻断项未清零 | 限期整改，重新提交检查 |
整体通过条件的表述应写进检查表首页，让所有参与人在检查开始前就知道规则。规则一旦确定，检查过程中不因个别项目的特殊情况临时放宽；确有特殊情形的，应在检查记录中单独说明并由确认人签字，作为例外留痕。
用研发管理平台承载证据留存
清单能否高效执行，很大程度上取决于证据是否本来就沉淀在日常工作中。如果评审、审批、缺陷处理都在研发管理平台内完成，检查时只需按项目与版本检索，而不必临时向各角色收集材料。ONES 在这方面的衔接点在于：需求、任务、缺陷、发布等工作项的状态流转本身构成过程记录，评审与审批可以随工作项或文档留存，检查时按阶段回溯。
具体操作可分三步。第一步，在项目开始时把清单中的证据类别映射到平台对象：需求评审对应需求工作项的评审记录，变更审批对应变更单的审批流转，缺陷闭环对应缺陷工作项的状态历史，发布追溯对应发布记录与版本号字段。第二步，在阶段门和结项前，由项目经理按项目与版本筛选出对应工作项，导出或整理成检查材料包，附上材料索引。第三步，内审时检查人按索引逐项核对，对部分符合项在平台内直接定位到具体工作项，要求责任人补充记录后复检。
这一流程的价值在于把“检查前集中补材料”转为“过程中自然留痕”。需要说明的是，不同团队在平台中的字段配置、审批流设置和导出方式存在差异，工作项流转记录能否按版本完整导出、评审记录以何种字段留存，建议在选型或配置阶段向厂商确认，并以实际配置结果为准。平台承载的是证据的组织与追溯，判定标准仍以本文清单为准。
常见问题
阶段门评审和季度内审使用同一份清单时，检查深度怎么区分？
可以用同一份检查项，但覆盖范围不同。阶段门评审只核查本阶段应留存的记录，例如设计与开发阶段门重点看设计评审和代码评审记录；季度内审按项目抽取，覆盖已发生阶段的全部检查项；结项与外部审计前自查覆盖五个阶段。建议在检查表上标注本次检查的阶段范围，避免检查人把未到阶段的检查项记为缺失。
部分符合的检查项，整改后由谁复检、多久内完成？
复检由原复核人执行，保持判定口径一致。时限按问题影响面设定：单份记录缺要素、可由责任人自行补齐的，一般两周内完成；涉及跨团队协调或需要重新组织评审的，可适当延长并在整改计划中写明原因。复检通过后更新判定结论，整改计划与复检记录一并留存，作为问题已识别并处理的证据。
团队日常在多个系统里协作，证据分散，清单还能用吗？
可以用，但需要先做一次证据位置盘点。由项目经理在检查前发布材料索引，逐类写明证据存放在哪个系统或目录、命名规则和责任人，检查人按索引定位。若同一类证据长期分散在聊天记录和本地文件中，建议在下一阶段把评审、审批、缺陷处理收敛到同一平台完成，让记录随工作项自然沉淀，减少检查前的集中收集。
阻断项判定后，项目是否必须停止推进？
阻断项影响的是审计结论，不直接等同于项目停工。实际处理中，阻断项未清零时整体结论判为不通过，需限期整改并重新提交检查；项目是否暂停由组织根据问题性质决定，例如发布记录无法追溯可能要求先补齐版本对照再继续发布。建议在检查规则中写明阻断项对应的处置要求，让团队提前知道后果。
用研发管理平台承载证据时，需要提前确认哪些配置？
至少确认三件事：需求、任务、缺陷、发布等工作项的状态流转记录能否按项目与版本筛选和导出；评审与审批记录以什么字段或文档形式留存、谁能查看；导出结果是否包含时间、操作人等审计需要的基本要素。不同团队的字段配置与审批流设置存在差异，建议在选型或配置阶段向厂商确认，并以实际配置结果为准。
