企业官网建设流程全解析

• 桌面应用

本文以 novelWriter 示例项目中的真实场景文档 bc0cbd2a407f3.md 为标本，系统讲解如何在章节下组织多个场景：标题层级如何定义章节与场景、同一文件与多文件两种组织方式的取舍、@pov/@focus/@location引用元数据的写法、###!硬场景分隔符的含义，以及如何用 Split Document 工具把合并写作的文本按标题拆回独立场景文件。读完本文，你将掌握 novelWriter 以"标题驱动结构"为核心的场景组织方法论，并能直接套用到自己的小说项目中。

一、标本解读：一个场景文件长什么样

先看示例项目里这个名为Another Scene的场景文件（sample/content/bc0cbd2a407f3.md）的完整内容：

+++ name = "Another Scene" parent = "780f67364ea6a" handle = "bc0cbd2a407f3" class = "NOVEL" layout = "DOCUMENT" textHash = "d35e2629876e627b1a2418affa40d477022984f8" createdDate = "Unknown" updatedDate = "2024-03-11 22:56:28" +++ ### Another Scene @pov: John @focus: Jane @location: Earth Adding more scenes to a chapter is as easy as adding more scene files with a level three heading. You can of course also just add another level three heading in the same file if that works for the way you want to structure your files. In fact, if you wish, you can add all the scenes in the chapter file too. All novelWriter cares about is the level of the headings and the order in which they appear. ###! More Scenes @pov: Jane @focus: John @location: Earth This is a second scene in the same file as the previous scene. You can always split the files up later using the split tool.

这个文件虽然只有寥寥数段，却浓缩了 novelWriter 场景组织的全部关键机制：

• 文件头（frontmatter）：由+++包裹的元数据块，记录文档名称、父节点 handle、自身 handle、类别（NOVEL）、布局（DOCUMENT）与时间戳。这些元数据不是给你手写的，而是由项目索引（sample/nwProject.nwx 中对应的<item handle="bc0cbd2a407f3" ...>条目）在保存时自动维护的。
• 一个三级标题（###）定义一个场景：正文第一行### Another Scene即声明了本文件是一个场景。
• 引用元数据行：标题下方紧跟着@pov、@focus、@location三行，为场景标注视角人物、焦点人物和发生地点。
• 同一文件内可容纳多个场景：文件后半部分用另一个三级标题###! More Scenes直接开启了第二个场景——注意多了一个!。

二、标题层级决定一切：为什么 novelWriter 只看标题

novelWriter 的核心设计理念是：项目的结构由文档内的标题层级推断，而不是由文档文件本身决定。这是官方文档 chapters_and_scenes.rst 明确说明的规则，也是理解本文所有内容的前提。

对于放在Novel类根文件夹下的文档，四个层级的标题分别对应小说的不同结构单元：

关键规则有三条：

1. 多个标题可共存于同一文档，但项目树中该文档显示的名称与图标由第一个标题决定。示例文件### Another Scene出现在首行，因此项目树里它显示为场景（H3 图标）；sample/nwProject.nwx 中对应条目<meta ... heading="H3" ...>证实了这一点。
2. 标题后的空格是强制的（#与文字之间必须有空格），否则编辑器不会把它识别为标题并改变颜色字号。
3. 其他根文件夹（如 Characters、Locations）中的笔记也可以使用同样的标题层级，但它们不会被当作章节或场景对待，可以自由使用。

从源码看，手稿构建器正是按标题层级来分发格式化逻辑的：tokenizer.py 中为 partition、chapter、scene、section 分别维护了独立的样式开关（如_hidePart、_hideChapter、_hideScene、_hideSection），并针对每个层级提供了独立的字号与上下边距设置方法。这意味着标题层级的选择会一路影响到最终导出文档的排版。

三、两种组织方式：多文件场景 vs 单文件多场景

示例文档正文第一段给出了两个同样可行的方案：

"Adding more scenes to a chapter is as easy as adding more scene files with a level three heading."

方式一：每场景一个文件

这是最常见也最推荐的做法。在项目树中，场景文件可以作为章节文档的子文档，也可以排在章节文档之后与它同级——官方文档明确指出，这两种排法在最终输出中结果完全一致，纯属个人偏好。

在示例项目中可以看到这两种排法的真实样例（sample/nwProject.nwx）：

• 章节Basic Formatting（handle6a2d6d5f4f401）下挂着两个子文档：Making a Scene（636b6aa9b697b）和Another Scene（bc0cbd2a407f3），这是"场景作为章节子文档"；
• 章节So it Begins（88706ddc78b1b）下面同样挂着Where is John?和We Found John!两个场景子文档。

每个场景文件只需一个三级标题，配合各自的引用元数据，就能在 Outline View（大纲视图）和 Novel View（小说视图）中独立显示、独立统计字数。

方式二：单文件内连续多个场景

示例文档的第二段明确说明：

"you can add all the scenes in the chapter file too. All novelWriter cares about is the level of the headings and the order in which they appear."

即你可以把整章所有场景都写进同一个文件里，只要保持标题层级与出现顺序正确即可。本示例文件正是如此——它在一个文件里放进了### Another Scene和###! More Scenes两个场景。这种做法的优点是写作时不打断思路、不用频繁切换文件；缺点是大纲视图中的场景粒度与文件粒度绑定，后续想单独管理某个场景时需要用拆分工具处理。

四、场景引用元数据：@pov、@focus、@location 的语义

场景标题下的引用行是 novelWriter 标签-引用系统的实际应用。根据官方文档 tags_and_references.rst，引用行的通用格式为：

@keyword: value1, value2, ..., valueN

所有引用关键字都支持多个值。示例场景中用到的三个关键字语义如下：

• @pov：本场景的视角人物（Point of View）。目标必须是Characters类型根文件夹中某个笔记定义的标签。
• @focus：本场景中具有"焦点"的角色，适用于焦点人物与视角人物不同的情况。目标同样必须是 Characters 类笔记标签。
• @location：本场景发生的地点。目标必须是Locations类型根文件夹中的笔记标签。

此外还有@char（其他出场角色）、@plot（推进的剧情线）、@time（涉及的时间线）、@object、@entity、@custom、@mention（仅提及未出场的事物）与@story（引用 Novel 类文档）等关键字，完整列表见 tags_and_references.rst。

这些引用能生效，前提是目标标签已在对应根文件夹的笔记中定义过。以本示例项目为例，@location: Earth引用的正是 sample/content/b3e74dbc1f584.md 中定义的 Earth 地点标签（对应项目树Locations根下的Earth笔记，见 sample/nwProject.nwx 中 handleb3e74dbc1f584的条目）；@pov: John/@focus: Jane引用的则是Characters根下John and Bob Smith、Jane Smith笔记中的角色标签。

使用技巧：

• 标签不区分大小写（2.2 版本起），显示时保留你定义时的写法；
• 编辑器会在你输入@时自动弹出补全菜单，冒号后补全已定义的标签；
• 若引用了尚不存在的标签，可右键选择Create Note for Tag自动在正确的根文件夹生成带新标签的笔记；
• 引用正确时编辑器会给它加高亮色，无效引用会显示波浪下划线——若高亮不准，按F9重建索引即可。

五、硬场景分隔符：###!的含义

示例文档的第二个场景标题写作###! More Scenes，比第一个场景多了一个!。这是 novelWriter 为三级标题提供的一种变体写法。

根据 chapters_and_scenes.rst，!修饰符只对手稿构建产生影响，写作时可以先了解其用途再决定是否使用：

• #! Title：一级标题的变体，用于小说或笔记文件夹的主标题（如封面书名），构建时使用与分部标题不同的独立样式；
• ##! Chapter Title：二级标题变体，告诉构建工具不要为这个章节自动编号，适合序章（prologue）和尾声（epilogue）；
• ###! Scene Title：三级标题变体，在手稿构建中可用不同的格式渲染，用于区分"软性场景分隔"与"硬性场景分隔"（soft vs hard scene break），除此之外行为与普通场景标题完全一致。

从源码实现看，tokenizer.py 中场景标题的格式化逻辑确实区分了普通场景与硬场景：_hideScene与_hideHScene是两个独立的隐藏开关，分别控制普通场景标题和硬场景标题是否出现在输出中；场景编号的递增也发生在标题格式化之前。这意味着你可以在同一章里混用###与###!，让它们在手稿中呈现不同的样式或分隔符。

示例文档用它演示的正是"同文件内第二场景"的写法——软/硬场景分隔符的语义由你自行定义，novelWriter 只负责在构建时按不同样式输出。

六、反推工作流：拆分工具如何把单文件还原为多场景

示例文档最后一句写得很妙：

"You can always split the files up later using the split tool."

这正是对 Split Document by Headings 功能的预告。当你像本示例这样把多个场景写在同一个文件里、之后又想拆成独立文件时，可以在项目树中右键该文档，在Transform子菜单里选择Split Document by Headings，打开拆分对话框（源码实现见 docsplit.py）：

1. 选择拆分层级：下拉框提供四级选项——"Split on Heading Level 1 (Partition)"、"Split up to Heading Level 2 (Chapter)"、"Split up to Heading Level 3 (Scene)"、"Split up to Heading Level 4 (Section)"（docsplit.py）。对场景组织而言，选 Level 3 即按场景标题拆分；
2. 预览列表：对话框上方的列表会实时预览按当前层级将被拆出的每个标题；
3. 三个开关选项（docsplit.py）：
   • Split into a new folder：把拆出的文档放进新文件夹；
   • Create document hierarchy：按层级重建文档树（section 归入 scene，scene 归入 chapter）；
   • Move split document to Trash：拆分后把源文档移入 Trash（源文档不会被删除，是否回收由你决定）。

这套工具的默认选项（拆分层级 3、新建文件夹、建层级）保存在项目配置中，可在 config_novelwriter.toml 这类配置模板中找到对应记录，说明拆分偏好是持久化的用户设置。

对应的反向操作是Merge Documents：选择Merge Child Items into Self把子文档内容并入父文档，或Merge Child Items into New合并后生成新文档；合并对话框中可以排除不想合并的文档并调整合并顺序（详见 split_and_merge.rst）。于是"合并写作 → 按标题拆分 → 独立管理"就构成了一个完整的闭环工作流：先用单文件连续写作保持思路连贯，需要精细化整理时再用拆分工具按场景标题还原文件结构。

七、实践要点小结

基于以上分析，在 novelWriter 中组织章节内的多场景，可以遵循以下要点：

1. 结构只看标题：##是章节、###是场景、####是小节，文件数量与层级关系不影响最终输出，标题层级与顺序才重要；
2. 每场景一个三级标题：无论采用单文件多场景还是多文件一场景，每个场景都必须以###（或###!）开头，且标题后必须有空格；
3. 场景文件既可作章节子文档也可与章节同级，两种排法输出一致；
4. 引用行紧跟标题：@pov、@focus、@location等引用必须指向已定义的角色/地点/剧情线标签，并保持标签唯一、跨文档有效；
5. 用###!区分场景分隔类型：需要软/硬场景分隔差异化排版时使用带!的三级标题；
6. 善用拆分工具还原结构：单文件写多了就右键 → Transform → Split Document by Headings，按 Level 3 拆回独立场景文件，可选建文件夹、建层级、移 Trash 三项配置。

通过这套以标题为核心的组织方式，你的章节-场景结构将同时被项目树、大纲视图、手稿构建器与字数统计系统正确识别，形成从写作到导出的完整链路。

• 桌面应用