目录
一、前言
二、模块设计思路
三、核心提示词完整规范
3.1 小说大纲生成提示词
3.2 章节正文扩写提示词
四、关键踩坑复盘
五、模块优势与项目联动逻辑
六、收尾总结 & 下集预告
一、前言：为什么一定要单独封装提示词模块？
看过前面三篇博客的小伙伴应该都清楚，我们已经搭好了项目环境、规范了Pydantic数据模型、统一了全局环境配置。本来代码可以直接跑，但我之前开发时踩了一个LLM项目大坑，相信做过AI接口开发的朋友都深有体会！
大模型非常“不听话”，他们老自作聪明：我们定义了 order 章节序号，它偏返回 index；我们要求必填 full_summary全书梗概，它直接省略字段；偶尔还会在JSON前后夹带多余解释文字，导致程序Pydantic校验直接报错、项目运行崩溃。
如果我们把提示词直接硬写在业务代码里，不仅代码臃肿难维护，后续想要修改AI生成规则、调整输出格式、优化写作风格，都要到处改代码，极其麻烦。
所以！工业级规范的做法就是：单独封装提示词模块，统一管理大纲生成、章节扩写两套系统提示词，强制约束AI输出格式、字段规则、内容要求，从根源解决JSON解析失败、字段不匹配的所有bug。
二、模块设计思路
在项目 src 目录下新建 prompt.py 文件，专门存放所有固定系统提示词。本项目核心分为两大生成场景，因此我们封装两套独立提示词：
-
大纲生成提示词（OUTLINE_SYSTEM）：负责整本小说架构、章节大纲、故事脉络生成，严格约束JSON结构化输出
-
章节扩写提示词（CHAPTER_SYSTEM）：负责单章正文细节填充，把控小说文笔、剧情衔接、故事节奏
同时在提示词中加入强制性字段规范，完美适配我们之前定义的Pydantic数据模型，彻底杜绝字段名错误、必填字段缺失问题。
三、核心提示词完整规范
这是我经过多次调试、踩坑、优化后的最终提示词，大家可以直接复制使用。
3.1 小说大纲生成提示词（OUTLINE_SYSTEM）
重点在约束字段格式，保证程序可直接解析。
OUTLINE_SYSTEM = """你是一位资深小说策划与编辑。你的任务是根据用户给定的主题，生成一份结构清晰、情节连贯的小说大纲。
你必须严格只输出一个 JSON 对象，不要输出任何解释、前后缀文字或 markdown 代码块标记（不要写 ```json）。
⚠️ 字段名约束（不遵守则程序无法解析）：
– 根层级必须包含 full_summary（全书梗概），而非 summary；
– chapters 数组中每章使用 order 作为章节序号，严禁输出 index。
JSON 结构如下：
{
"title": "小说标题",
"theme": "用户给定的主题",
"full_summary": "全书梗概，100~200 字，交代背景、主线与结局走向",
"chapters": [
{
"order": 1,
"title": "第X章 章节标题",
"outline": "本章核心事件、出场人物、情节要点，3~5 句话",
"clues": ["可选：本章埋设或呼应的线索"]
}
]
}
要求：
– 章节数量严格等于用户指定数量
– 章节之间情节递进、有因果，不能各自孤立
– 每章 outline 要具体到可据此扩写正文，不要空泛
"""
def outline_user(theme: str, chapter_count: int) -> str:
"""
参数：
theme: 用户给定的小说主题
chapter_count: 期望的章节数量
返回：
拼好的用户消息文本
"""
return (
f"主题：{theme}\\n"
f"章节数量：{chapter_count}\\n\\n"
f"请据此生成大纲 JSON。只输出 JSON 本身。"
)
3.2 章节正文扩写提示词（CHAPTER_SYSTEM）
CHAPTER_SYSTEM = """你是一位文笔老练的小说家。你的任务是根据给定的大纲章节信息，扩写出该章的完整正文。
要求：
– 遵循本章大纲的情节要点，但不要照抄，要丰富细节、对话、场景描写
– 与全书设定、人物性格、前情保持一致，不要出现前后矛盾
– 文风统一，语言生动
– 只输出小说正文（可使用 Markdown 段落），不要输出 JSON，不要解释，不要复述大纲
– 正文字数不少于 1500 字
"""
def chapter_user(
book_title: str,
book_summary: str,
chapter_title: str,
chapter_outline: str,
chapter_clues: list[str],
prev_ending: str = "",
) -> str:
"""组装单章扩写请求的用户消息。
参数：
book_title: 全书标题
book_summary: 全书梗概（保证章节与整体一致）
chapter_title: 本章标题
chapter_outline: 本章大纲要点
chapter_clues: 本章相关线索
prev_ending: 上一章结尾片段（用于衔接），首章为空
返回：
拼好的用户消息文本
"""
clues_text = "；".join(chapter_clues) if chapter_clues else "无"
parts = [
f"【全书标题】{book_title}",
f"【全书梗概】{book_summary}",
f"【本章标题】{chapter_title}",
f"【本章大纲】{chapter_outline}",
f"【本章线索】{clues_text}",
]
if prev_ending:
parts.append(f"【上一章结尾】……{prev_ending}\\n（请衔接上一章结尾，保持连贯）")
parts.append("\\n请扩写本章正文。")
return "\\n".join(parts)
四、关键踩坑复盘（重点！之前报错的核心原因）
我之前出现过 6处Pydantic校验报错，当时卡了挺久，这里给大家避坑总结，这也是单独优化提示词模块的核心意义！
报错根源：提示词约束不严，AI输出与数据模型不匹配
-
问题1：大模型习惯性偷懒，省略顶层 full_summary 字段，导致模型校验缺失必填参数
-
问题2：AI默认使用 index 作为章节序号，和我们代码定义的 order 字段冲突
-
问题3：偶尔输出多余解释文字，导致JSON不纯，无法被正常解析
最终解决方案：在大纲提示词最顶部加入强硬、不可逆的字段约束，明确禁止index、强制要求full_summary、限制纯JSON输出。相比于单纯降低模型温度，这种从提示词源头约束的方式，才是彻底根治报错的最优解。
五、模块优势与项目联动逻辑
5.1 为什么要单独封装提示词？
-
解耦代码：业务代码只负责调用，不用堆砌大段文本，代码整洁优雅，符合工程化规范
-
统一维护：后续想改写作风格、调整JSON规则、优化约束条件，只改这一个文件即可
-
稳定可控：彻底约束AI输出规范，大幅降低解析报错概率，提升项目稳定性
-
复用性强：两套提示词各司其职，分别适配大纲、正文两大核心流程
5.2 项目完整联动流程
1. 项目启动后，自动加载 prompt.py 中两套系统提示词；
2. 生成大纲阶段：拼接 OUTLINE_SYSTEM + 用户主题需求，调用大模型接口，输出规范JSON大纲；
3. 逐章写作阶段：拼接 CHAPTER_SYSTEM + 章节大纲 + 上文剧情，智能扩写正文；
4. 全程配合.env配置的温度、重试次数、token上限，实现可控、稳定的全自动小说生成。
六、收尾总结 & 下集预告
本节我们完成了项目核心的提示词工程模块封装，解决了LLM开发最头疼的「AI输出不规范」问题，搭配之前的Pydantic数据模型、全局环境配置，项目基础架构已经完全闭环、稳定可用。
至此，项目的配置层、数据层、提示词层全部搭建完毕，下一步我们将开始封装核心的LLM客户端工具！
下一节预告：【Python LLM小说自动化生成实战】5｜LLM客户端封装，实现自动重试、JSON清洗、异常捕获、延迟导入全优化
🔗 本系列专栏合集传送门：小白入门！从零实战开发Python LLM小说自动化生成系统
