⌘K

用 AI 写小说那些事儿

2026-09-16 · 11 分钟 · #AI #写作

相信每一个热爱小说的人，在这个 AI 的浪潮下，可能都会去尝试利用 AI 做各种各样的东西。

今天我来聊一聊我在利用 AI 写小说过程中遇到的问题。

首先我是一个重度的小说爱好者，从初中开始就开始看，15 年以上了吧。当然不上班的日子里，我在番茄猛猛看，成功地把我自己给看腻歪了。

看腻了就想自己写。然后我发现：写小说这事儿，哪怕有了 AI，最先要解决的还是设计问题。

这就像做产品一样，需求永远是第一位的。没有一个明确的需求，你很难做出一个产品——AI 时代这句话反而更成立，因为 AI 会非常勤快地帮你把错误的需求实现得很完整。

第一个坑：AI 不缺文笔，缺的是记忆和边界

我一开始的做法很朴素：打开对话框，说"帮我写一部异界种田小说，第一章"。

第一章写得不错。第三章开始，主角莫名其妙多了一个师门。第五章，前面说好的"资源极度稀缺"变成了随手捡灵石。第七章，我问它"主角的系统什么时候激活的"，它给了我一个和第一章完全不同的答案。

不是它文笔退化了，是上下文窗口装不下一部 600 章的长篇。

用程序员的话讲：你给了一个无状态服务，却指望它维护一份跨 600 次调用还不出错的事务日志。这不可能。

AI 写长篇有三种经典崩法：

  1. 忘——写着写着忘了前文设定，人物性格、资源数量、时间线前后打架
  2. 编——遇到资料里没有的东西，不提问，直接编一个填满，而且编得特别自信
  3. 混——把没通过审核的初稿当成已定稿的事实，后面章节基于它继续写，错误一路继承

第 3 条最隐蔽，也最致命。一旦错误进入"事实层"，后面每一章都会基于它继续推演，等到 50 章后你发现的时候，已经没法改了——改一处要动二十处。

设计先行：把"需求文档"写给 AI 看

所以我掉头回来做设计。这部分 AI 帮不上忙，也不该让它帮——它会给你一份看起来很完整、实际上全是套路的东西。

我自己填的东西大概是这样：

开书定位（七问）：写给谁看、什么类型、什么情绪体验、读者为什么点开、为什么读完前十章、为什么能读几十万字。

核心设定（七项）：一句话故事、主线目标、失败代价、核心冲突、重复剧情发动机、结局方向、不可改设定。

这里最关键的是"重复剧情发动机"——600 章的书，靠什么让读者不腻？我的答案是：改善生活、种田、探险、遭遇外部威胁、接触原始部落与先天生灵。这条不写清楚，AI 写到第 30 章就只能不停地重复"遇到凶兽—打跑—获得资源"。

主角卡（九要素）：公开目标、私下欲望、当前利益、害怕失去、底线与缺陷、资源与权限、利益冲突、语言指纹、重大刺激反应。

举个例子，我不会写"主角很强"，我写的是：

  • 天赋资质平平
  • 系统只给方法和图纸，不直接给实力
  • 缺陷：偏保守，不爱冒险赌命，容易在"修炼精进"和"种田安逸"之间犹豫
  • 语言指纹：简洁务实，逻辑清晰，危机时语言变简练

有了这些，AI 写出来的对白才不会千人一面。我的主角杨阳是个失业程序员，他穿越后的第一反应是"先摸清现状，就像接手一个祖传系统"——这个反应是从人物卡里长出来的，不是 AI 随机发挥的。

动笔前，先去看看市场在发生什么

设计完我没急着写，先让它去扒了一轮榜单：起点、纵横、书旗、番茄。

先说清楚数据口径：订阅数据平台不公开，所以用月票榜（起点/纵横）、在读人数（番茄）、综合榜（书旗）做替代指标。月票受催票活动影响会有 1—2 位波动，番茄"在读"是累计口径——这些局限得先认下来，不然就是在骗自己。

扒完有几个结论挺有用的：

"修真文明"是男频付费端最大的隐形种田赛道。 起点月票榜前列的几本，本质都是"经营/培育式修仙"——把种田的"养成—产出—升级"内核装进修仙皮。我要写的东西和这个赛道天然同源。

求生 + 基建 + 开局流是免费端的流量密码。 番茄的游戏体育分频几乎被求生文承包，《全民公路求生》在读 49.8 万，《全民大航海》50.7 万。"从零开始建家园"是跨平台通用钩子。

反差幽默标题成了头部标配。 《没钱修什么仙？》《一百岁了还要修仙》——我的第一章标题《我超威，给我干哪儿来了》恰好是这个路子。

还有一条直接改了我的方案：我原本打算把系统激活放在第 003 章（让主角先挣扎两章，金手指才到账）。但番茄读者的耐心显著低于起点，发番茄的话，系统得提前到第 1 章末或第 2 章初。同一本书，发不同平台，开篇节奏是不一样的。

能落地的才叫工作流：把流程固化成目录

光有提示词没用，聊完就散了。我把整套东西落成了目录：

我的新书/
├── 00-项目状态.md      仪表盘：当前章节、本次必读清单、待确认项
├── 01-开书定位.md      七问
├── 02-核心设定.md      七项 + 不可改设定登记表
├── 写作规则.md         八条铁律 + 八步循环 + 冷读清单
├── 人物/               主角卡、配角卡、人物关系
├── 大纲/               全书大纲、分卷大纲、滚动细纲（只细化未来 5—12 章）
├── 追踪/               时间线、角色状态、伏笔、资源与权限
├── 正文/               只有通过裁决的章节
├── 待确认/             初稿、修改稿、试验稿
└── 审核与复盘/         章节合同、冷读报告、滚动复盘

这里最核心的一条规则，我管它叫事实唯一：

正文/ 是唯一事实源。待确认/ 里的稿子在作者裁决通过前不算事实，转正后立刻删掉待确认里的副本，不留双份。

用 git 类比就很好懂：待确认是工作区，正文是已提交。只有 commit 过的才算数，而且不能同时存在两份。这条规则就是用来堵上面第 3 种崩法的。

顺着这个思路还有几条配套的：

  • 大纲、设定和正文冲突时，以正文为准
  • 资料里没有的核心设定，AI 不得擅自补全，必须停下提问
  • 每个场景至少改变一项信息、关系或风险，不然就是废场
  • 章尾必须形成一个具体的、不可逆的新局面，不许用"欲知后事如何"糊弄

每章八步，顺序不能颠倒

真正写的时候，每一章都走同一个循环：

步骤 名称 做什么
01 LOAD 读取资料 规则、细纲、上一章、人物卡、开放伏笔
02 CHECK 写前检查 冲突 / 缺失 / 时间 / 资源 / 权限，缺一样问一样
03 CONTRACT 章节合同 十问填满，明确目标、阻力、主场面、章尾
04 DRAFT 写初稿 按场景写，存进 待确认/
05 REVIEW 读者冷读 六问检查，问题记 S1/S2/S3
06 REVISE 修改 S1、S2 没清零就不算完成
07 UPDATE 回写数据库 时间线、角色状态、伏笔、资源
08 DECIDE 作者裁决 通过→转正+提交；退回→改；废稿→弃

八步里最不常规、也最有用的是 CONTRACT 和 REVIEW，单独说。

章节合同：动笔前先回答十问

不是"写什么"，是"这一章凭什么值得存在"。十问：

  1. 读者这一章追的具体问题是什么？
  2. 失败会失去什么？
  3. 最值得看的具体场面是什么？
  4. 主角主动想完成什么？
  5. 谁在阻止？为什么阻止？
  6. 主角要做出什么关键选择？
  7. 时间、地点、人物、道具从哪来？
  8. 他有权、有能力这样做吗？
  9. 本章改变什么信息、关系或风险？
  10. 章尾形成什么不可逆的新局面？
  11. （加问）读者为什么会在这一刻点开下一章？

最关键的是这条退回机制：十问里任何一问，如果答案只能是"为了推进剧情"，就停止写正文，退回细纲重做。

这一条拦掉了我最多的烂章节。一章想不出"最值得看的场面"，说明这一章本来就不该存在。

冷读：让 AI 用读者视角挑自己的刺

初稿写完，换个身份重读，只看正文、不替作者脑补。六问：

  • 这是谁？为什么现在这样做？
  • 他凭什么决定？资源从哪来？
  • 人物有没有失忆、越权或写偏？
  • 场景、位置和动作能不能看见？
  • 哪里会让读者想跳读？
  • 章尾会不会让人马上追？

第 001 章冷读时真抓出了一个 S1 级问题：原文写"河在东北方向"——一个刚穿越、没罗盘没参照物的人，凭什么知道哪边是东北？

改法也简单：让他记下高坡与河的相对位置，再用太阳影子的方向做修正。土办法，不精确，但在没有罗盘的地方，太阳是唯一不会骗人的参照物。

问题分级是这样定的：

级别 定义 要求
S1 设定、动机、主线、现实逻辑错误 必须清零
S2 明显损害节奏、读感和追读 必须清零
S3 局部表达问题 交稿前尽量清零

得说清楚一件事：AI 审自己的稿是有用的，但不能替代人的判断。 它能抓出"凭空方位"这种逻辑 bug，抓不出"这一章不好看"。后者只有你知道。

我把它封成了一个 skill

这套流程我用了两个月，越用越觉得不该每次都重新讲一遍。所以封装成了一个 Agent Skill，开源在 GitHub：github.com/yyl1208/ai-novel-workflow。

结构就是标准的 skill 格式，SKILL.md 只放核心流程，细节拆到 references/ 按需读取，19 个模板放 assets/，脚手架脚本放 scripts/：

# 一条命令搭好一个小说项目
python3 ~/.workbuddy/skills/ai-novel-workflow/scripts/init_novel_project.py "~/Documents/我的新书"

装法（WorkBuddy 和 Codex 通用同一份文件）：

# WorkBuddy
git clone git@github.com:yyl1208/ai-novel-workflow.git ~/.workbuddy/skills/ai-novel-workflow

# Codex
git clone git@github.com:yyl1208/ai-novel-workflow.git ~/.codex/skills/ai-novel-workflow

装不上最常见的原因就一个：目录名必须叫 ai-novel-workflow，SKILL.md 必须在它的第一层。GitHub 下载的 zip 解压出来是 ai-novel-workflow-main，平台只扫 skills 目录的下一层，多套一层就识别不到。

效果我拿自己的历史数据对比过：搭一个项目，没有这套流程时是 23 次工具调用、手写 633 行；有了之后是 1 次调用、手写 0 行，重复执行零覆盖。

不过 skill 解决的是"稳定"和"省事"，不是"写得好"。

一个诚实的结论

折腾这一圈，我最想说的其实是三件事。

第一，AI 把"写"的成本降到了接近于零，于是"设计"的价值被放大了。 以前你写不出 600 章，是因为体力不够；现在你能写 600 章，问题变成这 600 章值不值得读。瓶颈从产能转移到了判断力。

第二，长篇的核心工程问题不是生成，是状态管理。 上下文窗口、事实一致性、变更追溯——这些全是软件工程的活儿。我用的那些手段：唯一事实源、待确认区、变更登记、分级审核，没有一样是文学方法，全是工程方法。

第三，AI 负责执行，作者负责灵魂。 这句话说起来像口号，但落在我这套流程里是具体的：AI 做 LOAD、CHECK、DRAFT、REVIEW、UPDATE，我做 CONTRACT 的把关和 DECIDE 的裁决。它能写一章没有逻辑 bug 的稿子，但它不知道这一章到底好不好看。

我的第 001 章写完了，1950 字，还躺在 待确认/ 里没转正。不着急，等我想清楚它够不够好。

反正急也没用——这书我规划了 600 章呢。

← 返回