NOTEQuality Engineering

重组派生产物后,如何让哈希、QA 与能力认证保持一致

本文结论

派生产物通过本地检查后,下游 QA 与能力记录仍可能引用旧文件。本文介绍如何让身份变化沿完整证明链传播。

一条媒体流水线替换单个源片段后,成功重组了最终视频。新文件通过仓库技术检查,也获得了新的视觉评分卡,独立审计却仍然失败:任务状态保存的是上一版成片哈希。

修复这一处哈希后,复核又发现第二个陈旧绑定。能力认证同时引用旧成片和旧对照评分卡。这次故障说明,替换派生产物会改变一整张证据依赖图,不能只把它当成一次文件写入。

第一次失败提供了有效证据

独立审计比较了三种身份:

证据 应有绑定
磁盘文件 当前组装产物的 SHA-256
任务状态 同一个当前 SHA-256
视觉评分卡 同一个当前 SHA-256,以及相关输入哈希

文件与评分卡一致,任务状态却仍指向上一版产物,因此审计在最终批准前停止。这是正确的门禁结果:技术通过只能证明文件可解码并满足可测指标,不能证明所有审批记录都引用这个文件。

直接根因是生命周期顺序错误。流水线在组装阶段写入 final.mp4,却到最终批准阶段才更新 final_sha256。两步之间运行的任何独立检查都会读到陈旧状态。

在组装边界绑定产物身份

修复把身份绑定移动到创建或替换产物的操作中:

def assemble_and_bind(state, output):
    assemble(output)
    technical_result = run_technical_gates(output)
    if not technical_result.passed:
        raise GateFailure(technical_result.reasons)

    state["final_sha256"] = sha256(output)
    state["final_bound_at"] = now()
    save(state)

这个顺序建立了明确契约:组装和技术验证成功后,即使视觉审批还在等待,任务状态也必须标识当前产物。最终审批只需核对评分卡是否绑定同一身份,不再顺带修改身份。

流水线还为修复前已经生成的产物增加了受限对账入口。它只允许在审批尚未完成时运行,要求技术 QA 已通过,并要求当前视觉评分卡已经绑定磁盘上的文件;记录中同时保留旧哈希与新哈希。这样的对账会在证据不足时关闭,不能演变成通用绕过命令。

沿证明链继续检查下游

只更新任务状态仍然不够。同一产物身份还出现在下游能力记录中:

组装产物
  -> 技术 QA
  -> 视觉评分卡
  -> 对照评分卡
  -> 能力认证

每条箭头都代表依赖关系。产物变化后,每个后代证明都必须重新计算、失效,或证明自己不受该变化影响。遗漏任何一层都会形成状态分裂:当前任务看起来已经通过,注册表认证的却仍是旧文件。

能力刷新采用了四项约束:

  1. 只刷新同一任务、同一能力模式下已有的通过记录;
  2. 要求当前技术、视觉和对照门禁全部通过;
  3. 把被替换的认证复制到只追加的 history,并标记为已被新证据取代;
  4. 保留其他能力模式和注册表总体资格状态。

这些约束可以阻止返工意外认证另一个任务、扩大能力范围,或抹掉旧决策曾经依赖的证据。

为失效传播定义明确策略

派生产物系统可以按身份变化后的反应方式,对下游记录分类:

依赖类型 替换产物后的动作
内容绑定 重新计算或失效
输入集合绑定 任一绑定输入变化时重新计算
任务绑定且与内容无关 核对任务身份后保留
历史记录 标记为被取代后保留,不能继续作为当前证据

这套分类同时避免两个常见错误。全部删除会破坏审计历史;全部复用会把陈旧证据展示成当前事实。按依赖类型处理,能够严格维护当前状态,同时留下完整变更轨迹。

验证要同时证明失败和恢复

修复后的流水线通过了多层验证:

  • 独立审计先因陈旧哈希失败,没有接受“技术合格但绑定错误”的文件;
  • 定向测试证明组装阶段会在视觉批准前绑定当前产物;
  • 对账测试拒绝缺失技术证据或评分卡不匹配的状态;
  • 能力测试只刷新同一任务的证据,把旧认证保留到历史,并保持其他能力模式不变;
  • 完整离线测试共 277 项,全部通过;
  • 最终只读审计确认检查证据时没有改写生产状态。

测试数量本身不是主要结论。更重要的是,测试覆盖了导致故障的状态迁移:创建、等待审批、对账、同任务返工、历史保留和无关能力隔离。

可复用的设计规则

这套方法适用于视频、编译包、生成式报告、机器学习模型、签名归档,以及所有把审批绑定到内容哈希的产物。

  1. 在产物成为权威版本的边界绑定身份,不要推迟到审批步骤。
  2. 保存证据输入的哈希,不能只保存最终结论。
  3. 把审批与认证建模为依赖图。
  4. 让产物替换触发确定性的失效或刷新规则。
  5. 把旧证明作为历史保留,并与当前事实明确分开。
  6. 增加只读独立验证器,发现异常时不要自动修复。

适用边界

哈希一致只能证明记录引用同一组字节,不能证明产物正确、视觉合格、安全,或适配所有下游消费者,这些性质仍需各自的门禁。

这套方案还假设系统能够在产物生成后可靠更新状态。无法原子发布文件与元数据的系统,需要可恢复的两阶段协议,例如先写入 pending(待完成)记录,再把产物移动到目标位置,最后提交当前绑定。具体存储机制可以不同,但不变量必须保持:任何当前认证都不能继续指向已经被取代的字节。

遇到类似系统问题?

先说明系统,再说明症状

如果需要生产排障、DevOps 交付或物流系统集成协作,请提供当前表现、预期结果、受影响环境、可用日志或数据样例,以及发布限制。我会从现有证据开始判断。

通过邮件开始