时间线练习真正的价值，不是60分钟里写出多少世界史，而是计时结束后留下一个别人也能继续使用的成果。

这次练习只做一件东西：一段“正史可用”的时间线切片。最好包含8—12个事件、稳定事件ID、明确依赖关系、不确定性标签，以及很短的修改记录。

工具可以是表格、数据库、Markdown，甚至版本库。Git官方文档能验证“提交历史”和“分支”这些版本追踪能力，但这套练习并不要求一定使用Git。真正重要的是三件事：什么是当前权威版本、改了什么、哪些事件互相依赖。

现在开始60分钟计时。只选一个故事弧、一场历史危机、一位角色的一段旅程，或者一季游戏剧情。不要选整个宇宙。

0—5分钟：先定义交付物，不要急着填日期

在页面最上方写一句：

60分钟结束时，我要得到一段别人不需要再问“哪版才是最新版”就能使用的时间线。

然后收窄范围。

适合的范围：

  • 一场政变前后七天；
  • 主角从出发到第一次重大失败；
  • 一座城市崩溃前的关键事件；
  • 一个派系分裂的连续过程；
  • 如果只记录大事件，也可以是一整个王朝的几个时代节点。

不适合的范围：

  • “整个世界的全部历史”；
  • “所有角色背景”；
  • “第一卷之前发生的一切”。

范围越大，你越容易在60分钟里制造大量半成品。

5—12分钟：先给事件稳定ID

不要拿日期当事件身份。日期会改，事件身份最好不改。

例如：

EVT-0201 —— 信使离开北门
EVT-0202 —— 发现桥梁被破坏
EVT-0203 —— 议会延迟撤离

以后标题可以变，日期也可以移动，但ID继续指向同一件事。

这对跨部门特别重要。插画、翻译、任务设计如果都引用EVT-0202，即使它从第三天移到第四天，也不用重新猜“大家说的是不是同一场事件”。

这一阶段只要完成“ID + 一句话事件”清单。

12—22分钟：精确日期之前，先写依赖关系

问每件事：它发生之前，什么必须已经成立？

可以使用很简单的字段：

  • **必须晚于：**EVT-0201
  • **必须早于：**EVT-0205
  • **不能重叠：**EVT-0206
  • 依赖状态：“城门已经封闭”
  • 关系不确定：“第一次降雪后，具体日期未定”

这个步骤比美化日期更早抓出矛盾。

例如：

  • EVT-0202 发现破坏；
  • EVT-0204 发布撤离令；
  • EVT-0205 西路关闭。

如果撤离令明确依赖“发现破坏”，那它就不能在EVT-0202之前发生，除非世界里存在另一条信息来源。这里检查的是因果，不是日历。

先搭因果骨架，再排日期。

22—32分钟：开始填日期，但必须同时填“确定程度”

建议至少两列：日期和状态。

状态可以这样设计：

  • LOCKED：已经公开、签约或不能轻易改；
  • APPROVED：当前正史，修改需要审批；
  • DRAFT：工作稿；
  • RANGE：只确定时间区间；
  • UNKNOWN：先后关系已知，但精确时间故意开放。

例子：

ID 日期 状态 依赖
EVT-0201 第1天上午 APPROVED —
EVT-0202 第2天 DRAFT 晚于EVT-0201
EVT-0204 第2天傍晚 DRAFT 晚于EVT-0202
EVT-0205 第3—4天 RANGE 暴风开始之后

不要把所有不确定性伪装成精确。剧情根本不需要“第三天09:30”时，写“第三到第四天”反而更强。

32—40分钟：做一次旅行与时长检查

现在才开始问现实感：

  • 这段路在这个世界里大概要多久？
  • 人物是否需要睡眠、治疗、准备或等待？
  • 信息能不能这么快传到下一个角色？
  • 日照、季节、天气是否影响场景？
  • 有没有同一个人被安排在同一时间出现在两个地方？

不需要做复杂模拟，但脆弱环节最好加一个“时长备注”。

例如：

EVT-0203 → EVT-0204：信使抵达后，议会讨论至少需要2小时。

如果世界里有传送、门、瞬移或时间差，也不要一句“有魔法”就跳过。写清楚它的运行限制，时间线才有约束力。

40—47分钟：故意移动一个最重要的事件

挑依赖最多的事件，故意挪动。

把EVT-0202从第二天上午挪到第二天晚上，然后看谁会坏：

  • 撤离令是不是也要延后；
  • 插画里的昼夜条件是否改变；
  • 某角色还能不能在宵禁前到桥边；
  • 天气状态是否不同；
  • 另一个事件是否失去原因。

这就是依赖压力测试。

如果一个“重大事件”移动后什么都不用改，要么它其实不重要，要么你的时间线没有记录足够的关系。

是否保留改动，最后由故事需要决定，而不是由表格方便决定。

47—52分钟：做一个极小的修改记录

四列就够：

版本 改了什么 为什么 状态/批准
v0.1 初次组合事件 练习草稿 DRAFT
v0.2 EVT-0202后移 原旅行时间不成立 DRAFT
v0.3 EVT-0205改成第3—4天 天气保持不确定 APPROVED

“最新文件”并不能回答为什么日期变了。修改记录能。

Git的git log用于查看提交历史，git branch用于管理分支引用。这里引用它们，只是为了说明“历史可追踪”可以由工具支持；团队用表格加版本列和修改记录，同样可以实现编辑目标。

52—56分钟：制作一份真正能交接的视图

内部工作表可能有大量别人不需要看的笔记。现在做一个干净视图，只保留：

  • Event ID；
  • 当前可用日期/范围；
  • 一句话事件；
  • 状态；
  • 一条核心依赖；
  • 导出版本和日期。

顶部再加一句：

参考视图。正式时间线位置：[地址]。本文件由版本[X]于[日期]导出。

它很无聊，但特别有用。

56—60分钟：用四个问题做正史检查

逐行问：

  1. **身份：**有没有稳定事件ID？
  2. **顺序：**关键先后关系有没有写出来？
  3. **确定性：**精确程度是否和真实信息匹配？
  4. **影响：**如果事件改动，能不能知道哪些下游资产要复查？

一件事如果有两项以上答不上来，就先别标APPROVED。

60分钟到了就停。

你最后得到的不是一篇漂亮设定文，而是一小块其他创作者可以信任的基础设施。

最终一页成果应该有什么

一屏就够：

  • 范围说明；
  • 8—12条事件；
  • 稳定ID；
  • 日期/区间；
  • 状态；
  • 依赖关系；
  • 三四条修改记录；
  • 唯一权威源位置；
  • 当前版本和导出日期。

如果还能多一列，就加“受影响资产”：章节、任务、插画、地图、预告片、翻译包。这样日期变化会自动变成制作提醒。

练习中最常见的失败

先写长篇历史，再做结构

每个事件先写几百字很有成就感，但一小时过去，你仍不知道顺序是否成立。先让事件保持短。

强迫所有日期精确

精确并不等于可靠。范围和不确定标签有时更符合正史。

所有人都能直接改正式版

协作不等于每个人都有最终编辑权。一份权威源 + 可审查提案，通常比四份“最新版”安全。

只写版本号，不写原因

v7-final-FINAL2不是决策历史。真正有用的是“为什么移动”。

把软件当方法

纯文本也能完成这次练习。工具只有在让身份、历史、交接更清楚时才有价值。

什么情况下要升级这套流程

个人小说，稳定ID+简单版本记录可能已经够用。

多工作室授权IP，就需要增加负责人、审批、受影响资产、发布状态。如果日期已经对外发布，改动风险更高。如果世界观本来就设计成“不同史料互相矛盾”，也不要强迫所有资料合并成一个所谓真日期，而应该记录不同来源各自声称什么。

不确定性有时就是世界观的一部分，系统应该容纳它，而不是把它擦掉。

每月可以怎么重复

下一次重大剧情调整时，用同样的一小时：

  • 10分钟：定义变化范围；
  • 10分钟：更新依赖；
  • 10分钟：移动日期；
  • 10分钟：检查受影响资产；
  • 10分钟：更新修改记录；
  • 10分钟：发布新的交接视图。

你得到的是一种维护节奏，而不是一次性整理。

最简单的验收方式：把成果交给一个没参加会议的人。如果他不需要问你，就能看懂当前顺序、不确定日期、依赖关系和版本，那么这段时间线已经真正可用。

Sources

  1. Git, git-log documentation: https://git-scm.com/docs/git-log
  2. Git, git-branch documentation: https://git-scm.com/docs/git-branch

来源边界：Git资料只用于核实提交历史、分支等版本追踪能力；本文的编辑流程不依赖某个特定软件，也不要求团队必须使用Git。

Related Reading