企业官网建设流程全解析

简介：一套功能完整的人工智能小说创作助手项目，基于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, temperature=0.9, top_p=0.95): user_prompt = f""" 核心设定：{core_concept} 主角身份：{protagonist} 类型：{genre} 请基于以上信息，生成10个小说书名候选。 要求： - 每个书名不超过12个字 - 至少3个书名包含主角的职业或身份特征 - 至少2个书名包含核心设定中的独特元素 - 避免使用"之"、"传"、"录"等烂大街字眼 输出格式：纯列表，每行一个书名。 """ response = call_llm( system_prompt="你是资深出版编辑，对网文市场和读者心理有敏锐判断。", user_prompt=user_prompt, temperature=temperature, top_p=top_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(encoding="utf-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, temperature=0.2, top_p=0.8) # 清理输出中的markdown围栏 raw_output = re.sub(r"```json\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(f"polish_{style}", {}) user_prompt = f"请润色以下段落，保持原意不变：\n\n{paragraph}" return call_llm(system_prompt, user_prompt, temperature=0.65, top_p=0.9)

拆书函数里，我把温度设成0.2，因为结构化抽取任务需要的是稳定，不是发散。top_p设成0.8进一步限制候选词范围，尽量避免JSON格式被打破。润色函数温度0.65，保留一定的表达变化，但又不至于偏离原意。这段代码里最关键的是load_prompt函数——它从文件系统加载提示词模板并统一替换变量。这样一来，你的提示词修改不需要动代码，只要改txt文件即可，这对后续调整非常有价值。

4.3 参数说明：温度、top_p、max_tokens、system prompt怎么调

这四个参数是让同一个提示词在不同场景下产生不同效果的杠杆。先说温度。温度控制输出的随机性，0表示每次尽量取最高概率的token，1表示更大的不确定性。我在拆书、抽取类任务中用0.2-0.3，在取名、创意类任务中用0.9，在润色、改写类任务中用0.6-0.7。这个区间不是拍脑袋定的，而是来自对任务风险度的判断：拆书拆错了会误导后续全部流程，必须压低随机性；取名本来就是寻找意外惊喜，低温度只会让结果平平无奇。

top_p是核采样参数，它控制候选token的累计概率阈值。比如top_p=0.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-8，zip规范本身又对编码支持不统一，导致解压工具识别错乱。

解决方式分两步。第一步是解压时指定编码，很多工具支持-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小说创作助手的价值，只有在提示词成为你可控、可复盘的资产之后才真正体现出来。希望这套落地路径能帮到你，让你少走几趟拆书拆歪、润色润废的弯路。

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