企业官网建设流程全解析

“风清扬刚继任破落宗门掌门，便强势激活【诸天神宗系统】！开局直接召唤无上大帝老祖坐镇大本营，安全感直接拉满！不仅如此，系统更助他收尽天下逆天神徒”这一句话里，包含的其实不是一个技术项目，而是一套完整的“系统流网文产品需求”：主角设定、初始危机、金手指、长期目标、爽点节奏全都在。如果把它当成需求文档来看，真正值得技术侧讨论的问题就变成了：怎么用当前市面上成熟的大模型工具，把这样一句标题快速拆解成角色卡、世界观设定、章节大纲，并批量生成可继续编辑的稿件？这篇博客我会给出一套可落地的“网文创作辅助系统”搭建思路，包含环境准备、接口设计、批量任务、效果验证和问题排查，适合做内容工具、写网文辅助脚本、做自动化内容管线的读者收藏。

先说结论：这套方案不需要自己训练模型，核心思路是用“提示词模板 + 大模型接口 + 批量任务脚本”组装成一条内容生产流水线。输入一个小说标题或创意方向，输出一套结构化的角色设定、势力设定、章节大纲和正文初稿。整体要解决的问题很实际：AI 生成内容容易飘、角色前后不一致、批量任务容易断、接口调用经常超时。下面按工程化的方式拆开讲。

1. 核心能力速览

这个设计和“诸天神宗系统”里的核心逻辑是一样的：你只需要把一个初始想法丢进去，系统会帮你把后续的“剧情面板”“角色面板”“势力面板”都展开。区别在于，这里的“系统”是代码和提示词，不是金手指。

2. 适用场景与使用边界

这类创作辅助工具适合谁？首先是网文作者，尤其是写系统流、无敌流、宗门流题材的作者，需要快速产出多版本角色设定和章节大纲用来筛选灵感。其次是内容团队，需要批量生成“标题-简介-角色卡-案头设定稿”，这些内容后续还要人工修改。最后是技术同学，他们不写小说，但想研究“结构化提示词 + 批量接口调度”这套通用工程思路。

不适合什么场景？不适合指望模型直接产出可发布成品的场景。大模型生成的长文本存在上下文遗忘、角色语气漂移、情节重复等问题，尤其是超过 3000 字之后，质量下滑很明显。更不适合把生成内容直接商用而不做人工审核，这里涉及两个层面的风险。

第一是版权与授权。小说标题里的“风清扬”是金庸作品中的知名角色名，如果真要写相关小说，必须确认原作品版权状态和平台授权要求，不能默认可以直接使用。更稳妥的做法是改成原创角色名，只保留“老掌门 + 破落宗门 + 召唤老祖”的设定框架。

第二是隐私与内容合规。批量生成角色设定时，不要采集真实人物的姓名、肖像、声音特征。涉及历史人物或现实人物，只能做符合公序良俗的虚构创作。AI 生成内容发布前也要过一遍审核工具，避免生成违规内容。

3. 环境准备与前置条件

整套系统依赖不重，核心环境如下：

• 操作系统：Windows / Linux / macOS 均可。
• Python 版本：3.10 或更高，建议 3.11。
• Python 依赖：requests、fastapi、uvicorn、pydantic，用于批量任务和接口服务。
• 大模型接口：推荐使用支持 OpenAI 兼容协议的服务，可以是云端 API，也可以是本地 Ollama。
• 网络要求：如果调用云端 API，需要稳定网络；如果是本地推理，确保磁盘空间足够存放模型文件。
• 磁盘空间：纯脚本方案不到 100MB；本地模型按模型大小算，7B 模型约 4GB 到 5GB，14B 模型约 8GB 到 10GB。
• 端口准备：FastAPI 默认占 8000，如果被占用可以换 8001、8080 等端口。

本地推理时，显存占用需要按实际模型版本测试。以常见情况来看：

• 7B 量化模型通常需要 6GB 左右显存。
• 14B 量化模型通常需要 10GB 以上显存。
• 如果没有独立显卡，只靠 CPU 跑 7B 模型也可以，生成速度会明显下降。

不过这些数字会因量化方式、上下文长度、并发数变化，不能作为固定结论。更稳妥的判断是：先拉一个最小的量化模型跑通流程，再决定要不要上更大模型。

安装依赖的命令是：

pip install requests fastapi uvicorn pydantic

如果选择本地 Ollama，需要先安装 Ollama 并拉取一个支持 OpenAI 兼容协议的模型，示例：

ollama pull qwen2.5:7b

注意：模型名需要根据你实际拉取的版本替换，不要假设一定存在某个具体模型。

4. 项目结构与启动方式

我建议把它做成一个小型工程，目录结构如下：

novel-studio/ ├── config.json ├── main.py ├── server.py ├── batch_run.py ├── prompts/ │ ├── title_breakdown.txt │ ├── character_card.txt │ ├── world_setting.txt │ └── chapter_outline.txt └── outputs/

配置文件config.json控制模型接口和批量任务参数，是一个通用模板，需要按实际环境替换：

{ "api_base": "http://127.0.0.1:11434/v1", "api_key": "EMPTY", "model": "qwen2.5:7b", "temperature": 0.85, "max_tokens": 2048, "input_file": "./inputs/titles.txt", "output_dir": "./outputs", "max_concurrency": 2 }

如果使用云端 API，把api_base换成服务商提供的地址，api_key换成真实 Key。如果是本地 Ollama，api_key通常填EMPTY即可。

核心调用逻辑写在main.py中，先实现一个最基础的“标题拆解”函数：

import json import requests def load_config(path="config.json"): with open(path, "r", encoding="utf-8") as f: return json.load(f) def call_llm(prompt, config): url = config["api_base"] + "/chat/completions" headers = { "Authorization": f"Bearer {config['api_key']}", "Content-Type": "application/json" } payload = { "model": config["model"], "messages": [ {"role": "system", "content": "你是一个资深网文编辑，擅长拆解小说核心设定。"}, {"role": "user", "content": prompt} ], "temperature": config["temperature"], "max_tokens": config["max_tokens"] } response = requests.post(url, json=payload, headers=headers, timeout=120) response.raise_for_status() return response.json()["choices"][0]["message"]["content"]

然后写一个调用示例，把标题拆解成“主角 / 初始身份 / 金手指 / 初始冲突 / 成长目标”五要素：

if __name__ == "__main__": config = load_config() title = "风清扬刚继任破落宗门掌门，便强势激活【诸天神宗系统】！开局直接召唤无上大帝老祖坐镇大本营，安全感直接拉满！不仅如此，系统更助他收尽天下逆天神徒" prompt = f""" 请对以下小说标题做结构化拆解，输出 JSON 格式，字段包括： title, protagonist, initial_identity, cheat_system, initial_conflict, short_goal, long_goal 标题：{title} """ result = call_llm(prompt, config) print(result)

跑通的判断标准是：终端输出一个完整 JSON，里面字段齐全，没有多余的报错输出。如果模型经常输出 JSON 前后带解释文字，可以在提示词里加一句“只输出 JSON，不要解释”。

启动命令行脚本的方式：

python main.py

如果要用 HTTP 接口对外提供服务，再写一个server.py：

from fastapi import FastAPI from pydantic import BaseModel import main as core app = FastAPI() config = core.load_config() class TitleRequest(BaseModel): title: str task_type: str = "title_breakdown" @app.post("/api/generate") def generate(req: TitleRequest): prompt = f"请对以下小说标题做结构化拆解，输出 JSON。\n{req.title}" try: result = core.call_llm(prompt, config) return {"code": 0, "data": result} except Exception as e: return {"code": 1, "message": str(e)} if __name__ == "__main__": import uvicorn uvicorn.run(app, host="127.0.0.1", port=8000)

启动服务：

python server.py

访问地址为http://127.0.0.1:8000，接口路径为/api/generate。

5. 功能测试与效果验证

这套创作辅助系统至少要测四个核心功能：标题拆解、角色卡生成、世界观设定、章节大纲生成。每个功能都有明确的验收标准。

5.1 标题拆解测试

测试目标是确认模型能识别标题中的主角、金手指和初始冲突。输入素材就用“风清扬”那句标题。预期输出包含protagonist=风清扬、cheat_system=诸天神宗系统、initial_conflict=破落宗门面临生存危机等字段。

判断成功的标准是 JSON 格式合法，字段与标题语义一致。失败常见原因是模型把protagonist识别成“掌门”而不是“风清扬”，或者漏掉金手指。排查时先检查提示词是否明确要求“只输出 JSON”，再检查max_tokens是否太小导致输出被截断。

5.2 角色卡生成测试

测试目标是生成多张互相独立又风格统一的角色卡。我设计提示词模板prompts/character_card.txt，内容大意是“以小说标题为基础，生成 5 个角色卡，每个角色卡包含姓名、身份、性格、口头禅、目标、与主角关系”。

这里最容易出现的问题就是角色同质化。比如生成三个角色都是“沉默寡言、实力强大”，这需要调高temperature，或者修改提示词要求“每个角色的性格必须从不同维度展开，不能出现重复关键词”。批量生成多个版本后，人工挑选最合适的。

5.3 世界观设定测试

测试目标是生成宗门、势力、境界体系等结构。针对“诸天神宗系统”，可以让模型设计：

• 破落宗门前任掌门的失踪原因。
• 诸天神宗系统的激活条件。
• 宗门当前面临的三大外部压力。
• 天地境界体系从低到高的层次名称。

判断逻辑是检查设定之间是否存在自相矛盾。例如前文写“灵气枯竭”，后文又写“无上大帝每日消耗大量灵气”，这类矛盾在长文本里经常出现，人工审核阶段必须处理。

5.4 章节大纲生成测试

章节大纲直接决定模型后续能不能稳定输出正文。可以让模型生成“开局 5 章大纲”，每章包含：章名、核心事件、爽点、结尾钩子。对应到标题里，第一章是“继任掌门 + 激活系统”，第二章是“召唤老祖 + 震慑来敌”，第三章是“立威 + 收第一批神徒”。

预期输出是 5 章之间事件逻辑连续，主角实力提升节奏合理，每章结尾留有悬念。如果大纲出现明显跳剧情，比如第一章刚激活系统，第三章就统一诸天万界，需要降低temperature并给模型限定“实力提升必须按等级循序渐进”。

5.5 长文本正文生成测试

正文生成是压力最大的一环。建议先让模型写第一章初稿，限定 800 到 1200 字。观察角色是否走形、系统播报是否一致、叙事视角是否稳定。这里的稳定是指主角视角不能突然切到反派视角。

如果正文生成质量不行，不一定要换大模型，可以先优化提示词，把第五章大纲中的“核心事件”“爽点”“结尾钩子”直接拼接成正文提示词，效果会明显好于“凭空生成一章”。

6. 接口 API 与批量任务

接口服务写好后，可以用curl快速验证：

curl -X POST http://127.0.0.1:8000/api/generate \ -H "Content-Type: application/json" \ -d '{"title": "风清扬刚继任破落宗门掌门，便强势激活【诸天神宗系统】！", "task_type": "title_breakdown"}'

Python 调用示例：

import requests url = "http://127.0.0.1:8000/api/generate" payload = {"title": "风清扬刚继任破落宗门掌门，便强势激活【诸天神宗系统】！"} response = requests.post(url, json=payload, timeout=120) print(response.json())

批量任务才是真正的关键。所谓“批量”，是把多个标题或角色需求写进titles.txt，脚本自动逐条调用模型接口，并把输出保存成独立文件。

batch_run.py的核心逻辑：

import json import os import time from concurrent.futures import ThreadPoolExecutor, as_completed import main as core def process_title(title, config): prompt = f"请对以下小说标题做结构化拆解，输出 JSON 字段：title, protagonist, cheat_system, initial_conflict, short_goal, long_goal。\n标题：{title}" result = core.call_llm(prompt, config) return {"title": title, "result": result} if __name__ == "__main__": config = core.load_config() with open(config["input_file"], "r", encoding="utf-8") as f: titles = [line.strip() for line in f if line.strip()] os.makedirs(config["output_dir"], exist_ok=True) with ThreadPoolExecutor(max_workers=config["max_concurrency"]) as executor: futures = [executor.submit(process_title, title, config) for title in titles] for future in as_completed(futures): item = future.result() out_path = os.path.join(config["output_dir"], f"{item['title'][:20]}.md") with open(out_path, "w", encoding="utf-8") as f: f.write(item["result"]) print(f"已生成: {out_path}")

批量任务设计要注意三点：

• 并发数不要一次调太高，本地模型一般 1 到 2 并发即可，云端 API 根据服务限额调整，否则容易被限流。
• 每条任务单独写入一个文件，不要所有结果都塞进一个大文件，避免单个文件损坏导致全部丢失。
• 失败任务要重试。简单做法是捕获异常后 sleep 3 秒再重试一次，仍然失败就把标题写入failed.txt，方便二次处理。

7. 资源占用与性能观察

如果使用云端 API，本机资源占用很低，主要关注点是接口延迟、限流、预算。如果使用本地模型，要从三个层面观察性能。

首先是显存占用。启动本地模型后，用nvidia-smi观察显存变化：

nvidia-smi

在生成过程中，显存占用会随模型加载和上下文长度变化。如果显存不够，优先选择更小的量化模型，或者限制上下文长度。

其次是生成速度。影响速度的关键因素包括：模型参数量、量化程度、输入提示词长度、生成 token 数量、并发数。同一模型在 7B 和 14B 上的生成速度差距明显。实测必须在自己机器上进行，不能拿网上别人的数字直接套用。

最后是稳定性。高频并发调用本地模型时，容易出现请求超时或服务崩溃。建议给每个请求设置 120 秒以上的超时时间，并在脚本里增加失败重试。如果任务量很大，更稳妥的做法是分批跑，每批 10 个标题，跑完休息几秒再继续。

降低显存占用和提升稳定性的常用手段：

• 使用低比特量化模型。
• 限制max_tokens到实际需要的长度。
• 降低并发数。
• 关闭不需要的浏览器标签页，避免额外显存占用。
• 如果服务跑在 Windows 上，注意进程残留，任务结束后杀掉后台 Python 进程。

8. 常见问题与排查方法

端口检查命令示例：

netstat -ano | findstr 8000

如果进程占用，可以换端口启动：

python server.py --port 8001

或者手动记录进程 PID 再结束进程：

taskkill /PID <PID> /F

批量任务里最容易踩的坑是：标题文件里混入空行、空格、特殊符号，导致请求发送前就报错。处理方式是在读取标题后统一做strip()，并且过滤掉长度小于 5 的行。

9. 最佳实践与使用建议

第一次跑通不要直接用大模型，先准备两个测试标题，用最小并发跑一遍全流程。确认输出格式稳定后再增加批量规模。整套流程里，提示词模板是最值得花时间的部分，建议把提示词单独放文件，方便反复调优。

目录管理上，输入文件、输出结果、失败任务、日志要分开。我推荐的目录结构：

outputs/ ├── ok/ ├── failed/ └── logs/

每个生成结果要附带元信息，包括模型版本、temperature、提示词版本、生成时间，这样出现问题时可以回溯。如果条件允许，尽量把关键参数写入文件名或 JSON 头部。

批量任务必须加日志。简单的做法是把每次调用的模型、耗时、是否成功都追加到task.log：

python batch_run.py >> task.log 2>&1

涉及角色名、真实人物、版权素材时，必须确认授权。这里的“风清扬”是一个典型例子，不能因为标题素材方便就直接用于商用项目。建议改成原创角色名，保留“继任掌门 + 激活系统 + 召唤老祖”的结构。

接口服务不要直接暴露到公网。如果只是本机使用，启动服务时写死127.0.0.1。如果需要局域网其他设备访问，再绑定0.0.0.0，同时要加一个简单的 Token 验证，避免被扫到后无限调用。

AI 生成内容在发布或商用前要做效果复核，重点检查三块：逻辑连贯性、角色一致性、内容合规性。尤其不能用 AI 生成的内容冒充人工原创发布到需要原创审核的平台，否则有违规风险。

10. 总结与下一步

这套创作辅助系统最值得尝试的点，不是某个具体模型，而是“标题拆解 -> 角色卡 -> 世界观 -> 章节大纲 -> 正文生成 -> 批量调度”这条完整流水线。最先应该验证的功能是标题拆解，因为它关联后续所有环节，也最容易看出模型是否理解你的提示词。

最容易踩的坑有三个：第一，提示词不写“只输出 JSON”，导致解析失败；第二，并发数设置过高把本地模型打崩；第三，不设超时和重试，批量任务卡死一晚上。这三个问题都可以在第一次运行时提前规避。

后续可以继续扩展的方向很多：增加一个简单的 Web 页面来编辑角色卡和章节大纲；接入向量数据库把已生成的设定存起来，生成正文时自动检索相关内容；加入人工审核标记，让作者可以在 Web 页面里标注“可用/需修改/废弃”。如果想把这套系统做成团队工具，还可以加任务队列、权限管理和生成记录审计。建议先把单机版跑通，再决定要不要加服务化层。