AI小说创作助手实战：提示词驱动的创作流水线与提示词管理

简介一套功能完整的人工智能小说创作助手项目基于Python与前端技术实现面向小说作者及AI应用开发者提供从灵感生成到正文润色的全流程支持。压缩包共52个文件包含Python脚本、JavaScript逻辑、HTML页面、Markdown教程、界面截图等整体仅3.48MB目录结构明了。资源核心功能覆盖智能提示词管理、拆书分析、书名与简介生成、正文润色及错别字语法修正并适配DeepSeek、Claude、ChatGPT、Ollama等多种大模型接口方便用户按需接入。智能拆书功能可帮助用户分析经典作品并提炼创作元素内置的Shi.zip工具支持将作品压缩打包便于收藏与分享满足日常创作管理需求。此外还附带详细的编辑器教程与提示词优化文档既可直接运行用于日常写作也可作为学习提示词工程和AI写作工具开发的参考。已有52人学习下载适合希望借人工智能提升创作效率的写作者以及想研究相关技术实现的人群。1. 这标题讲什么AI小说创作助手不是自动写文机而是一套提示词驱动的创作流水线一个常见的误解是AI小说创作助手等于“输入一句话AI直接吐出一整本小说”。真这么做的人三章之后就会开始跟AI吵架——角色性格漂移、时间线混乱、对话全是AI腔。而标题里反复强调的“AI 提示词技术 提示词管理”其实是在说另一件事把小说创作拆成一个个可以独立指挥AI的子任务每个子任务交给不同的提示词去控制再用一套管理机制把这些提示词存好、调好、复用起来。这个工具真正提升效率的点不在于AI替你写而在于它把你从“反复输入同样要求”这种琐碎劳动里解放出来。智能拆书、生成书名与简介、正文润色每一件都是提示词工程的落地场景而Shi.zip这类资源包通常就是把这些提示词、模板和配置文件打包成可分发、可备份的载体。这篇文章写给想自己动手搭一套类似工作流的创作者和技术从业者你会看到每个功能背后的提示词设计思路、最小可跑的代码、以及那些不跑一遍根本发现不了的坑。2. 从拆书到生成书名简介先想清楚AI在这个流程里替代了什么2.1 智能拆书把一本陌生小说拆成可复用的结构单元拆书这件事传统做法是编辑或作者自己读完全文然后按照“主线、支线、人物弧光、冲突节点”做笔记。换成AI来做核心问题不是“AI能不能读懂”而是“你让它按什么规则拆”。如果不给规则大模型会自由发挥拆出来的东西今天像语文课段落大意明天像豆瓣书评后天像出版提案。智能拆书的第一步是定义输出格式。我在实际使用中会先让模型输出一个特定结构的JSON而不是自然语言长文。原因很简单JSON有明确的键值约束后续可以直接喂给其他流程或存进数据库。以下是一个最小可用的拆书提示词模板适合处理章节级内容。system_prompt 你是一位经验丰富的网文编辑。请按照以下结构拆解给定的小说章节 1. main_plot: 本章主线事件限40字以内 2. sub_plot: 本章出现的支线线索如果没有写null 3. character_change: 本章主要人物的状态或关系变化限60字以内 4. conflict: 本章的核心冲突点限30字以内 5. hook: 章节结尾是否留下钩子值为true或false 要求只输出JSON不要输出任何解释。 这里的关键是把“拆书”从开放式问答变成结构化抽取。main_plot和sub_plot区分了主线和支线character_change强制模型关注人物变化避免它只复述情节hook是布尔值用于后续判断章节是否适合作为断更点或付费点。这套结构一旦固定下来同一本书的每章输出就具有可比性你可以用脚本统计全书的主线密度、钩子频率甚至画一张人物关系变化表。但要注意拆书不仅仅是输出JSON。真正有价值的拆书还需要对全书做中观层面的拆分——比如识别“三幕结构”或“黄金三章”。这部分不能靠单次调用而是要分段处理。常见做法是先把全书按每3-5章切块做一次粗拆再对粗拆结果做一次汇总拆解。两次提示词的差异在于第一次强调的是“局部事实”第二次强调的是“全局结构”。2.2 生成书名与简介提示词模板和参数怎么定生成书名和简介看起来是一件小事却是很多AI写作工具做得最差的部分。问题在于模型默认倾向于生成“漂亮但空泛”的标题比如《星海征途》《命运之轮》。这些标题放一百本书上都能用唯独不像你手里这本书的专属书名。要解决这个问题提示词里必须注入这本书的独有元素。我一般会构造这样一个输入用一句话交代核心设定用几个关键词点出主角身份与目标然后让模型在限定风格内产出候选标题。下面是一段带参数的生成代码。def generate_book_metadata(core_concept, protagonist, genre, temperature0.9, top_p0.95): user_prompt f 核心设定{core_concept} 主角身份{protagonist} 类型{genre} 请基于以上信息生成10个小说书名候选。 要求 - 每个书名不超过12个字 - 至少3个书名包含主角的职业或身份特征 - 至少2个书名包含核心设定中的独特元素 - 避免使用之、传、录等烂大街字眼 输出格式纯列表每行一个书名。 response call_llm( system_prompt你是资深出版编辑对网文市场和读者心理有敏锐判断。, user_promptuser_prompt, temperaturetemperature, top_ptop_p ) return response注意这里把temperature调到了0.9因为书名属于“低约束高发散”任务。如果为了追求稳定把温度设成0.2模型会反复生成相似的保守选项失去候选的意义。而简介则相反应该用独立的提示词生成且温度建议控制在0.6到0.7之间——简介要吸引人但不能偏离故事内容太远。生成简介还有一个容易被忽略的细节必须先把拆书得到的人物关系、核心冲突作为上下文喂给模型而不是直接让它“写一份简介”。没有上下文的简介无论润色多少遍都是空壳。所以前面拆书环节产出的JSON在这里就派上了用场。把main_plot、character_change、conflict拼接成一段摘要再让模型在这个摘要的约束下写简介你会发现生成结果立刻变得具体能让人一眼看出这是哪本书的介绍。3. 正文润色的提示词管理如何把零散的prompt变成可维护的资产3.1 提示词管理的三个维度场景、版本、变量很多人写提示词是“用到哪个写哪个”今天在聊天界面里敲一段明天复制到别的地方改几个字继续用。短期内没问题但一旦你同时维护多本书、多种风格就会开始混乱同一个“动作描写”的需求可能同时存在三个版本分别散落在聊天记录、备忘录和某个txt文件里。这时候最需要的不是更好的提示词而是提示词管理。我把提示词管理拆成三个维度场景、版本、变量。场景指的是这条提示词服务于哪个创作环节——是拆书、取名、简介、润色还是对话生成。版本指的是同一场景下的不同风格或迭代记录——比如“润色-简约版”“润色-华丽版”“润色-2025-04-11修复版”。变量指的是提示词中可替换的占位符比如书名、角色名、世界观背景。一个实用的做法是把提示词组织成以下结构的目录prompts/ ├── book_name/ │ ├── v1_default.txt │ ├── v2_trendy.txt │ └── config.json ├── intro/ │ ├── v1_default.txt │ └── v2_focus_conflict.txt ├── polish/ │ ├── v1_general.txt │ ├── v2_no_dialogue.txt │ └── v3_short_sentence.txt └── decompose/ ├── v1_json_strict.txt └── v2_chapter_summary.txt每个txt文件里写的是这一条提示词的完整内容包括系统提示词和用户提示词模板其中可变量的位置用{book_name}、{character_name}这类占位符标记。config.json里记录每条提示词对应的参数组合比如温度、top_p、max_tokens。这样做的最大好处是你可以随时比较“同一个需求两个版本的效果差异”而不是全凭记忆猜测。3.2 用Shi.zip里的资源组织一套可复用的提示词工作区标题里的Shi.zip从命名习惯来看大概率是一个打包好的资源文件——里面可能装着预设的提示词模板、拆书规则、样例数据或者是某个特定需求的配置集。这里不臆测内容本身但你要建立的一个基本认知是zip不仅是压缩格式更是提示词资产分发的最佳载体之一。一个zip包可以把一整套提示词工作区完整保留下来包括目录结构、配置文件、示例输入输出换电脑或交付给团队时解压即用。我见过很多人不愿意用zip理由是“解压麻烦、容易乱码”。但zip的好处是它把多个文件的依赖关系固化在了一起。比如一个拆书工作区里面包含拆书提示词、输出JSON的schema定义、校验脚本、README说明这四件事缺一不可。如果只是零散发送接收方很难知道哪个文件配哪个脚本。打包成zip后整个工作区的完整性才有保障。Shi.zip这类资源落地方式就是解压后把它当成一个独立工作区不要拆散放到别的目录里。mkdir -p ~/novel_workspace unzip Shi.zip -d ~/novel_workspace tree ~/novel_workspace解压后你要做的第一件事不是看提示词写了什么而是查看文件结构和配置文件。如果里面有一个类似settings.json的文件先确认它是否指向了正确的模型接口和参数路径。如果资源里有多个版本的提示词花十分钟通读一遍把“明显过时”或“与你需求不符”的版本标记出来但不要直接删除——因为你不知道后面会不会某个奇怪的需求又需要它。这里还有一个容易踩的坑zip包里的文件可能在解压后出现编码问题。中文书名、中文提示词如果是在Windows上压缩的默认可能是GBK编码而Linux或macOS上解压后直接读取会乱码。后面我会专门讲这个问题的排查方法这里先提一句拿到Shi.zip后第一件事是检查文本文件能否正常读取而不是急着跑示例。4. 搭一套能跑起来的AI小说创作助手最小落地路径4.1 环境与选型大模型API、本地模型、提示词管理脚本要真正把这套工作流跑起来你需要三样东西一个大模型推理入口、一段用来调度提示词的脚本、以及一份结构化的提示词工作区。大模型入口可以选商用API也可以选本地部署的开源模型。两者的取舍很实际商用API效果稳定、免维护但涉及敏感文本时你可能不希望内容出本地本地模型隐私性好但显存要求高、推理速度慢。如果只是个人创作助手我建议先用商用API把流程跑通等确实验证了效果再考虑迁移到本地。这里有一个容易被忽略的点提示词管理脚本不需要一开始写得非常复杂。很多人看了一些框架Demo后想直接上一套智能体系统有工具调用、有记忆机制、有路由规划。对于小说创作助手来说这些是后续的事。第一版只需要一个能读取提示词模板、替换变量、调用模型接口、保存结果的脚本就够了。4.2 用Python写一个拆书润色的命令行工具下面这个脚本是我会做的第一版工具核心逻辑从命令行读取章节文本调用拆书提示词得到JSON结构再调用润色提示词对指定段落进行改写。注意代码里所有模型调用都做了函数抽象方便你替换成不同的API或本地服务。import json import re from pathlib import Path def load_prompt(template_name: str, variables: dict) - str: 从prompts目录加载提示词模板并替换变量 template_path Path(prompts) / f{template_name}.txt content template_path.read_text(encodingutf-8) for key, value in variables.items(): content content.replace({ key }, str(value)) return content def call_llm(system_prompt: str, user_prompt: str, temperature: float 0.7, top_p: float 0.9, max_tokens: int 2048) - str: 模型调用接口这里用占位函数替代实际使用请接入OpenAI-compatible API或本地模型服务 # 伪代码request build_request(...) # response http_post(request) # return response[choices][0][message][content] pass def decompose_chapter(chapter_text: str) - dict: 拆书返回章节的结构化信息 system_prompt load_prompt(decompose_v1, {}) user_prompt f请拆解以下章节内容\n\n{chapter_text} raw_output call_llm(system_prompt, user_prompt, temperature0.2, top_p0.8) # 清理输出中的markdown围栏 raw_output re.sub(rjson\s*, , raw_output) raw_output re.sub(r, , raw_output).strip() return json.loads(raw_output) def polish_paragraph(paragraph: str, style: str v1_general) - str: 润色正文按指定风格模板对段落进行改写 system_prompt load_prompt(fpolish_{style}, {}) user_prompt f请润色以下段落保持原意不变\n\n{paragraph} return call_llm(system_prompt, user_prompt, temperature0.65, top_p0.9)拆书函数里我把温度设成0.2因为结构化抽取任务需要的是稳定不是发散。top_p设成0.8进一步限制候选词范围尽量避免JSON格式被打破。润色函数温度0.65保留一定的表达变化但又不至于偏离原意。这段代码里最关键的是load_prompt函数——它从文件系统加载提示词模板并统一替换变量。这样一来你的提示词修改不需要动代码只要改txt文件即可这对后续调整非常有价值。4.3 参数说明温度、top_p、max_tokens、system prompt怎么调这四个参数是让同一个提示词在不同场景下产生不同效果的杠杆。先说温度。温度控制输出的随机性0表示每次尽量取最高概率的token1表示更大的不确定性。我在拆书、抽取类任务中用0.2-0.3在取名、创意类任务中用0.9在润色、改写类任务中用0.6-0.7。这个区间不是拍脑袋定的而是来自对任务风险度的判断拆书拆错了会误导后续全部流程必须压低随机性取名本来就是寻找意外惊喜低温度只会让结果平平无奇。top_p是核采样参数它控制候选token的累计概率阈值。比如top_p0.9意味着只从概率累计到90%的那些token里抽选。它的效果和温度有重叠但不等同。我一般会同时调节两者而不是只动一个。如果一条提示词总是输出“官方腔”我会尝试把top_p从0.95降到0.85比单纯调温度更有用。max_tokens决定了模型最多生成多少token。这里有个常见误区有人为了节省成本把max_tokens设得刚刚好结果长章节润色时输出被硬生生截断。我一般给润色任务设2048给拆书任务设1024如果单章超过4000字拆书要分段调用不要让一次调用处理太长的文本。system prompt的调参逻辑和上面三个参数完全不同。系统提示词的任务是设定模型的行为边界它越清晰后续三个参数越有效。一个差劲的system prompt是“你是一个小说编辑”一个合格的system prompt是“你是一个中文网文编辑擅长识别爽文节奏与人物弧光输出时严格遵循给定JSON结构不允许额外解释”。写system prompt时我会把“禁止做什么”也写进去比如“不要输出与JSON无关的任何内容”这些约束比“请你注意”这种模糊表达有效得多。5. 避坑与常见问题提示词越写越长、输出不听话、zip资源加载失败5.1 现象模型总把润色写成改写角色设定全丢了你让助手润色一段对话结果它不仅改了措辞还悄无声息地让主角的性格变得面目全非甚至把原文里埋的伏笔给删了。这个问题的核心在于润色提示词没有定义“可修改”和“不可修改”的边界。模型天生倾向于“权利最大化”你不限制它它就默认什么都可动。解决办法是在润色提示词中显式声明不可变项。我通常会在提示词末尾加一段约束“以下内容不可改变角色姓名、身份、人物关系、关键道具、情节因果逻辑禁止增加原文不存在的设定禁止删除任何影响后文的细节。”每一条都要具体不要用“尊重原著”这种模糊话。修改后你会发现模型仍然会调整措辞但它不再自作主张地给主角添一段黑暗过去。5.2 现象zip包里的提示词文件中文乱码从网上下载的Shi.zip或同事发来的zip资源包解压后打开里面的提示词txt文件中文全变成乱码。这在Linux和macOS上尤其常见。原因是Windows上用压缩软件打包时中文文件名和内容通常使用GBK编码而Unix类系统默认使用UTF-8zip规范本身又对编码支持不统一导致解压工具识别错乱。解决方式分两步。第一步是解压时指定编码很多工具支持-O参数unzip -O gbk Shi.zip -d ~/novel_workspace如果unzip不支持该参数可以用7z替代。第二步是检查解压后的文件编码再用iconv转码file prompts/decompose_v1.txt iconv -f gbk -t utf-8 prompts/decompose_v1.txt prompts/decompose_v1_utf8.txt这里还要提醒一个进阶坑zip伪加密。有些zip包看起来需要密码才能解压但实际上只是标志位被改过文件数据本身并没有加密。如果你遇到一个标注加密但来源可信的资源包可以先尝试无密码解压或者用工具检查实际加密状态。当然这只针对你自己有权限处理的资源不要抱着“破解”的心态去处理他人的加密包。5.3 现象拆书结果不稳定同一本书两次结果差很远同一段章节上午拆出来主线是“主角寻宝”下午拆出来主线是“主角复仇”后者是因为你补了一句“请仔细分析人物动机”结果模型的重心彻底偏移。这不是模型发疯而是提示词里的“二义性”在温度浮动下被放大了。稳定拆书结果有三个手段。第一把温度调到0.1-0.2这个区间下模型输出基本可复现。第二把输出格式从纯文本切换成JSON并在提示词中给出一个样例。第三在用户提示词末尾固定追加一句“严格按照以上格式输出不要补充任何额外信息”。特别注意“额外信息”这四个字模型非常吃这一套。如果做了以上调整仍然不稳定问题可能出在输入文本长度上。章节过长时模型对开头的记忆淡漠末尾又占据了主要注意力。这时候建议按2000-3000字切片分片拆解后再合并。把拆书任务变成分片处理虽然调用次数变多了但结果质量可控得多。5.4 现象把系统提示词塞满后输出反而变差很多人以为提示词越详细越好于是把角色设定、世界观、写作风格、禁止事项、示例统统塞进system prompt。结果模型开始“过度遵守”输出变得僵硬甚至把一些无关紧要的规则也当成创作红线。比如你只是让助于别用“流光溢彩”这个成语它连“光彩”都不敢写了。实际上系统提示词的长度与指令遵循能力并不是线性关系。越长的system prompt权重越分散核心约束反而被稀释。我的经验是系统提示词控制在300字以内把那些“较长的背景设定、详细的例子”挪到用户提示词里。因为用户提示词的内容在推理时同样参与注意力计算但它的角色定位更接近“本次任务的具体素材”。如果你的Shi.zip资源包里有很长的提示词文件记得做一次“裁剪手术”把设定部分和指令部分拆开而不是整段抄用。6. 收尾用版本化提示词和回归测试养一套自己的助手当你把拆书、取名、简介、润色都跑通之后真正的分水岭不是第一次成功输出而是后续持续调整提示词的过程中如何不把之前已验证的效果弄坏。我给自己的硬性习惯是每一条提示词的每次修改都必须保存一个新版本而不是覆盖旧版本。目录结构里那些v1_default、v2_trendy就是干这个用的。同时我会为每个场景准备一组“标准测试输入”——比如固定三个小说片段、两个段落样本、一个书名需求。每次改完提示词先跑一遍这组测试凡是输出明显不如上一版的地方立刻回滚。这个习惯的来源是一次惨痛教训我曾经为了优化动作描写把润色提示词从“保持简短句”改成了“多用动词”然后顺手覆盖了原文件。三天后我忘掉了具体改动只记得“最近润色效果不对”却拿不出旧版做对比。后来我用了git管理整个工作区把prompts/目录纳入版本控制配合上述回归测试才算真正摆脱了“黑匣子式改提示词”的状态。如果你也拿到了一份像Shi.zip这样的资源包我的建议是这样的先解压、转码、通读把它当成一个起点而不是标准答案跑通最小流程后再逐条调整提示词每调一条都做对比记录用git或简单的文件版本备份兜底。这套做法不依赖任何特定工具只需要你有一个“不覆盖旧文件”的意识。AI小说创作助手的价值只有在提示词成为你可控、可复盘的资产之后才真正体现出来。希望这套落地路径能帮到你让你少走几趟拆书拆歪、润色润废的弯路。本文还有配套的精品资源点击获取