“LLMs Set My Fiction Free”——這個標題如果直譯就是“大模型讓我的小說創作獲得了自由”。過去一年里這個判斷經常出現在科幻作者、網文寫手和同人創作者的討論中不再是“我寫不出來讓 AI 幫我寫”而是“我想寫的太多整理和實現不過來現在終于可以放手去寫”。很多開發者看到這句話第一反應是“這不就是 AI 代寫嗎”。但我更想把視角拉回工程一側LLM 在小說創作中真正釋放的不是“生成能力”而是“批量驗證和快速迭代能力”。換句話說它改變的并不是“有沒有靈感”而是“從靈感到正文之間的那條又長又容易放棄的路徑”。這篇文章不是一篇文學創作心得而是一篇面向開發者和創作者的技術實踐文章。我會從“LLM 的能力邊界”切入講清楚它為什么能釋放創作自由度然后給出一套可以跑通的最小工作流包含提示詞設計、API 調用示例、本地部署方案、RAG 資料庫雛形以及我在工程接入中最常踩的坑。讀完你可以用一套可落地的技術方案把 LLM 接進自己的小說創作流程知道哪些環節適合交給模型哪些環節必須由人控制遇到生成效果差、上下文斷裂、設定沖突時知道該從哪一層去排查。1. 這篇文章真正要解決的問題先說結論LLM 對小說創作最重要的貢獻是把創作過程中的“體力活系數”降了下來。寫一部小說尤其是長篇真正消耗人的往往不是“沒想到”而是世界觀設定散落在幾十個文檔里寫到第五章時忘了第二章埋的伏筆人物動機在寫作過程中發生漂移讀者覺得角色“崩了”時間線、能力體系、人物關系越來越多手動維護開始出現矛盾需要反復回到前文補細節導致寫作節奏被打斷有了靈感但缺乏足夠的內容結構去承接只能在腦子里反復“空轉”。這些問題的共同點是它們不是“創造性”問題而是“信息組織和上下文一致性”問題。而這兩點恰好是 LLM 作為工程工具最擅長處理的。但這不代表 LLM 能獨立寫好一本小說。如果你讓模型“自由發揮”一萬字它大概率會給你一篇結構完整、語言流暢、但邏輯松散的中庸之作。真正的用法是讓人負責決策讓模型負責擴展、改寫、校驗和檢索。當模型把“填充細節”這類工作接走之后創作者才有精力把時間花在“選擇哪條劇情線”“這個角色到底是誰”這類高價值的判斷上。所以這篇文章要幫讀者解決的核心問題不是“怎么寫小說”而是“怎么搭一套以 LLM 為執行層、以創作者為決策層的工程化寫作系統”。2. 為什么“自由”來自能力分層而不是模型單點輸出我在技術社區里看到過不少失敗的 AI 寫作嘗試幾乎都有一個共同點把 LLM 當成了“一個人”要求它從零到一完成整本小說。這種做法必然遇到三個問題上下文窗口有限模型很快就會遺忘前文的設定生成結果與既有設定沖突的概率隨文本長度遞增創作者失去了對作品的“手感”寫出來的內容不像自己的風格。真正可行的模式是把創作過程拆層。2.1 決策層創作者需要拍板的內容包括故事基調、人物弧光、關鍵情節點、敘事視角、哪些細節要保留、哪些沖突要激化。這一層的能力邊界是審美和世界觀模型不擅長做“選擇”因為選擇需要價值判斷。2.2 執行層LLM負責把決策轉化成文本。例如給出一句話的故事梗概讓模型擴寫出一章給出人物性格列表讓模型生成符合該性格的對話給出前文摘要讓模型續寫下一段。模型不需要“知道”整個宇宙只需要在當前任務里執行到位。2.3 記憶層RAG 與設定庫這是最容易忽略、也最關鍵的一層。長篇創作和短篇不同你不可能把前文的幾十萬字都塞進提示詞。需要把設定、人物檔案、時間線、風格樣本拆成結構化文檔用檢索的方式按需取用。這樣既節省 token又保證生成時的上下文在可控范圍內。2.4 校驗層二次模型調用或規則過濾寫完一章可以用另一個 prompt 讓模型檢查時間線是否一致、人物稱呼是否統一、是否有前后矛盾。這一步相當于自動化的“編輯審稿”。把流程拆開之后你會得到一個新的自由不再依賴某一次生成的質量。任何一次輸出不滿意都可以單獨重跑一個步驟而不是推倒重來。3. 創作場景中的模型選型與基礎環境既然要工程化第一步是選模型和跑通環境。創作者通常有兩種路線各有取舍。3.1 云端 API 路線適合大多數用戶不需要高端顯卡按量付費模型能力持續更新。在長文創作場景重點是選擇“長上下文能力好、中文指令理解強、支持結構化輸出”的模型。常見的云端方案包括 OpenAI 系列、Claude 系列、DeepSeek、通義千問、智譜 GLM 等。各家模型能力差異很大而且容易變化這里不寫死版本和參數你需要以官方最新文檔為準。但選型時有一個通用標準先用一個小型任務集做對比而不是看跑分。3.2 本地部署路線適合對隱私敏感、有創作數據保密需求、或者需要長期離線寫作的用戶。本地部署首選 Ollama 這類工具它可以方便地拉取并運行開源模型。在小說創作場景模型的精度格式直接影響到觀感。這就涉及到熱搜詞里反復出現的 fp16、fp32、bf16 問題我在第 6 章展開。這里先給出結論追求生成質量優先選 fp16 或 bf16 的模型顯存不夠時再考慮 4-bit 量化但要接受一定的文本流暢度下降。3.3 一次最小的環境準備本地部署的最小環境以目前常見的消費級配置為例# 安裝 OllamamacOS / Linux 用戶 curl -fsSL https://ollama.com/install.sh | sh # Windows 用戶去官網下載安裝包即可之后在命令行使用 ollama 服務 # 拉取一個適合中文創作的開源模型這里以 qwen 系列為例具體 tag 以官方為準 ollama pull qwen2.5:14b # 啟動一個常駐服務 ollama serve啟動之后可以用一個最小的 HTTP 請求驗證服務是否正常curl http://localhost:11434/api/generate -d { model: qwen2.5:14b, prompt: 用一句話描述一個發生在雨夜古城的懸疑開場。, stream: false }如果返回中包含response字段說明本地推理鏈路已經跑通。云端 API 路線的環境準備更簡單關鍵是申請并配置 API Key。注意Key 屬于敏感憑證不要硬編碼在代碼里更不要提交到公開倉庫。生產環境建議用環境變量或密鑰管理服務。4. 最小可用的創作工作流從靈感到章節現在進入核心部分。我帶你把創作過程拆成一個最小閉環。這套流程不需要開發復雜系統用腳本或甚至純提示詞就能跑起來。4.1 生成故事設定草案假設你只有一個模糊的靈感“一個失去記憶的調香師在一座永遠下雨的城市里尋找自己的過去。”先讓模型把這個靈感展開成結構化設定。關鍵點是要求模型輸出 JSON而不是散文。結構化數據后面可以被程序解析也能直接入庫。請把以下靈感擴展為小說設定草案并輸出 JSON 格式 { 故事梗概: , 核心沖突: , 世界觀關鍵詞: [], 主要人物: [ {姓名: , 身份: , 動機: , 秘密: } ] } 靈感一個失去記憶的調香師在一座永遠下雨的城市里尋找自己的過去。 要求人物動機要有內在邏輯世界觀關鍵詞控制在 5 個以內。這里有一個容易踩坑的地方很多模型對“輸出 JSON”理解不穩定偶爾會在 JSON 前后加說明文字。更穩妥的方案是在 API 調用層面把response_format設為json_objectOpenAI 系兼容接口、或在提示詞里加“只輸出 JSON不要任何解釋”。后面代碼示例我會給出一種通用處理方式。4.2 建立人物檔案模型生成的設定草稿只是一個起點。你需要手工篩選、修改形成真正屬于你的人物檔案。這一步不能省因為模型生成的動機往往偏“邏輯正確”但不夠“有血有肉”。修好之后把人物檔案保存為一個 Markdown 文件。比如# 人物檔案陸明遠 - 身份失去記憶的調香師27 歲 - 外在特點左手中指有舊傷疤常年帶著一只舊懷表 - 性格底色謹慎、疏離、但在氣味面前會失控 - 核心動機找回自己的過去 - 核心秘密他的記憶不是丟失而是被一家香水公司清洗過 - 說話習慣句子短很少用形容詞 - 禁忌拒絕談起玫瑰花這個文件后續既是創作時的參考也是 RAG 檢索庫里的核心條目。4.3 生成章節大綱有了人物檔案你可以讓模型生成章節大綱。和大綱相比模型的優點是可以快速提供多種劇情走向幫助你打破思維定式。請基于以下內容生成第一章的三種不同寫法大綱。 人物檔案 {把上面的人物檔案粘貼進來} 故事梗概 {粘貼你的故事梗概} 要求 1. 三種寫法分別側重懸疑氛圍、人物內心、事件推進 2. 每種寫法給出本場目標、沖突點、結尾鉤子 3. 控制輸出在 600 字以內注意大綱是模型輸出中少數可以“放心讓 AI 自由發揮”的環節。因為大綱不直接進入正文即使跑偏損失也很小。但正因如此它更適合用來做“腦暴”而不是替代你決策。4.4 章節擴寫把大綱變成正文這是最需要控制的一步。很多創作者在這里犯同樣的錯誤直接把大綱丟給模型說“寫出來”。問題在于缺少約束的正文會“泛化”。模型會寫出一段文筆優美、但完全不像你風格的內容。更有效的方式是給模型一個“錨點”開頭一句話、結尾一句話、必須保留的三個情節點、以及你希望的語氣風格。例如請根據以下結構擴寫第一章正文。 【已有背景】 下雨的城市調香師陸明遠在一家倒閉的香水店里發現了一瓶沒有標簽的香水。 【開場句】 雨滴砸在玻璃櫥窗上城市像一塊被泡發的舊海綿。 【結尾句】 他打開香水瓶聞到了一股不該在這個時代出現的味道十六年前母親廚房里的桂花香。 【本場情節點】 1. 陸明遠進入香水店躲雨 2. 他發現香水瓶上沒有標簽但瓶身有一道熟悉的劃痕 3. 店主出現言辭閃爍似乎認識他 4. 他偷偷拿走香水瓶離開店鋪 【寫作要求】 - 第三人稱限知視角跟隨陸明遠的所見所感 - 段落短句為主氛圍偏冷峻 - 不要解釋人物心理通過動作和感官描寫暗示情緒 - 輸出 1200 字左右這個 prompt 的意義在于你做了所有關鍵決策模型只負責文字執行。這樣生成的結果即使不滿意你也可以定位到具體問題——是情節不夠刺激還是風格不對而不是籠統地覺得“AI 寫得不行”。4.5 運行與驗證關于如何運行我用一個通用 Python 示例來演示。這里不再限定具體廠商思路是用 OpenAI 兼容接口通過base_url切換云端或本地服務。這樣代碼可以復用。# 文件路徑scripts/generate_chapter.py import os import json from openai import OpenAI # 方式一云端 API通過環境變量讀取 Key client OpenAI( api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL), # 例如云端服務的地址 ) # 方式二本地 Ollama 服務默認監聽 11434 # client OpenAI( # api_keyollama, # base_urlhttp://localhost:11434/v1, # ) def generate_chapter(prompt: str, model: str qwen2.5:14b) - str: try: resp client.chat.completions.create( modelmodel, messages[ {role: system, content: 你是一位擅長文學創作的編輯善于在框架內寫出高質量的小說正文。}, {role: user, content: prompt}, ], temperature0.8, ) return resp.choices[0].message.content except Exception as e: # 生產環境應記錄日志并做重試這里先拋出方便定位 raise RuntimeError(fLLM 調用失敗: {e}) def load_prompt_from_file(file_path: str) - str: with open(file_path, r, encodingutf-8) as f: return f.read() if __name__ __main__: prompt load_prompt_from_file(prompts/chapter_01.txt) result generate_chapter(prompt) print(result) # 保存結果保留原始輸出方便對比和回滾 with open(outputs/chapter_01_draft.md, w, encodingutf-8) as f: f.write(result)這個腳本有幾個值得留意的設計用環境變量管理 Key避免硬編碼。用文件讀取 prompt方便版本管理。輸出到outputs/目錄且不覆蓋原文件。每一次生成的草稿都保留這對后續對比模型效果很重要。運行命令export LLM_API_KEYyour_key export LLM_BASE_URLhttps://your-api-endpoint python scripts/generate_chapter.py如果你的模型在本地把LLM_BASE_URL改成http://localhost:11434/v1并把 API Key 填成ollama即可。驗證生成效果我建議按四步走是否完整有沒有漏掉某個情節點的展開。是否一致人物性格、稱呼、服化道細節是否和檔案一致。是否可讀拋開文學性不談句子是否通順、節奏是否正常。是否符合預期這是最主觀的一步也是必須由創作者判斷的一步。如果前兩步不過關通常不是模型不行而是你的提示詞里信息不夠。把人物檔案和更多背景粘進去效果立刻不同。5. 用 RAG 構建“設定檢索庫”當你開始寫長篇小說很快就會面臨一個尷尬問題提示詞放不下全部設定。假設你有 50 個人物檔案、20 個地點、30 年時間線這些加起來的字數可能超過 3 萬。每次寫一章之前都要手動把相關內容挑選出來這個成本會壓垮創作熱情。這時候就需要一個非常精簡的 RAG檢索增強生成流程。核心思路是把設定文檔切成小塊存入向量數據庫生成正文前先用向量檢索找出與當前章節最相關的設定拼進提示詞。這里我給一個最小可用的簡化實現足夠跑通概念。生產環境可以考慮用更完整的框架但原理都一樣。# 文件路徑scripts/build_rag_index.py # 這是一個概念演示版本生產環境請使用正式向量庫并處理更多細節 import os import json from pathlib import Path # 這里用輕量級方式模擬向量檢索按關鍵詞打分 # 生產環境建議使用開源的向量數據庫并接入真正的 embedding 模型 SETTING_DIR Path(settings) # 存放設定文檔的目錄 INDEX_FILE Path(setting_index.json) def build_keyword_index(): index [] for md_file in SETTING_DIR.glob(*.md): content md_file.read_text(encodingutf-8) # 提取文件標題和首行作為檢索入口 lines content.splitlines() title lines[0].lstrip(# ).strip() if lines else md_file.stem # 簡單切分按段落拆塊 chunks [] current_chunk [] for line in lines[1:]: if line.strip() : if current_chunk: chunks.append( .join(current_chunk)) current_chunk [] else: current_chunk.append(line.strip()) if current_chunk: chunks.append( .join(current_chunk)) for chunk in chunks: if len(chunk) 30: continue index.append({ title: title, file: md_file.name, content: chunk, keywords: set(chunk[:80].split()) # 簡化關鍵詞提取 }) return index def retrieve(query: str, index: list, top_k: int 3): # 簡化打分query 中的字詞在塊中出現的次數越多權重越高 query_terms set(query.replace(, ).replace(。, ).split()) scored [] for item in index: overlap len(query_terms item[keywords]) scored.append((overlap, item)) scored.sort(keylambda x: x[0], reverseTrue) return [item for score, item in scored[:top_k] if score 0] if __name__ __main__: index build_keyword_index() print(f索引構建完成共 {len(index)} 個文本塊) query 陸明遠 桂花香 香水店 下雨 results retrieve(query, index) for r in results: print(---) print(f來源: {r[file]} | 標題: {r[title]}) print(r[content][:200])這段代碼故意沒有引入真實的向量庫原因是為了讓你先理解流程。真正上生產時你需要用 embedding 模型把文本轉成向量而不是關鍵詞打分使用專門的向量數據庫或者至少在內存里維護向量索引在做正文生成前先用當前章節的情節點作為 query檢索出相關設定再拼進 prompt。這個“檢索 → 拼裝 → 生成 → 校驗”的循環是長篇創作工作流的基本單位。比起把全書塞進上下文這要省 token 得多而且效果更穩定。6. 模型精度fp16、fp32、bf16 對小說創作意味著什么寫小說最怕什么最怕文本“崩字”。一段話中出現奇怪的重復、邏輯跳躍、用詞失衡即使概率只有 5%長篇里也會頻繁遇到。而模型精度恰恰會影響這種“長尾錯誤”的概率。這里把三個概念講清楚。6.1 fp3232 位浮點模型訓練和推理最常見的表示方式之一。精度最高但顯存占用也最大。一個 70B 級別的模型用 fp32 推理普通消費級顯卡基本帶不動。6.2 fp1616 位浮點半精度顯存占用比 fp32 少一半推理速度更快。在生成文本時fp16 通常是本地部署的質量優先選擇。但它的數值范圍有限對特別大或特別小的數值不敏感可能導致訓練時出現精度問題。好在推理階段尤其對創作類文本fp16 的損失肉眼幾乎不可見。6.3 bf16bfloat16同樣是 16 位但保留了 fp32 的指數范圍舍棄了更多尾數精度。它的優勢是訓練穩定性更好不容易溢出。在生成任務中bf16 的質量通常和 fp16 非常接近。很多新硬件的推理框架默認用 bf16。精度格式顯存占用數值范圍文本生成穩定性適用場景fp32高大參考基準小模型、對精度極度敏感的場景fp16中較小好通用本地推理創作文本夠用bf16中較大很好新硬件推理訓練與生成通用對于寫小說這個場景我的建議是如果你的硬件支持 bf16優先用 bf16否則 fp16 也完全夠。只有在顯存實在不足時才考慮 4-bit 量化但要在質量與資源之間做取舍。你可以在 Ollama 中通過模型的 tag 或環境變量切換精度具體參數以你的硬件驅動和模型倉庫說明為準。這里不寫死命令因為不同平臺差異較大重點是你需要知道當生成結果出現莫名其妙的邏輯斷裂時除了檢查 prompt還應該考慮精度設置是否過低。7. 創作場景的版本管理與回滾寫小說和寫代碼有一個共通點版本管理很重要。而且在這個場景里版本管理不只是“保存舊稿”而是“保存每一次決策”。我的建議是建立如下目錄結構project/ ├── prompts/ # 所有可復用的提示詞按版本保存 │ ├── chapter_01_v1.txt │ ├── chapter_01_v2.txt │ └── compare_prompt.py # 對比不同 prompt 生成的正文 ├── setting_docs/ # 人物檔案、世界觀、時間線 │ ├── characters/ │ ├── world/ │ └── timeline/ ├── outputs/ # 模型生成結果按章/版本保存 │ ├── chapter_01_draft_v1.md │ └── chapter_01_draft_v2.md ├── scripts/ # 調用腳本、RAG 索引、校驗腳本 │ └── generate_chapter.py └── git_repo/ # 或者直接在項目根目錄用 git這樣做的原因很明顯你經常需要回到“上一版 prompt”重新生成。如果 prompt 和輸出散落在對話記錄里回顧成本會非常高。一個實用技巧在輸出文件的頭部加一行注釋記錄本次生成使用的模型、溫度參數、prompt 文件路徑。這樣可以快速復盤什么條件下效果最好。!-- 元信息: modelqwen2.5:14b, temp0.8, promptprompts/chapter_01_v2.txt, date2025-01-10 --正文開始……這種“元信息優先”的思想是從數據工程和實驗追蹤里借鑒來的。它不增加多少工作量卻能避免很多“咦上次那版是怎么寫出來的”的迷茫。8. 常見問題與排查思路在接入 LLM 創作流程時你會遇到幾類固定問題。提前知道原因排查會快很多。問題現象可能原因排查方式解決方案模型生成的設定前后矛盾提示詞中設定信息不足或上下文被截斷檢查 prompt 中是否包含人物檔案和世界觀摘要增加 RAG 檢索或把關鍵設定寫入 prompt生成正文“文筆很好但不像你的風格”缺少風格示例模型在模仿通用文學腔在 prompt 中加入你自己的 2-3 個句子作為風格參考維護一個風格樣本文件隨 prompt 一起提交同一段提示詞多次生成結果差異過大溫度參數設置過高檢查 temperature 參數創作草稿可用 0.7-0.9設定整理建議降到 0.3 以下模型輸出 JSON 格式不穩定提示詞沒有明確約束或模型版本不支持強制 JSON開啟 response_format 或后處理去掉多余內容用正則提取 JSON 塊失敗時重試一次本地推理速度慢模型過大、精度過高、顯存不足查看 ollama ps 或 nvidia-smi 監控資源換更小模型或使用量化版本長文生成到一半開始重復語句上下文過長導致注意力分散檢查輸出文本長度與模型窗口控制單次生成篇幅按章節生成而不是整本生成特別提醒一個創作場景特有的問題不要用默認的“對話式”思維去寫提示詞。模型在對話中會逐漸“討好”你給出的回復越來越趨于平均。你需要的是“任務式”prompt目標明確、邊界清晰、輸出格式固定。9. 最佳實踐與安全邊界最后一部分我想把工程上的建議和創作倫理結合著說。9.1 把模型當“執行編輯器”而不是“共同作者”在創作層面建議你始終保留標題、關鍵情節、人物弧光和最終潤色的決策權。這不僅是風格問題也是版權和創作完整性問題的底線。AI 生成的內容可以作為草稿和素材但最終的文學判斷必須由人完成。9.2 做好合規與授權這里有兩層意思。第一你使用的 API 和模型必須符合服務商的條款。第二如果你計劃發布作品尤其是商業發布建議明確標注哪些部分使用了 AI 輔助創作。不同平臺對 AI 輔助內容的政策不同發布前先了解目標平臺的規定。涉及他人作品、受版權保護的資料時不要隨意喂給模型并要求模仿生成這是法律風險較高的操作。9.3 設定文檔要保持單一事實源不要讓同一份人物信息既出現在角色檔案里又散落在章節注釋里。正確做法是角色檔案是唯一權威來源章節內不同可以臨時調整但最終要同步回檔案。這樣RAG 檢索時拿到的永遠是修正后的信息而不是某次草稿里的舊設定。9.4 做好輸出安全與隱私如果你的作品尚未公開注意不要把未公開的大綱、章節、人物設定上傳到不受信任的第三方模型平臺。敏感內容請選擇本地部署方案或者與簽署了保密協議的云服務商合作。對外調用 API 時日志里不要記錄完整 prompt 和輸出只記錄任務編號、耗時、成功失敗狀態。9.5 建立“人審”環節一次完整的模型輸出至少需要經過一遍人工審閱。你可以把審閱拆成兩遍第一遍看情節和人物第二遍看語言和風格。模型很少能一次寫出完全不用改的文本但能把“從零開始”變成“改稿”這個改動本身就是效率的巨大提升。10. 總結從一次最小閉環開始回到標題“LLMs Set My Fiction Free”。如果把它理解成“AI 幫我寫小說”方向就偏了。真正的“自由”來自把繁瑣的擴展、檢索、校驗工作交給模型讓創作者把精力集中在最擅長的判斷和決策上。你可以從一個小項目起步不需要搭建完整的系統選一個好用的云端 API 或本地模型跑通一次生成本文鏈路寫一個固定格式的 prompt保存為文件把自己的風格樣本放進去生成一章 500 字左右的測試文本手工改到滿意記錄下“哪些提示詞改動效果最明顯”。等這個小閉環穩定之后再逐步加入人物檔案、RAG 檢索、版本管理、結果校驗。這樣你不會被復雜度嚇退也能在看到真實效果后更清楚自己到底需要哪一層能力。技術只是工具故事還是你的。