為什麼同一批條記錄在幾份交件裡行數和順序都對不上

同一批條記錄在幾份交件裡行數與順序不同，不是因為它們從不同專案取數，而是因為它們從同一份按建立時間取得的快照出發以後，各自採用了不同的排序鍵和展開粒度。表格式產物保留建立時間序，結構化清單重新按場、鏡、條排序，可讀日報又使用另一套鏡頭鍵；與此同時，前兩者會按機位展開，而日報仍是一條 take 一行。

跨檔案對表時，穩定的共同鍵是場、鏡、條身份，不是「第幾行」。

起點相同，後面的排序規則不同

快照最初按記錄建立時間遞增取得。表格式產物之後不再重排，所以它大體保留這個建立時間順序。結構化清單會重新按場次、鏡頭編號與條號排序，其中場次和鏡頭使用自然序比較。於是資料來源相同，但行的位置已經和表格式產物分開。

可讀日報還會再走一套排序：場次之後，它使用鏡頭的限定名作為第二把鍵，再按條號排列。這個限定名並不等於結構化清單使用的原始鏡頭編號，因此兩份檔案即使包含同一批 take，也沒有「第二行就應該對第二行」的關係。

介面日誌還有另一套順序。它按鏡頭號字串遞增，再按條號遞增。字串排序下，10 會排在 2 前面。這是介面層自己的顯示順序，也不能拿來反推匯出檔案中的位置。

行數不同，核心在於是否按機位展開

結構化清單和表格式產物都按機位展開：一條 take 如果包含多個機位，會產生多行；沒有機位時也會保留一行。可讀日報不同，它按 take 數成行，因此一條多機位 take 仍然只佔一行。

這也解釋了為什麼同一個現場記錄集合會產生不同的總行數。一個多機位 take 在清單與表格裡會被拆開，而在日報裡仍是一個 take。日報那一欄看起來像序號的 No. 還是整份檔案的行號，不是 take 編號，所以更不能把它作為跨檔案的對表鍵。

行數不同來自產物粒度不同；它不等於某一份檔案「多了一條拍攝」或「少了一條拍攝」。

鏡頭標識在不同產物裡也可能不是同一個字串

可讀日報會使用鏡頭限定名，而表格式產物的鏡頭欄使用原始鏡頭編號。一個鏡頭在介面或某份檔案中可能帶著場次前綴或限定形態，在另一份檔案裡只保留較短的編號。接收方應把它們放回場、鏡、條關係中理解，而不是僅憑某一欄字串全等來判斷是否同一條。

這裡描述的是我們產物側的機制。目前證據不能繼續斷言某個下游軟體會因此如何錯配、漏配或拒絕匯入。具體接收行為仍應由接收方按自己的匯入範本逐欄核對。

對表時應該用什麼

跨檔案核對時先鎖定場次，再鎖定鏡頭，再看條號；多機位記錄還要繼續看機位。這樣做的目的，是把身份關係當作共同語言，而不是把某一份檔案偶然出現的行位置當成主鍵。

如果兩份檔案的總行數不同，先問它們是不是採用了不同的展開粒度；如果順序不同，再看它們是不是用了不同的鏡頭排序鍵。只有身份關係本身對不上時，才需要回到來源記錄檢查，而不是先要求幾份產物行行對齊。

這套差異是產生機制的結果，但「機制如此」也不等於可以忽略核對。每一份產物承擔不同職責，接收方仍需確認自己使用的欄位確實能回到同一條現場記錄。

FAQ

為什麼表格式產物和結構化清單順序不同？

因為表格式產物保留建立時間序，而結構化清單會按場、鏡、條重新排序。兩者從同一批快照出發，但後續排序規則不同。

為什麼多機位時幾份檔案的總行數不同？

結構化清單和表格式產物按機位展開，一條多機位 take 會佔多行；可讀日報按 take 成行，所以同一條 take 仍只佔一行。

日報裡的 No. 可以拿來和另一份檔案的行號對嗎？

不應該。日報的 No. 是整份檔案的行號，與 take 編號不是同一個概念，不能作為跨檔案身份鍵。

幾份檔案應該用什麼共同鍵來核對？

優先使用場、鏡、條身份，並在多機位記錄上繼續核對機位；不要把行號或某一份檔案的排序位置當成共同鍵。

Axiom One LLC — SlateX。以上數字截至 2026-09-24。