企业官网建设流程全解析

简介：这是一款基于人工智能与提示词技术的小说创作辅助工具，可应用于智能拆书、书名与简介生成、正文润色、错别字修正等写作场景，面向职业作家、写作爱好者以及希望研究AI写作技术的开发者，帮助用户显著提升创作效率。资源包共52个文件，包含17个Python脚本、13个JavaScript文件、10张PNG截图、TXT/MD说明文档及HTML页面等，整体压缩包约3.48MB，结构清晰，便于本地运行与二次开发。目前已有52人学习下载。通过它可了解ChatGPT、Claude、Gemini、文心一言等多模型接入的具体实现，掌握提示词管理、小说框架生成、内容拆分等完整流程；附带的教程文档、思维导图和附赠资源还能进一步辅助学习，适合作为AI写作工具研发或小说创作效率提升的参考。

1. AI小说创作助手，解决的不只是“让AI替你写”

如果你写过网文，一定经历过这种晚上：第一章三千字改了三遍，人物动机拧成麻花，新建文档比写正文还多。这时候你打开一个对话框说“帮我写”，模型确实能吐两千字，但读起来像材料汇编，主角说话像客服。AI小说创作助手这类工具，本质是把“用AI写小说”从碰运气变成流水线：基于大模型做生成，靠提示词管理把风格、设定、输出格式固定下来，再通过智能拆书、书名简介生成、正文润色这些具体功能，把“灵感→初稿→可发布”的链条压缩到几分钟。适合兼职作者、想快速验证脑洞的新手，以及要给编辑交样章的老写手。这篇笔记就按实际用的顺序，把原理、参数和坑一次讲完。

2. 大模型与提示词工程：AI小说创作助手的地基

2.1 为什么小说生成必须走提示词工程，而不是开个对话框就写

很多第一次用这类工具的人会问：大模型对话能力已经很强，为什么还要多做一层提示词管理？你把一个问题丢进对话框，模型能答，但小说不是一次问答，是几十万字的长程生成。

直接对话的问题出在“语境漂移”上。你让模型接着上一段写，它会越写越顺滑，但主角的口吻开始像解说员，环境描写开始堆成语，三章之后人物关系甚至可能对不上。这不是模型变笨了，而是对话式交互没有把“作者意图”固化成约束。提示词工程要做的，就是把“我想要一部什么样的作品”翻译成模型能稳定遵循的指令结构。

具体到小说场景，提示词工程至少要管住四件事：风格锚点（是冷峻还是话痨）、角色设定（每个角色的语气和禁忌）、结构指令（这段是铺垫还是高潮）、输出格式（对话、旁白、心理描写的排版）。这四样在对话框里靠复制粘贴撑不过三章，在提示词管理里则是结构化字段，每次生成都原样注入。

顺便说一句，这类AI小说创作助手背后一般接的是通用对话大模型或专门微调过的写作模型，但不管接谁，提示词工程都是决定成品像不像“人写的”的关键。模型是引擎，提示词才是方向盘。

2.2 选型：通用大模型、写作专用模型与本地部署怎么选

这个工具到底该接哪种大模型，直接决定生成质量、成本和你能不能跑起来。别一上来就追最强模型，先看你的写作场景吃哪头。

我一般建议：纯网文作者先试写作辅助模型，它天生带“爽点”和“对话流”的偏置，润色时少操一半心。如果你要处理长篇（几十万字的小说），通用大模型的上下文窗口和价格会是瓶颈，别等到账单吓人才换。本地部署适合的是团队或对数据敏感的人，个人作者折腾显卡不太值。

选型时记住一个下限：模型的中文语感不能弱，生成结果不要有明显的“翻译腔”。这类问题没法靠提示词补救，属于模型本身的底子。

2.3 一个最小可跑的提示词模板：系统指令、风格锚点与输出约束

在实际搭AI小说创作助手时，我会把提示词拆成三块：系统指令、风格锚点、输出格式。下面这个JSON模板是润色功能的最小骨架，你复制下来就能当起点。

{ "system": "你是一位资深网文编辑，擅长商业类型小说。你的任务是修改用户提供的章节，保留原有情节和人物行为逻辑，只优化表达。", "style_anchor": { "叙述视角": "第三人称限知，不写主角视角之外的内心活动", "句式偏好": "短句为主，对话不追求书面语，要有口语节奏", "禁用表达": ["窗外", "与此同时", "不禁", "微微一笑"], "节奏要求": "段落间要有动作、有停顿，不要连续三句话都在描述环境" }, "output_format": { "返回内容": "只返回润色后的正文，不要返回任何分析或解释", "章节长度": "与原章长度接近，浮动不超过10%", "对话格式": "对话独立成行，使用破折号引出" } }

这段模板的关键，在于把“文风”从玄学变成字段。你不需要写“请写得好看一点”，而是用“禁用表达”和“句式偏好”这类可执行的约束，让模型知道边界在哪里。

调用时，把这段JSON作为system_prompt注入，把待润色的章节内容作为user_prompt传入。Python侧的最小代码长这样：

import json import requests def run_llm(system_prompt, user_prompt, api_key, temperature=0.7): url = "https://api.example.com/v1/chat/completions" # 替换为你的服务商地址 headers = { "Authorization": f"Bearer {api_key}", "Content-Type": "application/json" } payload = { "model": "writing-model", # 按实际可用模型名替换 "messages": [ {"role": "system", "content": json.dumps(system_prompt, ensure_ascii=False)}, {"role": "user", "content": user_prompt} ], "temperature": temperature, "max_tokens": 1800 } resp = requests.post(url, headers=headers, json=payload, timeout=120) resp.raise_for_status() return resp.json()["choices"][0]["message"]["content"]

这里有两个参数直接影响生成质量。temperature控制随机性，润色场景我一般设在0.7到0.8之间，太低会机械重复，太高会放飞叙事。max_tokens按章节长度给，单章3000字对应的生成量建议设到1800左右，宁可多调一次，不要让它在章节中间截断。

3. 提示词管理：把散落的灵感变成可复用的资产

3.1 提示词管理解决的三个痛点：散落、漂移、难复用

AI小说创作助手里“配备完善的提示词管理功能”这句话，实际使用中对应三个非常具体的痛点。

第一是散落。你昨天写好的角色设定提示词贴在备忘录里，今天用的润色模板在另一个文件里，明天想给新书生成简介又得重新写。提示词管理把所有的提示词集中到一个库里，按类型组织，随取随用。

第二是漂移。同一个角色，你第一次描写用“冷峻寡言”，第二次提示词里写“说话带刺”，模型就会把角色写成两个人。提示词管理里的角色模板是统一入口，所有章节生成都从这里注入，就不会出现人格分裂。

第三是难复用。拆书模板敲了一遍，换一本书又要重写。成熟的做法是把提示词做成带变量的模板，只替换小说名和设定，结构不变。这本质上是在建你自己的提示词资产库，写书越多，资产越厚。

3.2 结构化存储与变量注入：作者视角、主角设定、场景状态分开存

提示词管理功能落地时，最忌讳把所有内容塞进一个大文本里。我习惯在本地保持这样一套目录结构：

prompts/ ├── roles/ # 角色设定模板 │ ├── 主角.json │ └── 配角.json ├── scenes/ # 场景提示词 │ ├── 打斗.json │ ├── 谈判.json │ └── 感情戏.json ├── styles/ # 风格锚点库 │ ├── 都市冷硬.json │ └── 古风言情.json ├── pipelines/ # 组合式工作流 │ ├── 拆书.json │ ├── 书名生成.json │ └── 润色.json └── variables/ # 每本书的变量值 └── 当前作品.json

这样做的好处是：风格锚点管“文风”，角色模板管“人设”，场景提示词管“桥段”，互不污染。生成时通过变量注入，把三块拼成一次调用的完整提示词。

下面是加载模板并注入变量的示例：

import json from copy import deepcopy def load_and_fill(template_name, variables, prompts_dir="prompts"): with open(f"{prompts_dir}/pipelines/{template_name}.json", encoding="utf-8") as f: template = json.load(f) filled = deepcopy(template) # 将变量注入到模板里的 {占位符} for key, value in variables.items(): placeholder = "{" + key + "}" # 递归替换所有字符串里的占位符 walk_and_replace(filled, placeholder, value) return filled def walk_and_replace(obj, placeholder, value): if isinstance(obj, dict): for k, v in obj.items(): if isinstance(v, str) and placeholder in v: obj[k] = v.replace(placeholder, value) else: walk_and_replace(v, placeholder, value) elif isinstance(obj, list): for i, v in enumerate(obj): if isinstance(v, str) and placeholder in v: obj[i] = v.replace(placeholder, value) else: walk_and_replace(v, placeholder, value) # 使用示例 variables = { "主角名": "陈默", "主角性格": "沉默寡言，观察力极强", "当前场景": "废弃工厂谈判" } pipeline = load_and_fill("润色", variables) user_prompt = "请按模板处理以下章节：\n" + chapter_text

参数说明：模板文件名对应pipelines目录下的JSON，variables提供本次作品的主角名、性格、场景状态。deepcopy是为了防止反复注入时污染原始模板文件，这是多人协作时最容易踩的坑。占位符统一用{主角名}这种大括号格式，和JSON语法兼容，替换逻辑也简单。

3.3 标签体系与版本管理：几百条提示词之后靠什么找

提示词库一旦超过一百条，就得靠标签而不是靠记忆。我不建议建复杂的分类树，扁平标签加多属性检索更实用。每个提示词打三个维度：

比如你要给一本“都市悬疑”书润色，搜索条件就是润色 + 都市 + 悬疑，命中一个模板组合，再替换变量即可。这套逻辑不需要开发成复杂系统，一个JSON文件加几行Python过滤就够。

版本管理这块，很多人忽略。提示词模板改了一版，效果反而变差，想回滚却找不回旧版。我用的是最土的办法：每个模板文件头部保留version字段，改动前复制一份带日期的备份。脚本生成时先读version，写到日志里，这样哪个章节用哪个版本的提示词，事后可查。不要小看这一步，长篇写作中风格前后不一致，多半就是版本乱了。

4. 智能拆书与书名简介生成：从结构里找灵感

4.1 智能拆书拆的是什么：结构、节奏与人物关系

智能拆书这个功能，说白了就是让大模型当你的“读稿编辑”，把一本完本小说拆成可复用的结构数据。它的输入是一整本小说的文本，输出是一份结构报告，通常包括：主要人物关系网、剧情主线拆段、高潮节点的位置与触发条件、每卷的节奏曲线、伏笔与回收的对应关系。

拆书的目的不是“分析名著”，而是让你看到“别人是怎么把故事撑起来的”。比如你卡在中期情节疲软，拆一本同类型完本，看看它在第40章到第60章之间安排了什么事件，密度如何，就能照猫画虎地给你的作品补上节奏。

拆书的质量取决于两个东西：模型的上下文能力，和提示词里对“结构”的定义。如果提示词只写“分析这本书的结构”，模型会给你一堆正确的废话。必须明确要求输出“人物关系表”“高潮节点清单”“每万字事件密度”这类可读的结构字段。

4.2 分卷拆书：代码示例与三个影响结果的参数

长篇小说不可能一次性塞进模型，常见做法是分卷拆书：按章节切段，分批调用模型，最后合并成一份完整报告。下面是我常用的切分思路：

def split_chapters(text, min_chars=3000, overlap_chars=200): """ 将整本小说切成适合模型处理的分段。 min_chars: 单段目标长度，按模型上下文窗口打折后设定 overlap_chars: 相邻段重叠字数，防止章节边界信息丢失 """ paragraphs = text.split("\n\n") chunks = [] current = "" for para in paragraphs: if len(current) + len(para) < min_chars: current += "\n\n" + para else: chunks.append(current) current = para # 边界重叠：取上一段末尾若干字符粘到下一段开头 result = [] for i, chunk in enumerate(chunks): if i == 0: result.append(chunk) else: overlap = chunks[i-1][-overlap_chars:] result.append(overlap + "\n\n" + chunk) return result

调用拆书模型时，我一般把temperature设到0.3以下。拆书是结构化任务，不需要创意的随机性，温度高了会编造书中不存在的情节。另外两个参数是max_tokens和top_p。拆书输出的结构报告尽量一次生成完整，max_tokens给足；top_p保持默认0.9即可，这个参数在拆书场景影响不大，真正影响质量的是分段长度。

分段长度上，单段不要超过模型上下文窗口的三分之一。因为拆书报告本身也要占输出长度，输入占太多，输出的结构字段会被截断。我用3000字作为默认分段，超过5000字的时候，后半段的拆书结果开始出现“只概括不分析”的偷懒现象。

4.3 从拆书报告生成书名与简介：约束条件与示例模板

拆完结构后，书名和简介的生成就有据可依了。智能生成书名不是让模型瞎编几个词，而是从拆书报告里抽取核心卖点，再按类型规则组合。

书名生成的提示词模板里，我会强制两类约束：一是题材必须出现在书名里或给人明确类型预期，二是字数限制在8到14字之间，太短没信息量，太长不像网文。简介的约束更细，一般控制在150到250字，要求第一句抛悬念、第二段交代设定、最后一句给期待感。

麻烦的是模型更容易把简介写成产品说明书。解决方法是把拆书报告里的“高潮节点”直接作为素材注入简介模板，让模型把最刺激的情节点改写成悬念句。下面这个JSON是简介生成的最小模板：

{ "system": "你是一位图书编辑，擅长写商业小说简介。只输出简介正文，不输出分析。", "inputs": { "类型": "都市异能", "核心卖点": "主角能看见他人死亡倒计时，但不能说出来，否则规则反噬", "开篇悬念": "主角在电梯里看见整栋楼的人倒计时都是5分钟", "字数范围": "160到220字", "语气要求": "冷峻、克制，不用感叹号" } }

注意语气要求里明确写了“不用感叹号”，这是针对模型总想煽情的对症下药。简介这东西，感叹号越多越掉档次。如果你遇到的模型屡教不改，就把这个限制写进system层而不是inputs层，system层的指令优先级更高。

5. 全流程常见问题排查：润色参数、zip解压与上下文超限

5.1 两种润色模式：整章重写与逐段打磨

正文润色是这个工具里使用频率最高的功能，但很多人一上来就用错模式。润色至少有两种：整章重写和逐段打磨，适用场景完全不同。

整章重写适合“情节对但表达全垮”的章节。模型拿到整章，按风格锚点重写一遍，效率最高，但风险是模型会顺手改掉你的情节细节。逐段打磨适合“大部分能看，个别句子刺眼”的情况，改得少，保留原味，但耗时长、调用次数多。

我自己的习惯是：新章节先整章重写，再对主角的对话单独精修一次。这两个步骤拆开来，比一次调用让模型“既改表达又管对白”稳定得多。

5.2 润色调用示例与四个必调采样参数

小说润色不是把prompt写好就完事，模型推理参数才是真正决定“像不像人写的”的那只手。下面是润色调用的核心代码：

def polish_chapter(chapter_text, style_anchor_text, api_key): system_prompt = f""" 你是一名资深网文编辑。请按以下风格要求润色给定章节： 保留原情节、人物行为与对话内容，只优化表达。 风格要求：{style_anchor_text} 只输出润色后的正文。 """ payload = { "model": "writing-model", "messages": [ {"role": "system", "content": system_prompt}, {"role": "user", "content": chapter_text} ], "temperature": 0.75, "top_p": 0.9, "presence_penalty": 0.5, "frequency_penalty": 0.3, "max_tokens": 1800 } # 调用逻辑与前文相同，省略 return run_llm(payload)

这里的presence_penalty和frequency_penalty是润色场景最容易忽略的两个参数。很多人遇到“AI味”的第一反应是换大模型，其实先调这两个参数更实际。

如果润色出来的文本满篇“然而”“不禁”“仿佛”，把frequency_penalty往上加到0.5，同时把“不禁”“仿佛”写进风格锚点的禁用表达里。这比单纯调参好用，因为是根据你的具体文本定制的。

5.3 排障一：Shi.zip解压乱码、路径异常导致模型加载失败

现象：拿到AI小说创作助手的压缩包Shi.zip，解压后运行脚本，日志报错提示找不到模型文件或配置文件路径为空。

原因：这个工具包是多层目录结构，压缩包里的中文文件名在Windows默认解压工具下容易出现乱码，或者被安全软件拦了部分文件。最常见的是解压工具把嵌套目录压平了，脚本里relative_path找不到目标。

解决：用7-Zip按原始路径解压，不要用系统自带的“全部解压”。解压后检查第一层目录下是否有app.py或main.py这类入口文件，如果没有，说明解压时目录层级丢了。重新解压一次，并确认路径中没有空格和特殊符号。再把脚本里所有读取路径改成相对路径而不是绝对路径，换一台电脑也不至于翻车。

这个坑看起来低级，但在下载类工具包里是最常见的第一道门槛。先排除它，再谈功能。

5.4 排障二：拆书后半段格式崩塌、输出越来越像流水账

现象：同一本书，前半部分的拆书报告有结构、有事件密度分析，后半部分开始退化成“第几章到第几章讲了什么事”的流水账，人物关系也丢失了。

原因：模型上下文超限。长文本拆书时，前面的分析结果累积到上下文中，后面的输入挤占了输出空间，模型就开始偷懒，只做摘要不做分析。另外，分段太长也会让每段的信息密度下降，模型分不清主次，只好平均用力。

解决：把拆书分段从3000字下调到2000字，同时给每段拆书任务增加一个“本节重点”参数，明确告诉模型这一段重点看什么。比如循环时轮流指定“关注人物关系变化”“关注冲突升级”“关注伏笔”。不要把整本书一次拆完，拆完一卷就把报告存下来，清空上下文再拆下一卷。这一步是“后悔药”式的调整，不用推翻重来，但能明显改善后半段质量。

5.5 排障三：润色后“AI味”太重、角色口吻千篇一律

现象：润色过的章节读起来通顺，但主角、反派、配角的对话全部一个腔调，且频繁出现“然而”“在这时”之类的连接词。

原因：采样参数和风格锚点都没到位。对话口吻千篇一律，往往是temperature太低，模型倾向于生成“最安全”的表达；连接词高频重复，则是frequency_penalty没起作用。另外，你会把角色的说话习惯写进风格锚点吗？如果没写，模型只会按默认的“普通话书面语”生成，所有角色当然一个样。

解决：把temperature回到0.75，frequency_penalty调到0.4以上。然后在风格锚点里为每个主要角色单独加一条“对话特征”，例如主角“说话短、少用成语”，反派“爱用反问句”。润色时把当前章节出现的角色名单及其对话特征注入到system里。做完这三步，AI味至少能感觉消失一大半。不用迷信那些降AI率工具，把参数和锚点调正，才是根本。

6. 一套标准验收流程：用一个800字章节检验整条流水线

功能都能跑通之后，还要确认“跑出来的东西能不能用”。我的一套折腾下来的验收流程，固定用一个800字章节做试金石，所以不是每次都要拿全书去测。

这个800字章节我会故意写成带三种缺陷的样本：一段对白干瘪、一段环境描写堆砌、一处情节亮点被淹没。然后依次跑一遍拆书、书名简介生成、正文润色，看三件事。

第一，润色后是否还保留原章节里的情节动作。模型最擅长把“他推开门”改成“他推开那扇沉重的铁门”，但这种扩写未必更好。验收时对比改写前后，动作是否丢失。

第二，对话是否有辨识度。把润色后所有角色的对白单独拉出来，遮住人名，如果你分不清谁在说话，说明角色锚点没生效，这条路子不能用于全文。

第三，AI味检查点。数一下润色后的文本里“然而”“与此同时”“仿佛”“不禁”这四类词的出现频率，如果每千字超过两次，就回到5.5的调参步骤。

我的验收习惯是：新写的章节先用这套流程过一遍，达标了才发出去；不达标的，直接回退上一版提示词，重新调参。宁可多花十分钟跑验收，不要等写到三十章发现风格已经在第八章就崩了。这套流程在几本书上折腾了大半年，是踩坑踩出来的血泪经验，希望帮到你。

本文还有配套的精品资源，点击获取