為什麼 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）是一種技術，不是把所有內容都塞進上下文視窗，而是將小說資料儲存在可搜尋的資料庫中，只檢索每次生成相關的片段。

概念工作流程：

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

優點：

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

缺點：

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

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

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

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

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

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

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

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

選擇你的方法

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

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

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

每章連貫性檢查清單

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

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

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

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