企业官网建设流程全解析

写作是件很矛盾的事：灵感来的时候手速跟不上脑子，灵感不在的时候，模型、大纲、角色弧光全卡在那里，屏幕比墙还冷。这两年我试过的解法很多，从“硬写”到“换工具”都折腾过，真正让创作状态稳定下来的，反而是 LLM。它解决的其实不是“帮你写小说”这件事，而是把写作链条里最消耗心力的环节拆开：素材整理、脑洞发散、情节分支、批量试写、统一文风。全串起来之后，LLM 不再是聊天框里的“自动续写机器”，而是一套可以本地部署、批量调接口、按自己节奏调参的创作流水线。

这篇文章就是把这套流水线讲清楚。我会先说它到底能干什么、门槛在哪；然后按“环境准备 -> 模型部署 -> 功能测试 -> 接口与批量任务 -> 性能观察 -> 常见问题”的顺序，把从零搭一套小说创作 LLM 工作流的过程完整过一遍。文章结尾会留一套可以直接照着做的验收清单，方便你收藏后逐步落地。

如果你只是想看它能不能帮自己节省试错时间，答案是可以；如果你关心的是本地推理、OpenAI 兼容接口、批量生成、RAG 风格库这些工程细节，下面这些内容可以直接对号入座。

1. 核心能力速览

有一点要说明：这里的“项目”不是某个特定 GitHub 仓库，而是一条相对完整的 LLM 创作链路。它把开源模型、推理服务、提示词管理、批量任务和风格资料库组合在一起，最终落成一套可以持续产出的工具系统。

2. 用 LLM 创作小说：适用场景与使用边界

先聊边界，是因为很多朋友把 LLM 写作想成了“给一句话，出一本小说”。实际用下来，它更擅长的是给创作过程提供“无限草稿”和“低成本的错误选项”。

2.1 适合谁

• 有明确创作目标但缺素材的作者：需要人物名、世界观设定、情节冲突、反转设计的灵感库。
• 需要批量试稿的创作者：比如一章内容写五个开头，比较节奏和语气，用 LLM 批量生成可以大幅降低时间成本。
• 想把写作流程工程化的团队：漫画脚本、短剧分集、网文章节需要固定格式输出，LLM 能按 JSON 模板稳定返回。
• 对数据隐私敏感的创作者：故事框架、未发表章节不方便传到外部 API，本地部署就很有价值。

2.2 能解决什么问题

LLM 写作最有价值的地方不在“最后成稿”，而在过程：

• 把创作者从空白页焦虑里拉出来：先给一个粗糙版本，再进行人工修改，比自己从零开始轻松得多。
• 把文风统一问题从“凭感觉”变成“可量化”：把一段范文交给模型，让它提取句式特征、用词习惯、段落节奏，写出来的内容会明显贴近。
• 把“大纲—细纲—正文”的层级拆开处理：每个环节由不同的提示词模板负责，比让模型一次性写完整章节稳定。

2.3 不适合什么场景

• 追求绝对原创性、文字带有强烈个人审美标记的严肃文学创作，LLM 容易把语言改“平”，丢失风格锐度。
• 需要严格考据的历史小说、专业知识高度密集的行业小说，LLM 会一本正经地编造，必须人工核对。
• 已有完整定稿、只需要“快点写完”的项目，LLM 对叙事节奏和伏笔回收的理解并不可靠。

2.4 版权、隐私与合规边界

用 LLM 辅助写作，有几条红线建议先理清楚：

• 不要把未公开的完整稿件、客户委托文本、真实人物隐私信息发送到不可控的外部接口。
• 使用“风格模仿”功能时，只对自己拥有版权或已获得授权的文本做参考，不要仿写他人作品并对外发布。
• 面向平台投稿、商业出版、剧本出售前，确认平台对“AI 辅助创作”的要求，很多内容平台有自己的披露规则。
• 批量生成的内容要经过人工复核，避免输出歧视、暴力或违反公序良俗的段落。

3. 环境准备与前置条件

铺垫完了，进入部署部分。先看一眼需要准备哪些东西，再根据你的实际情况选一条路。

3.1 通用环境清单

如果你用的是商用 API 路线，环境准备会简单很多，只需要 Python 环境、网络连接和 API 密钥即可。

3.2 本地推理框架选型

目前比较流行的本地 LLM 部署方式有几种，按使用场景选就行：

对小说创作这种“单次生成短文本、随机性较高”的任务，Ollama 和 llama.cpp 已经够用。如果后续要做大批量章节试稿，再考虑 vLLM 这类服务化框架。

3.3 模型选择思路

写小说和写代码不一样，对数学推理能力要求低，但语文能力、长文本理解能力、叙事连贯性要求高。选模型时可以按这个思路来：

• 轻量优先：7B-14B 级别的中文模型，配合量化，能在消费级显卡上运行，适合日常场景草稿。
• 中文优先：关注中文语料占比高的开源模型，输出的人名、成语、古风词汇更自然。
• 长上下文优先：如果一次要生成七八千字的长章节，模型上下文窗口最好在 32K 以上。
• 风格可控性：优先选择指令遵循能力强的模型，因为写作工作流高度依赖提示词。

这里不绑定具体某个模型版本，因为实际效果受量化方式、提示词写法影响很大。稳妥做法是同一批指令在多个模型上各跑一轮，人工对比后固定一个作为创作主力。

4. 部署与启动：LLM 本地推理与 API 接入

环境准备好之后，选一条主要路线跑通。下面以 Ollama 和 Python 调用为例，演示“本地模型服务 -> 接口接入 -> 批量脚本”的完整链路。

4.1 安装并启动 Ollama

Ollama 的安装很简单，官方支持 Windows、macOS 和 Linux。装完后先确认服务可用。

# 查看版本 ollama --version # 拉取一个适合中文写作的模型，具体模型名需按 Ollama 仓库实际支持情况填写 ollama pull qwen2.5:7b # 启动服务 ollama serve

ollama serve会默认监听本地11434端口，并提供一个 OpenAI 兼容接口。如果你不想让服务占用终端，也可以让它常驻后台。

启动后可以直接聊天验证：

ollama run qwen2.5:7b

输入一句“给一个仙侠小说的开头，两百字，气氛要冷”，看返回内容是否稳定。这一步通过，本地推理链路就通了。

4.2 用 curl 验证 OpenAI 兼容接口

Ollama 的 OpenAI 兼容接口一般在下面这个路径：

curl http://127.0.0.1:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b", "messages": [ {"role": "system", "content": "你是一个擅长都市悬疑小说的编辑，善于铺陈氛围和塑造人物。"}, {"role": "user", "content": "请为一个短篇设计三个不同走向的开头。"} ], "temperature": 0.8 }'

返回结果里会有choices[0].message.content字段，这就是模型生成的文本。这一步验证的核心是：能否通过标准 HTTP 请求拿到创作结果。能拿到，后面接自己的 Python 脚本、批量任务、Web 工具都没有障碍。

4.3 接入商用 API 作为备选

如果你短期没有本地显卡，但又想先跑通完整创作流程，可以注册商用大模型 API 服务，拿到密钥后写一套统一的调用层。

from openai import OpenAI client = OpenAI( base_url="https://api.example.com/v1", # 以你的服务商实际地址为准 api_key="your-api-key" ) response = client.chat.completions.create( model="your-model-name", messages=[ {"role": "system", "content": "你是小说共创编辑，输出克制、具体、有画面感。"}, {"role": "user", "content": "写一个推理小说中金库失窃案的案发现场描述。"} ], temperature=0.9 ) print(response.choices[0].message.content)

注意：base_url、model、api_key必须换成服务商提供的字段，不同服务商之间会有差异。这个步骤的意义是把“本地模型”和“API 模型”统一成同一套调用方式，将来想切换部署方式，只改配置不拆代码。

5. 功能测试与效果验证

服务跑通之后，不要急着写整本小说，先把能力拆成小块验证。下面这套测试维度，基本覆盖小说创作 LLM 工作流的核心环节。

5.1 灵感发散：从一句话设计三个前提

测试目的：确认模型能否根据一个模糊想法，输出多个有效前提。

curl http://127.0.0.1:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": "请根据“深夜便利店的收银员能看见每个人的死期”这一设定，设计三个立意不同的故事前提，每个 150 字以内。"}], "temperature": 0.9 }'

判断标准：

• 三个前提是否各不相同，而不是同一句话换措辞。
• 是否包含“人物-冲突-悬念”的基础结构。
• 是否出现可延展的画面或道具。

常见失败原因：提示词里没有要求“立意不同”，模型会围绕同一主题反复打转。改进方法是在提示词里拆维度：一个偏人情、一个偏悬疑、一个偏黑色幽默。

5.2 章节大纲：把故事梗概拆成可写清单

测试目的：确认模型能按结构输出章节化大纲。

curl http://127.0.0.1:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": "这是一个短篇的梗概：主角在整理已故父亲的遗物时发现一封写给二十年后的信。请把它拆成 5 章大纲，每章包含：本章目标、主要场景、关键冲突、结尾钩子。"}], "temperature": 0.6 }'

判断标准：

• 是否出现“章节目标”而不是简单复述梗概。
• 是否每章都有明确冲突和下一章的钩子。
• 是否能把大纲直接用于后续扩写。

这套提示词模板稳定之后，建议保存成 Markdown 文件，后续批量套用。

5.3 文风迁移与统一

写作工作流里，文风统一是最难搞的一环。测试方法是给模型一段参考文字，要求它提取风格特征，再用同样风格写新内容。

参考文本： 风从巷口灌进来，卷起地上干枯的梧桐叶，贴着青石板滑出沙沙声。男人把领口紧了紧，却没有加快脚步，他知道巷子尽头那盏灯迟早会灭。 任务：按照上面文本的句式节奏和用词习惯，写一个同样氛围的 200 字片段，场景是雨夜地铁站。

判断标准：

• 句式长度是否接近参考文本：短句与长句节奏是否一致。
• 是否沿用类似的感觉词，如声音、温度、光线的描写方式。
• 是否出现明显“AI 腔”，比如“仿佛”“宛如”“跃然纸上”这类高频词。

如果风格不稳定，可以在提示词里强制加入“禁止词清单”：

{ "messages": [ {"role": "system", "content": "写作要求：避免使用“仿佛”“宛如”“同时”“值得一提的是”等词汇。使用具体名词和动作描写，少用形容词堆砌。"} ] }

5.4 细纲到正文：长文生成的稳定性

写完整章节是压力最大的测试。长文本生成容易在中途出现三个问题：人物名字变化、时间线错乱、重复描述。要缓解这个问题，需要在提示词里注入“事实基线”。

messages = [ {"role": "system", "content": "小说事实基线如下：主角名叫陈默，地铁维修工；凶手名叫周岚；事件发生时间：2023 年 11 月 3 日；地名统一为北滨市。以上信息如有冲突，以本条信息为准。"}, {"role": "user", "content": "根据这段细纲扩写完整章节，控制在 1500 字以内：陈默在隧道检修时发现一只不属于当晚作业的手套，手套内衬绣着周岚的名字缩写。"} ]

判断标准：

• 出现的人名、地名、日期是否与事实基线一致。
• 叙事视角是否保持稳定。
• 章节是否自然结束，有没有“突然停止”或“强行总结”的迹象。

5.5 批量试写：同一个场景五个版本

写作里“多版本对比”是很有效的打磨方式。把场景描述作为输入，用脚本循环调用五次，把结果保存为多个 Markdown 文件。

import requests import time payload = { "model": "qwen2.5:7b", "messages": [ {"role": "system", "content": "你是短篇小说写手，文字克制、画面感强。"}, {"role": "user", "content": "写一个 250 字的场景：主角在旧书店发现一本书，书页里夹着一张写着自己名字的旧照片。"} ], "temperature": 0.95 } for i in range(5): response = requests.post("http://127.0.0.1:11434/v1/chat/completions", json=payload) text = response.json()["choices"][0]["message"]["content"] with open(f"./outputs/draft_{i + 1}.md", "w", encoding="utf-8") as f: f.write(text) time.sleep(1)

执行后，直接打开五个草稿文件对比。人工选择一个版本作为底稿继续改，能明显减少“第一版怎么都下不了笔”的卡顿。

6. 接口 API 与批量任务

写作场景的 LLM 接口调用，不需要多复杂的框架，核心就是：启动服务、写请求、解析返回、保存结果。难点在于批量任务多了以后，怎么控制请求频率和失败重试。

6.1 准备章节任务清单

假设我要为一部 10 万字的网文生成初步草稿，不能一次性把全文塞进去，而是按“卷 -> 章 -> 场景”切分。推荐用 JSON 维护任务清单。

{ "np_task": [ { "chapter_id": "ch_001", "title": "深夜列车", "scene": "主角在一次末班地铁上发现乘客不断消失", "characters": ["陈默", "周岚"], "required_length": 1200 }, { "chapter_id": "ch_002", "title": "废弃站台", "scene": "陈默在废弃站台找到一张旧车票", "characters": ["陈默"], "required_length": 900 } ] }

脚本读取任务清单，逐条调用接口，生成结果写入outputs目录，并附带生成状态。

6.2 批量脚本核心写法

import json import time import requests from pathlib import Path def generate_chapter(item, output_dir): prompt = ( f"章节标题：{item['title']}\n" f"场景：{item['scene']}\n" f"出场人物：{'、'.join(item['characters'])}\n" f"要求：写成一章约 {item['required_length']} 字的小说正文，" f"注意环境描写和人物动作细节，结尾留悬念。" ) response = requests.post( "http://127.0.0.1:11434/v1/chat/completions", json={ "model": "qwen2.5:7b", "messages": [{"role": "user", "content": prompt}], "temperature": 0.8, }, timeout=300 ) content = response.json()["choices"][0]["message"]["content"] output_file = Path(output_dir) / f"{item['chapter_id']}.md" output_file.write_text(content, encoding="utf-8") print(f"完成：{item['chapter_id']}") def run_batch(task_file="task.json"): tasks = json.loads(Path(task_file).read_text(encoding="utf-8"))["np_task"] for task in tasks: try: generate_chapter(task, "./outputs") except Exception as e: print(f"失败：{task['chapter_id']}，错误：{e}") time.sleep(2) if __name__ == "__main__": run_batch()

这个脚本虽简单，但已经能覆盖大部分写作批量任务。真正落地上生产前，建议再加几层：

• 请求失败自动重试，最多重试三次。
• 每次请求之间增加随机延时，避免触发限流。
• 输出结果追加一个 JSONL 日志文件，记录每次请求的模型、参数、耗时和结果路径。
• 遇到连续失败时暂停任务并发送告警。

6.3 把 LLM 接到自己的写作工具里

如果不想在终端里操作，可以把上面的服务接口接到 Obsidian、Web 应用或自建模板工具中。流行的“LLM wiki 范式”也在做类似的事：把个人笔记、资料库、写作素材做成 RAG 检索库，大模型在生成前先检索相关设定和文风片段，再开始写作。

这里的关键点是：LLM 本身不必和你其他的创作工具装在同一台电脑上。只要网络能访问到服务地址，写小说的工作流完全可以把“模型推理”和“素材管理”拆分到不同机器。比如一台台式机跑本地推理服务，笔记本上只装编辑器和调用脚本。这也是“ComfyUI 和 LLM 是否要在同一台电脑上”这类问题的通用答案：看你的网络和接口设计，不一定需要同机。

6.4 用 RAG 搭建个人风格库

在小规模创作场景里，RAG 不一定需要重型向量数据库。把一个角色的外貌、性格、说话习惯打包成固定段落，在每次调用前替换进提示词，就足够应付很多问题。真正需要 RAG 的时候，通常是资料很多、风格样本很杂，需要动态检索。

轻量实现思路：

1. 建一个characters/目录，每个人物一个 Markdown 文件。
2. 建一个styles/目录，存放自己写过的范文片段。
3. 写一个 50 行左右的 Python 脚本，按关键词把相关内容拼接到提示词里。
4. 后续数据量大了，再引入向量库替代目录检索。

下面是简化的提示词拼接脚本：

from pathlib import Path def load_character(name): path = Path(f"./characters/{name}.md") return path.read_text(encoding="utf-8") if path.exists() else "" def build_prompt(user_content, characters): character_block = "\n".join([load_character(c) for c in characters]) return ( "以下是作品中的人物设定，必须严格遵守：\n" f"{character_block}\n\n" "用户内容：\n" f"{user_content}" )

7. 资源占用与性能观察

很多第一次跑本地 LLM 的朋友，最关心的是“会不会爆显存”“会不会卡死”。其实只要会观察，这些问题在动手之前就能预测。

7.1 显存占用怎么看

当推理服务正在运行时，另开一个终端执行：

nvidia-smi

关注Memory-Usage那一列，看的是 GPU 显存占用。除此之外，还要看 CPU 内存的占用，因为推理框架加载模型时通常先在内存里展开，再拷到显存。

观察时间点分三个：

7.2 精度与显存的关系

本地模型部署绕不开数值精度问题。常见的有 fp32、fp16、bf16 和 int8/int4 量化几种形态。

• fp32：精度最高，显存占用最大，消费级显卡基本没必要。
• fp16：半精度，显存占用是 fp32 的一半，很多 GPU 推理都能跑。
• bf16：和 fp16 位数一致，但指数位更多，数值范围更大，大模型推理时更稳。
• int8 / int4：量化后的低精度格式，显存更小，牺牲少量质量换速度。

如果你只有 8G 显存，想稳定跑 7B 级别的中文模型，选择量化版本通常会比硬跑 fp16 更实用。但具体占用多少，要看你用的模型文件、上下文长度和单次生成 token 数，最稳妥的做法是下载前先看模型的说明文件。

7.3 影响性能的主要参数

7.4 降低资源占用的通用措施

• 优先使用量化模型文件。
• 控制单次生成长度，不要一次让模型输出 8000 字，而是改成 1500 字一段分段生成。
• 关闭不用的并发任务，一次只跑一个长文本请求。
• 服务不使用时直接释放进程，避免模型一直占着显存。
• 如果端口被历史进程占用，用ps aux | grep找到残留进程清掉再启动。

8. LLM 写作常见问题与排查方法

9. 最佳实践与合规使用

9.1 工程化落地建议

• 第一波验证先用小参数跑通：模型选小一号、最大生成 token 数量设低一些，确认链路没问题再放开。
• 保留一套最小可运行配置：把模型版本、提示词模板、启动脚本固化到同一目录，避免“能跑但不知道怎么复现”。
• 素材目录分开管理：prompts/放提示词模板，characters/放人物设定，outputs/放生成结果，logs/放请求日志。
• 给每个生成文件加元信息头：模型名、时间、参数、上下文版本，方便回溯。

--- model: qwen2.5:7b temperature: 0.85 prompt_template: v3_chapter_expand generated_at: 2025-06-01 21:30 --- 正文内容...

• 批量任务一定要写日志。至少记录：任务 ID、请求状态、耗时、输出文件路径。
• 接口服务如果开启局域网访问，必须加访问控制，不要直接把11434或8000端口裸暴露到公网。

9.2 创作层面的使用技巧

• 把 LLM 当“共同创作人”，而不是“代笔”。先让它给十个不喜欢的方案，再从废稿里找方向，比直接让它写最终稿更有用。
• 人物设定尽量固定成结构化文本，每次调用都带上，而不是靠模型记忆。
• 把文风控制拆成两层：一层是“禁止词”，一层是“偏好词”。禁止词控制下限，偏好词控制上限。
• 每次生成完，保留至少一个成功案例作为工作流输出标准。

9.3 合规和安全边界

• 涉及真实人物形象的描写、真实事件改编，需要特别谨慎，必要时先获得授权。
• 对外部 API 发送的文本要脱敏，不要在故事草稿里包含真实联系方式、身份证号等敏感信息。
• 商业平台投稿前，仔细阅读平台对 AI 辅助创作的说明，按平台规则披露。
• 批量生成内容不搞色情、暴力、违法诱导，这类内容既违反公序良俗，也容易被服务商风控拦截。

10. 总结与下一步

这套 LLM 小说创作工作流，最值得尝试的一点是：它把“创作”从不可控的灵感和状态中部分抽离出来，变成了可调用、可批量、可复现的流程。先不追求让模型写出惊艳的句子，而是让它在“灵感发散、大纲拆分、人物设定、场景试写、批量对比”这些环节帮你把工作量降下来，你会发现写作压力会小很多。

建议你先跑通一行命令、一段接口调用、一次小批量生成，先完成最小闭环。开始时最容易踩的坑有三个：第一是选了过大的模型导致显存不够，第二是提示词里没有加入“事实基线”导致前后矛盾，第三是批量任务缺少重试和日志导致中断后无从排查。这三个坑前文都有对应的排查方式，收藏起来，实操时对号入座。

后续想继续深入，可以从这几个方向扩展：给写作流程接上向量检索，做一个真正属于自己的“灵感素材库”；把多个模型组合起来，让一个模型负责大纲、另一个负责正文、第三个负责文风润色，形成多角色流水线；或者把接口服务接入 Obsidian 这样的笔记工具，做到在写作界面里直接调用 LLM 能力。框架不重要，重要的是先把本职工作流跑通，再一步步加深。