為什麼同一批條記錄在幾份交件裡行號互不對應

同一批條記錄在幾份交件裡行號互不對應，不是因為它們從不同專案取數，而是因為每種產物都按自己的排序規則輸出。表格式產物保留建立時間序，結構化清單重新按場、鏡、條排序，可讀日報又使用另一套鏡頭鍵；三件現在都按機位展開，所以同一趟導出的行數其實是同一個粒度，對不上的只剩行序。

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

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

表格式產物大體按記錄建立的時間先後排列。結構化清單會重新按場次、鏡頭編號與條號排序，其中場次和鏡頭使用自然序比較。於是同一批記錄在兩種產物裡的行位置不再對應。

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

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

行號不對應，核心在於各走一套排序鍵

三件都按機位展開：一條 take 若包含多台機位，各自生成多行；沒有機位時也照樣保留一行。所以同一趟導出的三份檔案，行數其實是同一個粒度——差別只在同樣這些行被各自的鍵排成了不同的次序。

這也解釋了為什麼行號互不對應：CSV 大體按記錄建立的先後，ALE 按場次、鏡頭編號、條號重排，日報按場次、鏡頭限定名、條號。日報那一欄看起來像序號的 No. 還是整份檔案的行號，不是 take 編號，所以更不能把它作為跨檔案的對表鍵。

行號不對應來自各套排序鍵不同；它不等於某一份檔案「多了一條拍攝」或「少了一條拍攝」。

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

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

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

對表時應該用什麼

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

同一趟導出的三份檔案，行數現在已經是同一個粒度，順序不同就先看它們各用了哪套排序鍵。跨趟比不成立：只有按拍攝日那一趟才生成日報，整部戲那一趟只有 ALE 與 CSV。只有身份關係本身對不上時，才需要回到來源記錄檢查，而不是先要求幾份產物行行對齊。需要在接收方流程裡判斷一份交件能否繼續用時，可按《接收方怎樣判斷一份現場交件可以繼續用》的核對順序另行檢查。

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

FAQ

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

因為表格式產物保留記錄先後，機讀清單會按場、鏡、條重新排序。兩者出自同一批條記錄，之後的次序規則不同。

同一趟導出的幾份檔案，總行數一樣嗎？

一樣。三件都按機位逐台出行，一條多機位 take 在三件裡都佔同樣的幾行；不一樣的是次序。整部戲那一趟不生成日報，跨那種趟比行數本身就不成立。

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

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

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

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

Axiom One LLC — SlateX