3. 变更记录的唯一标识符规则

在工程项目全生命周期中，图纸与文档的变更是常态。为了确保每一次变更都可追溯、可定位、不混淆，必须建立一套严谨的唯一标识符（Unique Identifier, UID）规则。本章将详细阐述“项目代码+专业代码+流水号”的编码结构、版本号管理机制以及避免编号冲突的工程实践。

3.1 编码结构：项目代码 + 专业代码 + 流水号

唯一标识符是每份文档的“身份证”。推荐采用三段式组合编码，确保在组织级范围内唯一。其基本结构如下：

各字段定义与规则：

下图展示了唯一标识符的生成与解析流程：

3.2 版本号管理（V1.0, V2.0）

版本号用于追踪同一份文档（同一UID）在生命周期内的不同状态。采用主版本号.次版本号的格式，严格区分重大变更与微小修订。

下图展示了版本号在文档生命周期中的演进路径：

3.3 如何避免编号冲突

编号冲突会导致文档混淆、版本覆盖甚至施工事故。必须从流程、工具和审计三个层面建立防冲突机制。

3.3.1 集中分配与预注册

• 集中分配：所有 UID 由文档控制中心（DCC）统一分配，任何个人或专业组不得自行生成。
• 预注册机制：在文档创建前，先向 DCC 申请 UID，并在文档管理系统中预注册。即使文档尚未生成，该 UID 已被锁定，防止他人占用。

3.3.2 系统级校验规则

文档管理系统应内置以下校验逻辑，从技术层面杜绝冲突：

# 伪代码：UID 唯一性校验逻辑
function validateUID(projectCode, disciplineCode, serialNumber):
    uid = projectCode + "-" + disciplineCode + "-" + serialNumber
    if uid exists in database:
        return "错误：该 UID 已存在，请重新申请流水号"
    else:
        # 检查流水号是否被跳过
        maxSerial = getMaxSerial(projectCode, disciplineCode)
        if serialNumber != maxSerial + 1:
            return "警告：流水号不连续，建议使用 " + (maxSerial + 1)
        return "校验通过，UID 可用"

3.3.3 版本号冲突预防

• 版本锁定：一旦某版本号被发布，系统自动锁定该版本号，禁止再次提交相同版本。
• 版本回退规则：如果需要回退到旧版本，必须创建新版本号（如 V2.2），并在变更记录中注明“回退至 V1.0 内容”，而不是直接覆盖 V2.1。

3.3.4 定期审计与清理