2. 变更记录基础：变更记录的定义、变更记录的核心要素（谁、什么、何时、为何）

变更记录是软件配置管理（SCM）与质量保证体系中最基础的原子单元。它并非简单的“修改日志”，而是一份具备可追溯性、不可抵赖性、可审计性的结构化数据载体。在审查意见闭环中，变更记录充当了“证据链”的角色——它回答了每一次修改的完整上下文。

2.1 变更记录的定义

变更记录（Change Record）是指在软件生命周期中，对受控项（如源代码、需求文档、测试用例、设计规格、配置文件等）所实施的任何修改的正式描述与存档。它必须满足以下三个基本特征：

• 原子性：一条记录对应一次逻辑上不可分割的修改操作。
• 完整性：包含修改的发起者、时间戳、修改内容摘要、修改原因。
• 持久性：一旦提交，记录本身不可被篡改或删除（仅可追加注释或标记废弃）。

2.2 变更记录的核心要素：4W 模型

任何合格的变更记录都必须包含四个核心维度，即 Who（谁）、What（什么）、When（何时）、Why（为何）。这四者构成了变更的“元数据骨架”。

2.3 4W 模型的逻辑关系与数据流

下图展示了变更记录中四个核心要素之间的数据流向与依赖关系。Who 触发 When，When 记录 What，而 Why 作为驱动源头贯穿始终。

2.4 各要素的详细规范与常见陷阱

2.4.1 Who（谁）—— 身份与责任

• 规范要求：必须使用全局唯一的用户标识（如 LDAP 账号、邮箱），禁止使用昵称、别名或共享账号。
• 常见陷阱：使用“admin”或“root”等系统级账号提交变更，导致无法定位到具体自然人。
• 最佳实践：在 CI/CD 流水线中，强制要求提交者签名（GPG 或 S/MIME），实现不可抵赖性。

2.4.2 What（什么）—— 范围与影响

• 规范要求：明确列出受影响的文件列表、配置项标识、数据库脚本编号。对于代码变更，应包含变更行数统计（++/--）。
• 常见陷阱：仅写“修复了若干 bug”或“优化了性能”，缺乏具体的文件路径和变更类型。
• 最佳实践：使用自动化工具生成变更影响分析报告，自动关联受影响的测试用例。

2.4.3 When（何时）—— 时间与版本

• 规范要求：使用 ISO 8601 格式（如 2025-03-21T14:30:00+08:00），并记录对应的构建版本号或基线标签。
• 常见陷阱：仅记录日期而忽略时区，导致跨团队协作时时间线混乱。
• 最佳实践：所有时间戳统一使用 UTC 存储，展示时按用户时区转换。

2.4.4 Why（为何）—— 动机与上下文

• 规范要求：必须关联一个外部可追溯的 ID（如需求编号 REQ-1234、缺陷编号 BUG-5678、审查意见编号 CR-001）。
• 常见陷阱：仅写“根据要求修改”或“修复问题”，没有提供任何可追溯的链接。
• 最佳实践：在提交信息中强制包含 Closes #ISSUE_ID 或 Related-to: REQ-XXXX 等结构化引用。

2.5 变更记录在审查意见闭环中的角色

在审查意见闭环中，变更记录是连接“发现问题”与“验证修复”的桥梁。下图展示了变更记录如何嵌入审查流程：

2.6 变更记录质量检查清单

在审查意见闭环中，每次提交变更记录前，建议使用以下清单进行自检：

1. Who 检查：提交者身份是否可追溯到具体自然人？是否使用了签名？
2. What 检查：是否列出了所有受影响的文件/配置项？变更类型是否明确？
3. When 检查：时间戳是否包含时区？是否关联了构建版本号？
4. Why 检查：是否关联了审查意见 ID 或需求/缺陷编号？理由描述是否清晰？
5. 完整性检查：四个要素是否全部非空？是否存在“待补充”或“TBD”占位符？