第13章管理一百篇作品——覆蓋矩陣與檔案管理

十篇作品積累起來，接著變成二十篇。到了三十篇，奇怪的事情開始發生：很難記住哪篇稿件寫過哪個人物；要分辨姜明淑已經寫過和還沒寫過的題材，也開始耗費時間；兩篇稿件出現相似場景，卻無法確定那是有意重複還是失誤。

這不是記憶力問題，而是管理問題。創作一百篇作品既是寫作，也是管理。只有寫作而沒有管理，五十篇之後必然陷入混亂。

本講介紹一百篇專案的管理體系。

覆蓋矩陣的運營

第5章介紹了覆蓋矩陣的概念，這裡討論實際運營方法。

矩陣結構。 縱軸排列人物，橫軸排列篇號。每個單元格簡要記錄稿件代碼、形式與題材類型。

簡化後的記錄可能如下：姜明淑出現在第1篇（ST-01-短篇/演出前）和第3篇（ST-15-小品/候場室）；成員B在第2篇（ST-07-漫談/後輩）出現一次；承包人B在第1篇（ST-04-短篇/委託）出現一次。每個單元格都以縮寫記錄代碼、形式和題材類型。

檢視矩陣，就能一眼知道每個人物擁有幾篇稿件、每種形式使用了幾次，以及哪些題材已經處理過。

更新時間。 稿件獲得合格判定後立即更新矩陣，也就是完成QA報告後馬上更新。若先堆積成稿，再統一更新，必然會有遺漏。

檢查週期。 每完成十篇，就檢查一次整個矩陣：哪些人物仍是空白，哪些形式數量不足，哪些題材類型正在重複。檢查結果應進入下一個十篇的寫作計劃。

這種方法類似美國電視劇《迷失》六季中的人物分配。劇集為十四名主要和配角人物每季分配一至兩集“中心人物集”，讓每個人物每季至少擔任一次主角。MCU的階段運營也有相同思路：一個階段結束時，檢查哪些英雄獲得了個人電影、哪些沒有，再在下一階段糾正。韓國網漫《Free Draw》的多視角運營和《看臉時代》的角色矩陣，也採用了相似態度。

稿件檔案管理

稿件檔案的管理方式同樣重要。一百個檔案混在一個資料夾裡，很難尋找。

我們採用以下原則。

檔名規則： ST-[篇號]-[人物程式碼]-[形式程式碼].md

檔名中的ST是“Storytelling 100 manuscript”的縮寫，設計稿檔案則以DS（Design Sheet）為前綴。ST與DS編號一一對應：以DS-001為基礎寫出的稿件就是ST-001。QA報告以ST-001-QA.md的形式與稿件存放在一起。

例如：ST-001-姜明淑-短篇.md、ST-007-成員B-漫談.md、ST-015-承包人B-小品.md

篇號按寫作完成順序分配。人物程式碼採用Vault賦予的程式碼或姓名，形式程式碼採用短篇/小品/漫談/四格。

資料夾結構：

[故事創作100稿件]
├── 完成/
│   ├── ST-001-姜明淑-短篇.md
│   ├── ST-001-姜明淑-短篇-QA.md
│   └── ...
├── 進行中/
│   └── ST-016-[人物]-[形式]-進行中.md
├── 設計稿/
│   ├── DS-001-姜明淑-短篇.md
│   └── ...
└── 覆蓋矩陣.md

完成資料夾同時儲存稿件和對應QA報告；設計稿資料夾儲存每篇稿件的設計稿；進行中資料夾則儲存當前正在寫的稿件。

採用這種結構，任何稿件都能迅速找到，也能關聯檢視各自的設計稿與QA報告。

管理世界觀一致性

隨著一百篇作品不斷積累，最難管理的是世界觀的一致性。早期確定的設定，會在後期稿件中不知不覺發生變化。

因此需要一套預防體系。

世界觀衝突日誌。 每當兩篇稿件之間出現世界觀衝突，就記錄衝突內容、兩篇稿件的檔名和解決方法。日誌不斷積累後，就能看出哪些世界觀元素最容易衝突。

衝突有三種解決方式：（1）修改後寫的稿件。 以Vault為準修改相關部分。（2）更新Vault。 如果後寫稿件的描寫更精確，就以它為準更新Vault，並在早期稿件中加入腳註或變更說明。（3）用時間線解釋衝突。 如果兩篇稿件處理不同時期，可以解釋為世界觀“在此期間發生了變化”，就在時間線中記錄變化節點。

Vault版本管理。 每次更新Vault，都記錄日期與變更內容：哪個項目因哪篇稿件、以什麼理由被加入。這會成為回饋迴圈的記錄。

人物一致性檢查表。 某個人物的稿件積累到三篇以上時，檢查該人物的一致性：語言習慣是否穩定，身體錨點特徵是否保持，關係記錄是否與其他稿件衝突。

時間線管理

如果K-pop K世界存在時間線，就要管理每篇稿件位於時間線的什麼位置。

時間線衝突是最難發現的世界觀衝突。稿件A把事件X處理為“已經發生”，後來寫的稿件B卻把同一事件處理為“尚未發生”。如果不明確每篇稿件的時間位置，就會產生這種衝突。

在每篇稿件中註明時間線位置。可在設計稿的背景確認項目中寫：“時間線基準：出道第N年，演出X之前/之後。”

時間線過於細密也會難以管理。日常切面情景可以只記錄“大致時期”，例如出道初期/中期/現在，這樣的大分類通常已經足夠。

管理題材重複

不同人物處理同一題材，不算重複。如果姜明淑和另一位成員分別處理“等待粉絲簽名會”這一題材，那是在同一世界中從兩個視角觀看同一情境。

同一人物處理同一題材才是重複。如果兩篇姜明淑稿件都寫等待粉絲簽名會，就必須用不同時期、不同配角、不同Fun Engine或不同利害關係加以區分。

在覆蓋矩陣中記錄題材類型，就能輕易發現同一人物的題材重複。

接近一百篇完成時

超過五十篇後，專案會進入另一階段：從初期創意豐富的局面，轉向可用題材逐漸被消耗的局面。此時需要進行幾項調整。

重新發掘題材。 再次系統執行第6章介紹的四路題材發掘法。回看已經完成的五十篇作品，尋找尚未探索的空白。

重新分析人物。 檢查從未成為主角、或只作為配角登場的人物。重新開啟他們的Vault記錄，確認現在是否已有值得作為主角探索的題材。

擴展交叉關係。 在五十篇稿件中，找出尚未相遇的兩個人物組合，探索這種組合可能產生的搭檔動力。專案越往後，尚未使用的組合雖會減少，已經形成的關係卻會變得更加複雜，因此題材反而會增加。

深化世界觀。 探索初期設定中尚未在稿件裡處理的部分。Vault中還有哪些項目尚未在稿件中呈現？那就是新的題材。

完成一百篇的意義

一百篇終於完成。那是數字上的完成，但還有更重要的完成。

它證明K-pop K世界已經豐富到足以支撐一百篇日常切面情景。百名成員中，許多人擁有了自己的稿件，或者在其他稿件中充分出現，成為讀者眼中活著的存在。Vault比最初厚重得多，其中積累了透過寫作發現的世界觀細節。

寫作者也發生了變化：一百份設計稿、一百份QA報告、一百篇稿件。在這一過程中反覆使用的技術，最終會變成直覺——即使沒有設計稿，也能自動設計利害關係；寫開頭時，自然植入世界觀訊號；讓整篇稿件逐步收束到落點。

這正是一百篇專案希望塑造的寫作者狀態。

第13章所傳達的內容

一百篇作品既是寫作，也是管理。只有寫作而沒有管理，到了五十篇就會撞牆。管理得當，一百篇稿件會彼此連結，世界觀也會成長。

覆蓋矩陣是管理的中心。矩陣會顯示專案當前所在的位置，也會顯示下一步該往哪裡走。

下一章——第14章——是本系列講座的最後一章。它將總結實踐中得到的認識、完成一百篇後回望才能看見的內容，以及“故事創作100”系列講稿希望傳達的核心。

- 正文／基於資料庫的“故事創作100”第13講講稿／2026-04-30

第13章 管理一百篇作品——覆蓋矩陣與檔案管理