時間線錯誤的四種類型
第五章，角色說「三年前的那個夏天」。第二十章，同一個角色說「五年前的那個夏天」——講的是同一件事。
十萬字的小說裡，這種矛盾藏得很深。寫的時候不會發現，改稿的時候也不容易注意到。但讀者會。讀者一定會。
Conan Doyle 就栽在這上面。Sherlock Holmes 系列裡，華生醫生的戰傷先是在肩膀，後來跑到了腿上。學者們給這個bug起了個名字叫「Watson's Wandering Wound」——華生的漂移傷口。一百三十年了，每本研究 Holmes 的專書都會提到這件事。沒有時間線文件，沒有角色資料庫，一個「背景設定」層級的疏忽，就這樣被釘在文學史上。
時間線錯誤不會毀掉偉大的作品。但它會變成永久的疤痕。
先搞清楚問題長什麼樣子，再來談怎麼解決。時間線錯誤分成四種，每種的成因和發現難度都不一樣。
絕對時間錯誤最好抓。故事設定在 2020 年，角色卻用了 2022 年才上市的手機型號。歷史小說裡，角色在電話發明之前打了一通電話。只要有一個熟悉時代背景的讀者，這類錯誤就無所遁形。
相對時間錯誤就隱蔽多了。開頭那個例子——「三年前」和「五年前」指向同一件事——就屬於這類。另一個常見的情況：角色「三十五歲」，但根據出生年份和故事年份一算，應該是三十三。這種錯誤需要讀者交叉比對才會發現。認真的讀者，一定會做這件事。
因果時間錯誤牽涉邏輯。角色在第十章提到一件第十五章才發生的事。角色一小時內從台北開車到高雄——物理上辦不到。這類錯誤直接把讀者踢出故事，因為它違反了世界運作的基本規則。
平行時間錯誤出現在多線敘事裡。兩條故事線應該同時進行，但細節對不上。角色 A 在第三章的週五打電話給角色 B，角色 B 的視角卻顯示那天是週三。寫多視角小說的人，幾乎都踩過這個坑。
四種錯誤有一個共同特徵：它們很少在初稿階段出現，幾乎都是修改和重組的副產品。改了一個日期，忘記同步更新引用它的地方。刪除了一個場景，卻留下了提到那個場景的對話。所以——需要的是系統，不是記憶力。
建立你的時間線文件
File Tree 裡的「大綱與計劃」資料夾，就是放這種文件的地方。建立一個 時間線.md，讓它成為故事的時間真相來源——single source of truth。
一份夠用的時間線文件有三個核心區塊。
故事時間範圍——邊界問題。故事從哪天開始，哪天結束，跨多長時間。這些基本參數會連動很多東西：季節、節日、天氣、角色穿什麼衣服。設定錯了，後面全部跟著錯。
核心事件表是主體。分兩段：故事開始前的背景事件（那些塑造角色的過去），和故事進行中的主時間線。每筆事件記錄日期、內容、相關角色、在哪些章節被提及。這樣改動一個事件的時候，所有受影響的位置一目了然。
角色年齡對照是第三塊，也是最容易被忽略的。角色回憶過去的時候幾歲？兩個角色聊共同經歷，年齡對得上嗎？一張表——出生年份加上關鍵時間點的年齡——就能擋掉一大堆一致性問題。
Writing Studio 的分割視窗功能（Cmd+ 或 Ctrl+）在這裡特別好用。左邊開時間線，右邊開正在寫的章節。寫到任何跟時間有關的細節，眼睛往左一瞄就能確認。
Quick Open（Cmd+P）輸入「時間」兩個字就能直接跳到時間線文件，不用在 File Tree 裡翻來翻去。
讓 AI 成為你的時間守護者
十萬字小說裡的每一個時間提及，手動逐一比對？認真的嗎。
這正是 AI Assistant 該上場的時候。按 Cmd+Shift+A（Mac）或 Ctrl+Shift+A（Windows）開啟 AI Chat Panel，讓它幫忙跑一次時間線審計。
第一步：時間提及掃描。
把這段丟給 AI Assistant：
請掃描「草稿」資料夾中的所有章節，找出所有與時間相關的提及。包括：
- 具體日期或年份（例如「2024 年 3 月」、「那年夏天」）
- 相對時間表達（例如「三天前」、「下個月」、「去年冬天」）
- 季節或天氣描述（例如「雪下得很大」、「櫻花開了」）
- 角色年齡的提及（例如「他三十歲那年」、「她還是個孩子」）
- 歷史事件或時代標記（例如「網路泡沫時期」、「疫情之後」）
請整理成表格，標注章節位置和原文摘錄。
這份清單就是後續所有檢查的基礎。沒有它，一切都是靠感覺。
第二步：一致性交叉比對。
請根據以下時間線文件和時間提及清單，檢查是否有任何矛盾：
[引用時間線文件]
重點檢查：
- 相對時間是否指向正確的絕對時間
- 角色年齡在各個時間點是否一致
- 事件發生順序是否合乎邏輯
- 季節描述是否與日期匹配
請列出所有發現的矛盾，並標注具體位置。
第三步：場景間隔計算。
有時候問題更具體——
第五章的場景發生在週五晚上，第八章的場景據說是「三天後」。
請計算：
- 第八章應該是星期幾？
- 第六章和第七章發生在什麼時間？
- 這與其他時間線索是否一致？
如果發現矛盾，請建議如何修正。
重點在這裡：AI 負責計算和比對，判斷權留在作者手上。AI 不會漏掉「第七章的週二」跟「第八章的週一」對不上這種細節。但它分不清哪些矛盾是刻意設計的——比如不可靠敘事者——哪些是真正的錯誤。那是作者的工作。
處理複雜的時間結構
線性敘事已經夠難管了。非線性結構？那是地獄模式。
多時間線故事——「現在」和「三十年前」交替出現的那種——實際上是在同時維護兩條獨立的時間進程。每條都有自己的事件序列，而它們之間的對應關係（第三章的「現在」對應第四章的「過去」的哪個時間點？）必須記錄得一清二楚。
File Tree 裡可以分開建檔：時間線-現在.md、時間線-過去.md，再加一份 時間線-對照.md 記錄交叉點。分開管理，但隨時能對照。
非線性敘事的挑戰不一樣。「閱讀順序」和「故事時間」是兩套完全不同的序列。讀者先看到結局片段，再回到開頭，再跳到中間——但故事本身有客觀的時間順序。兩套序列都要追蹤，而且無論讀者從哪個角度切入，邏輯都不能破。
Christopher Nolan 的《Memento》是經典案例。一條線正向推進，一條線反向推進。Nolan 團隊必須精確追蹤每個場景在「電影順序」和「故事順序」中的位置，確保即使倒著看，因果關係依然成立。拍電影如此，寫小說也一樣——甚至更難，因為文字沒有鏡頭語言幫忙暗示時間跳轉。
當時間線需要修改
寫到第十五章，突然意識到故事跨度從一年改成六個月會好很多。或者某個關鍵事件必須往前移三個月。或者——最痛苦的——整段時間軸需要壓縮。
改一個日期很容易。但那個日期被引用了多少次？在多少個章節裡出現過「三個月前」「去年夏天」這類相對時間？改了源頭，所有下游都要跟著動。這是最容易引入新錯誤的時刻。
Version Control 在這種時候是救命的。
先建一個分支——比如 timeline-revision。所有修改都在這個分支裡進行。改完之後，用 AI Assistant 跑一次完整的一致性檢查。確認沒問題，再合併回主分支。
萬一改到一半發現問題比想像中複雜？直接放棄這個分支，回到原本的狀態。主分支毫髮無傷。
Version Control 面板（Cmd+Shift+G）裡，每次重大的時間線修改都值得建一個快照，描述寫清楚：「時間線壓縮：故事跨度從一年改為六個月」。三個月後回頭看，這行字會救命。
在時間線文件裡也留一段修改記錄。為什麼這個事件在這個日期？當時改了什麼？未來的自己會感謝現在多花的這三十秒。
沒有具體年份也需要時間線
「我的故事沒有明確的年代設定，就是一個模糊的『當代』——這樣也需要時間線嗎？」
需要。而且可能更需要。
沒有具體年份不代表時間不存在。事件之間經過了多少天？角色在回憶中是幾歲？冬天的場景之後，下一場戲不能突然出現蟬鳴。角色如果需要上班，星期幾就有意義。
相對時間的陷阱其實比絕對時間更多。「三天前」和「上週」都需要指向一個確定的時間點，即使那個時間點沒有被明確寫出來。模糊不等於隨便。
時間線可以用相對標記：Day 1、Day 15、Week 3。不需要 2024 年 3 月 15 日這麼精確。但需要一個參照系統，讓所有「三天前」「上個月」「那年冬天」都能對得上。
華生醫生的傷口從肩膀漂移到了腿上，Conan Doyle 大概到死都沒意識到。一百三十年後的今天，這個錯誤比很多正確的細節都更出名。
不是每個錯誤都會被記住一百三十年。但寫作者能做的，是把自己控制得了的部分做到位。時間線文件、AI 一致性檢查、Version Control 快照——工具都在 Writing Studio 裡了。剩下的，是坐下來把它們用起來的那三十分鐘。
下一篇，我們來聊研究資料的整理——那些在創作過程中不斷膨脹的參考素材，到底該怎麼收、怎麼管、怎麼在需要的時候三秒內找到。