目录一、前言二、模块设计思路三、核心提示词完整规范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_SYSTEMCHAPTER_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 字段导致模型校验缺失必填参数问题2AI默认使用 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小说自动化生成实战】5LLM客户端封装实现自动重试、JSON清洗、异常捕获、延迟导入全优化 本系列专栏合集传送门小白入门从零实战开发Python LLM小说自动化生成系统