為什麼 AI 寫到第 5 章就忘了你的小說（以及如何修復）

你一直在用 AI 寫小說。前三章很棒——文筆緊湊、角色一致、情節穩步推進。然後第 5 章出了問題：AI 把一個已經在第 2 章出場過的角色當成新人物介紹。你精心鋪設的情節線被無視。文風從文學小說突變為青少年讀物。

你沒做錯什麼。AI 只是忘了你的小說。

這不是 bug——這是大語言模型的根本工作方式。一旦你理解了其中的機制，就能找到應對方法。本文解釋 AI 為什麼會丟失上下文、這到底有多大代價，以及四種保持連貫性的實用方法——從免費的手動技巧到自動化方案。

AI 為什麼會忘記：技術現實（通俗版）

每個 AI 模型都有一個上下文視窗——它一次能「看到」的最大文本量。把它想像成 AI 的工作記憶。截至 2026 年：

| 模型 | 上下文視窗 | 大約相當於 | |------|-----------|-----------| | GPT-4o | 128K tokens | ~5 萬字（一部短篇小說） | | Claude Sonnet | 200K tokens | ~8 萬字 | | Gemini Pro | 1M tokens | ~40 萬字 |

這些數字看起來很慷慨，但問題在於：

1. 上下文視窗 ≠ 可用上下文。 你的提示、系統指令和模型自身的輸出都計入限額。128K 的視窗可能只給你留下 80K 用於實際的故事上下文——如果你運氣好的話。

2. 中間部分的品質會下降。 研究一致表明，大語言模型對上下文視窗的開頭和結尾關注最多，中間的內容關注最少——所謂的「中間迷失」（lost in the middle）問題。所以即使你第 3 章的摘要在技術上放得下視窗，AI 也可能沒有充分考慮它。

3. 每次生成都是無狀態的。 這是關鍵。當你開始一條新的聊天訊息或 API 呼叫時，AI 對之前的呼叫零記憶，除非你明確包含了那些上下文。它不是在「遺忘」——它從來就不知道。每次生成都從頭開始，只有你放進提示裡的內容。

4. 上下文視窗是昂貴的。 每次生成都傳送 10 萬 token 的上下文既慢又貴。你在為 AI「閱讀」你的整部小說買單，只為了寫一段話。

丟失連貫性的真實代價

角色不一致是最明顯的症狀。但丟失連貫性會導致更深層的結構性問題：

• 情節線蒸發。 第 4 章埋下的推理線索永遠不會被解決，因為 AI 在寫第 20 章時根本不知道它的存在。
• 節奏崩塌。 不知道前面章節的節奏，AI 就無法保持張力的累積或在恰當的時機提供緩解。
• 世界規則被違反。 你的魔法體系在第 1 章確立了具體的限制條件。到第 15 章，角色們用的魔法方式打破了那些規則。
• 伏筆落空。 AI 無法兌現它不知道的鋪墊。

結果：你的小說讀起來像是每幾章就換了一個作者。因為從某種意義上說，確實如此——每次生成都是一個沒有歷史記憶的全新 AI。

方法一：手動上下文注入（免費，適用於任何工具）

最易上手的方法。每次生成前，你手動將相關上下文貼到提示中。

需要包含的內容：

1. 故事前提（2-3 句話）
2. 當前相關的角色檔案
3. 最近 3 章的摘要
4. 未解決的情節線
5. 當前章節計畫

優點：

• 適用於任何 AI 工具（ChatGPT、Claude 等）
• 你完全控制 AI 看到的上下文
• 免費

缺點：

• 耗時：每章 15-30 分鐘的準備工作
• 容易出錯：漏掉一個細節，AI 也會漏掉
• 不可擴展：到第 20 章時，決定包含什麼本身就成了一個專案

時間成本估算： 對於一部 30 章的小說，預計僅在上下文管理上就要花費 8-15 小時——這些時間本可以用在創作決策上。

建議： 建立一個持續更新的「上下文文件」，每寫完一章就更新。用標題結構化組織，這樣可以快速複製相關部分。這比每次提示前重新閱讀之前的章節要快。

方法二：結構化摘要（免費，適用於任何工具）

相比原始上下文注入的一個改進。你不是貼上全文，而是維護結構化的摘要。

每章結束後寫：

• 摘要（3-5 句話）：這一章發生了什麼。
• 結局（3-5 句話）：發生了什麼變化。揭示的新資訊、關係轉變、角色狀態變化、打開或關閉的情節線。
• 活躍線索（要點列表）：哪些未解決的問題或鋪墊延續到後面。

為什麼這比全文有效： 摘要高效地壓縮資訊。不需要把第 3 章的 5000 字全部傳給 AI，你只需傳 100 字就能捕獲關鍵事實。這意味著你可以在同樣的視窗中裝入更多章節的上下文。

範例：

第 7 章摘要： 馬倫在圖書館檔案中發現了密碼資訊。她解讀了其中一部分——指向北海岸的座標——但被沃斯局長打斷，後者沒收了她的筆記。

結局： 馬倫現在知道了位置但失去了實體筆記。她記住了座標但沒記住資訊的後半段。沃斯現在知道了她的調查。馬倫和沃斯之間的信任破裂。

活躍線索： 座標指向哪裡？資訊後半段說了什麼？沃斯會對他看到的資訊採取行動嗎？

時間成本： 每章 5-10 分鐘來寫摘要。比原始注入可擴展得多。

方法三：基於 RAG 的方法（技術性，DIY）

檢索增強生成（RAG）是一種技術，不是把所有內容都塞進上下文視窗，而是將小說資料儲存在可搜尋的資料庫中，只檢索每次生成相關的片段。

概念工作流程：

1. 將所有章節、角色檔案和世界設定儲存在向量資料庫中
2. 生成第 15 章時，系統搜尋與第 15 章計畫相關的內容
3. 只有最相關的片段被注入到提示中

優點：

• 可擴展到非常長的小說
• 相關上下文自動選擇
• 高效利用上下文視窗

缺點：

• 需要技術搭建（向量資料庫、嵌入模型、檢索流程）
• 檢索不完美——可能遺漏沒有明顯關鍵詞重疊的相關上下文
• 對大多數作者來說不是開箱即用的方案

適合誰： 如果你是一個把寫小說當嗜好的程式設計師，這是個有趣的專案。如果你是一個想寫作的作者，這可能不值得投入工程成本。

方法四：專用小說工具（自動化）

一些工具專門為長篇小說設計，將上下文管理作為核心功能而非事後補丁。

自動化上下文管理是什麼樣的：

• 角色檔案儲存在持久資料庫中，而非聊天記錄中
• 每章完成後，摘要和結局會自動提取
• 生成新章節時，系統自動注入：小說背景 + 相關角色檔案 + 所有之前章節的摘要/結局 + 當前章節計畫
• 你永遠不需要手動貼上任何東西

權衡： 你被鎖定在特定工具的工作流中，而不是自由使用通用 AI。

Noveble 是這種方法的一個範例。它永久儲存角色檔案，自動生成章節摘要和結局，並在每次生成中注入完整的上下文鏈。結果是：當你生成第 20 章時，AI 知道第 1-19 章發生的一切——情節線、角色發展、未解決的問題——你不需要貼上一個字。

選擇你的方法

| 方法 | 搭建時間 | 每章成本 | 最適合 | |------|---------|---------|--------| | 手動注入 | 無 | 15-30 分鐘 | 短篇小說（< 10 章） | | 結構化摘要 | 1 小時 | 5-10 分鐘 | 中篇小說，任何工具 | | RAG | 10+ 小時 | 極少 | 程式設計師，超長小說 | | 專用工具 | 30 分鐘 | 1-2 分鐘 | 認真的長篇專案 |

對於大多數寫 15 章以上小說的作者來說，結構化摘要是最低可行方案。它免費，適用於任何 AI 工具，而且能大幅提升連貫性。

如果你正在計畫一部 30 章以上的小說，不想在上下文管理上花費大量時間，專用工具僅憑節省的時間就值回票價。

每章連貫性檢查清單

無論你使用哪種方法，在定稿每一章之前過一遍這個清單：

1. 角色事實 —— 有沒有任何人做了與已設定的特徵或能力矛盾的事？
2. 情節線 —— 這一章是否提及了所有應該在此相關的活躍線索？
3. 資訊一致性 —— 每個角色是否只知道他們實際上已經瞭解到的資訊？
4. 文風和語言 —— 寫作風格是否與前面的章節一致？
5. 因果關係 —— 這一章中的一切是否從前面發生的事情中合乎邏輯地推導出來？
6. 鋪墊與回收 —— 如果這一章解決了一個鋪墊，解決方式是否與最初設定一致？

這只需 5 分鐘，就能捕捉到大多數連貫性錯誤——那種讓讀者說「等等，他們不是已經……」的錯誤。

想讓上下文管理自動完成？Noveble 會跨整部小說追蹤每一個情節點、角色細節和章節結局——讓你可以專注於故事本身，而不是 AI 忘了什麼。30 個免費點數，無需信用卡。