docs: new post

2 files changed, 74 insertions, 38 deletions

diff --git a/content/posts/介系.md b/content/posts/介系.md
deleted file mode 100644
index be8cad34..00000000
--- a/content/posts/介系.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-title: 介系
-tags:
-  - Backrooms
-  - 叙事
-  - 创作
-date: 2025-07-17
-draft: true
-toc: true
----
-
-之前在 Backrooms 中文维基做版主的时候，遇到过一个管理问题。
-
-Backrooms 的世界观中有多个「层级」，你可以理解为一个异世界中相互独立的箱庭空间，每个层级都有各自的异常属性和环境，允许不同的故事发生，这也是创作者最主要的写作赛道。和 SCP 基金会一样，每个作品都有编号。
-
-编号具有双重意义。在世界观内，这是故事中角色对他们所记录的空间的命名格式，在世界观外，就起到对作品的管理作用。[^2]一般来说，像 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]，最终，有一个版主提出了「介系」这个概念，用来表示「主层级归属于某一层群，但自己却归属于另一层群的子层级」（很绕，对吧？）。她很聪明，在推出「介系」这个概念的时候，她要我们不对外给出任何解释，也就是不要把设定写死，避免造出另一个「层群」，让「介系」仅作为一个管理概念出现。
-
-尽管「介系」这个概念因为不明所以，并不如「层群」深入人心，但它无疑解决了问题。当然，最理想的方案是，在最开始「层群」的概念就不存在，这样就不需要再造出另一个概念做补丁了。
-
----
-
-
-
-前文我讨论的「作品管理」[^5]与「世界观」对编号的解释权冲突，也可以理解为是上下叙事层的冲突。
-
-[^1]: 原谅我乱用了俗语。不过社区发展到这个规模，要修改之前的设定就会非常棘手，不太现实。
-
-[^2]: 一些编号也会有特殊含义，比如 Level C-996 似乎就是一篇对 996 工作制的声讨。
-
-[^5]: 如果你好奇我们为什么需要「管理」作品，请记住这是一个由几百个（算上已经离开的作者的话，可能更多）创作者组成的写作社区，大家都在同一个世界观下写作，
diff --git a/content/posts/介系的故事.md b/content/posts/介系的故事.md
new file mode 100644
index 00000000..a6767599
--- /dev/null
+++ b/content/posts/介系的故事.md
@@ -0,0 +1,74 @@
+---
+title: 介系的故事
+tags:
+  - Backrooms
+  - 叙事
+  - 效率
+  - 软件
+  - 工程
+date: 2025-07-17T23:29:00
+draft: false
+toc: true
+categories: 生产力报告
+---
+
+之前在 Backrooms 中文维基做版主的时候，遇到过一个管理问题。
+
+Backrooms 的世界观中有多个「层级」，你可以理解为一个异世界中相互独立的箱庭空间，每个层级都有各自的异常属性和环境，允许不同的故事发生，这也是创作者最主要的写作赛道。和 SCP 基金会一样，每个作品都有编号。
+
+编号具有双重意义。在世界观内，这是故事中角色对他们所记录的空间的命名格式，在世界观外，就起到对作品的管理作用。[^2]一般来说，像 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. 建立系统实际上是一种虚假的工作，和做计划一样，尽管没有产出任何结果，但人仍然能够通过想象脑补自己通过这套系统完成工作的模样。就像嗑药一样，明明没有真正值得快乐的事情，却能无缘无故感到满足。
+2. 一个需要被推翻的系统往往是设计得很烂的系统，而设计一个烂系统又是最简单的。人可以用最少的精力建立一个看起来很有用的系统，然后又因为实际的原因推翻这个系统，重复让自己感到最快乐的过程。然而，这个「实际的原因」实际上是一开始就注定会出现的，因为自己根本没有花心思设计这个系统。
+
+之所以要在建立系统时考虑未来的修改，就是要避免「系统需要被推翻」的可能性，也进一步避免了个体在反复的推翻和重建中陷入「效率幻觉」。我在一年前非常热衷于重建博客，在这种过程中，有不少文章丢失了，重建的结果也早就在一次一次的更迭中消失了。我花了很多精力折腾，最终留下的却很少，我在数次重新开始的过程中感到的快乐，就是一种「幻觉」。
+
+当然，除了「推翻」这种极端情况，另一种可能是改良系统，也就是「打补丁」，这就是介系的故事了。
+
+## 必要的补丁
+
+Backrooms 最早一批管理人员在发明「层群」这个概念时，大概觉得这是一个在世界观内外都近乎完美的解释，并不觉得是引入了复杂性。这里又要提到一个软件工程领域常出现的词，叫做「技术债」。
+
+一种观点是：所有代码都是技术债——你写下的代码会因为各种原因需要在未来的开发过程中被不断修改，或者因为这段代码的存在，其他人在写新的代码时会受到限制。一个性能很差的图像引擎可以吹嘘自己被多少著名软件使用，但这个图像引擎被使用的主要原因可能是因为迁移和重构的成本巨大，难以完成，所以从一开始就保留到现在，而不是因为有客观上的优势。这就是技术债的一种。
+
+一些技术在几年前刚出现时的确是领先时代的，到后来会在各方面被新技术完败，但并不会很快死在沙滩上，原因就是难以避免的技术债。不可置疑，Deno 以及后来出现的 Bun 作为 JavaScript 运行时，都要远胜于 Node.js，而如今人们离不开 Node.js 的主要原因是其稳定性、完善的软件生态和文档资料，以及很多项目都在漫长生命周期的一开始使用了 Node.js，迁移的代价非常大。
+
+同理，「层群」的概念被提出时，的确解决了当下的燃眉之急。我们不能做事后诸葛亮，责备前人眼光不够长远，因为它在当时看起来真的完美无缺。==既然系统的缺陷和软件的技术债一样难以避免，在必要的时候通过「打补丁」来解决问题就很重要==。前文提到的「介系」就是对「层群」这个概念的补丁，那么好的补丁应该是什么样的？
+
+补丁不能只解决最表面的问题，至少要想办法避免相似的问题发生。就像修水管，不能只是把爆裂的水管补上，还要找到水管爆裂的原因，如果是水压太大，就要找到根因，避免水管再次爆裂。不过，有些结构性的问题是没法修改的，比如「层群」这个概念已经出现，又不能直接删掉或替换掉这个模块，就要「向下兼容」，同时要尽可能「向上兼容」。
+
+「介系」就是一个极佳的案例，他在「层群」的现有概念下自圆其说，为系统中本不合理的特例赋予了名字，这是「向下兼容」；同时，尽管每个人对于「介系」都有自己的理解，但并没有官方的、明确的定义，「介系」实际上是一个**没有解释任何事情但却解释了所有事情**的、不言而喻的概念——每个人都因为自己的理解而觉得它合理，但又因为没有定义，每个人都可以随时更改自己脑中的解释，从而让未来可能发生的改变也变得合理——这是「向上兼容」。「向上兼容」的本质和高明之处在于，提出者观察到了系统当下出现问题的根因，也就是「定义太明确导致限制太明显」，并通过主动模糊定义来避免类似的问题出现。
+
+总结一下，尽管系统在设计之初能尽量做到灵活，但难免会在未来出现当下考虑不到的情况。当推翻重建的成本高昂，打补丁就成了必要之举，而这个补丁除了要解决当下的问题，还需要通过观察问题的根因，来避免问题再次出现。
+
+---
+
+## 题外话
+
+我对这篇文章其实不太满意，因为并没有给出什么实在的效率方面的建议[^6]，不过，在写作的过程中我切实地感受到了「小说写作」和「程序设计」的相似性，这也是为什么 Paul Graham 会把黑客类比成画家吧。
+
+[^1]: 原谅我乱用了俗语。不过社区发展到这个规模，要修改之前的设定就会非常棘手，不太现实。
+
+[^2]: 一些编号也会有特殊含义，比如 Level C-996 似乎就是一篇对 996 工作制的声讨。
+
+[^5]: 如果你好奇我们为什么需要「管理」作品，请记住这是一个由几百个（算上已经离开的作者的话，可能更多）创作者组成的写作社区，大家都在同一个世界观下写作，
+
+[^6]: 可能是最近忙到脑袋转不过来，没办法集中注意力写作吧。