小說資料夾與CLAUDE.md寫作規則怎麼寫？用程式設計工具寫長篇的目錄與臺賬

本篇目錄 9 節

先說結論：資料夾分四類，規則文件寫硬約束，臺賬每章更新

Claude Code、Cursor、Codex CLI 原本是寫程式碼的工具，但越來越多作者拿它們寫小說。原因很實在：它們能讀寫整個資料夾，一次改動可以跨幾十個文件，改壞了也有辦法回退（Claude Code、Cursor 自帶檢查點，Codex CLI 官方建議用 Git 建檢查點），適合管理一本有上百個文件的長篇。

用它們寫小說，公開實踐裡大致收斂到同一套做法：

1. 設定、人物、大綱、正文四類文件分開放；
2. 根目錄放一個規則文件（Claude Code 用 CLAUDE.md，Codex 用 AGENTS.md，Cursor 用 .cursor/rules 下的規則文件），寫硬約束；
3. 另建一組臺賬（人物狀態、伏筆、時間線），每章寫完更新，作為"現在故事走到哪了"的統一依據；
4. 用 Git 或工具自帶的檢查點管理版本。

下面逐項講，最後說什麼時候換成寫作軟體更省事。本文提到的公開實踐均核對於 2026-10-11。

資料夾結構：一個可以直接照抄的骨架

參考公開項目和教程，一箇中文長篇的目錄可以這樣建：

• CLAUDE.md（或 AGENTS.md）：規則文件
• 設定/：世界觀.md、力量體系.md、勢力.md、地點.md
• 人物/：每個重要人物一個文件，如 林遙.md
• 大綱/：總綱.md、卷綱/第一卷.md、章綱/001.md……
• 正文/：001-雨夜.md、002-入門.md……
• 臺賬/：人物狀態.md、伏筆.md、時間線.md、進度.md
• 文風/：樣例段落.md
• 歸檔/：退場人物、舊地點

幾個細節：

• 章節檔名用三位數字開頭。 中文章節名按字母排序會亂，掘金上一篇用 Cursor 寫長篇的文章就提到過這個問題，最後只好寫指令碼合併章節（來源）。"001-雨夜.md"這樣的命名能避開。
• 一個文件只放一個人物或一類設定。 文件小，AI 每次只讀需要的那幾個，Cursor 官方論壇上分享 Buckram Studio 的作者就是這樣做的，寫哪章就引用哪幾個文件（來源）。
• 作者寫的和 AI 寫的分開。 一篇 CSDN 教程把目錄分成兩半：作者維護的硬約束（文風、整體設定、核心角色、主線）和 AI 維護的臺賬（章節狀態、人物時間線、伏筆、角色線），前者 AI 不許改（來源）。

CLAUDE.md 寫什麼：只寫每次都要遵守的事

規則文件按各工具的載入規則生效，寫得越長，佔用的上下文越多，所以要短，只寫硬約束。可以包含這些要點：

• 一句話介紹這本書：題材、視角、目標讀者；
• 寫章前必讀的文件：本章章綱、出場人物卡、臺賬裡的人物狀態、前兩章正文；
• 寫作硬規則：人稱和視角、每章字數範圍、停用的套話和句式；
• 寫完一章必須做的事：更新人物狀態、伏筆、時間線、進度四個臺賬；
• 不許改的文件：設定和人物卡只能由作者改，AI 發現衝突時列出來，不擅自修改；
• 衝突時以誰為準：正文已寫的事實優先於大綱，臺賬以最新一章為準。

篇幅上要剋制。以 Codex 為例，官方文件寫明 AGENTS.md 合計大小預設上限為 32 KiB（來源）；Codex 官方建議必須遵守的規則放進 AGENTS.md，不要只依賴記憶功能（來源）；Cursor 文件也說明模型在兩次補全之間不保留記憶，規則用來提供持久的上下文（來源）。

臺賬：長篇能不能寫下去的關鍵

規則文件管"怎麼寫"，臺賬管"現在寫到哪了"。公開項目裡比較成熟的做法有三點：

• 只認一個事實來源。 oh-story-claudecode 把追蹤狀態放在一個文件裡，作為結構化狀態的總來源，另有一份固定欄目、有大小上限的"上下文"摘要（來源）。webnovel-writer 同樣把總綱、卷綱、時間線、章綱和狀態索引分開存放（來源）。
• "作者知道的"和"讀者知道的"分開記。 oh-story-claudecode 這樣做，是為了防止人物提前知道答案。
• 每章寫完就更新。 人物狀態（在哪、傷勢、實力、知道什麼）、伏筆（埋在哪章、何時收）、時間線（書中過了多少天）。Reddit 上一位用 Claude 寫完 30 萬詞長篇的作者，為每個角色記錄了"在各個時間點知道什麼"，並讓 Claude Code 跨上百個文件做連續性檢查（來源）。

版本：檢查點之外，還要有 Git

• Claude Code 每次提示會自動建檢查點，可以用 /rewind 回退，官方文件寫明保留最近 100 個（來源）。
• Cursor 的檢查點存在本地、與 Git 分開，官方建議長期版本管理用 Git（來源）。
• Codex CLI 官方建議在任務前後建 Git 檢查點，以便回退（來源）。

所以比較穩妥的習慣是：每寫完一章提交一次 Git，提交說明寫章節號。

公開實踐裡反覆出現的問題

整理這些公開教程和討論，幾個問題出現得比較多：

• 對話一長就"糊"。 Buckram Studio 的作者提到，兩百條訊息的長對話會出現上下文退化、成本上升、重複和泛泛的文字（來源）；掘金那篇文章也說經常"忘了小說設定"。
• 人設和文風漂移。 CSDN 教程的原話是"主角能力忽強忽弱，像換了人"；Reddit 那位作者提到寫到第 80 章已經沒有第 12 章的節奏，需要反覆重新提供樣例段落。
• 用量和成本。 讓 AI 逐個合併文件會很快用完額度（來源）。
• 對非程式設計師有門檻。 同一篇文章提到 VS Code 對非程式設計師"聽起來就嚇人"；另一篇文章認為不需要計算機學位也能上手，同時判斷多數作者會主要使用聊天介面（來源）。

這些問題都有辦法緩解：文件拆小、臺賬每章更新、每章只讀需要的文件、定期開新對話。代價是作者要自己設計目錄、寫規則、維護臺賬、看文件對比。

什麼時候換成小說寫作軟體

程式設計智慧體給你的是完全的控制權：文件在本地，結構自己定，換模型、換工具都方便。喜歡這種方式、熟悉終端和 Git 的作者，用它寫小說是很好的選擇。

出現下面幾種情況時，可以考慮換成專門的寫作軟體：

• 維護臺賬和規則文件花的時間，開始超過寫正文的時間；
• 不熟悉終端、Git，每次看改動都要琢磨文件對比；
• 想在網頁或手機上隨時寫，不想綁在一臺電腦上；
• 想看人物卡、目錄、伏筆列表，而不是一堆 Markdown 文件；
• 網路或賬號條件受限。 例如 Claude 官方支持地區列表未包含中國大陸，這一限制覆蓋 Claude.ai、Claude Code 和 API（來源）。

馬良寫作把哪些步驟自動化了

上面的目錄、規則和臺賬，馬良寫作是這樣對應的：

• 四類文件各有位置。 人物、設定、伏筆、故事線是左側設定欄裡的一張張卡片；總綱單獨存放；文風樣本、開書資料是「文件」裡的文件。AI 寫作時按需讀取，你看到的是卡片和目錄，不用自己維護資料夾。
• 臺賬由檔案員整理。 章節寫完、這一段寫作結束後，檔案員按正文整理故事檔案：人物狀態、關係、位置、伏筆。和既有設定對不上的地方列進「待確認」，由你決定按哪邊改。不想要可以在「檔案」裡關閉。
• 對比和撤回在編輯器裡。 AI 改過的正文直接標出刪除和新增，可以逐處保留或還原；不滿意可以撤銷本輪、從本輪之前另起分支，或修改後重發。分支和原對話共用同一份書稿。

• 正文交給寫手。 續寫時寫手只拿這一章需要的材料：章綱、相關人物設定、前文、文風樣本。
• 按卷收起舊設定。 寫到新一卷時，只在前幾卷出場的人物、地點、伏筆會被收進歸檔，AI 寫新章時不再參考，需要時仍能查到。
• 網頁直接用，不用安裝。

兩種方式的詳細比較見 Claude Code 與馬良寫作對比、程式設計智慧體與小說寫作軟體怎麼選和資料夾與結構化寫作怎麼選。

常見問題

Q：Claude Code 能寫小說嗎？
能。它能讀寫整個資料夾、跨文件修改，自帶檢查點可以回退，已經有作者用 Claude 寫正文、用 Claude Code 做跨文件檢查，完成了長篇。需要你自己設計目錄、寫 CLAUDE.md、維護人物狀態和伏筆臺賬。

Q：CLAUDE.md 應該寫什麼？
只寫每次都要遵守的事：這本書的一句話介紹、寫章前必讀的文件、寫作硬規則、寫完一章要更新的臺賬、哪些文件不許 AI 改、衝突時以誰為準。保持簡短。

Q：Cursor 寫小說怎麼設定規則？
在項目的 .cursor/rules 目錄下建規則文件，寫清必讀文件和硬規則；也可以用 AGENTS.md。設定和人物拆成小文件，寫哪章就引用哪幾個。Cursor 的檢查點存在本地，官方建議長期版本用 Git 管理。

Q：Codex CLI 能寫小說嗎？
能，做法和 Claude Code 類似：用 AGENTS.md 寫規則，按目錄組織設定、大綱和正文。官方文件寫明 AGENTS.md 合計大小預設上限為 32 KiB，規則要寫得精煉。

Q：用 Claude Code 寫小說需要會程式設計嗎？
不需要寫程式碼，但要習慣終端或編輯器、懂一點文件和目錄管理，會用 Git 管理版本更方便。對完全不熟悉這些的作者，上手會有一段適應期。

Q：國內能用 Claude Code 嗎？
Claude 官方支持地區列表未包含中國大陸，這一說明覆蓋 Claude.ai、Claude Code 和 API。具體以官方頁面為準。

Q：什麼時候該從程式設計智慧體換成寫作軟體？
當維護臺賬和規則的時間超過寫正文的時間、不想用終端和 Git、想在網頁或手機上寫、或者更習慣看卡片而不是文件時，可以考慮換成專門的小說寫作軟體。