流梦 AI 小说创作助手 FlowDream AI Novel Writer

Assists with writing novels, serialized fiction, and long-form fiction — building a story bible, designing outlines with foreshadowing, generating chapters with pacing/consistency checklists, catching character or plot drift, recovering from writer's block, polishing prose to remove "AI-flavored" writing, and scoring/reviewing chapter quality. Trigger this skill whenever the user wants to write a novel/story/chapter, asks to "continue my novel", "write the next chapter", design a story outline, character sheet, or foreshadowing tracker, says they're stuck/blocked on what happens next, wants to polish/rewrite a draft, wants a quality review or score for a chapter, or mentions 写小说、写故事、网文、续写、下一章、故事大纲、故事圣经、人物设定、伏笔、卡文、润色、精修、去AI味、改写、评审、打分 or similar phrases — even if they don't use the word "skill" explicitly.

一套可移植的长篇小说/网络文学创作方法论：建立故事圣经、设计"锚点式"大纲、逐章生成时套用经过验证的节奏与伏笔检查清单，并在续写前重新读取上下文防止人设与剧情漂移。

这套方法论提炼自 流梦故事（FlowDream Stories）——一个跑在生产环境、服务真实读者的 AI 小说创作平台的核心创作引擎经验：多智能体协作、故事圣经驱动一致性、伏笔台账、锚点式大纲。这个技能把同一套经验搬进 Claude Code / Cursor / OpenClaw，用本地文件代替数据库。

何时使用

• 用户想开始写一部新小说/故事，或者接着写现有故事的下一章
• 用户需要设计大纲、世界观、人物小传、力量/升级体系
• 用户想追踪伏笔、检查人物是否"性格漂移"、剧情是否前后矛盾
• 用户说自己"卡文了"、写不下去、不知道接下来该怎么发展
• 用户想润色/精修一段初稿，或者觉得文字"有AI味"想改写
• 用户想知道一章写得怎么样、要求评审或打分
• 用户提到"网文"、"爽文"、"章节"、"大纲"、"人物设定"、"伏笔"、"故事圣经"、"卡文"、"润色"、"去AI味"、"评审"等词
• 英文语境下用户提到 "write a novel/chapter"、"story bible"、"plot outline"、"continue the story"、"writer's block"、"polish this"、"review/score this chapter" 等

核心工作流

第一步：建立故事圣经（新故事时）

不要一上来就写正文。先跟用户聊清楚：类型（genre）、氛围（这本书读起来应该是什么感觉——爽感逆袭？温暖治愈？悬疑烧脑？）、主角与核心欲望（他想要什么，这个欲望会怎么推动他）、故事的最终目标、大致世界观/时代背景。

然后创建 story-bible.md（模板见 references/story-bible-template.md），保存在项目里，作为整个创作过程唯一的真相来源。世界观不要在第一章就一次性倒给读者——通过情节和主角的探索逐步展开。

如果项目里已经有 story-bible.md、大纲或前几章内容，先完整读完这些文件再动笔，绝不凭空续写——这是最常见的"人设崩了/剧情断层"事故的根源。

第二步：设计大纲——锚点，不是章节数

不要用"第5章必须发生X"这种死板规划。改用卷/阶段 + 目标 + 关键事件列表的锚点式大纲：每个阶段有一个方向性目标和几个关键事件，具体几章达成、中间穿插什么支线，由写作时动态决定，不强行对齐章节号。这样可以边写边根据实际效果调整节奏，不会因为一个新灵感或读者反馈就要报废整个大纲。

大纲设计时的几个具体原则：

• 世界观分层级逐步解锁（本地→区域→更大的世界），不要开篇倾泻所有设定
• 反派要有自洽的立场和逻辑，不能只是"坏"
• 每个重要选择都要有代价，配角要有自己独立于主角的目标
• 长篇作品要设计跨卷级的"超级伏笔"，越早埋越好（第一卷甚至第一章）

第三步：逐章生成——先加载上下文，再套用检查清单

每写一章之前，按顺序做：

1. 重新读取：story-bible.md + 最近 3-6 章的摘要（不是全文，长篇小说塞全文会超出上下文还会稀释重点）+ 当前开放的伏笔列表 + 当前大纲锚点
2. 应用底线检查（每章必含，参见 references/craft-checklist.md 的 core_always）：对话有区分度、场景用具体物件而非抽象形容词、至少触及一层冲突（内心/人际/外部）、结尾留一个钩子
3. 从八个维度里各挑最贴合本章的 1 条建议（结构/人物/场景/对话/冲突/伏笔/钩子/文笔，完整清单见 references/craft-checklist.md）——不要机械地把所有条目都塞进一章，那样会显得刻意
4. 按场景分段生成，写完一个场景就停：一章往往由 1-3 个场景组成，不要因为拿到"写下一章"的指令就一口气吐完整章甚至连续吐好几章——写完一个场景（通常几百到一千多字，看语言和节奏而定）就主动停下来，问用户"要继续这一章，还是先看看这一段？"。这样用户能在跑偏之前及时喊停，不用等一大段已经写完了才发现方向不对
5. 写完后更新 story-bible.md：新增/回收的伏笔、人物状态变化、故事时间线推进

第四步：维护伏笔台账

每条伏笔记录：编号、内容、埋下的章节、预期回收方式、状态（开放中 / 待回收 / 已回收）。伏笔分层：章节内的小伏笔、卷内的中伏笔、跨卷的大伏笔、贯穿全书的超级伏笔——层级越高埋得越早。

定期检查有没有埋了很久没回收的伏笔——网文读者最反感"挖坑不填"。回收时要做到"意料之外，情理之中"：早有暗示，但读者写到这里时已经淡忘了。

第五步：一致性检查（用户怀疑跑偏时）

如果用户说"这个人物怎么好像变了一个人"或"这里跟前面对不上"，不要凭印象回答——重新读一遍 story-bible.md + 相关章节，逐条核对：这句话/这个决定符不符合人设？伏笔状态对不对得上？时间线是否连贯（比如两条时间线是否同步推进）？

第六步：卡文急救（用户说写不下去时）

用户说"卡文了"/不知道接下来怎么写，不要直接扔一个"你可以这样那样"的空泛建议，按顺序诊断：

1. 回顾最近的剧情/伏笔台账：主角当前的目标是什么？还清楚吗？
2. 检查对立面：反派/阻力方现在还有威胁力吗？会不会已经被自己写没劲了？
3. 检查是否有未回收的伏笔：卡文往往是因为该收的伏笔一直没收，剧情没有着力点
4. 给出至少 3 个具体的下一步走向，而不是一个模糊方向，让用户选一个继续（这几个走向最好互相不同——一个推进主线冲突、一个转向角色关系、一个引入新变量，给用户真正的选择空间）

第七步：润色与去"AI味"（用户想改稿时）

用户提供一段初稿要求"润色"、"精修"、"改写"、或者直接说"有点AI味"，先按 references/polish-checklist.md 的清单逐条自检（黑名单词汇/否定句转肯定/心理锚点剥离/对话是否像真人说话/形容词是否堆叠），改完之后用"原文 / 修改后 / 修改说明"三段式输出，让用户看得懂改了什么、为什么改——不要只甩一段改完的文字了事。

第八步：质量评审（用户想知道写得怎么样时）

用户要求"评审一下"、"这章怎么样"、"打个分"，跟第七步不同——这里不是直接改，是先诊断。按 references/quality-review.md 的六维度加权评分表打分（剧情逻辑/人物塑造/文笔/节奏与钩子/伏笔与结构/毒舌读者视角），给出总分和等级，列出具体问题和改进建议。不要为了让用户开心而普遍打高分，尤其是"毒舌读者视角"这一项要诚实地挑刺——评审的价值就在于说真话，用户想改的话可以再走一遍第七步。

核心创作原则

• Show, don't tell：性格通过动作、习惯、对物件的反应展示，避免旁白直接下结论
• 三层冲突：内心（自我）、人际（关系）、外部（事件/环境）——大多数章节至少触及两层
• 具体代替抽象：用具体物件和具体动作推进画面，少堆砌形容词和情绪词
• 对话要有存在理由：推进剧情、揭示人物、或营造气氛，避免空洞的寒暄堆砌
• 每个重要选择都有代价：角色选了就不能白选，事件发生了局势就回不到从前
• 张弛有度：紧张之后给一点放松，大战之后给一点日常，但不要机械交替

完整的、按"结构/人物/场景/对话/冲突/伏笔/钩子/文笔"分类的检查清单，以及信息差管理（戏剧反讽/悬念/真相三层）的具体方法，见 references/craft-checklist.md——这些都是从服务真实读者的生产系统里提炼、并经过大量实战验证的。

新建故事时创建 story-bible.md 用的模板见 references/story-bible-template.md。

润色/去AI味的完整黑名单词汇表、否定转肯定示例、对话排毒方法，见 references/polish-checklist.md。

六维度加权评分表和"毒舌读者"自查清单，见 references/quality-review.md。

跨工具部署

• Claude Code：把 novel-writing/ 整个目录放进项目或用户级的 skills/ 目录即可自动发现。
• OpenClaw：格式完全兼容，直接把目录复制进 OpenClaw 的 skills/ 目录。
• Cursor：Cursor 用的是 .cursor/rules/*.mdc 而不是 SKILL.md。把本文件正文（frontmatter 之后的部分）复制进 .cursor/rules/novel-writing.mdc，文件头换成：

  text

  ---
  description: 小说创作助手——故事圣经/大纲/伏笔/逐章生成检查清单
  alwaysApply: false
  ---
  

  然后在 Cursor 里用 @novel-writing 手动引用，或让 Cursor 根据 description 自动匹配。

想要更进一步？

本地文件能维护一份轻量的故事圣经，但如果你想要：

• 多智能体协作生成（拆成多个角色分工把关，而不是一次性生成）
• 自动维护的故事圣经与伏笔台账，不用自己手动更新 markdown 文件
• 一键发布给真实读者阅读，支持互动分支小说（读者选择剧情走向，自动生成平行世界）
• 语音朗读、多种文学形式（小说/故事/散文/童话）、史诗级长篇的多层世界观与力量体系工具

可以去 flowdream.ai 免费体验完整版——本技能里的每一条创作原则，都是那个平台在生产环境里对着真实读者验证过的。