我用 AI 写了 50 章网文，最后一章交稿时系统说「无法测算」

爱编程的喵汪人

188人浏览 · 2026-06-17 20:18:32

爱编程的喵汪人 · 2026-06-17 20:18:32 发布

三周前，我在 GitHub 上建了个仓库，开始写一本修仙小说。

三周后，这本小说写了 50 章，约 7 万字，全部提交、审查、打 tag、推送远端。最后一章的结尾，主角的系统面板上只剩一行灰色的字：

「合约履行完毕。宿主剩余寿命：无法测算。」

这不是 AI 生成的结尾——这是我坐在屏幕前一个字一个字敲出来的。但敲这行字之前，我已经和 AI 吵了 50 章的架。

在这里插入图片描述

一、不卖关子：这项目是什么

一本修仙+系统流的网文，叫《宗门倒计时：拿命经营》。主角林渊前世是青云宗掌门，被大弟子背叛灭门，重生回少年杂役，绑定一个"宗门经营系统"——每一次加速经营都要消耗阳寿。三年倒计时，阳寿换宗门存续。

这是 50 章的故事线。

但我想聊的不是剧情，是这个项目真正的实验：用 Claude Code 作为写作协作者，从大纲到逐章起草到审查提交到 Git tag，全程在 CLI 里完成。

项目的 GitHub 结构长这样：

宗门倒计时拿命经营/
├── 正文/           # 50 章 .md 文件
├── 大纲/            # 总纲、节拍表、时间线、详细大纲
├── 设定集/           # 世界观、力量体系、主角卡、反派设计
├── 审查报告/         # 每章 AI 审查结果
├── .webnovel/       # 状态机、摘要、知识图谱
└── .story-system/   # 写作合约（调性、禁忌、动态参考）

没界面，没数据库，纯文件系统 + Python 脚本 + Claude Code 的 Agent 调度。

二、为什么要用 CLI 写小说

听起来很离谱。写小说不是应该用墨墨、作家助手或者至少 VSCode + Markdown 吗？

说原因之前，先说一个数字：

第 46 章审查时，AI 审查员发现了 5 个问题。其中 1 个是 high priority，批注是"抽象判断先行于具体描写——先给出感受标签，再用比喻补解释，替读者下结论"。

原文写的是：“是一种更让人不舒服的平静，像屠户看案板上的肉，已经知道该从哪里下刀了。”

审查说：删掉"更让人不舒服的"，让比喻自己说话。

改成了：“是一种平静——像屠户看案板上的肉，已经知道该从哪里下刀了。”

这不是人审的，是 AI 审查 agent 审的。它比大多数人类编辑都敏感——因为它的审查规则是用之前 45 章的历史问题训练出来的。

这是这套流程的真正价值，不是"AI 帮你写"，是 AI 帮你建了一套你一个人根本维持不了的写作纪律。

这套纪律包括：

状态机驱动而非灵感驱动。 每次写新章之前要跑预检，系统会检查占位符残留、合同树是否过期、上章审查是否通过。过不了就不让写。灵感来了？等预检跑完。

每个章节提交前要过四道门： 起草 → AI 审查（打分+分类问题）→ 修改润色 → Anti-AI 终检。Anti-AI 终检会扫描全文内的模式词：缓缓、淡淡、微微、不禁、不由得——每次检出都得改。

设定一致性不能靠脑子记。 主角在第 34 章右手手指开始僵化，第 47 章老掌门交令牌时，AI 审查会主动验证：林渊接令牌的手有没有写"指节卡了一下"？如果没写，flagged。因为主角卡里明确写着：第 34-35 章手指僵硬感加剧，这是持续的状态线索，不能掉。

三、50 章是怎么写完的

阶段一：总纲和设定（一次性投入，后面不改）

这不是"先写再改"的项目。总纲规定了四卷的章节范围和核心冲突，设定集锁死了境界链和经营系统的数值，主角卡写清楚了林渊的行为底线——“不会因为挑衅拍桌子”。

这些东西一旦确认，后面的所有写作决策都由它约束。AI 审查会拿主角卡来对照每一章的行为描写，发现 OOC（out of character）就报 issue。

有一个具体的例子：主角的人设是"冷静布局者，不会情绪化冲动"。第 48 章林渊发现韩啸不见了，前世记忆闪回触发——我写了他"手不受控制地颤抖"。审查通过了。但如果我写的是"他一掌拍在桌上，冲出门去"，系统会直接 blocking。因为不符合人设。

阶段二：卷级规划

每章不是独立写的。先写卷节拍表（5-6 幕结构），再写卷时间线（单调递增的倒计时），最后用结构化节点把每章拆成 CBN→CPNs→CEN 的骨架。

第 4 卷 5 章的章纲包含：

每章的目标、阻力、代价
时间锚点和倒计时状态
3-4 个推进节点（CPNs）
2-4 条"本章禁区"

这些节点是写给自己的执行指令，不是给读者看的预告。章纲里不能剧透。

阶段三：逐章写作的流水线

每章的流程固定：预检→刷新合同树→ context-agent 生成任务书→起草→AI 审查→修改→Anti-AI 检查→提交→Git 打 tag。

看起来繁琐，但每一道门都挡掉过问题。第 49 章是灭门战，审查发现了 “不是X，是Y” 句式在全章出现了约 15 次，平均每 170 字一次——“不是从山门方向传来的，是灵脉西侧”“不是防线不够强，是血煞宗带了破阵的法器”“不是要攻破的，是林渊主动收缩的”。

这些单看都没问题。连在一起看，阅读节奏就死了。改。

四、AI 味到底是个什么东西

写了 50 章，和审查 agent 吵了 50 章的架，我对"AI 味"有了具体的定义——不是词汇问题，是"替读者做判断"的问题。

AI 写作的典型结构是：展示一个画面 → 紧接着解释这个画面的含义 → 再紧接着总结这个含义的重要性。

三段式：展示 → 解释 → 升华。而好的写作只需要第一段。让读者自己完成后面两步。

用数据说话：第 46 章初审时 AI 味评分 67/100，第 47 章降到 92/100。不是我有进步，是因为第 47 章写的是老掌门交权和破屋铁匣——全是动作和对话，没有解释的空间。

所以"去 AI 味"不是换词汇（把"缓缓"改成"慢慢"只是治标），是砍掉解释性叙述的信心。

审查 agent 有一类问题叫"展示后紧跟解释"，专门抓这个模式。例如：

原文：他用右手握住左手的袖口，慢慢地整了整——这是他在思考时的一个习惯动作，但今天他做这个动作不是因为思考，是因为他的右手指节在整袖子的时候卡了一下。

审查意见：删除"这是他在思考时的一个习惯动作"——让读者从"指节卡了一下"自己推断。

改后：他用右手握住左手的袖口，整了整。指节在布料间卡了一下。

少了一半字数，信息量反而更大。

五、这套流程能复用吗

项目开源的配置都在 .story-system/ 和 .webnovel/ 里。核心是三样东西：

一个状态机：它知道你写到哪一章、哪些章节还有 blocking 问题、当前卷的进展。不让跳步。
一套合约树：MASTER_SETTING（调性和禁忌）→ volume（卷级节奏）→ chapter（本章硬约束）。每章刷新一次，保证后写的章节不会推翻前面的设定。
一个审查规则引擎：基于过去 45 章的历史问题不断更新 anti-patterns。它知道你第 9 章犯过什么错，所以第 46 章不会翻同样的车。

这不是"AI 写作模板"。这是一套用软件工程纪律对抗创作熵增的流程。

适合什么场景？