當文字 RPG 累積數百篇貼文時，如何保持戰役歷史的可讀性
當文字 RPG 累積數百篇貼文時，要保持其歷史的可讀性，可以將這股資訊流轉化為一組精簡的關聯記錄：為每次跑團撰寫簡短回顧、建立動態索引，並為常駐角色、地點和未結案件記錄重點筆記。保留原始貼文作為完整記錄，但讓回顧成為玩家跟上進度時的起點。只要玩家能搜尋內容並對共享歷史應包含的項目達成共識，無論是共用文件、Wiki、筆記應用程式還是論壇，這套方法都同樣適用。
為什麼貼文存檔需要指引
按時間順序排列的記錄會記下說過的所有話，但很難拿來當作參考資料。玩家如果想找某個角色初次登場的地方，可能需要翻閱好幾頁；休坑一段時間後回歸的玩家，則可能需要快速了解最後一個未完結場景的梗概。因此，實際的目標並不是重寫每一篇貼文，而是加入一個便於瀏覽的導覽層，指向記錄中的相關部分。
RPG 戰役指南對「計劃的內容」與「實際發生的事」也做了類似的區分：跑團報告記錄了遊戲中的事件，其目的是幫助團隊日後回想。同樣的概念也很適合非同步的文字跑團，在這裡，「跑團（session）」指的可以是一個章節、場景序列或約定的暫停點，而不是預定的聚會時間。請參閱《跑團報告範本指南》。
可以將這個系統想像成三個層級：貼文存檔是原始記錄；回顧索引提供簡短、按時間順序的摘要；參考筆記則解答經常出現的疑問，例如「誰是 Vale 船長？」或「團隊在燈塔答應了什麼？」。將這些功能分開，可以防止角色頁面變成另一份龐大冗長的逐字記錄。
為回顧選擇可重複套用的單位
挑選符合你們團隊書寫方式的分界點。它可以是一個結束的場景、章節劃分，或是累積一定貼文量後的暫停。請使用團隊能一致認同的分界點。避免為每篇貼文都單獨寫回顧：這會增加維護成本，卻不一定能讓故事更容易瀏覽。
為每個單位建立一筆條目，並附上規律且可預期的標題，例如「第 12 章 — 玻璃港」或「場景 12.3 — 碼頭下的門」。如果故事順序容易混淆，請加入日期或序號。如果遊戲使用世界觀內建的曆法日期，請將其標註為虛構日期，並同時加上遊戲外的序號。這個小習慣能防止讀者把角色的日曆誤認為玩家撰寫事件的先後順序。
實用的回顧通常包含幾個精簡的段落或列點清單。擷取開頭的局勢、具影響力的選擇、產生的改變以及停下的位置。人物和地點的名稱必須保持一致。像「船員們見到了檔案保管員並了解了地圖」這樣的句子，遠不如「在北區檔案館，Mira Vale 向船員們展示了一張標有三座鐘樓的地圖；團隊決定先前往西側鐘樓」來得有用。後者能為回歸的玩家提供具體人名與下一步行動的著力點。
為便於檢索而寫，而非追求面面俱到
回顧是輔助記憶的工具，而不是場景的二次重演。生動的對話或描寫應保留在原始貼文中，除非某句簡短引言特別有用。改為總結起因與結果即可：「Rowan 歸還黃銅鑰匙後，渡輪伕同意引導團隊穿過海峽。」這樣既能保留劇情事實，又不需要複製整段對話。
在即興細節仍容易辨認時就記錄下來。RPG 記錄建議特別強調記下即興想出的名字、背景細節和意料之外的玩家抉擇，然後再將草稿筆記擴充為報告；同時也指出，只要能保留重要事件，列點清單就足夠了。對於文字 RPG 而言，新確立的事實尤其重要：一個隨口說出的名字、陣營的轉變或受損的地點，都可能成為團隊日後依賴的延續性設定。World Anvil 的跑團報告指南便提供了草稿筆記與最終記錄之間的實用區分。
將確立的事實與未解的疑問分開。例如：已確立：西側鐘樓已被遺棄。未解決：無人知曉是誰點亮了鐘樓的提燈。如果玩家的推測在故事中尚未證實，請將其標記為推論，而不要寫進事實回顧中。這個簡單的區隔有助於防止猜想意外變成正史設定。
為整場戰役建立索引
在存檔的最頂層放置一個簡短的戰役索引。它應按順序連結到各次回顧，並提供一句話的事件描述。極簡索引的樣貌可能如下：
上述貼文範圍皆為虛構範例。若您的平台支援穩定的貼文連結，請直接連結到場景或章節的第一篇貼文；若不支援，請使用團隊能穩定搜尋的定位方式，例如頁碼、日期或獨特的開頭語句。切勿依賴未經驗證的連結格式。如果場景出現分支或重疊，請在索引中加上簡要說明，而不是強行套入容易誤導的線性順序。
索引要保持精簡，以便快速掃讀。讀者應當能夠一眼看見最新章節並跳轉到特定回顧，而不需要逐條閱讀每個項目的段落。可以另設一篇「由此開始」筆記來解釋前提並指向第一篇貼文，但它不應取代按時間排序的索引。
串聯常駐人物、地點和故事線
只有在某個名字或主題反覆出現、達到玩家可能會搜尋的頻率時，才為其建立專屬的參考筆記。在角色筆記中，記錄姓名與別名、首次登場、已知職責，以及發生重大事件的回顧連結。在地點筆記中，記錄最新確立的狀態，並連結到改變該狀態的場景。在未解案件清單中，記下疑問、團隊目前已知的事項，以及該事件最後一次有進展的回顧。
保持這些筆記簡潔且具可追溯性。例如：「Mira Vale — 北區檔案館的檔案保管員；首次登場於第 2 章；將三座鐘樓的地圖交給船員；最後露面於第 5 章。相關：[第 2 章]、[第 5 章]。」這只是架構的虛構範例，並非針對特定遊戲或工具的主張。當參考筆記提出某項事實時，其連結應指向支援該事實的回顧或貼文。
在支援雙向連結（Backlinks）的筆記軟體中，這種架構會更容易建立。Obsidian 官方說明文件指出，其反向連結外掛程式會列出連結到目前筆記的其他筆記，也能顯示未連結的提及（unlinked mentions）；這使得找出提及常駐名稱的回顧變得十分容易。這項功能有其限制：未連結提及取決於名稱是否出現在文字中，且設定中排除的檔案可能不會顯示。請參閱《反向連結 — Obsidian 說明》。
使用一致的標籤和搜尋詞彙
挑選一組精簡的標籤，並在整個存檔中以相同的方式使用。實用的分類可能包括：recap（回顧）、character（角色）、location（地點）和 open-thread（未完伏筆）。只有在有助於檢索時才加上標籤。如果每篇筆記都加上一長串重疊的標籤，玩家就必須先學會分類系統才能找到故事。
如果您使用的工具支援結構化筆記屬性，請使用少數穩定的欄位，例如 type（類型）、chapter（章節）和 characters（角色）。Obsidian 的說明文件將屬性描述為結構化資料，可包含文字、清單、日期和標籤，並說明這些屬性是可以被搜尋的。這能支援多種搜尋需求，例如找出所有標記為回顧的筆記，或是與某個角色相關的所有筆記。標籤和確切的搜尋語法會因工具而異，因此在重新整理大型存檔之前，請先用小規模範例進行測試。《屬性 — Obsidian 說明》和《搜尋 — Obsidian 說明》詳細記錄了這些具體功能。
採用少數可靠的搜尋詞，勝過制定繁複的命名規則。在回顧中使用名稱的規範拼法，並在必要時註明別名：「Mira Vale（在第 2 章被稱為『檔案保管員』）」。如果角色改名或地點曾有舊名，請在參考筆記中納入舊稱。唯有當存檔保留了大家記得的字詞時，搜尋功能才能發揮作用。
保持存檔的準確性與實用性
依照團隊能持續負荷的節奏撰寫回顧：在每個約定的故事單位結束後，或在有人有空時進行。如果撰寫精修的文章是個負擔，可以先隨手記下名字、抉擇、新事實和停頓點；日後再來整理。World Anvil 的指南同樣建議，先記下幾天後仍能看懂的草稿筆記，再在時間允許時擴充為列點或敘述文字。持之以恆比產出詳盡卻在讀者需要時早已延遲許久的條目更為有用。
如果有多人共同編輯，請就簡易的編輯規則達成共識。可以由一人起草回顧，其他人指出遺漏的事件或延續性錯誤。在可能的情況下，將修正連結到相關貼文，並將有爭議的細節標記為不確定，直到團隊在遊戲中解決為止。切勿私自改寫回顧以掩飾先前的抉擇；應加上註明明日期的修正或說明，讓讀者能明白記錄變更的脈絡。
決定哪些內容屬於共享存檔。未經同意，公開回顧不應揭露私人角色筆記、未公開的劇情轉折或其他玩家的場外（OOC）言論。World Anvil 的跑團報告指南明確提醒公眾報告中應避免劇透，其戰役編年史（Chronicles）指南則介紹了如何區分公開與私人事件。即使沒有這些功能，簡單區分「共享回顧」與「私人筆記」也能讓受眾邊界保持清晰。請參閱《如何在編年史中規劃並記錄您的戰役》。
現有存檔的實用設定方式
您不需要一口氣總結數百篇貼文。從最新的幾個故事單位開始，因為它們對於恢復跑團最為實用。接著分批補充較舊的條目，從重大轉折點和常駐名字著手。誠實標註缺漏；若您只快速瀏覽了存檔的一部分，切勿暗示該回顧是完整的。
針對每一批次，遵循相同的簡短流程：
參考這個虛構範例，了解各個部分如何串聯。貼文 35–82 涵蓋了造訪玻璃港的過程。回顧中寫道，船員們在北區檔案館遇到了 Mira Vale，獲得了一張三座鐘樓的地圖，並選擇前往西側鐘樓。索引連結到該回顧並標明其貼文範圍。Mira 的參考筆記反向連結到該處，而未解案件筆記則記錄地圖的製作者仍然不明。玩家現在可以從索引開始，重溫章節事件，或直接跳至 Mira 或地圖之謎。
對於篇幅較短的存檔，帶有標題和索引的單一文件可能就足夠了。對於規模非常龐大的存檔，如果團隊願意維護，可以使用關聯筆記或 Wiki。工具功能有助於搜尋和交叉引用，但沒有任何組織方法能保證記錄下過去的每個細節；存檔的準確度取決於來源貼文以及總結時的細心程度。從團隊能夠維持更新的格式開始，並讓索引隨著故事一同成長。