docs: update drafts

1 files changed, 29 insertions, 0 deletions

diff --git a/content/posts/介系.md b/content/posts/介系.md
new file mode 100644
index 00000000..56db6149
--- /dev/null
+++ b/content/posts/介系.md
@@ -0,0 +1,29 @@
+---
+title: 介系
+tags: 
+date: 2025-07-17
+draft: true
+toc: true
+---
+
+之前在 Backrooms 中文维基做版主的时候，遇到过一个管理问题。
+
+Backrooms 的世界观中有多个「层级」，这也是创作者最主要的写作赛道。一般来说，像  Level 0 和 Level 178 这种直接用数字编号的层级，都是英文主站点的作品，其他语言分部为了避免编号冲突，会添加一个前缀，比如 Level C-185。这本是一个管理决策，但**为了在世界观内给出一个解释**，就引入了「层群」的概念——没有前缀的是主层群的层级，有 C 前缀的就是 C 层群的层级，不同语言分部都有自己的层群。
+
+这个设定导致了一个问题。大部分人在写作的时候，会为层级设置出入口，和其他层级连通，但即使是在不同层群的层级之间也能自如穿梭，作为各自的出入口不会有任何限制。这就导致「层群」的概念在大部分时候是一个管理概念，但在需要的时候又会出现在剧情里作为世界观内真实存在的区域划分。
+
+真正的问题是，Backrooms 世界观里还有「子层级」的概念，用来表示这一个层级内的特殊区域，例如 Level 1.5 就是 Level 1 的子层级。子层级的作者和父层级的作者往往不是同一个，创作者可能是想要对别人的作品做出新的诠释和拓展，或者只是纯粹喜欢某个层级，所以创作子层级。如果中文站点的作者为 C 层群的层级创作子层级，那就不会出现问题，Level C-10 的子层级编号为 Level C-10.1 就好了；但如果要为其他分部（不同层群）的层级创作子层级，就不能抛弃站点的前缀，否则可能会导致命名冲突。比如，如果中文站点的作者想为主站点的 Level 231 这篇层级创作子层级，写成 Level 231.2 就不行，因为没有前缀的编号只有主站点的作者才能用。后来我们想出了 Level 231.2-C 这种编号格式，但前人挖下的坑又绊倒了我们——
+
+主层群层级的子层级怎么会跑到 C 层群去了？<!--more-->
+
+如果没有「层群」的概念，Level 231.2-C 就不会既归属于主层群，又属于 C 层群。换句话说，如果一开始没有为编号的差异做出世界观内的解释，后来对编号的改动就不会需要考虑世界观内的合理性。《Rick and Morty》里面有很多平行宇宙，每个平行宇宙都有编号，比如主角 Rick 所在的宇宙就是 C137，其他宇宙编号不一定是这个格式，编剧也从未在剧集里解释这些编号到底有没有格式，因为这对剧情不重要。
+
+不过祖宗之法不可变[^1]，最终，有一个版主提出了「介系」这个概念，用来表示「主层级归属于某一层群，但自己却归属于另一层群的子层级」（很绕，对吧？）。她很聪明，在推出「介系」这个概念的时候，她要我们不对外给出任何解释，也就是不要把设定写死，避免造出另一个「层群」，让「介系」仅作为一个管理概念出现。
+
+---
+
+尽管「介系」这个概念因为不明所以，并不如「层群」深入人心，但它无疑解决了问题。当然，最理想的方案是，在最开始「层群」的概念就不存在，这样就不需要再造出另一个概念做补丁了。
+
+接力小说社区中可能有几百个作者，其中不少人都有创作理念上的分歧，在一开始把设定写得太具体就会限制创作的自由，但如果没有具体的设定，
+ 
+[^1]: 原谅我乱用了俗语。不过社区发展到这个规模，要修改之前的设定就会非常棘手，不太现实。