FDX 適合交換什麼，又會丟掉什麼

FDX 在 SlateX 裡承擔的是劇本結構交換：集、場、場頭、日夜標記、頁數、正文項與修訂色可以進入這條鏈路；拍攝完成後的鏡頭、條記錄、拍攝日、機位設定與現場狀態不屬於這次匯入會建立的對象。換句話說，FDX 能把劇本結構帶進來，但「匯入成功」不等於「拍攝工程已經建好」，更不等於往返後會逐字回到原樣。

FDX 在這裡是劇本結構的交換載體，不是拍攝結果的容器。

匯入到底會建出什麼

SlateX 目前的匯入鏈路只建立三類業務對象：集、場和劇本項。鏡頭不會隨匯入建立，條記錄不會建立，拍攝日不會建立，機位設定也不會建立。組別、導演、攝影指導這類製作人員預設也不會由這次匯入建立，需要在產品裡另行手動處理。

這條邊界直接決定了 FDX 適合回答什麼問題。它適合把劇本拆成可讀取的場與正文結構，讓後續記錄有劇本基礎；它不適合被描述成「匯入以後拍攝計畫和現場記錄都準備好了」。結構存在，只說明劇本結構已經進入專案。匯入會建立什麼、不會建立什麼，詳見《劇本匯入會建立什麼，又不會建立什麼》。

首個可讀場頭之前的內容不會形成場內正文

目前的解析以可讀場頭作為建立場的起點。首個可讀場頭之前的段落沒有一個已經存在的場可以掛接，因此不會進入匯入後的場內正文。類似開場條目的內容會落在這條邊界外。

場頭文字本身如果是空的，對應的場也不會被建立。這裡不需要解釋成某種產品「意圖」；準確的說法是：目前建立場的步驟要求有可用的場頭文字，缺少這個承載條件時就沒有場對象可寫。

「解析成功」也可能什麼場都沒有

目前還有一個容易誤判的情況：一份結構良好的 FDX，如果一場都沒讀出來，App 會當場說明這個檔案裡讀不出場次，選場介面不會打開；真正容易看漏的是只讀出一部分場，那種情況下介面照常打開，清單卻少於來源檔案裡的場數。

這說明「檔案解析成功」和「已經匯入了內容」是兩道不同的檢查。前者只能說明檔案讀得出來；後者還要看選場清單裡是否真的出現了場，以及那些場下面是否有對應的劇本項。

匯入狀態寫著成功，不代表已經有場進入專案；先看實際建立出的結構。

往返時有幾處確定會被改寫

往返時會出現幾處確定性改動。由 FDX 匯入過的場再次寫出時，寫出的場頭可能會把標題與日夜資訊附加到已經含有這些元素的場頭上。句點是條件補上的：已經有句點的場頭保持不動，沒有句點的場頭只補一個，所以往返不會出現 INT.. 那種雙點形式。

摘要也不對稱。摘要資訊可以讀入，但把專案寫回檔案時不會帶上同一個摘要，之後的匯入還可能用第一段正文取代場摘要。頁數為零時，不會寫入長度屬性；再次讀取該檔案時，缺少的長度會回到 1/8 頁。拍攝狀態同樣不會隨這條結構交換保留，重新匯入會回到「未拍攝」狀態。

這些觀察來自 SlateX 自己的匯入與匯出結果。它們不能證明其他編劇軟體會怎麼表現。對外能說的更窄：往返不保證逐字保真。

哪些拍攝資訊根本不在這條交換裡

鏡頭、條記錄、拍攝日、機位設定、時碼、檔位、媒體路徑等拍攝結果不在目前 FDX 的承載範圍裡。匯入鏈路沒有建立這些對象，匯出也沒有把這些現場記錄塞進劇本結構。

因此，看到某項資訊沒有回來時，正確的問題是「這一層有沒有承載它的欄位或對象」，而不是替產品編一個「為什麼要丟」的動機。在已核實的事實只是沒有欄位承載它時，不應把這種缺失描述成刻意捨棄資訊的決定。

往返不保真，不等於檔案沒有用途

FDX 仍然適合交換劇本結構。它能把場、場頭、日夜、頁數、正文項等結構帶入 SlateX，也能把目前專案裡的劇本結構寫回檔案。只是這種交換目前應被理解為結構交付，不是一個可以持續來回編輯、每個字元都不變的工作稿迴圈。

接收方如果要繼續使用，應按檔案裡實際存在的結構核對，不要把「能開啟」或「能再次匯入」當作內容保真的證明。

FAQ

FDX 匯入後會自動建立鏡頭和條記錄嗎？

不會。目前的匯入只建立集、場和劇本項，不建立鏡頭、條記錄、拍攝日或機位設定。

檔案解析成功，就表示已經匯入了場嗎？

不一定。一場都沒讀出時，App 會當場說明讀不出場次、不打開選場介面；只讀出一部分時選場照常打開，所以還要檢查實際建立出的場數。

FDX 往返能保持場頭逐字不變嗎？

不能這樣保證。往返之後可能看到標題與日夜疊加、摘要頂替這類改寫，所以這一族對外只寫「往返不保證逐字保真」，以你手上那份檔案往返前後的差異為準。

為什麼某些拍攝資訊不會從 FDX 回來？

因為目前的 FDX 交換沒有承載對應的拍攝對象或欄位。這是承載範圍的邊界，不是關於產品意圖的主張。

Axiom One LLC — SlateX