时间线交接不跑偏：负责人、审批与版本纪律

共享时间线最容易坏掉的方式，是把它当成“大家都可以随手更新的文档”。听起来很协作，实际很快就会变成：编剧为了修一章改了日期，编辑为了角色线又移动了一次事件，美术拿着两周前导出的表格继续画，最后没人知道哪一版才是真的。

可靠的时间线反而需要更少的最终编辑权、更清楚的交接、更可见的决策记录。目标不是把创作变成行政流程，而是让任何人都能快速回答三个问题：现在什么算正式设定？谁能改？为什么改？

先回答一个数字：正式时间线到底有几份

通常答案应该是一份。

团队很容易产生很多“看起来都像正式版”的副本：

作者自己的表格；
编辑批注版；
给合作方看的PPT；
世界观Wiki；
制作日历；
为客户导出的干净版本。

这些都可以存在，但只有一份应该是唯一权威源。其他都只是视图、导出或派生物。

建议每份派生文件顶部都写一句：

参考副本。正式时间线位于：[位置]。最后同步版本：[日期/版本号]。

这一句能减少大量“我以为我拿的是最新版”。

先给事件一个稳定ID，再讨论日期

日期会变，名称会变，场景会移动，但事件ID最好不要变。

不要只用“红港之战，317年”来识别事件，可以增加内部编号，例如 EVT-0042。即便标题后来改成“第二次红港围攻”，所有依赖、批注、修改记录仍然能指向同一件事。

最小事件记录建议包括：

字段	用途
Event ID	跨工具稳定引用
工作标题	给人看的名称
正式日期/区间	当前批准位置
参与者	涉及角色/势力
地点	发生在哪里
前置条件	发生前必须成立什么
后果	发生后什么变成事实
证据	对应章节/剧集/设定稿
状态	提议/批准/锁定/废弃
Owner	谁负责这条记录

这不是多余元数据。它解释了为什么一个日期移动后，会牵动另外五处内容。

把“可以提议”与“可以定稿”分开

真正健康的协作并不意味着所有人权限一样。

一个实用分工可以是：

贡献者：可以提出修改，并说明理由；
领域负责人：检查对角色、地图、制作、设定等各自领域的影响；
时间线编辑：处理冲突并准备正式修改；
审批人：对重大连续性、已发布内容相关修改做最终确认。

小团队里一个人可以兼任几个角色。关键不是人数，而是明确“谁能建议”和“谁能把它变成正史”不是同一回事。

没有这条规则，最后一次编辑往往会悄悄变成“事实”。

修改申请要短到一屏能看完

一个时间线修改申请不需要长篇会议纪要。

写八项就够：

影响的Event ID；
当前正式日期/区间；
拟调整日期/区间；
修改原因；
已知依赖；
会影响哪些已发布或外部材料；
如果失败怎么回退；
谁做最终决定。

其中最有价值的是“已知依赖”。它逼着提出人说明：如果围城提前六个月，那么A角色必须已经获得12章里的军衔，冬季山路是否仍开放，以及第4集提到的条约此时是不是还不应该存在。

这比“新日期读起来更顺”有效得多。

交接要交“状态”，不要只交链接

好的交接会明确告诉对方时间线现在是什么状态。

可以只用五个词：

DRAFT：不能给下游当最终依据；
REVIEW：可以审阅，但还会变；
APPROVED：当前下游制作可使用；
LOCKED：已经绑到发布、合同或高成本资产；
DEPRECATED：保留历史，但不再是正式版。

作者把时间线交给插画、翻译或商务团队时，要发版本和状态，而不是只丢一个链接。

例如：

TL-2026.10.03-r17，状态 APPROVED。EVT-0042 和 EVT-0068 仍在 REVIEW，暂时不要画成最终设定。

这句话比“这是最新版”有用得多。

版本控制是一种行为，不是某个软件名字

Git 适合纯文本项目，因为它会记录提交历史，git log 可以查看记录，分支也可以把提议中的修改和正式主线分开。但用了Git，不代表团队自动就有纪律。

数据库、表格、Wiki、在线文档也可以实现类似原则，只要至少有：

清楚的修改历史；
负责人；
评论或修改提议；
回退能力；
唯一正式位置；
权限管理。

选择团队真的会维护的最轻工具。没人使用的完美流程，比简单但坚持执行的规则更差。

什么修改才值得单独开审查

一个错别字没必要走完整审批流程。真正需要隔离审查的是会向外传播的变化：

把事件跨越重大时代边界；
修改角色年龄或旅行时间；
改变因果关系；
重写已经发布的事实；
改历法换算规则；
修改已经被美术、授权、影视改编引用的事件。

判断阈值可以很简单：

这个修改会不会让别人原本做对的工作突然变错？

如果会，就应该单独审查。

审批记录要“无聊但看得见”

很多审批失败，是因为只发生在聊天里，过两周就找不到了。

一条干净记录可以只有：

2026-10-03 | EVT-0042 | 317-04 → 317-06 | continuity lead批准 | CR-118

重大修改再附原因和影响分析；小修改一行就够。重点是以后能还原决策。

给时间线设定固定“发布节奏”

所有人同时实时改一份时间线，会让下游不敢相信任何版本。更好的方式是发布有名字的版本。

例如：

周一 r17：作者室修改；
周四 r18：连续性问题审完后发布；
只有阻断生产的严重矛盾才走紧急热修。

节奏不一定每周两次。个人作者可以每月一次，游戏团队制作期可以每天一次。关键是同步时间可预测。

每次发布说明只回答五件事：

改了什么；
哪些Event ID变了；
有没有日期移动；
哪些下游资产需要复查；
新版本与上一版是否兼容。

团队争议不要先比“谁觉得更好”

两组人想要不同日期时，先比较后果。

可以用五级影响：

外观级：几乎不影响连续性；
局部级：只改一个章节或资产；
跨系统级：角色、地图、多个剧集一起动；
外部级：已经发布、授权、翻译或签约内容要改；
基础级：历法、年代体系、因果结构本身要改。

级别越高，越应该要求更完整的理由和更高级别审批。这样能避免一句“我觉得提前更好”触发大规模返工。

给不确定年代留一个隔离区

有些事件本来就不应该被写得过于精确。传说、史料冲突、叙述者不可靠，都可能让时间保持模糊。

单独建立“未决区”：

日期有争议；
只知道先后关系；
世界内史料互相冲突；
取决于未来剧情决定。

把“已经知道的部分”写清楚即可：

EVT-0091：发生在EVT-0077之后、322年冬季之前；具体月份未定。

公开承认不确定，比伪造精确日期安全得多。

交接前十项检查

已写明正式源位置；
版本/发布编号可见；
导出后Event ID仍保留；
提议状态和批准状态能区分；
未决日期被明确标记；
改动有理由或修改单链接；
下游知道允许使用哪个版本；
已发布/锁定内容有标识；
旧副本明确写“仅参考”；
有历史或回退能力。

一个常见翻车案例

小说团队有一份已经批准的时间线。美术为了画季节环境，把它导出成表格。两周后作者为了修旅行时间，把葬礼从深秋移到初冬，但美术表格没有更新。于是插画里下雪，正文仍写干燥大风。

坏的解决办法是：“以后大家沟通认真一点。”

好的解决办法是：

只有一个正式时间线；
葬礼有稳定Event ID；
修改单注明会影响季节性美术；
新版本发布说明明确 EVT-0042 移动；
导出的表格上写清版本与同步日期。

不是所有人突然变得更细心，而是系统变得更难误解。

流程要和团队规模匹配

两个人团队不需要企业级治理；四十人IP项目也不能继续只靠一个作者记忆。

可以这样缩放：

个人作者：稳定ID + 版本备份 + 简短修改记录；
小团队：唯一负责人 + 审阅状态 + 发布说明；
大团队：角色权限 + 依赖字段 + 能自动检查的地方尽量自动化。

不管规模多大，目标都一样：让时间线修改在变成连续性漏洞之前可以追踪。

再加一条规则：交接日期时必须带上依赖关系上下文

一个孤立的日期看起来很容易拿去使用，这恰恰也是它危险的地方。如果插画师、译者或游戏设计师只收到“317年6月”，却没有同时拿到事件ID和依赖说明，那么他们即使把日期本身用对了，也仍然可能做出与正史冲突的内容。更稳妥的交接至少要把日期和事件ID、当前状态，以及一句“这个日期依赖什么”的说明放在一起。

这样也会让后续复核更快。依赖关系一旦变化，团队可以直接搜索事件ID，而不是逐个部门追问“你们有没有用过旧的六月日期”。大型项目真正节省的时间，不只是编辑更快，而是减少那些散落在不同部门、肉眼看不见的过期副本。

Sources

Git, git-log documentation: https://git-scm.com/docs/git-log
Git, git-branch documentation: https://git-scm.com/docs/git-branch
Pro Git, Git Branching: https://git-scm.com/book/en/v2/Git-Branching-Branches-in-a-Nutshell

来源边界：Git资料仅用于说明提交历史与分支能力；本文的协作流程是编辑运营模型，不代表团队必须使用Git。