營運與維護 · 實作指南
檔名一樣，不代表收到的是審核那一份
以受控版本、完整摘要與實際位元組比對交接檔案，分清完整性、內容審核及授權。
AAHouse 原創解說影片，採用 AI 輔助概念畫面、合成旁白及原創音樂。
英文逐字稿 · 簡體中文普通話逐字稿 · 台灣華語逐字稿 · 澳門粵語逐字稿
一份列印前的交接單
設想一家美國小型印刷店：AI 整理了客戶宣傳冊，設計師複核後匯出 PDF，上傳後卻又被同名檔案覆蓋。“檔案已上傳”只說明動作發生，不說明收到的就是複核那份。以下是虛構交接練習，不是客戶事故或產品釋出訊息。
- 同名 PDF ≠ 已複核的位元組
- 匯出 → 受控交接 → 實際接收
- 虛構印刷店 · 非客戶事故
已接受的區域說明圖重繪，並非未經修改的原始截圖。
先凍結位元組，再寫收據
我們建議把匯出完成的檔案作為交接物件，記錄版本、位元組數、所用演算法和完整摘要，例如 SHA-256。接收方對實際下載的檔案重新計算並比較；不要只比較檔名或截圖。S3 官方文件把驗證值用於上傳、下載的資料完整性驗證。[1] 這是一種機制，不是對所有工具的預設承諾。
- 物件：匯出完成的檔案
- 收據：版本 + 位元組數 + 演算法 + 完整摘要
- 接收端：重新計算並比較
已接受的區域說明圖重繪，並非未經修改的原始截圖。
三種結果，三條路線
摘要一致：進入下一項內容檢查，不自動開始印刷。摘要不一致：保留兩份檔案，停止這個交接並調查轉換或傳輸。沒有摘要：標成未驗證，不用“看起來一樣”代替證據。這裡的流程是我們的建議；摘要比較是否可信，還取決於預期值來自哪裡。
- 一致 → 內容複核
- 不一致 → 停止交接，保留證據
- 缺少可信預期值 → 未驗證
已接受的區域說明圖重繪，並非未經修改的原始截圖。
信任不能只靠一串字元
如果檔案和預期摘要都來自同一個不可信來源，一起被替換仍可能相符。摘要不是作者身份證、內容正確證明或執行授權。RFC 9530 明確區分完整性機制與身份認證、授權、隱私；其摘要欄位還可以結合簽名使用。[2] 儲存預期值時，應沿用經過認證且受控的交接渠道。
- 摘要：完整性證據
- 不是：身份、正確性或執行授權
- 預期值：經過認證且受控
已接受的區域說明圖重繪，並非未經修改的原始截圖。
轉換是新物件，不是失敗藉口
壓縮、重新匯出或修改中繼資料都可能改變位元組。我們的做法是分別儲存原件與衍生檔的摘要及轉換關係，不能先改檔案再沿用舊收據。HTTP 規範也區分訊息內容與表示資料的摘要，編碼和所選物件會影響比較。[2] 介面團隊須明確究竟驗證哪一層，不要混用。
- 原件摘要 → 轉換記錄 → 衍生檔摘要
- 不要給新位元組沿用舊收據
- 介面明確：哪一層、哪種演算法
已接受的區域說明圖重繪，並非未經修改的原始截圖。
用兩份合成檔案驗收
交付前安排一次小演練：原樣副本應通過；改動一個位元組的副本應停止；合法轉換應生成新記錄；缺少可信預期值應顯示未驗證。以上是建議測試，未在客戶系統執行。最後把“位元組核對通過”和“內容審核通過”分成兩欄。AAHouse 的版本化審核指南補充解釋了為何審核仍須繫結具體版本。
- 原樣通過；改動一個位元組就停止
- 轉換新建記錄；無預期值未驗證
- 位元組核對 ≠ 內容審核
已接受的區域說明圖重繪，並非未經修改的原始截圖。