NovelForge：以 JSON Schema 約束 AI 長篇小說生成的卡片式引擎
AI辅助长篇小说创作，卡片式创作，支持基于 JSON Schema的结构化 AI 生成与上下文引用，可扩展性强。
秒懂
- 它是什麼？
- NovelForge 把長篇創作拆成可定義結構的卡片，讓 AI 產出先過 Schema 校驗再落地。這篇從它的資料流、啟動方式與工作流重構講起，判斷它適合誰、又在哪裡會卡住。
- 適合誰用？
- NovelForge 適合已經在用 LLM 寫長篇、但被「設定前後矛盾、生成結果格式散亂」困住的人，尤其是願意自己寫 Pydantic Schema 與 Python 風格工作流的使用者。只想打開就寫、不想碰設定檔的人不適合，因為它的價值幾乎都建立在 Schema 與 @DSL 的配置上。
- 可以商用嗎？
- 可以，但條件嚴格。AGPL-3.0 是網路 copyleft 授權：如果別人透過網路使用你修改過的版本（例如作為託管服務），你必須以同一授權向他們提供原始碼。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 14 天前。
- 用什麼語言寫的？
- 主要是 Python（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
卡片不是筆記本，是帶 Schema 的資料單元
多數 AI 寫作工具把生成結果當成一段文字，貼進編輯器就結束了。NovelForge 的做法相反：每一種卡片都可以先定義結構（Schema），AI 生成時按結構校驗，README 對這件事的說明是「減少『看起來能用、落地卻混亂』的輸出」。這句話點出了問題的核心。長篇小說寫到幾十萬字，真正拖垮進度的是設定漂移：第三章說主角怕水，第四十章他在河裡游了三公里。
NovelForge 針對的不是文筆，而是可控性。它把世界觀拆成角色、關係、場景、組織、物品、概念等實體，每個實體是一張卡片，卡片有 Schema，Schema 決定 AI 能填哪些欄位。v0.9.4 的更新日誌顯示，這些實體類型被補上了輕量狀態與記憶能力，並且統一成「先預覽、後確認」的流程：基於當前章節正文發起提取，先看結果，使用者可在預覽中手動調整，確認後才寫回卡片或圖譜。
這裡有個設計上的取捨值得指出。日誌自己寫了一句提醒：「按需使用，不一定全部都要用上，避免增加上下文複雜度」。也就是說，實體類型開得越多，每次生成塞進提示詞的內容就越雜，模型反而更容易失焦。Schema 給了秩序，但秩序本身有成本。
適用對象因此相當明確：正在寫百萬字級長篇、已經被一致性問題折磨過的作者，或想把創作流程自動化的進階使用者。寫短篇或隨筆的人會覺得整套機制太重。
從輸入要求到欄位級填充：生成流程的實際資料流
v0.9.0 是這條資料流的分水嶺。在那之前，AI 卡片生成是「點擊後等待整段結果」；之後改成「輸入要求 → 對話框內欄位粒度生成 → 確認或回饋繼續生成」。README 把這個變化描述為聚焦於「當前這張卡片」的生成與完善，並補充了一句限制：關閉生成對話框後本次會話即結束。
這句話是硬約束，不是補充說明。它意味著欄位級生成沒有跨對話的記憶延續，你中途關掉視窗，上一輪的填充脈絡就沒了。想要接著改，得重新開一輪。
資料流大致是這樣：使用者在卡片對話框輸入要求，後端組裝提示詞，其中包含由 @DSL 引用的專案資料，模型以流式方式逐欄位回傳，前端即時顯示，使用者確認後才寫入卡片。上下文注入靠的是 @DSL，README 的目錄把它列為獨立章節，說明它能「精準引用專案資料」，並結合關係圖譜與動態資訊，讓後續生成更貼近已寫內容與角色關係。
章節正文是另一條路徑。續寫支援兩種模式：提示詞約束只做提示詞層面的字數限制，文本較自然、成本較低；控制模式則按目標總字數切分多輪並分配預算，v0.9.3 的日誌說明它「當前採用固定多輪預算策略」，字數更穩但消耗更多 token。兩者的差別不是精度高低，而是你願意用多少 token 換取確定性。
啟動與配置：從 backend/.env 到一鍵啟動
技術棧是 Python 後端加前端，README 的目錄裡有「運行指南」與「專案結構」兩節，v0.9.2 的更新日誌提到新增了「前後端一鍵啟動」，這是目前最省事的入口。
後端連接埠在 v0.9.7 之後可以自訂，設定位置是 backend/.env 裡的 APP_PORT，預設值維持 54321，並加上 1 到 65535 的範圍校驗。這個改動看似微小，實際上解決了連接埠衝突時只能改程式碼的窘境。
資料庫層面有幾件事必須先知道。v0.9.2 加入了一項機制：自動檢查模型元數據與資料庫現有表結構的差異，並補齊「可安全追加」的缺失欄位。注意「可安全追加」這個限定，它處理的是新增欄位，不是結構重構。真正的大改在 v0.9.0，日誌用警告語氣寫著：由於該版本更新變動較大，舊版本資料庫可能無法直接使用，請嘗試用發布的遷移腳本進行遷移，且「不保證成功，建議提前做好資料庫 db 文件備份」。
關係圖的儲存是可選的。v0.9.1 加入 SQLite 支援並相容 Neo4j，同時提供篩選、批量修改、匯入匯出。這代表單機使用者不必為了知識圖譜去架 Neo4j，直接用 SQLite 就能跑。
模型端要先過一關。v0.9.6 在 LLM 配置頁加入能力檢測，可觸發模型能力與相容性測試，判斷基礎對話、串流、結構化輸出、工具呼叫等相容情況。這一步不能跳過，因為 NovelForge 的卡片生成依賴結構化輸出，工具呼叫則影響靈感助手。
程式式工作流：拿直觀性換可維護性
v0.9.0 把工作流從舊的 DAG 式編輯器遷移到「程式式工作流」，語法接近 Python 語句加特殊標記 DSL，並逐步移除了舊的 DAG 方案。README 對這個決定的說明相當坦白，甚至直接列出兩邊的優缺點。
優點方面：邏輯更線性，順序、等待（Logic.Wait）、非同步（async=true）等語義更貼近真實執行過程；進度處理與非同步操作更自然，執行器可按語句計畫調度；對 AI 更友善，同一個功能用程式式往往幾十行就能表達，DAG 配置經常需要幾百行的節點與連線描述。
缺點也寫在同一段：不如 DAG 直觀；對字串與程式碼格式更敏感，參數序列化、字典欄位型別、變數引用等細節更容易引發校驗或執行錯誤，需要更強的校驗與提示詞約束。
這是整份文件裡最有價值的自述。它承認了一個真實的權衡：把工作流寫成程式碼，等於把圖形介面的容錯空間換成了文字格式的嚴格性。對熟悉 Python 的人是效率提升，對只想拉節點連線的人是門檻上升。
配套的是工作流 Agent，可用自然語言描述需求，由 Agent 生成或修改工作流程式碼並做校驗，支援「先預覽再應用」。日誌對此的措辭是「可能還有些 bug」。另外還有工作流工作室、觸發器配置、全域後台執行的狀態欄，以及節點級進度與中斷恢復，後者標註為 Beta。內建模板包含拆書工作流，v0.9.5 把它改成預設指令流模式以提高成功率。
審核與記憶層：先預覽再寫回，代價是流程變長
v0.9.3 重構了審核功能，統一為「先生成審核草稿，再確認建立或更新審核結果卡片」。審核結果不再依賴舊的記錄模型，統一沉澱為內容審核卡片，並自動歸檔到根級「審核結果」資料夾。不同卡片類型可切換不同審核提示詞，但結果卡片結構保持一致，便於集中查看與引用。
v0.9.4 把同樣的「先預覽、後確認」模式推廣到記憶層：角色動態資訊、關係提取入圖、場景狀態、組織狀態、物品狀態、概念掌握，全部改成先展示預覽結果、允許手動調整、確認後才寫回。
這個一致性是優點，也是摩擦點。每一次提取都要人眼過一遍，好處是 AI 不會悄悄改壞你的設定，壞處是當你一天寫一萬字，確認動作會累積成可觀的時間成本。文件沒有提供批次確認或自動套用的選項，至少在提供的材料裡看不到。
靈感助手是另一條互動路徑。v0.8.0 加入工具呼叫後，它可以直接在對話中建立或修改卡片、搜尋、查看型別結構。v0.8.5 換了新的 agent 框架，並為工具呼叫能力不強的模型重新實作了 ReAct 模式（文字格式工具呼叫），預設關閉，可在設定中開啟。同一份日誌建議把 DeepSeek、Qwen 之類的模型選為 OpenAI 相容提供商。v0.8.3 對 ReAct 模式的評價是「實現較為粗糙，可能存在些 bug，還是建議優先使用原生工具呼叫支持比較好的模型」。
v0.9.6 讓靈感助手可一次回傳多條正文修改建議，編輯器支援逐條檢視、接受或拒絕，並保留工具結果處理與文字格式降級解析，降低模型回傳格式不穩定時的失敗機率。
與通用寫作工具的差別在哪裡
拿 Obsidian 加社群 AI 外掛來比，差別不在功能清單，而在資料模型。Obsidian 那一類工具以 Markdown 檔案為單位，AI 外掛多半是對選取文字做補全或改寫，上下文靠你自己手動貼進去。設定與人物關係散落在不同筆記裡，一致性靠人腦維護。
NovelForge 走的是另一條路：資料以結構化卡片存在資料庫，Schema 定義欄位，@DSL 負責引用，關係圖譜負責追蹤角色與實體之間的連結。AI 生成不是對文字做補全，而是對欄位做填充，填完還要過校驗。
代價是自由度。在 Obsidian 裡你可以隨手寫一段沒有結構的草稿，之後再整理；在 NovelForge 裡，內容要嘛屬於某張有 Schema 的卡片，要嘛屬於章節正文。這種約束對長篇是助力，對還在探索題材、設定天天改的階段就是阻力。
另一個實際差別是部署。Obsidian 是本地應用，NovelForge 是 Python 後端加前端，需要自己跑起來，還要處理連接埠、資料庫與模型配置。v0.8.6 加入的 Web 版本適配讓它能在瀏覽器裡用，但也意味著如果你要對外提供服務，AGPL-3.0 的網路散布條款就會進入視野。
授權與維護成本：AGPL-3.0 不是裝飾
專案採用 AGPL-3.0。這個授權與 MIT 或 Apache-2.0 的實際差異在於：如果你修改 NovelForge 並以網路服務形式提供給他人使用，通常需要向使用者提供對應的原始碼。自己本機寫小說不受影響，但把它包成 SaaS 或團隊內部平台對外開放，就要先確認合規路徑。這不是法律意見，具體情況請找專業人士。
維護成本可以從版本節奏看出輪廓。v0.9.0 到 v0.9.7 之間有多次功能重構：卡片生成流程、工作流系統、審核流程、字數控制，都在同一個 0.9 系列內改過。這代表升級不是無痛的，資料庫結構與工作流程式碼都可能需要跟著調整。v0.9.0 的遷移腳本「不保證成功」這句話，應該當成升級前的行動項，而不是警語。
工作流程式碼對格式敏感這一點，也構成隱性的維護負擔。當你升級版本，既有工作流的參數序列化與變數引用可能需要重新校驗。v0.9.2 的自動補列機制只處理「可安全追加」的缺失欄位，涵蓋不了這類變動。
從提供的材料看，專案仍在快速迭代期，最後推送時間為 2026 年 9 月 2 日，最新版本 v0.9.7 於 2026 年 8 月 24 日發布。這意味著你採用的是持續變動的軟體，而不是穩定凍結的工具鏈。
編輯結論
NovelForge 適合已經在用 LLM 寫長篇、但被「設定前後矛盾、生成結果格式散亂」困住的人，尤其是願意自己寫 Pydantic Schema 與 Python 風格工作流的使用者。只想打開就寫、不想碰設定檔的人不適合，因為它的價值幾乎都建立在 Schema 與 @DSL 的配置上。採用前先確認三件事：你的模型在 LLM 配置頁的能力檢測中能不能通過結構化輸出與工具呼叫；v0.9.0 之後的資料庫是否需要跑遷移腳本，並先備份 db 檔；以及你能否接受 AGPL-3.0 對網路服務形式的散布要求。
社群筆記