如果你手里有一套AI編程輔助工具除了寫代碼它其實還非常適合做另一件事生成一部萬字級的奇幻世界設定。我最近用某款AI代碼編輯器里的編程助手下文簡稱CA純粹是為了敘述方便不構成任何工具推薦花了差不多三個晚上把原本零散在腦子里的種族、地理、神系設定整理成了一份有目錄、有索引、可校驗的完整世界觀文檔。整個過程下來我的體會是世界設定本質(zhì)上是一個需要持續(xù)維護、保證內(nèi)部一致的信息工程而這恰好是AI Coding工具最擅長的領域。這篇實踐記錄就把完整思路和步驟拆給你看適合那些想用AI做小說設定、跑團戰(zhàn)役背景或者游戲世界觀構架的創(chuàng)作者參考。1. 為什么拿代碼工具來寫世界設定可管理、可校驗、可回滾1.1 從“聊天式寫作”到“工程化寫作”狀態(tài)從無到有最早我用AI聊天窗口寫設定發(fā)現(xiàn)一個很要命的問題AI沒有記憶。上午剛確定精靈王子的名字叫“凱爾薩”下午再開一個新對話它就給你寫成“凱爾洛斯”你問它上一版設定里某個城邦在哪里它一臉茫然。原因很簡單聊天窗口里沒有項目文件每一次對話都是無狀態(tài)的AI只能依賴你臨時塞給它的那點上下文。把同樣的事情挪到AI Coding工具里邏輯完全變了。你生成的所有設定都以文本文件的形式存在于同一個項目目錄下AI生成新內(nèi)容之前會自動掃描項目內(nèi)的相關文件把它當作參考上下文。這相當于代碼倉庫里所有模塊共享一套類型定義不會各寫各的。我后來的工作方式就變成了不是在聊天而是在維護一個持續(xù)演進的設定倉庫。每一次生成、修改、刪除都有文件層面的記錄隨時可以翻看、回滾、對比。1.2 世界設定最大的敵人不是靈感是內(nèi)部矛盾寫過一個長篇奇幻設定的人都知道開頭靈感迸發(fā)時是最爽的但寫到兩萬字之后真正的噩夢不是“沒東西寫”而是“對不上號”。某個角色在第一紀元建立了一座城邦到第三紀元的時候你又讓他以“年輕的旅人”身份登場前文明確說某種魔法只能由精靈使用后文人類主角卻莫名其妙施展了出來。這種問題和代碼里的全局變量被意外修改、接口定義前后不一致本質(zhì)上是同一回事。我見過很多創(chuàng)作者用Excel表格來管理設定這比聊天強得多但表格只能管“存在的事實”管不了“矛盾的事實”。比如人物狀態(tài)從“活著”變成“死亡”之后還繼續(xù)在后續(xù)事件中出現(xiàn)這種邏輯沖突靠肉眼很難發(fā)現(xiàn)。AI Coding工具提供了一條新的解決路徑用腳本掃描。把設定轉(zhuǎn)成結(jié)構化數(shù)據(jù)之后寫一個簡單的檢查腳本就能快速找出時間線沖突、人物狀態(tài)沖突和名詞重復定義。這種“代碼級校驗”的能力是普通聊天AI和筆記軟件給不了的。1.3 工具選型對比代碼編輯器憑什么贏過筆記軟件有人可能會問我直接用在線筆記軟件管理設定不行嗎當然可以但如果你需要大規(guī)模生成和長期一致性維護代碼編輯器的優(yōu)勢非常明顯。對比維度AI Coding工具CA普通筆記軟件內(nèi)容形態(tài)純文本/Markdown文件可批量處理、全文檢索富文本為主批量處理能力弱規(guī)則約束項目規(guī)則文件自動生效AI每次生成都遵守無類似機制靠人工提醒校驗手段可以編寫腳本掃描矛盾自動定位問題基本靠人工通讀版本管理直接接入git任意版本可回滾多數(shù)沒有版本記錄改錯難恢復我并不是否定筆記軟件在頭腦風暴階段的作用說實話前期收集靈感、隨手記碎片我用得最多的還是筆記工具。但進入“生成萬字設定”這個階段之后信息量一大筆記軟件的維護成本就開始失控。而AI Coding工具本質(zhì)上把設定變成了一個可編譯的項目有依賴、有約束、有測試。這一點決定了它能扛住萬字規(guī)模。2. 寫設定之前先做四項工程化準備2.1 目錄結(jié)構把設定文件當代碼模塊來組織決定用AI Coding工具之前我先花了一個小時設計目錄結(jié)構。這步看起來基礎實際上決定了后續(xù)AI能不能準確找到需要的文件。我最終采用下面這個結(jié)構供你參考worldbook/ ├── rules.md ├── index.md ├── 00_總綱/ │ ├── 世界概述.md │ ├── 紀元年表.md │ └── 基礎規(guī)則.md ├── 01_地理/ │ ├── 大陸地圖.md │ ├── 主要城邦.md │ └── 氣候與資源.md ├── 02_種族/ │ ├── 精靈.md │ ├── 矮人.md │ └── 人類諸國.md ├── 03_超凡/ │ ├── 神系.md │ ├── 魔法體系.md │ └── 禁忌儀式.md ├── 04_勢力/ │ ├── 王國與聯(lián)盟.md │ └── 秘密結(jié)社.md ├── 05_人物/ │ └── 人物關系.md ├── 06_事件/ │ └── 關鍵事件.md └── scripts/ └── check_consistency.py數(shù)字前綴是我刻意加的作用是讓文件夾按順序排列AI在項目里瀏覽文件列表時能一眼看出主次關系。內(nèi)部關聯(lián)采用“一處定義、處處引用”的做法這個原則直接借用了代碼里的DRY。比如精靈的壽命是800年這個事實只寫在02_種族/精靈.md里其他文件需要提及時就寫明“見02_種族/精靈.md”而不是復制一份數(shù)據(jù)。復制意味著將來可能改一邊漏一邊AI最擅長在這種地方制造矛盾。2.2 規(guī)則文件相當于給AI一份“編碼規(guī)范”AI Coding工具普遍支持在項目里放一個規(guī)則文件比如社區(qū)里常說的rules文件作用是讓AI在每次生成前自動加載這些約束。我一開始沒意識到這東西有多重要直到AI連續(xù)兩輪都寫出了帶現(xiàn)代感的對話才明白必須把規(guī)則寫死。我那份rules.md是這么寫的# 世界設定生成規(guī)則 - 所有名詞以術語表為準瑟蘭迪爾只指代一座城市不指任何人物。 - 禁止出現(xiàn)現(xiàn)代詞匯不得出現(xiàn)“手機”“互聯(lián)網(wǎng)”“血壓計”等。 - 年份一律采用“光復歷 XXX年”格式不得使用“前XX年”的模糊表述。 - 每個文件開頭必須包含狀態(tài)標記draft草稿、confirmed已確認、archived已歸檔。 - 涉及人物狀態(tài)時必須與05_人物/人物關系.md保持一致。這個文件的價值在于它把每次對話前手打一段要求的工作自動化了。你不需要每次重新跟AI強調(diào)“不要用現(xiàn)代詞匯”它自己就會讀到規(guī)則文件并按規(guī)則執(zhí)行。這就像給AI發(fā)了一份編碼規(guī)范雖然不能保證它百分之百不犯錯但能把低級錯誤率壓到很低。2.3 總索引與術語表讓每個名詞只有一個真實含義設定生成到后期最怕的就是名詞混亂。同一個地名前面叫“白塔城”后面變成“白塔堡”同一個角色前面叫“艾琳·光語”后面被AI縮寫成“艾琳”。解決這個問題的辦法是建立一個總索引和一個術語表?？偹饕褪莍ndex.md相當于代碼工程里的路由表。AI生成新文檔時第一步就是看這個文件找到它應該參考哪些相關文檔避免漏掉重要上下文。術語表我用表格記錄結(jié)構很簡單名詞類別一句話定義狀態(tài)瑟蘭迪爾城市精靈文明的首都光復歷前已存在confirmed艾爾德蘭世界核心舞臺大陸周邊有破碎群島confirmed鐵砧議會勢力矮人諸部聯(lián)盟的最高議事會confirmed狀態(tài)列是關鍵。凡是畫了confirmed的詞條就意味著這個定義已經(jīng)鎖死任何人或AI都無權擅自修改。后續(xù)如果確實要調(diào)整必須先更新術語表再同步所有引用位置。這實際上就是代碼工程里的“唯一數(shù)據(jù)源”思想。2.4 JSON設定卡結(jié)構化數(shù)據(jù)才是校驗的基礎散文能提供閱讀快感和氛圍感但它不適合做校驗輸入。AI生成一萬字的長篇設定后如果全是段落文本你很難用腳本去檢查里面有沒有矛盾。所以我在項目里做了一個讓步讓AI把核心事實抽成JSON設定卡散文另存為描述文檔。舉個例子一座城市的事實部分長這樣{ name: 瑟蘭迪爾, category: city, founder: 艾琳·光語, founded_year: 312, population: unknown, status: active, notes: 精靈文明的首都光復歷后成為外交中心 }散文負責講故事JSON負責記事實。后續(xù)寫檢查腳本時只需要讀取所有JSON文件就能做字段完整性檢查、跨文件引用的矛盾檢測。我承認讓AI同時輸出兩種格式會多一點工作量但相比后期人工通讀幾萬字挑矛盾這點成本非常劃算。3. 從零生成萬字世界設定的四步實操流程3.1 第一步先寫設定總綱再談萬字輸出我見過很多朋友一上來就扔給AI一句“幫我生成一個奇幻世界”結(jié)果得到的是一篇極其無聊、充滿了古早味元素的萬金油設定。原因很簡單AI是概率模型你的輸入的約束越少它輸出的平均值就越平庸。我的做法是先手寫一份設定總綱把最關鍵的內(nèi)容定死不給AI太多自由決定的余地。總綱不用長幾百字就夠重點說清楚世界觀基調(diào)、核心沖突和當前時間點。# 設定總綱輸入給AI的版本 - 世界名艾爾德蘭 - 基調(diào)低魔、近現(xiàn)代、大陸破碎、舊神與凡人議會并存 - 核心沖突舊神回歸試圖重塑世界 vs 凡人議會維持現(xiàn)有秩序 - 當前紀元時間光復歷 842年 - 自然法則六大元素封印穩(wěn)定存在高階魔法需要議會許可 - 文明形態(tài)精靈偏保守矮人重工業(yè)人類處于議會聯(lián)盟階段這份總綱寫完之后再讓AI先生成“紀元年表”。年表是整個世界觀的時間骨架后面的所有事件都要掛到這條時間線上所以這個文件必須工整、嚴謹、可追溯。3.2 第二步分批生成子文檔一次只做一件事很多人輸就輸在貪多。讓AI一次性生成“全部世界觀”它會在同一段輸出里出現(xiàn)兩種巨龍體系、三種魔法來源而且互相根本對不上。正確的做法是分批次生成每批只產(chǎn)出一個子文檔并且明確告知AI的任務邊界。我當時按這個順序推進總綱 → 紀元年表 → 地理 → 種族 → 神系/魔法 → 勢力 → 人物關系 → 關鍵事件。每批給的提示詞大概長這樣請閱讀 00_總綱/紀元年表.md 和 01_地理/大陸地圖.md然后生成“主要城邦”文檔。 要求 1. 每個城邦包含名稱、位置、人口規(guī)模、統(tǒng)治者、與總綱核心沖突的關系。 2. 禁止新增總綱中沒有的大陸。 3. 年份采用“光復歷 XXX年”格式。 4. 輸出完成后在每座城邦的名稱旁標注其所屬地理區(qū)域。這樣做的原因是AI Coding工具的上下文窗口有限任務邊界越窄它輸出的質(zhì)量越穩(wěn)定。而且分批生成還有一個好處每生成完一個文檔你都可以立刻檢查發(fā)現(xiàn)問題當場修正不會把錯誤累積到后面。3.3 第三步寫一個設定矛盾掃描腳本這是整套流程里最有“工程感”的一步也是普通AI聊天完全替代不了的一步。既然設定已經(jīng)轉(zhuǎn)成了JSON卡就可以用腳本來自動檢查矛盾。我寫了一個不算復雜的Python腳本核心邏輯有幾條重名檢測、狀態(tài)沖突檢測、年份順序檢測。import json from pathlib import Path people {} cities {} for file in Path(.).rglob(*.json): data json.loads(file.read_text(encodingutf-8)) if data.get(category) person: people.setdefault(data[name], []).append(data) elif data.get(category) city: cities.setdefault(data[name], []).append(data) # 1. 重名檢測 dup_people {n for n, items in people.items() if len(items) 1} dup_cities {n for n, items in cities.items() if len(items) 1} if dup_people: print([警告] 重名人物, dup_people) if dup_cities: print([警告] 重名城邦, dup_cities) # 2. 人物狀態(tài)與年份順序檢測這里只做最簡單的死亡早于登場檢查 for name, items in people.items(): for item in items: born item.get(born_year) died item.get(died_year) if born and died and died born: print(f[錯誤] {name} 的死亡年份早于出生年份{died} {born})這個腳本本身需要人工去適配自己的數(shù)據(jù)格式但它說明了一件很重要的事校驗自動化完全可行。你不需要把腳本寫得多么優(yōu)雅只要能把“低級但高頻”的邏輯錯誤抓出來就能省下大量人工通讀的時間。實測下來這一輪檢查幫我找出了一處死亡年份早于登場時間的硬傷以及一個重名城邦。3.4 第四步人工復核與增量修正腳本能抓邏輯錯誤但抓不了風格問題、情緒問題、審美問題。所以生成完成后我會挑幾個關鍵文檔做人工復核。重點看三件事專有名詞是否和術語表一致人物行為是否符合之前設定的性格整體文風是否保持了統(tǒng)一的史詩感。發(fā)現(xiàn)BUG之后的修正過程也要遵循“代碼思維”。比如腳本提示某個角色在光復歷412年死亡但后續(xù)事件中他又登場了這時候不能只改事件文檔而是要連人物卡、時間線、甚至其他相關事件的引用一起改。修正提示詞我是這樣下的發(fā)現(xiàn)設定矛盾角色奧德里奇在光復歷412年死亡但06_事件/第二紀元戰(zhàn)爭.md中他在420年再次登場。 請修改該事件文檔把登場時間改為409年或在人物卡中將死亡年份更新為430年。 修改后同步更新所有引用該角色的文件并在文件狀態(tài)中注明“已修正”。整個過程不一定一次到位可能需要跑兩三輪“修改→掃描→再修改”。但我個人體驗是用這種增量修正的方式一套設定基本能在三個晚上內(nèi)穩(wěn)定下來。比起一遍遍讓AI重新生成全文效率高得多。4. 我踩過的四個設定生成坑與排查實錄4.1 紀元時間線連環(huán)沖突AI“穿越”到了1000年后第一次生成“舊神回歸”事件時AI把回歸時間寫成了光復歷1000年。問題在于我在生成任務里沒有給它總綱中“當前時間1942年”的明確提示AI按照自己默認的“宏大敘事”慣性直接跳到了一個很遙遠的未來。這個問題非常有代表性。解決思路是把“當前時間”寫進rules.md并強制所有事件文檔都標注“與年表關系”。我整理了一張速查表方便對照排查。常見問題典型表現(xiàn)排查思路預防手段時間線沖突事件發(fā)生在當前時間之后檢查事件年份與總綱當前時間在規(guī)則文件中固定當前時間人物狀態(tài)沖突死亡人物后續(xù)登場檢查人物卡狀態(tài)與事件文檔生成事件前先讀人物卡地理關系矛盾城市所在大陸前后不一致檢查地理文件夾中的位置標注強制所有城邦標注地理區(qū)域名詞重復定義同名不同體跑重名檢測腳本用術語表統(tǒng)一名詞歸屬4.2 同名不同人兩個伊莎差點被AI合并成一個人我的世界觀里有兩個叫“伊莎”的角色一個是精靈詩人伊莎·晨露一個是矮人鐵匠伊莎·鐵砧。AI生成戰(zhàn)爭場景時把兩個角色直接當成同一個人處理讓精靈詩人拿起了鐵錘上戰(zhàn)場。這個錯誤非常經(jīng)典核心原因就是我沒有在術語表里給相似名字做區(qū)分。后來我立了一條硬規(guī)矩所有重名或相似名的角色必須帶姓氏或氏族名且在術語表中標注“與另一伊莎無關”。這條規(guī)矩讓AI的后續(xù)生成再也沒有把兩人搞混過。其實這就是給角色加“命名空間”——和代碼里同名函數(shù)用不同包名區(qū)分是同一個道理。4.3 設定漂移AI越寫越嗨自己發(fā)明了第七封印在生成“禁忌儀式”文檔時模型居然自己編了一個“第七封印”但我的世界觀體系里明明只有六元素封印。原因是我給它的上下文太薄它不知道“六元素封印”是這個世界的鐵律于是按照“封印應該有七個”的套路記憶自行補全了。遇到這種超綱擴展必須當場判斷是接受還是拒絕。如果接受就要把它正式錄入規(guī)則文件和術語表讓這個“臨時發(fā)揮”變成唯一事實來源如果拒絕就讓AI刪掉相關內(nèi)容并恢復到六元素體系。但最怕的是什么都不做留著這種半生不熟的設定在文檔里后續(xù)生成全都會被帶偏。這就是典型的“設定漂移”放任不管的后果就是整個世界觀逐漸脫離你最初的設計。4.4 上下文窗口限制AI開始“忘記”早期設定項目文件越來越多之后AI Coding工具的上下文窗口開始吃緊。有一輪生成人物關系文檔時它居然把我最早期確認的“夜鶯家族”設定忘得一干二凈導致人物關系里出現(xiàn)了一個完全不同的“夜鶯商團”。這種情況不是模型笨而是長上下文的注意力本來就有限塞進去的東西太多AI會優(yōu)先看最近的對話和當前打開的文件。對策是維護一個“關鍵摘要.md”每次任務前只喂摘要加當前相關文檔不把整個項目都塞進上下文。摘要必須精簡到一屏能看完只列最關鍵事實# 關鍵摘要每次生成前投喂 - 當前時間光復歷842年 - 已完成文件見 index.md - 核心沖突舊神回歸 vs 凡人議會 - 禁止改動六元素封印數(shù)量固定 - 待辦城邦貿(mào)易路線未定 - 特別注意鐵砧議會與精靈議會關系處于冷戰(zhàn)期這個小改動立竿見影。此后AI生成相關文檔時哪怕項目已經(jīng)幾十個文件它也能先把握住全局關鍵信息再深入具體文件錯誤率明顯下降。5. 讓AI寫設定更順手的四個進階經(jīng)驗5.1 把確認過的設定固化進規(guī)則文件規(guī)則文件的初始內(nèi)容只是基礎約束但它應該隨著項目的推進不斷“生長”。每當我在人工復核階段確認了一條新設定就把它同步寫進rules.md。比如確認“人類蒸汽技術不能突破19世紀水平”我就把它加入規(guī)則文件之后AI生成任何科技向內(nèi)容時都會自動受約束。這相當于讓AI在每次生成前先讀一遍最新設計文檔不需要你再重復叮囑。規(guī)則文件越長生成內(nèi)容越穩(wěn)但注意別讓它超過一屏否則AI又會把后面的內(nèi)容當噪音忽略掉。5.2 用git給設定上一道回滾保險這個經(jīng)驗完全是從代碼工程里借來的。我的設定項目從第一天就初始化了git倉庫每生成完一個文件就提交一次。AI有時候會“好心”幫你修改一個舊文檔但改得亂七八糟如果沒有git你就只能手動把它慢慢改回去。git init git add . git commit -m 初始設定總綱與紀元年表后續(xù)每次批量生成完成后再提交一次。萬一AI改壞了用git checkout回退到某個穩(wěn)定版本就行。哪怕不習慣命令行也可以用代碼編輯器的圖形面板操作。這個習慣在生成到第三天時救了我一次當時AI把某個種族的歷史時間線整體改歪了我花了不到一分鐘就回到了前一天的穩(wěn)定版本。5.3 用隨機抽問代替逐字校對萬字級別的設定集逐字閱讀是不現(xiàn)實的。我的做法是讓AI自己考自己隨機抽幾個人物問他們當前年份應該在哪個位置、在做什么事情然后和人物卡、事件文檔對照。比如抽問“光復歷842年精靈詩人伊莎·晨露在哪個城市、在做什么”AI會去項目里尋找相關文件給出的答案再與人物關系文檔交叉驗證。抽問10個點如果全對那么這個體系基本是可信的如果錯了就根據(jù)具體錯誤反推是哪一層文檔出了問題。這個方法配合腳本掃描比我人工埋頭硬讀效率高太多。5.4 誠實邊界這套流程不適合所有創(chuàng)作場景最后也得說點實話。這套工程化流程不是萬能的如果你只是隨手寫一個小短篇背景幾百字就可以講完完全沒必要折騰目錄、規(guī)則文件和JSON設定卡。如果你的創(chuàng)作過程極度依賴隨機靈感、抗拒結(jié)構化約束這套流程甚至會讓你覺得束手束腳。它真正適合的是那些“規(guī)模大、角色多、要求長期一致”的項目比如系列小說、跑團戰(zhàn)役、游戲原型世界觀。在這些場景下一致性就是生命線工程化不是負擔而是保障。最后再分享一點個人體會。用AI Coding工具寫設定最大的收獲不是字數(shù)快速漲到一萬而是它逼著我把靈感變成了結(jié)構。以前我構思奇幻世界時滿腦子都是漫無邊際的腦洞現(xiàn)在我會先問一句這個設定放在哪個文件、由誰維護、和什么后續(xù)內(nèi)容互相影響。聽起來像在做軟件工程但奇幻世界本身就是要長期維護、反復擴展的系統(tǒng)。如果你正打算用AI生成一套長篇世界觀我建議你從目錄結(jié)構和規(guī)則文件開始哪怕第一版只有三四個文件也比直接在聊天窗口里猛沖要靠譜得多。至少在我自己反復踩坑之后這是目前唯一能讓AI寫設定寫得不散架的辦法。