即閱模式還是原始碼檢視？寫作流暢與 Markdown 可控可以同時擁有
不必在純 Markdown 原始碼與格式化編輯之間二選一。了解 Scroll 即閱模式與原始碼檢視如何編輯同一份正文，以及儲存、檢查與備份邊界。
習慣 Markdown 的作者，往往珍惜原始碼帶來的確定感。標題前的井號、連結的目標、YAML frontmatter 裡的欄位都擺在眼前；檔案離開目前軟體，仍然可以被一般文字工具開啟。
可當一章寫到三千字，標記也會開始佔據視野。作者想讀句子的節奏，卻不斷看見強調符號、連結語法和長地址。格式化編輯器解決了閱讀問題，又可能帶來另一種不安：它剛才究竟改了什麼？原始結構還在嗎？
這常被描述成二選一：要麼接受純原始碼的可控，要麼選擇格式化介面的流暢。其實更實用的判斷是，不必為整個寫作生涯選擇一種陣營，只需為目前任務選擇一種工作姿勢。
在 Scroll 中，原始碼檢視與即閱模式編輯的是同一份正文。它們不是兩套內容，也不是後台互相同步的兩個版本；切換的是呈現和編輯方式。理解這一點，才能同時談流暢與可控，也才能理解為什麼儲存與檢查仍然重要。
即閱模式：讓格式退到閱讀之後
連續起草時，作者主要判斷的是詞語、句子、段落與場景。標題應該像標題被看見，清單應該以清單出現，引用、連結及受支援的高階內容也應儘量以可讀方式呈現。即閱模式減少標記對句子節奏的干擾，讓日常寫作更接近閱讀正文。
這並不意味著作者失去了 Markdown。內容仍然來自同一份正文，只是常用結構不再始終以原始符號佔據視覺中心。對於不願記住所有標記的新作者，它提供更自然的入口；對於熟悉原始碼的作者，它則是一種在語言修訂時暫時降低結構噪聲的方法。
「即閱」需要被準確理解。它指寫作層面的格式化閱讀和編輯，不是書籍分頁預覽。螢幕上的標題大小、正文寬度與顏色，不代表 Scribe Appearance，也不能告訴你未來 PDF 或印刷版會有多少頁。最終成品受頁面尺寸、字型、樣式與分頁規則影響，那是下游排版問題。
因此，即閱模式最適合這樣的工作：連續起草一場戲，通讀段落過渡，調整對話節奏，編輯常用標題、清單、引用與連結。作者關心的中心是「這段文字讀起來怎樣」，而不是「底層標記是否按預期排列」。
原始碼檢視：在需要時把結構重新放到眼前
原始碼檢視適合直接檢查和編輯 Markdown、YAML frontmatter 以及其他受支援的文字內容。它讓標題層級、連結目標、清單縮排與未知標記保持可見，尤其適合以下情形：
- 某段格式在即閱模式中表現異常，需要確認原始符號；
- 內容從其他工具遷入，要檢查標題、清單或連結結構；
- 需要調整 frontmatter 中作者確實理解的欄位；
- 準備使用外部文字工具前，先確認原始檔狀態；
- 從格式化寫作返回後，核對未識別或無法完整呈現的標記。
純原始碼並不天然更專業，它只是把結構判斷放在首位。許多作者完全可以始終在原始碼中寫作；如果標記不會打斷你的閱讀，就沒有為了「更現代」而改變習慣的義務。反過來，偏愛格式化介面的作者也不必先背完全部 Markdown，才能開始寫正文。
如果遇到自己不認識的標記，不要因為即閱顯示看起來正常就直接刪除，也不要假設任意 Markdown 擴充語法都能被完整理解與儲存。先返回原始碼確認內容，查清它的用途，再決定是否編輯。可控不是始終盯著符號，而是在需要做結構決定時能夠看到依據。
一個章節，怎樣在兩種模式之間往返
假設作者正在整理一章關於舊港口的歷史非虛構。第一輪，她在即閱模式連續寫作，標題、引用與連結以可讀形式出現，注意力留在敘述節奏和資料如何進入段落。臨時缺失的年份用一致標記留下，等這一段寫完再查。
章節成形後，她先儲存，再切到原始碼檢視，檢查標題層級、資料清單的縮排、連結目標和自己負責的 frontmatter 欄位。若發現未知標記，先保留並確認其用途。模式切換、批次重組或外部修改前儲存目前標籤頁，可以讓後續檢查從一個已確認狀態開始。
需要用外部文字工具精確查詢時，她再次儲存，結束 Scroll 中對該檔案的目前編輯，再讓外部工具讀取最新內容。外部修改完成後回到 Scroll 檢查結果，最後以即閱模式通讀語言。避免兩邊同時留下未儲存修改，比頻繁切換工具更重要。
每章無需固定迴圈兩遍：有的正文可以一直在即閱完成，有的技術性資料始終在原始碼中更清楚。雙模式提供的是按任務切換的餘地，而非一套新增儀式。
可移植性不只是一句「檔案在本機」
一般 Markdown 與可讀原始檔，讓正文更容易被其他編輯器開啟、複製和移轉。Project 由作者選擇本機位置；需要備份時，應先關閉 Scroll，再用 Finder 或其他備份工具複製整個 Project 資料夾。如果希望保留異地副本，可以把這份完整備份交給自己選擇的雲端硬碟儲存，而不要在同步狀態不明確的目錄中直接開始工作。
但「正文可讀」不等於「Project 的全部語義都只存在於一份 Markdown 檔案裡」。一部長篇還可能包含人物與地點卡片、事件、關係、設定以及受支援的高階內容。另一款文字編輯器能夠讀出正文，不代表它能無損理解所有 Story 結構。
因此，可靠備份的物件應是整個 Project，而不是只複製眼前的一章。移轉時也應區分兩個目標：如果只需要保住可讀正文，一般文字工具已經很有價值；如果要完整保留 Scroll 中的 Project 語義，就必須帶上整個 Project，並在目標環境中核對識別結果。
本機與可讀帶來的是控制權和選擇空間，並不承諾其他軟體能無損理解全部內容。第三方雲端硬碟可以存放作者主動建立的完整備份副本，但這不等於 Scroll 自己提供了代管同步，也不能替代多副本與恢復測試。
對於未支援、無法完整儲存或來源不明的高階結構，回到原始碼核對標題、清單、連結與未知標記。若真實需求已經從「正文怎樣寫得順」變成「書頁怎樣排、目錄怎樣生成、PDF 或 EPUB 怎樣輸出」，則應進入 Scroll 與 Scribe 的分工指南所描述的下游流程；Scroll 中的交付準備仍需在 Scribe 中核對接收與識別。
依任務選擇，不必按身分選邊
可以把選擇縮成三句話：
- 主要在寫句子、讀段落與調整節奏時，使用即閱模式；
- 主要在查標記、核對結構與處理未知內容時，使用原始碼檢視；
- 需要跨工具操作時，先儲存，再檢查原始檔與返回後的結果。
你可以在 Scroll 編輯器工作台說明文件檢視兩種模式的準確邊界；想減少寫作過程中的視覺干擾，可以繼續閱讀《怎樣建立可持續的沉浸寫作時段》；若要重新選擇整套創作路徑，則回到《Scroll 長篇創作指南》。
流暢與可控並不是同一條軸的兩端。真正的控制，不是強迫自己永遠看見全部標記；真正的流暢，也不是放棄檢視原始檔。它們可以屬於同一份正文，只在作者需要時輪流走到前景。
想體驗同一正文的兩種工作姿勢？在 Scroll 中開啟一篇真實 Markdown，先用即閱模式通讀，再儲存並切到原始碼檢查結構。