FDX 適合交換什麼，又會丟掉什麼
FDX 在 SlateX 裡承擔的是劇本結構交換：集、場、場頭、日夜標記、頁數、正文項與修訂色可以進入這條鏈路；拍攝完成後的鏡頭、條記錄、拍攝日、機位設定與現場狀態不屬於這次匯入會建立的對象。換句話說，FDX 能把劇本結構帶進來，但「匯入成功」不等於「拍攝工程已經建好」，更不等於往返後會逐字回到原樣。
FDX 在這裡是劇本結構的交換載體，不是拍攝結果的容器。
匯入到底會建出什麼
SlateX 目前的匯入鏈路只建立三類業務對象：集、場和劇本項。鏡頭不會隨匯入建立，條記錄不會建立，拍攝日不會建立，機位設定也不會建立。組別、導演、攝影指導這類製作人員預設在這條匯入路徑上也沒有寫入點，需要在產品裡另行處理。
這條邊界直接決定了 FDX 適合回答什麼問題。它適合把劇本拆成可讀取的場與正文結構，讓後續記錄有劇本基礎；它不適合被描述成「匯入以後拍攝計畫和現場記錄都準備好了」。結構存在，只說明結構進入了資料模型。
首個可讀場頭之前的內容不會形成場內正文
目前的解析以可讀場頭作為建立場的起點。首個可讀場頭之前的段落沒有一個已經存在的場可以掛接，因此不會進入匯入後的場內正文。類似開場條目的內容會落在這條邊界外。
場頭文字本身如果是空的，對應的場也不會被建立。這裡不需要解釋成某種產品「意圖」；準確的說法是：目前建立場的步驟要求有可用的場頭文字，缺少這個承載條件時就沒有場對象可寫。
「解析成功」也可能什麼場都沒有
目前還有一個容易誤判的情況：一份結構良好的 FDX，如果裡面沒有任何可讀場頭，解析過程仍可能回傳成功，並照常開啟選場介面，但清單是空的，也沒有額外提示。
這說明「檔案解析成功」和「已經匯入了內容」是兩道不同的檢查。前者只能說明解析流程走到了成功分支；後者還要看選場清單裡是否真的出現了場，以及匯入後是否建立了對應的劇本項。
匯入狀態寫著成功，不代表已經有場進入專案；先看實際建立出的結構。
往返時有幾處確定會被改寫
SlateX 目前的讀寫兩側程式碼可以推出幾處確定性改寫。由 FDX 匯入過的場再次寫出時，場頭構造會把已經包含在原場頭裡的標題與日夜資訊再拼接一次。場頭前綴在讀入時保留句點，而寫出時又會追加句點，因此往返後可能出現 INT.. 這樣的雙點。
摘要欄位也不是雙向對稱的。摘要可以被讀入，但目前的寫出側不會寫回同一個摘要欄位；再次匯入時，場摘要還會被首條正文內容頂替。頁數為零時，寫出側不寫長度屬性，而讀回側在沒有長度時按 1/8 頁處理。拍攝狀態同樣不隨這條結構交換往返，重新匯入會回到「未拍攝」狀態。
這些不是對某個第三方軟體行為的猜測，而是 SlateX 自己讀寫兩側程式碼組合出來的結果。邊界也必須同時寫清：我們尚未用真實的第三方劇作軟體做「開啟、另存新檔、再匯入」的往返驗收，因此對外只能說往返不保證逐字保真，不能寫成已經通過某種外部驗收。
哪些拍攝資訊根本不在這條交換裡
鏡頭、條記錄、拍攝日、機位設定、時碼、檔位、媒體路徑等拍攝結果不在目前 FDX 的承載範圍裡。匯入鏈路沒有建立這些對象，寫出側也沒有把這些現場記錄塞進劇本結構。
因此，看到某項資訊沒有回來時，正確的問題是「這一層有沒有承載它的欄位或對象」，而不是替產品編一個「為什麼要丟」的動機。沒有寫入路徑，就是沒有寫入路徑。
往返不保真，不等於檔案沒有用途
FDX 仍然適合交換劇本結構。它能把場、場頭、日夜、頁數、正文項等結構帶入 SlateX，也能把目前專案裡的劇本結構寫回檔案。只是這種交換目前應被理解為結構交付，不是一個可以持續來回編輯、每個字元都不變的工作稿迴圈。
接收方如果要繼續使用，應按檔案裡實際存在的結構核對，不要把「能開啟」或「能再次匯入」當作內容保真的證明。
這一族還要分開回答兩個問題
本篇只回答 FDX 適合交換哪些結構，以及哪些內容不會在這條鏈路裡保留下來。後續還應把兩個問題單獨展開：一類是「哪些資訊回不來」，逐項說明缺少的是欄位、對象還是寫出路徑；另一類是「匯入到底會建出什麼」，把集、場、劇本項與不會建立的拍攝對象分開核對。
FAQ
FDX 匯入後會自動建立鏡頭和條記錄嗎？
不會。目前的匯入只建立集、場和劇本項，不建立鏡頭、條記錄、拍攝日或機位設定。
檔案解析成功，就表示已經匯入了場嗎？
不一定。目前一份沒有可讀場頭的良構檔案仍可能走到解析成功並開啟空的選場清單，所以還要檢查實際建立出的場。
FDX 往返能保持場頭逐字不變嗎？
不能這樣保證。目前讀寫兩側會產生標題與日夜疊加、前綴雙點等確定性改寫，因此對外只能寫「往返不保證逐字保真」。
為什麼某些拍攝資訊不會從 FDX 回來？
因為目前的 FDX 交換鏈路沒有承載對應的拍攝對象或欄位。應描述缺少的寫入或寫出路徑，不把這種缺失解釋成產品動機。
Axiom One LLC — SlateX。以上數字截至 2026-09-24。