TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
Arboris：開源 AI 小說寫作工作台，替長篇管住設定與伏筆
Arboris-Novel 是一千五百多星的開源 AI 小說寫作工作台，把角色設定、伏筆與已完成章節收進可檢索的資料庫，生成時自動帶入相關前文。本文整理它的記憶系統組成、自架與線上版的金鑰信任線，以及動手前要先接受的三件事：授權檔缺席、開發停更與文件漂移。
用 AI 摘要這篇文章：
用聊天視窗寫長篇的人都遇過同一道牆：新開一個對話，模型把你筆下角色的名字、性格、勢力關係全部忘光，你只好把設定重貼一次；貼少了它自行腦補，貼多了又把上下文塞爆。寫到第五十章，記得整個故事的人只剩你自己。開源專案 Arboris-Novel 對這件事的回應，是把「讓 AI 記住你的小說」從對話技巧升級成系統設計：一套可以自己架的寫作工作台，把角色、地點、派系、規則、伏筆與已完成的章節全部收進資料庫，需要生成時再檢索相關片段餵給模型。它在 GitHub 上累積了 1,559 顆星，後端是 Python 加 FastAPI，前端是 Vue，資料庫預設 SQLite，Docker Compose 一個指令就能起來。
作者在說明文件裡把它定位成寫作夥伴：幫你釐清思路、記錄設定、給出可選方向；一鍵吐出整本書的自動生成，本來就不在它的承諾裡。這是作者自己的宣稱，實際生成品質要架起來才知道，但原始碼的結構也指向同一件事：這個專案力氣花得最兇的地方，是生成之前與之後的記憶管理，生成本身只佔一小塊。三百多次 fork 與一千五百多顆星，說明這個切入點確實打到了一批正在寫長篇的人。
聊天視窗寫作卡住的地方，它換成一張張資料表接手
在多 AI 並行對話殼那類工具裡，你面對的還是對話框，差別只是同時開幾個模型。Arboris-Novel 把形態整個換掉：打開的是工作台，作品、角色、大綱、寫作各有專屬頁面，設定在這裡是結構化的資料。
角色、地點、派系這類設定集中記錄在管理介面裡，寫到後期隨時回查，避免主角的眼睛顏色前後不一這類基本失誤。靈感片段和零散場景可以先丟給 AI 對話整理，由它梳理出從開頭到結局的主線大綱，大綱底下再展開章節綱要。寫作時可以自己起頭讓 AI 續寫，也可以讓它先出草稿再按自己的筆觸修改。同一章可以要求多個版本並列生成，寫作路由裡的版本數是可調參數，程式預設一次出兩版，你看過幾版之後挑定其中一版當作正式稿，也能直接動手改，存檔後系統會在背景重新生成章節摘要並更新檢索索引，挑選、改稿、評審在後端都是獨立的 API 端點。已經寫了很久的既有作品也不必從頭來過，倉庫附的導入功能把整本小說吃進去建立檔案。8MB 等級的全本匯入曾傳出介面無回應，2026 年 5 月有社群貢獻者提出改成非同步任務的修法，但那條 PR 沒有被合併，主線的匯入到現在仍是同步等待，大檔案要有耐心。偏好命令列與文字編輯器的人，作者還有一個姊妹專案 NovelKit，用斜線命令在 AI 編碼環境裡操作同類的角色與劇情管理流程，兩個專案間的整合痕跡也留在倉庫文件裡。
換句話說，它賣的是另一種工作方式：模型還是你提供的那些，接任何 OpenAI 相容端點都行；設定、大綱、章節、版本各自變成可以被查詢與追蹤的資料，幾十個對話分頁就此退役。
記憶系統的實際組成：向量庫、伏筆帳本與小說憲法
這個專案真正的主體，是一組記憶相關的服務，後端目錄裡最大的一塊就是它們。嵌入與檢索的基礎是 libsql 向量庫：每章定稿後會走章節攝取流程，把內容切塊、向量化、存進資料庫，之後生成新章節時，系統先檢索與當前劇情相關的前文片段再交給模型。嵌入模型預設走 OpenAI 的 text-embedding-3-large，程式裡也留了 Ollama 本地嵌入的路徑，換成 nomic-embed-text 這類本地模型就不必把章節內容送往外部嵌入服務。這套檢索機制從 v1.1.0 版加入，當時的發布說明寫的就是「新增 RAG」。
在向量檢索之上，還有幾個更貼近創作語彙的設計。伏筆追蹤服務把每條埋下的線索當成一筆紀錄管理，狀態涵蓋埋設與回收，寫到中後期隨時能叫出清單，檢查哪些梗丟了沒收。所謂的小說憲法，則是把這本書不可動搖的核心規則寫成一份文件，世界的底層設定、敘事禁忌、人物行為底線，生成時一併帶入，避免模型越寫越歪。寫作人設檔控制敘事者的語氣節奏，情感分析服務畫出章節與全書的情緒曲線。餵給模型的提示詞本身也是可管理的：站方後台存放各環節的提示詞範本，章節摘要用哪套規則、生成時帶入哪些結構，都能由管理者調整，提示詞跟著作品與站點走，不必改程式碼。
對習慣資料庫的人來說，這套東西可以一句話講完：它把長篇創作裡靠人腦硬扛的連續性問題，變成了可以查詢的結構化資料。你寫的每一章都在替未來的檢索做索引，越寫，系統對你作品的理解越完整。聊天視窗每開一個新對話就歸零；這套系統的前提剛好相反，你寫過的每一章都算數。不過記憶系統並沒有接進每一個 AI 環節，倉庫裡一個 2026 年 2 月提出的問題就直指：章節評審送進模型的內容只有章節本文，大綱與前文摘要並沒有一起帶入，與提示詞設計的預期有落差。這類縫隙提醒我們，工作台的記憶力取決於每個環節實際餵了什麼，端點之間未必同步。
金鑰放哪、一天能生成幾次：自架與線上版的信任線
自架版的部署有三條路，差別在資料庫與門檻：
| 部署方式 | 資料庫 | 適合 |
|---|---|---|
| Docker Compose 直接啟動 | SQLite（預設，無需另裝） | 想最快跑起來的人 |
| Compose 以 mysql profile 啟動 | 內建 MySQL 容器 | 多人共用、想省事的架站者 |
| 自備 MySQL 連線啟動 | 既有 MySQL | 已有資料庫環境的站長 |
模型金鑰填在伺服器端的環境變數裡，管理員的鑰匙服務全站共用；一般使用者也能在個人設定裡填自己的金鑰。原始碼裡的規則是：使用者設了自己的金鑰，請求就直接走那把鑰匙，不佔站上的每日額度；沒設的人共用管理員金鑰，預設上限一天一百次請求，管理員可調。個人金鑰存在部署端的資料庫裡，所有稿件與提示也都在伺服器上流轉。這與純瀏覽器自帶金鑰的工具是兩種信任模型：後者金鑰留在使用者自己的瀏覽器，題目從本機直送模型端點；前者要你先相信架站的人。真想把一切都留在自己手裡，自架是唯一選項，這也是這類自架 AI 服務共同的分界線。
自架的帳號體系也值得順便弄清楚。它不是單機軟體，而是多帳號服務：管理員帳號的初始密碼用環境變數設定，一般使用者的註冊功能預設關閉，要開放就得配上 SMTP 郵件服務發驗證碼。講白了，就算只是自己一個人用，你也是在架一個有登入、有權限、有管理後台的網站，資安基本功一樣得做：改掉預設密碼，金鑰走環境變數，也別把服務裸露在公用網路上。
想接本地模型的人，程式面上是通的：任何 OpenAI 相容端點都能填，Ollama 的支援也已寫進程式碼。不過 GitHub 的待解問題裡，本地部署 LMStudio 連線失敗、生成藍圖失敗、閘道超時這類疑難從 2025 年 10 月起陸續掛著，全都沒有得到專案作者的回覆。接本地端點之前，要有自己除錯的心理準備，它離開箱即用還有距離。
README 的線上體驗連結，現在通往另一個名字
說明文件開頭給了線上體驗網址，點進去會發現一件事：這個網站的標題叫拯救小說家，主介面的前端程式碼裡已經找不到 Arboris 這個名字，註冊流程要求帳號、密碼加電子郵件驗證碼，登入方式還掛了 LinuxDo 的 OAuth。而開源倉庫裡的前端，介面文字用的仍然是 Arboris。
也就是說，線上版已經自成一條線。線上版和 GitHub 上這份開源程式碼看得出同源：API 端點的長相與倉庫裡的程式對得上，但品牌與註冊體系換了整套。對讀者的實際影響很直接：你想先到線上版摸摸介面再決定要不要自架，那要注意你的稿件、設定與金鑰都寄存在別人的伺服器上，服務條款與資料去向要自己看清楚；而開源倉庫的功能說明與線上版的實際功能，也已經不能互相代表了。
架之前，先看清這個專案的現狀
先看授權。README 掛著 MIT 徽章，結尾也寫著授權詳見 LICENSE 檔案，但整個儲存庫裡找不到這個檔案，該路徑目前回應 404。作者釋出的意圖應該就是 MIT，但檔案缺席的當下，法律上的預設是保留所有權利。想拿它做二次開發或商業利用的人，先留意這個落差；這種徽章與檔案對不上的狀況在開源圈並不罕見，多醫生會診面板那篇提過一模一樣的案例。
再來看開發節奏。儲存庫建立於 2025 年 10 月，頭一個月發版很勤，六個版本擠在兩週多一點的時間裡，然後發布線就停在 2025 年 10 月底。程式碼最後一次推送是 2026 年 2 月底，內容只是說明文件更新（含 README 英文化），最後一次功能性提交停在 1 月，之後將近半年沒有動靜，GitHub 上掛著二十多個待解問題，2026 年 3 月起新開的都沒有得到專案作者的回覆。貢獻紀錄也值得看一眼：提交數最多的帳號屬於社群貢獻者，四十七次提交多於作者的二十四次。儲存庫沒有封存，線上服務也活著，但實際使用時要當成沒有人隨時修 bug 的工具，遇到問題得自己改或 fork。
照著 README 打指令卻找不到檔案，是部署時最常踩到的坑，成因正是文件與程式的漂移。說明文件的快速開始要你複製根目錄的 .env.example，這個檔案實際放在 deploy 目錄下，指令原樣照打只會撲空；環境變數表寫著預設模型是 gpt-3.5-turbo，程式裡的預設值其實是 gpt-4o-mini。這類漂移有它的成因：這個專案自身的開發也大量交給 AI 代理，後端一百一十八個 Python 檔裡有一百零一個的開頭留著機器產生的結構註解，全儲存庫放著三十六份給代理讀的說明檔，根目錄還留著 AI 產出的程式碼審查與整合報告。用 AI 開發不是問題，後果是文件更新的速度跟不上程式，部署時以原始碼與部署目錄的範本為準，別只讀 README。
什麼樣的創作者值得把它架起來
它最適合的對象很明確：已經在寫長篇或連載、設定數量多到人腦開始吃不消、家裡有機器能跑 Docker、願意自備模型金鑰，並且能接受專案停更狀態下自己扛維護的人。對這群人來說，一套把設定、伏筆、前文全部變成可檢索資料的系統，價值不在生成得多好，而在第兩百章的時候它還記得第一章埋的東西。
反過來說，期待填個書名就輸出整本小說的人會失望，作者自己都沒有這樣承諾；不想碰伺服器的人，線上版是另一個名字的另一個產品，信任條件不同；需要明確授權依據的商業使用者，則應該等授權檔真正補上再動。自架路線的起步也不複雜：把儲存庫 clone 下來，進 deploy 目錄複製環境變數範本，改好金鑰、管理員密碼這幾個必填項，起容器，預設就用 SQLite 不必另裝資料庫。起來之後先別急著寫正文，開一個作品把核心設定錄進去，跑一輪大綱生成，看看它檢索回來的前文與設定是否對得上，再決定要不要把正事交給它。
