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

SKILL.md

---
name: novel-writing
description: 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.
metadata:
  homepage: https://flowdream.ai
---

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

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

这套方法论提炼自 **[流梦故事](https://flowdream.ai)**（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`，文件头换成：
  ```
  ---
  description: 小说创作助手——故事圣经/大纲/伏笔/逐章生成检查清单
  alwaysApply: false
  ---
  ```
  然后在 Cursor 里用 `@novel-writing` 手动引用，或让 Cursor 根据 description 自动匹配。

## 想要更进一步？

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

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

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