3. 需求分析

在构建审批工作流之前，必须对“变更”本身进行精确的需求分析。本章以一个典型的代码合并（Pull Request）与文档审批混合场景为例，解读其背后的核心需求。该场景融合了技术资产（代码）与业务资产（文档）的变更管理，是工程团队中最常见的协作模式。

3.1 场景定义：混合资产变更

假设我们正在为一个内部微服务项目“Order-Service”实施变更。本次变更涉及两部分内容：

• 代码变更：修复订单超时计算的边界条件 Bug，修改了 src/core/order.go 和 src/api/handler.go 两个文件。
• 文档变更：同步更新了 API 接口文档 docs/api-order-v2.md，并新增了变更日志 CHANGELOG.md 条目。

该变更的审批流程不能简单一刀切，必须根据资产类型和变更影响范围进行差异化处理。

3.2 需求文档关键要素解读

一份合格的变更需求文档（通常以 PR 描述或变更单形式存在）应包含以下五个核心要素。我们以表格形式进行结构化解读：

3.3 权限模型：谁可以批准什么？

基于上述需求要素，我们可以推导出权限模型。权限不是简单的“管理员/普通用户”二元划分，而是基于文件路径和变更类型的细粒度控制。

• 路径匹配规则：src/* 路径下的变更由 @tech-leads 组审查；docs/* 路径下的变更由 @product-owners 组审查。
• 变更类型规则：对于 D（删除）类型的变更，无论路径如何，都需要 @architects 组额外批准。
• 冲突处理：当同一个文件同时被代码和文档审查人关注时（如 README.md），采用“任一通过即通过”或“全部通过才通过”的策略。本案例采用后者，确保质量。

3.4 变更记录：不可篡改的审计轨迹

每一次审查意见、状态变更、权限判定都必须被记录，形成完整的变更记录（Change Log）。这不仅是合规要求，更是事后追溯和问题定位的关键。

一个典型的变更记录条目应包含以下字段：

{
  "changeId": "CHG-2025-003",
  "timestamp": "2025-04-08T10:30:00Z",
  "actor": "alice",
  "action": "APPROVE",
  "resource": "src/core/order.go",
  "context": {
    "reviewComment": "边界条件处理逻辑正确，单元测试覆盖充分。",
    "previousStatus": "PENDING_REVIEW",
    "newStatus": "APPROVED"
  },
  "signature": "sha256:abc123..."
}

该记录采用结构化 JSON 格式，便于写入事件存储（如 Kafka 或数据库审计表）。signature 字段用于防止记录被篡改，是工程合规性的重要保障。

3.5 需求分析总结：从文档到工作流

通过上述需求解读，我们可以将零散的需求文档转化为可执行的工作流规则。下图展示了从“变更提交”到“审批完成”的核心逻辑：

该流程图清晰地展示了：变更提交后，系统自动解析范围，通过 CODEOWNERS 匹配审查人，然后触发并行审查。只有当所有必要的审查意见都通过后，汇总决策环节才会执行最终的合并或批准操作，并生成不可篡改的变更记录。