> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kai-yan.com/llms.txt
> Use this file to discover all available pages before exploring further.
# 幕
> 把长故事分成可测试的阶段，并规定每一幕如何推进和收束。
## 这个节点负责什么
“幕”是故事的阶段容器。它负责说明这一段故事要发生什么变化、哪些角色和地点可以参与、事件在什么范围内展开，以及什么时候可以进入下一段。幕本身不是玩家看到的页面标题，玩家会通过这一幕里的场景、人物反应、行动结果和结局感受到它。
雾港来信的第一幕叫**潮汐前的邮局**：它只负责让玩家从“收到信”走到“确认信件来自今晚仍在港内的人”，不要在这一幕直接替玩家决定是否去旧码头。
## 幕核心
| 字段 | 作用 | 示例 | 玩家看到的结果 |
| ------- | ---------------------- | ----------------------- | ------------------------- |
| 幕名称 | 给这一阶段一个便于管理的名字 | `潮汐前的邮局` | 通常不直接显示，可能作为阶段上下文出现在管理信息中 |
| 主流程连接 | 连接上一段和下一段的主路线 | 起点 → 潮汐前的邮局 → 是否追到旧码头 | 玩家实际进入这一幕并继续故事 |
| 本幕可出场角色 | 限定这一幕可以参与演出的角色 | `林舟` | 玩家在这一幕遇到这些角色，未绑定角色不应突然出现 |
| 本幕可进入地点 | 限定这一幕可以发生故事的地点 | `潮汐邮局` | 玩家在地点查看和移动时看到可用地点 |
| 本幕推进方向 | 写这段故事必须推动的因果变化 | `让玩家确认信件来自今晚仍在港内的人` | 通过对话、观察和行动结果逐步体现 |
| 本幕收束依据 | 写什么事实成立后可以结束本幕，以及要承接什么 | `玩家找到信封上的潮痕，下一步承接旧码头方向` | 满足条件后进入下一段，不会凭空跳幕 |
### 推进方向怎么写
建议拆成两段：
1. **核心变化**：这一幕结束时，玩家和世界相比开始时多了什么事实；
2. **变化方向**：玩家可以通过哪些不同方式接近这个变化，哪些部分仍然要留给玩家决定。
示例：
> 核心变化：玩家确认车票不是当天发出的，并发现站台的灯光会在有人靠近时改变。
>
> 变化方向：玩家可以从票面、广播或站务员的反应中找到证据，不要求玩家按固定顺序调查，也不提前宣布玩家已经理解全部规律。
### 收束依据怎么写
按“正常收束、提前收束、承接内容”三部分写：
* **正常收束**：本幕正常完成时，玩家能观察到什么；
* **提前收束**：玩家做出不同选择时，哪些事实可以提前结束，哪些事实不能假装已经发生；
* **承接内容**：下一幕必须带走的位置、物品、线索、情报和状态。
不要只写“完成任务后进入下一幕”。要写清“任务完成”的可观察证据。
## 幕伏笔
伏笔字段用于记录之后可能被引爆的事实。每条伏笔写三项：
| 字段 | 示例 |
| ---- | ------------------------------- |
| 伏笔名称 | `信封上的潮痕` |
| 伏笔内容 | `盐痕只出现在旧码头一侧的纸边，像信件被潮水打湿后又被带回。` |
| 引爆影响 | `玩家在旧码头再次查看信封时，能把潮痕与码头的潮位标记对上。` |
伏笔不是必须马上揭开的线索，也不是结局条件。先写它是什么，再写它被触发后会改变什么，避免把幕后答案直接塞进开场。
## 幕内事件
幕内事件是这一幕里真正发生的剧情单元。页面提供两种填写方式：让演出保留更大的发挥空间，或使用**精细控制**把事件拆成更具体的步骤。无论选哪一种，都要先写清事实边界。
### 共同字段
| 字段 | 填写方法 | 示例 |
| --------- | ---------------- | ---------------------------------- |
| 事件概述 | 按“开场、发展、结果”写三层内容 | `林舟否认见过信；玩家检查寄件记录；最终确认信件在今晚被放入邮局。` |
| 建议回合数 | 估计玩家完成事件需要的回合范围 | 最少 2，最多 5 |
| 涉及人物 | 只选这一事件真正会出现的人物 | `林舟` |
| 涉及地点 | 只选事件允许发生的地点 | `潮汐邮局` |
| 叙事意图 | 说明事件要让玩家认识到什么变化 | `让玩家意识到信件不是偶然落在桌上的` |
| 入口情境 | 事件开始时已经成立的事实 | `玩家拿着未寄出的信站在停电的门厅` |
| 事件必须解决的问题 | 事件结束前必须得到的答案或变化 | `信件是否在今晚被放入邮局` |
| 允许的结果边界 | 写允许成功、部分成功和失败到哪里 | `可以确认投递时间，但不能直接说出寄信人的身份` |
这些字段都是后台字段。玩家不会看到“叙事意图”或“允许的结果边界”，只会在游玩页中读到事件实际发生的文字、动作和结果。
### 需要精细控制时
把事件拆成连续的剧情推进节点，每个节点填写：
* **节点名称**：例如“确认电源位置”；
* **本节点要完成的叙事变化**：例如“玩家知道广播设备在候车室后方”；
* **导演编排指引与边界**：例如“可以允许玩家先调查站台，但不能因为一句猜测就视为已经修好设备”；
* **主动推动来源**：说明是哪个人物、环境、物品或前一事实在推动它。
还可以在事件中记录要**埋设**或**引爆**的伏笔。每个推进节点只做一个主要变化，玩家才有机会在页面中观察和回应。
## 颜色和玩家展示
幕中的名称、连接、角色/地点选择、推进方向、收束依据、伏笔和事件字段都属于后台编排。玩家看不到这些字段的原文；他们看到的是：
* 当前地点的描述和场景图；
* 角色出现时的名字、台词、动作和反应；
* 观察、提问和行动带来的事实；
* 进入下一幕时承接下来的位置、物品、线索和状态。
因此，幕字段不要写成“请展示给玩家的公告”。把玩家要读的句子放进故事背景、开场文本、地点描述、线索内容、角色设定的可见部分或结局描述中。
## 完成检查
* 本幕是否有清楚的开始事实和结束事实；
* 可出场角色和可进入地点是否已经绑定；
* 每个事件是否只承担一个主要变化；
* 事件边界是否允许玩家用不同方式行动；
* 伏笔的内容和引爆影响是否分开；
* 下一幕需要承接的事实是否已经写在收束依据中；
* 本幕的主流程连接是否只有合理的入口和出口。
幕完成后，继续看[分支](/create/editor/branch)，为不同事实连接不同后续路线。