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