企业官网建设流程全解析

如果你看过《UNDERTALE》的同人二创区，大概率会对“假如其他sans来到原版时间线”这类标题不陌生。它几乎是把同人圈最有吸引力的两个命题直接粘在一起：一个是“如果外来者强行进入主线，故事会如何失控”，另一个是“这个能够记住重置、看穿因果的骷髅角色，面对另一个自己时到底会做什么”。

很多人点开视频之后的第一反应是“很震撼，但没有完全看懂”。为什么？因为这类创作表面上讲的是角色相遇，实际上讲的是世界观规则之间的冲突。而世界观规则这件事，恰恰是软件工程师每天都要处理的问题。如果你把“原版时间线”理解成发布分支，把“其他sans”理解成来自另一个分叉仓库的提交，把“穿越”理解成一次跨分支合并，那么整段剧情的逻辑会变得异常清晰。

这篇博客不做剧情考据，也不讨论某个具体AU的角色强度排行。我会用版本管理这套技术模型，把“其他sans来到原版时间线”这个经典命题拆开，再把它背后的同人动画制作工程讲清楚。读完你会得到两样东西：一套用来理解同人叙事的新工具，以及一套真正能落到创作落地阶段的素材管理与协作方法。

1. 这篇文章真正要解决的三个问题

第一，为什么“其他sans来到原版时间线”这类故事天然好看，而且容易造成剧情失控？因为它本质上是一次违反分支保护规则的跨分支合并。外来sans不是原版时间线的本地提交，他自带另一套记忆、能力体系和目标。合并发生时，原版角色对他的了解程度、信任程度、战斗力评估全部失效，冲突不是偶然，而是结构性必然。

第二，为什么很多观众看完之后会“懵”？因为这类创作默认观众已经知道《UNDERTALE》官方的重置机制、sans在屠杀线路中的行为，以及AU文化的核心设定。如果你只看了零散片段，很容易把“sans”当成同一个角色，进而觉得剧情莫名其妙。本文会给出一个更精确的框架：同一角色名在不同时间线上，是不同的快照对象。

第三，同人动画这种内容形态到底需要什么样的工程能力？很多人以为它是“画几张图、配个音乐”的事情，实际上从分镜到动画到剪辑到多人协作，每一步都可能毁在素材管理上。本文会给出目录规范、版本管理方案和协作分工建议，这部分对所有做视频创作的人都有参考价值。

本文的目标读者是三类人：正在追这类AU视频但总觉得没看懂的技术人；自己也在做同人动画、需要工程化方法的内容创作者；以及想用软件工程思维重新理解叙事模型的开发者。如果你是纯路人，也能通过“分支、快照、合并冲突、回滚”这套概念，快速进入同人世界观的讨论语境。

2. 基础概念：把《UNDERTALE》同人宇宙当成一棵分支树

2.1 原版时间线 = main 分支

在官方游戏《UNDERTALE》里，时间线并不是一个可以随便改写的系统，但它确实存在“重置”的设定：拥有决心的人类灵魂在死亡或结局达成后，可以重置世界，让所有人都回到起点。这件事用版本管理类比，就是重置到某个历史提交。

“原版时间线”并不是官方明确给出的一个分支名，它更多是同人圈的公共认知：玩家第一次进入地下世界、完成普通结局或和平结局时，所经历的那条线。把它理解成main分支没有问题。它的特征是稳定、被多数人认可、承担着“标准叙事”的角色。官方游戏流程就是这一条主干上的完整提交历史。

2.2 AU 世界 = fork 出的独立仓库

同人AU（Alternate Universe）本质上是从原版 fork 出去的独立世界。创作者是仓库维护者，他们复制了初始设定，然后添加自己的修改：换掉某个角色的立场、改写某个关键事件、调整世界规则，最终得到一条和原版完全不同的提交历史。

你可以把每个AU理解为：

• 有自己的main分支。
• 有自己的 commit 历史，和官方主仓共享前半段祖先提交。
• 有自己的角色状态快照，因此同一个名字sans，在不同仓库里的实现完全不一样。

“其他sans来到原版时间线”就是一次跨仓库操作：把另一个仓库中的某个提交，应用到原版仓库的主干上。

2.3 角色版本 = commit 上的快照

理解这个问题的关键是：sans 不是一个全局单例对象。官方原版里的 sans，和UnderFell里的sans、Error!Sans、Ink!Sans，虽然共享同一个基础形象资源，但内存中的状态、技能列表、记忆栈、行为逻辑完全不同。

用代码表达就是：

// 原版时间线中的 sans 状态快照 { "character_id": "sans", "timeline": "original", "memory_ids": ["judgment_day", "papyrus_bound", "promise_kept"], "intent": "observe_and_judge", "abilities": ["shortcut", "gaster_blaster", "bones"] }

// 另一个时间线中的 sans 状态快照 { "character_id": "sans", "timeline": "alternate-001", "memory_ids": ["world_destroyed", "no_papyrus", "war_survivor"], "intent": "destroy_or_protect", "abilities": ["error_corruption", "summon_blue", "timeline_travel"] }

两个JSON字段里的timeline、memory_ids、intent完全不同。当第二个对象被强行放进原版时间线时，它携带的外部依赖（记忆、目标、能力）在原版上下文中找不到对应接口，系统自然会报出“合并冲突”。

2.4 核心术语对照表

这张表是后面所有分析的基础。记住一点：在原版时间线里，其他sans是一段不可直接运行的代码，他需要重新绑定上下文。

3. “其他sans来到原版时间线”是一次跨分支合并事故

3.1 场景一：只读访问，一切正常

如果外来sans只是短暂观看原版时间线，不参与任何事件，那么这次操作可以看作“只读快照”。对应在Git里就是git fetch另一个仓库的内容，但不执行merge，本地主干不会被触碰。

这种剧情模型通常很温和。外来sans观察原版角色，不改变任何事件节点，观众获得的是信息增量而不是剧情破坏。很多同人作品会先安排这个阶段：一个陌生sans突然出现，但没有立刻改变世界。

然而，同人视频想要制造看点，几乎不会停在只读阶段。因为“只是看看”意味着没有冲突，没有冲突就没有戏剧张力。所以第二个场景才是主流。

3.2 场景二：合并别人的改动

当外来sans开始和原版角色说话、战斗、改变某个事件的结局，他就从“只读”变成了“写入”。这时候系统要做的事情是：把他的行为提交合并到原版时间线的主干上。

问题在于，原版时间线的历史提交基本是稳定的——角色关系已经建立，事件因果已经闭合，甚至连“某个时间点谁必须死亡”都写死在剧情脚本里。外来sans的改动一旦合并，就会和原有提交产生大量冲突：

• 他认识Papyrus，但Papyrus不认识他。
• 他知道某个玩家路线会走到什么结局，但原版角色不知道。
• 他试图阻止某个事件，但那个事件是主线后续逻辑的前置依赖。

在Git里，这种冲突根本没法自动解决。同人剧情的处理方式通常是两种：让外来sans强行改变世界规则，或者让原版角色接受新信息后重新决策。但无论哪种，都意味着原版时间线已经不再“原版”，它变成了一个合并后的新分支。

3.3 场景三：强制推送与覆盖

更极端的情况是，外来sans试图覆盖整个原版时间线。用Git术语说，就是git push --force。他带来的不是“合并”，而是“替换”。

这一场景在AU创作里非常常见，也是最容易引起观众争议的部分。因为从原版角色的角度看，自己的整个世界被人为重置或改写，个人意志、记忆、经历全都不再算数。这种冲突本质上是“分支重写权”之争：谁有权力覆盖一条已经存在的时间线？

理解这个模型后，你就能看懂为什么这类作品会让观众产生强烈情绪反应。观众对原版sans的情感投入，建立在他所在时间线的历史积累之上；而强制推送意味着这些历史积累被破坏。剧情里表现出的痛苦、反抗、妥协，全是“冲突解决策略”的外在呈现。

4. 用软件工程思维拆解这类叙事的三种模型

4.1 快照模型：只是路过，不留下痕迹

模型特征：外来sans读取原版时间线状态，不做任何写入。剧情层面的结果是“他看到了另一个自己，然后离开”。这类叙事适合介绍角色设定、建立情感铺垫，但它不改变主线。

用技术话说，这是git diff操作：我们查看两个分支之间的差异，但本地分支的 HEAD 没有移动。

这种模型的软肋是：观众看多了会觉得“没有推进”。如果一集视频只停留在“相遇—观察—离开”，叙事价值会很快耗尽。它更适合作为大故事的第一集，用来交代外来sans的背景。

4.2 合并模型：外来者真正参与主线

模型特征：外来sans变成活动对象，与主线角色产生交互，事件路径发生偏移，最终形成一个新的、融合了双方记忆的时间线状态。这是“假如其他sans来到原版时间线”最典型的展开方式。

对应到工程上，就是一次真实的git merge或git cherry-pick。合并完成后，历史不是简单替换，而是产生了新的合并提交，双边的变更都在新状态里有所体现。

从创作者视角看，这个模型的可控性最好。你可以保留原版角色的人设基础，再叠加外来sans带来的变量。观众既能看到熟悉的世界观，又能感受到“出格”的新鲜感。这也是大多数同人长剧集选择的叙事结构。

4.3 重置模型：把原版时间线推向另一个状态

模型特征：外来sans拥有覆盖能力，最终原版时间线被改写，所有角色被推到一条新的命运路径。对应到Git，相当于对外来提交执行了：

git reset --hard HEAD~3

历史提交丢失，世界回到新起点。

这种模型的冲击力最强，风险也最大。因为它非常依赖观众对外来sans动机的理解。如果观众没有接受“为什么他要这么做”，那么整个覆盖行为就显得强制和生硬。而一旦接受了动机，这种模型往往是催泪和震撼的根源。

创作者在选择模型时，其实是在回答一个问题：你要让这条时间线变成谁的提交历史？这比确定角色强度更重要，因为它定义了整个故事的价值观。

5. 从“看懂故事”到“做出故事”：同人动画制作工程拆解

5.1 这类动画的基本制作环节

虽然我不清楚这部《假如其他sans来到原版时间线...?-骷进重澜 新第一集 【空潮虚寞 主】》具体使用了什么工具链，但从同类AU动画的常见制作路径来看，流程大体包括：脚本、分镜、角色原画、动画、背景、配音、音效、剪辑、合成、字幕、压制发布。

很多个人创作者会压缩到极简流程：使用像素风或者纸片人式的表现方式，降低原画工作量；使用模板化配音和BGM；优先把剧情和节奏做出来。这样做可以保证“一集视频能在合理周期内发出来”，而不是陷入无限打磨的质量黑洞。

对于刚开始做这类内容的人，我的建议是：不要一上来就追求剧场级质量。先做一集能完整表达剧情的产物，跑通全流程，再考虑美术升级和动画表现力。这在工程上叫“先做最小可用版本”。

5.2 素材管理与目录规范

无论你用哪种工具，素材命名混乱都是最大的时间杀手。一部作品往往包含：角色立绘、差分表情、背景图、特效素材、配音文件、音乐文件、剪辑工程、字幕文件、版本导出文件。如果不做目录规范，第三周你就会发现“最终版_final_真的最终版_v2”这类文件出现。

推荐目录结构：

project_root/ ├── 00_docs/ # 脚本、分镜、设定文档 │ ├── script/ │ ├── storyboard/ │ └── world_setting/ ├── 01_assets/ # 原始素材 │ ├── character/ # 按角色建子目录 │ │ ├── sans_original/ │ │ ├── sans_alt/ │ │ └── papyrus/ │ ├── background/ # 场景背景 │ ├── effect/ # 光效、粒子、特效 │ └── sound/ # 配音、音效、BGM ├── 02_working/ # 中间工程文件 │ ├── animation/ │ ├── compositing/ │ └── edit/ ├── 03_release/ # 发布版本 │ ├── v1_preview/ │ ├── v2_rc/ │ └── v3_final/ └── README.md # 记录每集状态和改动

命名规范建议使用集数_场景_角色_动作_版本格式，例如：

ep01_scene03_sans_enter_v01.png ep01_scene03_sans_enter_v01.psd

这套规范和代码仓库的命名哲学完全一致：让文件本身携带上下文信息，而不是靠人类记忆去关联。

5.3 善用 Git LFS 管理大文件

说到版本管理，很多人会问：视频项目能用Git吗？能用，但大文件必须交给Git LFS（Large File Storage）。普通仓库会把PSD、配音WAV、视频片段当作大文件，导致克隆和提交极其缓慢；LFS则会把大文件指针存入仓库，真实内容存到远程存储服务。

在项目根目录添加.gitattributes：

# 标记需要由 Git LFS 接管的大文件类型 *.psd filter=lfs diff=lfs merge=lfs text=false *.wav filter=lfs diff=lfs merge=lfs text=false *.mp4 filter=lfs diff=lfs merge=lfs text=false *.mov filter=lfs diff=lfs merge=lfs text=false *.aep filter=lfs diff=lfs merge=lfs text=false

初始化LFS：

git lfs install git lfs track "*.psd" git lfs track "*.wav" git lfs track "*.mp4" git add .gitattributes git commit -m "chore: add git lfs tracking for big media files"

需要注意的是，Git LFS并不能解决所有协作问题。它只负责版本追踪，不负责团队同步的沟通纪律。即使有LFS，也应该避免两个人在同一时间编辑同一个Prate文件，否则合并冲突仍然会让你崩溃。

5.4 多人协作分工建议

同人动画进入多人协作阶段后，最容易出事的往往不是制作，而是“交接”。原画、动画、配音、剪辑各环节都会产生中间版本，如果每个人在自己的本地目录里存文件，然后用网盘传来传去，那么版本错乱只是时间问题。

比较稳妥的方式是：由一个人维护“发布基线”，所有素材以这个基线的版本为准；其他人只提交增量改动，并附带说明。简单说，就是让整个项目有一个唯一的main分支，而不是每个人各自维护一个私有主干。

这看起来很基础，却是大多数个人项目翻车的原因。如果你只是自己做着玩，完全可以不搞这套；但只要超过两个人协作，请务必先定规则再动手。

6. 一个最小示例：用 Git 模拟一次时间线入侵

接下来做一个可以直接运行的实验，用Git本身模拟“其他sans来到原版时间线”的过程。这个实验不依赖任何视频素材，只需要一台装好Git的电脑，十分钟内能看到结果。

6.1 准备仓库

首先创建一个演示用的Git仓库：

mkdir sans-timeline-demo cd sans-timeline-demo git init git config user.name "sans" git config user.email "sans@undertale-demo.local" cat > timeline.md <<EOF # 原版时间线 - 玩家落入地下世界 - 遇到Papyrus - 在雪镇与sans对话 - 走到最终结局 EOF git add timeline.md git commit -m "feat: 初始化原版时间线"

这一条提交就是“原版时间线”的初始状态。

6.2 创建“外来sans”分支

新建一个分支，代表另一条时间线中的sans：

git checkout -b sans-alt cat > alt_plan.md <<EOF # 外来sans计划 - 阻止原版结局发生 - 改变Papyrus的命运 - 尝试覆盖时间线 EOF git add alt_plan.md git commit -m "feat: 外来sans带着自己的计划进入时间线"

此时本地有两个分支：main代表原版时间线，sans-alt代表外来sans携带的改动。

6.3 模拟合并冲突

现在执行“外来sans来到原版时间线”的合并操作：

git checkout main git merge sans-alt

这次合并会成功，因为两条分支修改的是不同文件。但这也说明一个关键问题：剧情冲突不取决于文件是否同名，而取决于改动是否触及同一条语义依赖。所以下一步，我们把两个sans的状态写进同一个文件，制造真正的冲突。

在main分支里修改角色配置：

cat > character.json <<EOF { "character": "sans", "timeline": "original", "ability": "shortcut", "memory": "judgment" } EOF git add character.json git commit -m "feat: 原版sans状态"

切回sans-alt分支，修改同一个文件：

git checkout sans-alt cat > character.json <<EOF { "character": "sans", "timeline": "alternate", "ability": "corruption", "memory": "world_destroyed" } EOF git add character.json git commit -m "feat: 外来sans状态"

再次合并：

git checkout main git merge sans-alt

这次Git会报告冲突，character.json进入冲突状态。查看冲突文件：

cat character.json

在输出中会看到<<<<<<< HEAD和>>>>>>> sans-alt之间的冲突标记。这就是“外来sans进入原版时间线”的代码级表达：两边都不愿意放弃自己的状态。

6.4 观察结果

现在你需要决定如何解决冲突。选择原版状态、外来状态，或者手动融合出一个新状态。这个决策动作，本质上就是同人作者在写的“剧情推进”。

Git实验到这里，你应该已经理解了一个抽象但重要的结论：冲突不是异常，而是两个上下文合并时的必然产物。同人动画里的战斗、对峙、妥协，全都是冲突解决策略的具象化。

7. 常见理解误区与排查思路

7.1 “sans到底是不是时间线管理者？”

不是。在官方《UNDERTALE》中，sans并没有明确表现出“时间线管理者”的身份。他在屠杀线路里的行为更多是基于观察和判断。能感知重置的另有角色，比如Flowey。同人圈里“sans能记住重置”“sans打破第四面墙”的说法，属于二创演绎，而不是官方准则。

观众如果把二创设定当成官方设定，就会对剧情产生错误预期。建议在讨论时明确区分：这是官方设定、同人常见设定、还是本作专属设定。

7.2 “为什么重置之后大家还有记忆？”

官方设定中，重置不是所有人都会失去记忆。拥有强大决心或特殊连接的角色可能保留部分记忆。而同人作品里的“记忆保留”往往是为了服务剧情。

用版本管理的语言说：重置相当于git reset --hard，但某些角色相当于“外挂进程”，运行在版本系统之外，所以重置对他们只影响文件系统，不影响进程内存。这类角色天然适合做穿越剧情的主角，因为只有他们还记得“之前发生过什么”。

7.3 “为什么外来sans在原版里看起来会ooc？”

ooc是“Out of Character”的缩写，意思是角色行为偏离了大家在原版中形成的认知。这句话隐含一个预设：所有sans应该共享同一套性格。

但从版本模型看，来自不同时间线的sans原本就是不同快照，ooc只是快照差异，不是错误。真正的问题应该是：创作者是否给出了足够合理的背景，让观众理解这种差异的来源。如果没给，观众就会觉得角色崩坏；如果给了，那就是一个合理的AU设定。

7.4 综合排查表

这张表可以当成看番时的排错手册。遇到看不懂，先问一句：这里是哪条时间线？这个sans是哪次提交的快照？

8. 给同人创作者和开发者的共同建议

8.1 维护世界观 Changelog

同人长剧集最怕“设定前后矛盾”。今天sans还能穿越，明天就穿越不了；这期Papyrus知道真相，下一期他又不知道。观众不会去读你的设定文档，但他们会对“记忆一致性”极度敏感。

建议为作品维护一个world_changelog.md，每次修改世界观规则，记录：

## ep01 - 新增 - 外来sans可以从其他时间线进入原版时间线 - 原版角色初次见面时保留自己的记忆 ## ep02 - 调整 - 外来sans穿越存在冷却时间 - 原因：避免能力无限制滥用

这不是一个复杂操作，但能帮你避免所有长线叙事的致命伤——设定崩塌。

8.2 角色也可以做成状态机

开发者在设计复杂系统时，喜欢把对象建模成状态机：空闲、攻击、受击、死亡，每个状态定义合法迁移路径。同人创作者同样可以这样管理角色。

比如外来sans在原版时间线中的状态可以分为：

• 探索状态：观察原版角色，不展示敌对意图。
• 对峙状态：与特定角色发生冲突，能力系统启用。
• 妥协状态：接受无法改变某些事实，调整目标。
• 覆盖状态：尝试强制执行自己的时间线方案。

给每个状态下定义触发条件和出口条件，角色行为就会变得稳定和可预测。这不会限制创作，反而会减少“为了冲突而冲突”的剧情混乱。

8.3 发布前测试与灰度反馈

视频发布前，找一个没看过原版设定的路人，让他试看前5分钟。如果他能流畅说出“谁、在哪、为什么”，说明叙事交代到位了；如果他一头雾水，说明你的前5分钟是在自嗨。

这个概念很接近开发中的“灰度发布”：先在最小范围内验证，再推向大平台。对创作者来说，可以先把样片发给同人圈核心群、信任的审片朋友，收集三种反馈：设定能不能看懂、情绪有没有到位、节奏会不会拖。而不是直接发布到大平台然后看着差评陷入自我怀疑。

8.4 风险意识与二次创作边界

同人创作本身存在授权边界问题。不同游戏、动画IP对同人的态度不同，《UNDERTALE》社区整体对二创比较开放，但这不意味着所有衍生作品都没有边界。创作者应该主动了解原始IP的二次创作规范，不用原创角色去冒犯原作角色设定，同时避免商业用途带来的版权风险。

对开发者来说，这也是一种“责任意识”：你可以把别人的开源项目fork出来做修改，但要保留原作者署名、遵守许可证协议。道理是完全一致的。

9. 借助版本思维，看懂任何“时间线”故事

回到标题里的问题：假如其他sans来到原版时间线，会发生什么？

用版本控制回答就是：会发生一次必然的跨分支合并，冲突无法避免，最终状态一定不再是原来的main。这时真正重要的已经不是“谁打赢了”，而是“保留和执行了哪些提交”。一段记忆、一条承诺、一次选择，在这个模型里统统可以被看作commit信息。原版sans做出的每一个决定，都是曾经写入这支时间线的关键提交。

理解这层逻辑之后，你会发现同类作品真正想讨论的不是战力高低，而是世界观不可兼容时，角色愿意为哪条时间线保留哪一段历史。这才是“跨分支事故”最有价值的地方。

如果你之后再做自己的同人项目，可以试着先画一棵逻辑分支图，把每个角色的时间线背景写清楚，再推动剧情。这样既不会有漏洞百出的设定，也能把造成全剧最大情绪冲突的节点，精准地安放在跨越分支的那一次合并中。毕竟观众记住的从来不是某段特效，而是某条时间线最终被书写的结局。