既然你来到了这里，相信你多少都会对“为什么这些文档”产生疑问

对于这个问题，在常见问题中其实回答过了：

这就涉及到ARG流程本身了，首先一方面用来归档，方便留存线索，毕竟绝大部分ARG是没有笔记本的，需要你自己备一个，一方面解谜文档/wiki是用来告诉新来的进度，另一方面也是为了方便后续总结的

但是具体为什么重要，为啥需要这些，以及需要这些到底是什么，怎么做，这些可能很多人还是没有一个相对完整的概念，听的有点云里雾里的，更多人还是会抱着大佬的大腿说：欧内该，如果你不做文档/wiki的话，瓦达西，然后有些大佬就会烦起来，说：你（们）这个人啊，满脑子都想着自己啊，当然，这种状态也是会形成多数人吃瓜，少数人干活这种场面，甚至可能就因为没人做文档的事情，从而导致解ARG的团体解散了

所以，我就写了这篇文章，告诉你们为什么要这些以及怎么做：

（事先声明，我讲的文档/wiki，并非字面意义上的文档/wiki，而是ARG里所必要的记录环节（由于概念大家没有明确印象，所以我在下面会以文档/wiki/档案这些来称呼，更多是文档））

论为什么需要文档？

为什么需要文档？

首先，正式回答这个问题之前，先想想一个问题，ARG都是怎么加入并参与的吗？

那么，我举个例子，比如说《传送门2》arg，它是一个奇怪的更新公告+神秘的成就开始作为兔子洞的，但是也会有很多玩家是在收音机收集阶段啊才发现有这种奇怪的现象，更有人只在Potato一堆游戏阶段才知道说：欸？这难道是...arg？然后参与

那么，既然是这些进来的话，他们是怎么知道全过程然后一起汇总信息呢？只凭一堆聊天记录？要知道聊天记录很多都是碎片化信息，并不是说是垃圾，而是说人在正常讲话很多都是不按时间顺序来的，很多都是想到哪说到哪的，这肯定是不现实的，那么是不是需要一个汇总信息的手段啊？欸？共享文档/wiki那些不就是这么用的吗？于是那些人开始汇总各种信息，从头到尾，理顺了，让他们知道自己是什么情况，什么阶段

既然只是这样，就这一个理由还足够吗？那肯定不是，做多了之后，肯定会有人说，欸？这不是很好的一个arg吗，我想要做一个相应的解析去告诉别人，这个arg是怎么样怎么样的，那么负责解析的人去哪里找材料？总不能只靠一堆有一堆垃圾信息的聊天记录去找吧，那么文档/wiki作用更加体现出来了

那么，肯定会有人说：有些arg小的吓人、可以直接描述、相当冷门，那么是不是就可以不用做了？

那么，我反问下这些人，你们知道lostmedia（失传媒体）吗？

lostmedia（失传媒体）是指那些曾经存在/被制作/公开过，但是因为各种原因难以获取或被认为已经消失的媒体内容，就之前迷雾论坛和帷幕站合作那次，去寻找中国国内可能是最早的论坛——51arg那个视频上，这甚至只是一张报道偶然提到的图片

然后通过各种途径去寻找，最终我们只发现以前的网站的备份、百度贴吧发出的部分信息之类，这些信息少的可怜，也足够说明这些东西难找的很

ps：这是我写的时候，51arg这块几乎没有任何相应的进展，若有很大的进展之类，跟这篇文章无关，这边更多是通过这个例子来告诉我们不要因为arg本身怎么样而不去做备份/留存之类

那这时候，有人就头疼了：为什么一定有人要写文档啊？往死里解谜不好吗？那我举个例子吧，去勇闯地下城，你们可以说你们可以一直战斗，但是总得有后勤吧，吃啊水啊都是后勤要干的东西吧，文档就是所谓的后勤，所以这本身就是解ARG的一部分，不应该被认为这是无意义的东西在，所以还是有必要去写文档，只不过是不是你干，那就是分配和有没有自愿发起的了活了

那么，你觉得现在这个事情很小，描述一下就够了，但是人毕竟不是移动硬盘，肯定会忘记，而且，那些相当冷门的arg很多地方都是和其他那些较为成功的arg来说都是一样，可能不永久的（当然，前提是这货符合arg的定义），也会因为信息载体的关系从而找不到而因此彻底丢失吧，我不希望你们因为这些而不做文档，更不希望因为arg的时效性，关闭了部分的网站之类，失去了某些重要内容、然后成为lostmedia（失传媒体）

只用文档足够了吗？

诚然，这肯定不是就这样结束了，真要这么简单，那就跟只用AI就能解决一切代码，程序员可以滚了一样离谱

那么，反过来想，为什么只用文档不足够呢？

首先，你想想，ARG有一个特性就叫：时效性，那也就是说，ARG结束之后肯定会因为某些原因导致失效了什么的，那么该如何让别人知道为什么失效了呢，又是什么样的状态呢，那就是有必要去特意搞备份原作者视频/网站啊/线下视频啊等等，甚至红鲱鱼这个片段也建议是保留，这样就可以让后面的知道当时是什么样的状态，也知道前人是怎么踩坑的

然后，你们看到这，肯定会想，既然文档不够，做个wiki不就行了？我这边更多是说记录过程，但是二次整理本身替代不了原始记录，就说之前某AI公司销毁书（甚至是孤本）的事件来，很明显，数字化内容并不意味着原始载体就失去了保存价值，而且这还是销毁原始资料，那么，对于原始资料之后，别人如果看到，不相信的话，那怎么办，你原始资料没有，那别人只能是信你的说辞，那信任的条件就还是你所提供的原始资料吧，你不备份那别人就会质疑你吧

那么，既然都有这些，那只有文档肯定是不够的，而且文档并不是真正的原始资料，更像是我们所称的二次整理之类，所以还是需要去多备份原始资料之类告诉别人这个arg都是什么样的

只是为了解析服务/备份的吗？

如果只是为了解析服务/备份的话，如果是Solo的话，只是为了解析服务/备份这块可能确实会成立，尽管还是会落实到需要自己告诉自己什么样的，有什么需要自己告诉自己的那种情况在

但是一旦不是Solo，而是跟别人协作的情况之下，那就必然存在更多关于协作的问题，这个条件就不可能成立

ps：这里不是说arg本身规模的问题，Öoo这种短流程的都有多人一起协作去分析知识锁的精妙呢

还是给个更真实的例子吧：写自己程序的代码，这块你自己想怎么写怎么写都行，玩家状态机这块你switch甚至if别人都不知道，但是耦合性啊，性能什么的都得自己来，但是协作，你还是需要搞什么规范之类防止出现混乱之类，比如说代码含义一致、格式规范文档啊、API文档啊之类很多很多

那么，既然是协作文档/wiki那些，那首先第一要务，肯定是能看懂吧，那肯定有人会问了，我不瞎编几个不也是能让别人看懂吗？我这里说的能看懂是指你到底是怎么想的，然后把这些线索怎么展开去讲述一遍，毕竟文档那些也不是纯粹的资料库，也是二次整理的东西，所以，既然有协作，那必然就有规范之类，那么就肯定不是只有解析服务/备份这些作用在

而且你随便说你也确实能作为信息一部分啊，就算是误导的，错误的，但是这玩意确实应该得要存在（当然，太离谱的就不要写了），当然既然知道这个是误导的、错误的，那就去修改掉，然后去纠正这些错误论点或者是保留着，告诉别人这样去想是错误的（就跟我现在写的文章去思考你们可能会提出的问题一样）

ps：当然，如果真出现直接把人盒了什么的还是尽量先别写了，防止出问题

以及，我现在所说的文档、档案那些，本质上就是一个特定的记录环节，开头我也在事先声明里简单提及过，这种记录环节就是需要协作的，除非单通，协作的所带来的问题就一定会存在的

不过，至于剧透这一块，文档本身就必然会剧透，这个我并不能直接回答，你可以事先声明，接下来含有剧透之类的，然后怎么样怎么样，但毕竟这个是共同组合的结果，就跟解谜游戏解析一样，一旦举例子必定会有玩法剧透一样，这种怎么样去提醒，怎么样去布置还是你自己去做决定的

总之，文档/wiki那些只是为了解析服务/备份，肯定是想的太少了

具体怎么做？

说了这么多，肯定会有人说：说了这么多，那到底怎么做啊，你光讲理论干什么啊？那现在就是讲怎么做

在这里，我先事先声明，协作这块其实非常多，格式什么的我根本不会刻意去讲，就像变量名怎么取那种格式规范之类我是不会细讲的，具体怎么做还是要按实际的来，由于主题关系更多还是参考

以及我会以先来的/群内没写文档的情况入手，后面来的这个就按文档怎么样来就怎么样调整，这个由于是文章不是1对1教程不好讲，也不是什么模板之类的玩意，对于ARG的性质来说，我根本没有办法给你喂饭，所以这里更多是时机之类的：

首先，假设你是一个最开始发现arg的人，你觉得这玩意挺感兴趣，但是没有文档怎么办？那就开始做！

既然你是第一个先知道的，也是第一个写文档的，那么，我对于这方面的建议是说，如果有相应的格式模板啊之类的玩意，那就先直接套，但如果你没有，那么你可以先把你知道的所有东西，按时间顺序去写，然后在每一个事件上，以类似谜面-方式-谜底的方式（这个是相对来说最基本的结构）去写，这样就可以开始文档的路程了

那么后来，人多起来了，这种东西不够，而且也会想史山一样堆起来了，怎么办？那就是写格式规范，整理新手观看指南，重构文章，甚至规模更大的时候，组织一帮人去做相应的、更大的东西去承载、去方便解析之类，诸如wiki之类的

那么，这时候就有人要说了，你讲这些具体有啥用啊，这换其他的都是一样的，协作这块我承认都是差不多的，毕竟协作这块换什么独立游戏啊，程序制作啊这些都是需要协作的，我根本没有办法去告诉你具体怎么样怎么样，只能告诉你，创程序，写东西，重构，接着写，重构，拓展，重构...这些的操作，但是这些还不能没有，这种就是必须会出现的玩意