一行場頭裡的內外景是怎樣按分隔符猜出來的

SlateX 處理一行場頭時，做的是按分隔符猜測，不是拿一張內外景詞表去比對。它先從末尾切日夜，再從行首嘗試切內外景；整個過程依賴空格、句點、連字號形態和字元數門檻。語言本身不是判據，所以同一種寫法規則既可能接住中文，也可能漏掉英文，反過來也一樣。

場頭切分靠分隔符與字元數門檻，不靠內外景或日夜關鍵詞白名單。

先切日夜，再猜內外景

日夜先處理。程式優先取最後一個 - 之後的整段，也就是連字號兩邊都有空格的形態；找不到這種寫法時，才退回最後一個 -，並要求切出來的末尾片段通過長度保護。

內外景隨後處理。程式依次嘗試空格和句點兩個分隔符，取分隔符之前的前綴，並要求前綴不超過 6 個字元才接受。這裡沒有關鍵詞白名單，也不會去讀專案裡的內外景預設或日夜預設，因此預設清單不是這一步的判斷依據。

四個例子顯示真正的分水嶺

内景 控制室 - 日 有空格，前綴 内景 會被取到。内景：控制室 - 日 使用全形冒號並且前綴後沒有空格，這條分支拿不到內外景。EXTERIOR. OFFICE - DAY 雖然有句點，但句點前的 EXTERIOR 超過 6 個字元，因此不接受。INT./EXT. 屋顶 - 夜 的空格分支先得到過長前綴，隨後句點分支命中，結果只取到 INT。

在這組例子裡，直觀分水嶺是有沒有可用空格；完整規則還要連同句點分支和長度門檻一起看。兩個長度條件算的都是字元數，不是單詞數，所以中日韓文字一個字就按一個字元參與判斷。

兩種形狀會把別的東西吞進欄位

帶序號的 1. INT. 控制室 - DAY 會把 1. 當成內外景前綴，場號看起來可以存在，但內外景值已經錯位。無空格的全大寫標題 ROOFTOP-PARTY 會把末尾 PARTY 切成日夜，同時把地名截短；這不是當場拒絕，而是把切出來的值繼續交給後面的流程。

長破折號、全形連字號，確實不在目前那兩條分隔分支裡。INT.,EXT. 這類複合寫法則不是「沒人接」：空格分支先拿到過長的前綴而被棄，句號分支會命中，取到的只是 INT 這一小截（同上例）——留下的是不完整的前綴值，而不是當場拒絕。不能因此概括成某一種語言支援好或差，因為同一套字元門檻會在不同語言裡以不同方式漏掉輸入。

錯值會留下來，不是當場拒絕

被猜成內外景的前綴會原樣加入專案的內外景預設，並出現在編輯頁的下拉選單裡。上面的 1. 因而可能變成一個可再次選擇的預設；無分隔符標題切出的末尾值也會進入對應的預設清單。

這條邊界很重要，因為「拿到了一個值」不等於「這個值符合現場語義」。接收方應自行核對匯入後出現的內外景和日夜預設，尤其是帶序號、複合前綴或非標準連字號的場頭。

被誤切出的前綴會繼續進入預設清單；錯值會留下來，不是當場拒絕。

這套規則沒有覆蓋的事

《一行場景標題由哪幾段組成》講的是場頭整體由哪些部分構成；這裡更窄，只說明內外景與日夜如何從一行文字裡被切出來。至於《匯出的 FDX 回不來的是什麼》所涉及的再匯出與回讀，接收方應自行核對實際往返結果，不能從一次切分成功推斷往返會保持原樣。

這套邏輯也不處理所有破折號變體，也不會把複合標記當成一個整體來讀。遇到不在空格、句點和目前連字號分支裡的形狀時，應把它當作需要人工核對的輸入，而不是替格式來源下結論。

FAQ

專案裡的內外景預設會參與場頭切分嗎？

不會。目前的切分邏輯沒有關鍵詞白名單，也不讀取內外景預設或日夜預設。

EXTERIOR. OFFICE - DAY 為什麼拿不到內外景？

因為句點前的前綴超過 6 個字元，超過了目前的前綴長度門檻。這個門檻按字元數算，不按單詞數算。

INT./EXT. 會得到什麼？

按目前的分隔順序，它會落到句點分支並取到前半段 INT。這不代表複合寫法被完整保留。

被切錯的值會被清掉嗎？

不會在這一步被拒絕。被取到的前綴可以進入預設清單，因此匯入後需要自行核對。

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