資產紀錄／ASSET LEDGER
《夜獵》素材盤點：98 檔正典圖庫與「同名取最高版」的版本判準
98 檔正典圖庫、同名取最高版的判準，與 1.1GB 主檔逐位元驗證的盤點全紀錄。
事情是這樣開始的：第一季都交付了，我們在整理成果的時候，把一支已經停用的舊版集數當成現行版呈現了出去——當場被抓包。那支片子就躺在 Drive 根目錄，檔名看起來一本正經，內容卻是舊章節。沒有人粗心，是根本沒有人定義過「哪個檔案算數」。
《夜獵 NIGHT HUNTRESS》第一季 8 章加合集做完之後，素材散在三個地方：本地工作目錄、生成平台的歷史紀錄、還有先前交付留下的成片。同一個東西有好幾個長得很像的版本，誰來接手——包括隔週的自己——都可能挑錯。所以我們停下來做了一件很無聊的事：盤點。把全部素材收成一個正典圖庫，定下版本判準，再把主檔驗證歸檔。這篇就是那次盤點的完整紀錄；它和第 1 篇〈臉部基準圖工作法〉是一組的：那篇講生成的引用紀律，這篇講檔案的治理紀律。
- 環境 ENVIRONMENT
- 《夜獵》第一季（8 章＋合集）交付後的素材盤點；Google Drive「夜獵」資料夾
- 工具 TOOLS
- Drive 正典圖庫（incoming，98 檔）；主檔經 Dropbox 中轉歸檔
- 實測日期 TESTED ON
- 正典定案 2026-10-16；歸檔驗證 2026-10-21；本篇查核 2026-10-22
- 成本 COST
- 無工具支出；盤點與驗收工時併入第 4 篇季成本帳
- 正典圖庫（canonical asset library）＝專案唯一認可的素材來源；引用素材只從這裡取，「哪個版本算數」由書面判準決定，不靠任何人的記憶。
- 《夜獵》的正典是 Google Drive「夜獵／incoming 圖庫」，2026 年 10 月 16 日定案：首輪盤點 94 檔，同日晚間補入 4 檔角色設定圖，共 98 檔。
- 版本判準：同名多版本一律取 r 值（修訂序號）最高者；正典以外的舊本地影片與素材全部停用。
- 主檔歸檔驗證（2026-10-21）：兩支第一季合集各約 1.1GB，Drive 端檔案大小與本地母帶逐位元一致——投稿版 1,116,570,054 bytes、v2-1080p 版 1,095,364,996 bytes。
盤點那天，我們先把 94 檔全攤開
盤點紀錄的第一頁寫得很白：incoming 圖庫首輪共 94 檔，全部平鋪、沒有子資料夾，分四區——第三章分鏡素材 36 檔（16 鏡首尾幀幾乎全齊）、角色設定三視圖 33 檔（李夜兒、白蛇、鴉先生與配角們）、場景圖 22 檔、道具 3 檔。當晚使用者再補上傳 4 檔新角色設定圖（陳渡兩版、千面、白手套），我逐一下載親驗過，總數到 98。
攤開之後，問題就現形了。同名多版本並存的有四組：服裝 A 三視圖有原版、r2、r3；林曉、鴉先生 49 號圖、玉言弩各有兩版。哪一張才是「現在這張臉」？在定判準之前，答案是「看誰記得」。而根目錄那支誤標的合集（575.81MB，內容是舊章節）就是這種模糊的代價——它甚至不是粗心存錯，是從來沒人說過它不算數。
順帶一提，圖庫裡當時沒有任何第一季成片、章節影片、海報或 Logo——正典庫收的是「生成與設定的源頭素材」，成片主檔走另一條歸檔線（見文末的驗證紀錄）。先分清楚庫的用途，盤點才不會越盤越亂。
判準只有三條，寫下來就生效
2026 年 10 月 16 日定案的判準，原文不長，執行起來是這樣：
| 判準 | 內容 | 擋住的錯誤 |
|---|---|---|
| 來源唯一 | Google Drive「夜獵／incoming 圖庫」（98 檔）為唯一正典；引用素材只從這裡取 | 從本地舊目錄或平台歷史隨手抓檔 |
| 同名取最高版 | 同名檔案有多個版本時，以 r 值（修訂序號）最高者為準，不逐案判斷 | 「看起來比較新」的主觀挑版 |
| 舊版全面停用 | 正典以外的舊本地影片與素材全部停用，不再引用、不再呈現 | 已淘汰的集數或圖被當成現行成果 |
這裡要特別講「同名取最高版」為什麼不逐案判斷。逐案判斷聽起來認真，其實是把決定權交給當下的人——而當下的人可能很累、可能沒參與那一版的修改、可能就是隔週的我。判準寫死的好處是：它不需要你是對的人，它只需要你照做。第 1 篇講的臉部特寫基準圖也在這套判準裡——基準圖是正典庫的成員，所以每次生成引用的都是同一個檔案、同一張臉，不會漂移成「某次用的那張」。
主檔歸檔：1.1GB 的檔案，我們核對到最後一位數
盤點完還有最後一關。第一季兩支合集（投稿版與 v2-1080p 版）各約 1.1GB，2026 年 10 月 21 日才完成歸檔：因為體積大，走 Dropbox 中轉，由使用者下載、合併、上傳到 Drive「夜獵／04_主檔與交付包」。我方再實查 Drive 端的檔案大小，跟本地母帶逐位元對照：
| 主檔 | 位元組數（兩端一致） |
|---|---|
| 合集投稿版 | 1,116,570,054 bytes |
| 合集 v2-1080p | 1,095,364,996 bytes |
兩筆一位不差。這一步看起來龜毛，但大檔案跨平台中轉最常見的失敗，恰恰是「傳到 99% 的殘檔看起來很正常」。大小核對是成本最低的完整性證據——不用開片、不用等轉碼，一眼見真章。為什麼母帶非自己存不可，第 8 篇〈Sora 退場啟示錄〉從平台面講了另一半：平台會退場，正典庫不會。
到這裡，《夜獵》第一季在素材面才算真正結案：正典在庫、舊版停用、主檔驗證入庫。作品本人在這裡看得到：夜獵 YouTube 頻道。
失敗與限制：這套判準擋不住什麼
照本站規矩，這一段不省略：
- 判準靠命名紀律活著。r 值判準的前提是每個新版本都老實遞增序號；若存檔時忘了升版，判準會「正確地」選到錯的檔案。制度擋的是隨手，擋不了繞過制度的人——所以「正典以外不引用」要同時是硬規則，讓繞過的成本變高。
- 98 檔是當日快照。正典庫會隨製作長大——定案當晚就從 94 檔補到 98 檔。盤點不是一次性的事，是每季交付後的固定收尾；本篇數字只代表 2026-10-16 定案時點。成本面我們記在第 4 篇的季成本帳裡，盤點工時也在其中。
- 逐位元核對只證明大小相同。嚴格說，這是完整性的強證據，不是密碼學證明。我們的威脅模型是傳輸殘缺而非竄改，這個等級足夠；若日後涉及對外交付爭議，應升級為雜湊值核對。
出處與延伸
- 《夜獵》Drive 正典素材盤點紀錄（2026-10-16，專案內部文件）：94 檔首輪盤點分區、同日晚間補入 4 檔至 98 檔、同名多版本清單與誤標合集查明，皆出自此處。
- 《夜獵》素材正典定案（2026-10-16）：來源唯一、同名取最高 r 值、舊素材停用三項判準出自此處。
- 《夜獵》Google Drive 歸檔驗證紀錄（2026-10-21）：兩支合集位元組數與入庫路徑（04_主檔與交付包）出自此處，數字經我方實查。
- 本站第 1 篇〈夜獵是怎麼讓 AI 角色 8 章不換臉的〉：臉部特寫基準的引用工作流；本篇的正典庫正是那套工作流的檔案面。
- 本站第 8 篇〈Sora 退場啟示錄〉：母帶自存的平台面——平台會退場，正典庫不會。
- 夜獵 NIGHT HUNTRESS YouTube 頻道：第一季成品的公開版本。
VERDICT・結論
我的建議：每個 AI 產線在第一個專案交付後，就做一次正典盤點。定唯一來源、定版本判準、停用舊版、主檔驗證入庫——半天做完。拿錯版本的事故不會預告，它只會在你把舊版當現行版交出去的那一刻發生；判準立得越晚，散掉的檔案越多、盤點越貴。這套做法的完整背景在關於頁的六項紀錄原則裡，寫作格式則在入門頁有說明。
常見問題
什麼是「正典圖庫」？為什麼不直接用最新檔案就好？
正典圖庫是專案唯一認可的素材來源：引用素材只從這裡取，「最新」由判準決定而不是由誰的記憶決定。AI 產線一季就有上百個檔案、多個同名版本，「直接用最新的」在實務上等於「用某人以為最新的那個」，拿錯版事故就是這樣來的。
「r 值」是什麼？是業界標準嗎？
不是業界標準，是本專案的版本命名慣例：同名檔案每次修訂遞增修訂序號（r 值），盤點判準規定同名多版本一律取 r 值最高者。重點不在命名法本身，在「判準寫死、不逐案判斷」——換成日期或序號命名都能成立。
舊素材停用是刪掉嗎？
不是刪除，是標記停用、不再引用與呈現。停用的理由是防誤用（把淘汰版本當現行成果），不是銷毀紀錄；歷史版本仍在原處，只是離開流通路徑。
為什麼歸檔要核對到位元組？看上傳成功不夠嗎？
不夠。約 1.1GB 的檔案經第三方中轉（本次走 Dropbox）下載、合併、上傳，任一環節中斷都可能留下看似正常的殘檔。這次兩支合集（1,116,570,054 與 1,095,364,996 位元組）在 Drive 端與本地母帶逐位一致，才算歸檔完成。
這套做法適用於小團隊或個人創作者嗎？
適用，而且越早越便宜：判準只有三條（來源唯一、同名取最高版、舊版停用），不需要任何付費工具。檔案還少時立判準是半天的事，等累積到數百檔再盤點，就是本篇這種規模的工程了。
相關閱讀
