营运与维护 · 实作指南
文件名一样，不代表收到的是审核那一份
以受控版本、完整摘要与实际位元组比对交接档案，分清完整性、内容审核及授权。
AAHouse 原创解说视频，采用 AI 辅助概念画面、合成旁白及原创音乐。
英文逐字稿 · 简体中文普通话逐字稿 · 台湾华语逐字稿 · 澳门粤语逐字稿
一份打印前的交接单
设想一家美国小型印刷店：AI 整理了客户宣传册，设计师复核后导出 PDF，上传后却又被同名文件覆盖。“文件已上传”只说明动作发生，不说明收到的就是复核那份。以下是虚构交接练习，不是客户事故或产品发布消息。
- 同名 PDF ≠ 已复核的字节
- 导出 → 受控交接 → 实际接收
- 虚构印刷店 · 非客户事故
未经修改的原始来源说明图。
先冻结字节，再写收据
我们建议把导出完成的文件作为交接对象，记录版本、字节数、所用算法和完整摘要，例如 SHA-256。接收方对实际下载的文件重新计算并比较；不要只比较文件名或截图。S3 官方文档把校验值用于上传、下载的数据完整性验证。[1] 这是一种机制，不是对所有工具的默认承诺。
- 对象：导出完成的文件
- 收据：版本 + 字节数 + 算法 + 完整摘要
- 接收端：重新计算并比较
未经修改的原始来源说明图。
三种结果，三条路线
摘要一致：进入下一项内容检查，不自动开始印刷。摘要不一致：保留两份文件，停止这个交接并调查转换或传输。没有摘要：标成未验证，不用“看起来一样”代替证据。这里的流程是我们的建议；摘要比较是否可信，还取决于预期值来自哪里。
- 一致 → 内容复核
- 不一致 → 停止交接，保留证据
- 缺少可信预期值 → 未验证
未经修改的原始来源说明图。
信任不能只靠一串字符
如果文件和预期摘要都来自同一个不可信来源，一起被替换仍可能匹配。摘要不是作者身份证、内容正确证明或执行授权。RFC 9530 明确区分完整性机制与身份认证、授权、隐私；其摘要字段还可以结合签名使用。[2] 保存预期值时，应沿用经过认证且受控的交接渠道。
- 摘要：完整性证据
- 不是：身份、正确性或执行授权
- 预期值：经过认证且受控
未经修改的原始来源说明图。
转换是新对象，不是失败借口
压缩、重新导出或修改元数据都可能改变字节。我们的做法是分别保存原件与派生件的摘要及转换关系，不能先改文件再沿用旧收据。HTTP 规范也区分消息内容与表示数据的摘要，编码和所选对象会影响比较。[2] 接口团队须明确究竟校验哪一层，不要混用。
- 原件摘要 → 转换记录 → 派生件摘要
- 不要给新字节沿用旧收据
- 接口明确：哪一层、哪种算法
未经修改的原始来源说明图。
用两份合成文件验收
交付前安排一次小演练：原样副本应通过；改动一个字节的副本应停止；合法转换应生成新记录；缺少可信预期值应显示未验证。以上是建议测试，未在客户系统执行。最后把“字节核对通过”和“内容审核通过”分成两栏。AAHouse 的版本化审批指南补充解释了为何审批仍须绑定具体版本。
- 原样通过；改一字节停止
- 转换新建记录；无预期值未验证
- 字节核对 ≠ 内容审批
未经修改的原始来源说明图。