即阅模式还是源码视图？写作流畅与 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，并在目标环境中核对识别结果。
本地与可读带来的是控制权和选择空间，并不承诺其他软件能无损理解全部内容。第三方网盘可以存放作者主动创建的完整备份副本，但这不等于 Scroll 自己提供了托管同步，也不能替代多副本与恢复测试。
对于未支持、无法完整保存或来源不明的高级结构，回到源码核对标题、列表、链接与未知标记。若真实需求已经从“正文怎样写得顺”变成“书页怎样排、目录怎样生成、PDF 或 EPUB 怎样输出”，则应进入 Scroll 与 Scribe 的分工指南所描述的下游流程；Scroll 中的交付准备仍需在 Scribe 中核对接收与识别。
按任务选择，而不是按身份站队
可以把选择缩成三句话：
- 主要在写句子、读段落与调整节奏时，使用即阅模式；
- 主要在查标记、核对结构与处理未知内容时，使用源码视图；
- 需要跨工具操作时，先保存，再检查源文件与返回后的结果。
你可以在 Scroll 编辑器工作台文档查看两种模式的准确边界；想减少写作过程中的视觉干扰，可以继续阅读《怎样建立可持续的沉浸写作时段》；若要重新选择整套创作路径，则回到《Scroll 长篇创作指南》。
流畅与可控并不是同一条轴的两端。真正的控制，不是强迫自己永远看见全部标记；真正的流畅，也不是放弃查看源文件。它们可以属于同一份正文，只在作者需要时轮流走到前景。
想体验同一正文的两种工作姿势？在 Scroll 中打开一篇真实 Markdown，先用即阅模式通读，再保存并切到源码检查结构。