文章目录
《60分天花板：AI网文写作行业全景调研》
全15篇（14篇正文+1篇开篇导读），覆盖13个主题：商业工具、开源项目、文风蒸馏、学术前沿、瓶颈分析、路线判断、行动指南、失败案例、合规政策、多模态、经济学、实验验证、方法论
本文定位：开源项目技术路线拆解的下篇，覆盖训练路线（预训练/SFT）、作品DNA路线、其他值得关注的项目。上篇（P2）覆盖InkOS、产品级平台路线和Agent管线路线。后半部分为六条路线的横向对比、路线判断与技术选型建议。
数据可信度说明：
- ✅ Star数、许可证、技术栈、提交数：来自GitHub仓库页面，可信
- ⭕ 功能描述：来自项目README和文档，为项目方自述，可能有夸大
- ❌ 产出质量：除ai-novel-lab有完整作品外，其余项目未做一手验证
- ❌ 实际效果：“架构优势”"长期潜力"等判断为分析结论，非事实
四、训练路线：从零预训练到风格微调
4.1 RWKV AI-Writer — 最早的中文网文模型
彭博的早期项目，基于RWKV架构从零预训练网文模型。3.8k stars，是这个领域的鼻祖。
路线：纯next-token prediction预训练，几万本网文小说语料。
现状：作者自己都标了"过时"。后来演进成了RWKV-Runner（1.5B/3B/7B），但本质还是同一套思路。
优点：
- 网言语感地道（原生训练，不是通用模型改的）
- 效率极高（RNN架构，显存占用极低）
- 本地部署，完全可控
根本问题：
- 风格粒度太粗（只能区分玄幻/言情这种题材级）
- 纯续写，没有结构控制
- 质量不如现在的通用大模型+好的Prompt
结论：这条路在2023-2024年有价值，2025年以后被通用大模型+Prompt工程超越了。除非你要做本地离线部署，否则没必要走这条路。
4.2 StyleLLM — SFT风格迁移
基于Yi-6B底座，用四大名著做SFT微调，每个风格一个模型。
效果：白雪公主→三国/水浒/西游/红楼风格的Demo效果很直观，风格识别度高。
优点：
- 效果直观，demo好看
- 工具链完整（LLaMA-Factory训练 + AWQ量化部署）
- 部署门槛低（4.2GB显存）
致命问题：
- 每个风格一个6B模型：你想迁移10个作者就要存60GB模型
- 风格不可控：只能全量迁移，不能调强度
- 只验证了古典风格，现代网文风格效果未知
- 训练数据构造方法不透明（怎么造的"原文-风格文"配对？）
结论：适合固定几种风格的场景，灵活性差。对网文作者来说，不可能为每个想模仿的作者都单独微调一个模型。
五、作品DNA路线：提取"方法"而非模仿"文字"
works-dna-extractor — 16层结构化DNA
这是最有意思的一条路线，也是最少人做的路线。
核心思路：不训练模型，纯用LLM分析+Prompt工程，从小说原文里提取16层"叙事DNA"，然后用DNA指导后续写作。
16层DNA结构：
| 层级 | 维度 | 例子 |
|---|---|---|
| 1 | 叙事引擎 | 靠什么驱动读者翻页 |
| 2 | POV与聚焦 | 谁在看，谁知道多少 |
| 3 | 场景架构 | 开头/升级/转折/收尾模式 |
| 4 | 语言纹理 | 句法节奏、用词偏好 |
| 5 | 对话系统 | 轮次长度、潜台词、权力动态 |
| 6 | 内心戏系统 | 直接思想/自由间接体/身体反应 |
| 7-16 | …… | 意象母题、情感算法、信息控制、角色行为语法…… |
工作流：
提取DNA → 指导续写 → 质量评估（8维度打分） → 迭代优化
为什么这条路线值得关注：
- 零训练成本：不需要GPU，调用现有LLM就行
- 可解释可编辑：DNA是可读的结构化文本，人可以改
- 粒度最细：从叙事引擎到语言纹理，16层全覆盖
- 可评估：自带8维度rubric，能量化一致性
- 可组合：可以和任意基座模型、任意生成方式搭配
问题：
- 依赖基座LLM的能力——提取质量受限于调用的模型
- 推理成本高（每次提取都要大量token）
- 长篇一致性还没验证——DNA说起来好，写50章不走样有多难？
- 项目很小众（5stars），成熟度低
六、其他值得关注的项目
6.1 NovelClaw — 动态记忆优先的多智能体框架
| 项目 | 详情 |
|---|---|
| GitHub | iLearn-Lab/NovelClaw |
| Star | 361 |
| 许可证 | MIT |
| 技术栈 | Python + FastAPI + SQLite |
| 部署 | Docker Compose / 本地bat一键启动 |
| 定位 | 动态记忆优先的协作式AI长篇小说写作工作区 |
架构特点：
- 三层应用结构：auth-portal（入口）+ multiagent（创意构思）+ novelclaw（核心写作区）
- 动态记忆银行 + 手稿视图
- 可视化Web UI + 对话式交互
评价：star数不高但同属"记忆优先"路线，Python栈（对Python生态更友好），MIT许可证（商业友好）。相对早期，值得关注。
6.2 NovelStudio — Go语言的本地优先引擎
| 项目 | 详情 |
|---|---|
| GitHub | Xiaoyangy/novel-studio |
| Star | 74 |
| 许可证 | Apache-2.0 |
| 语言 | Go（主要）+ Python |
| Commits | 87 |
| 定位 | 开源、本地优先的AI长篇小说创作引擎 |
核心理念：最小Host，最肥Prompt，最强工具
分层架构：
- Host层：只做启动/恢复/路由/观察，纯函数路由
- Coordinator：LLM总协调，10万turn上限，裁定子代理调用
- SubAgents：Architect（规划）/ Writer（写作）/ Editor（编辑）
- Tools：原子IO + checkpoint + 幂等，三件套（artifact落盘+Progress推进+checkpoint追加）
- Store：文件系统（tmp + rename原子操作）
特点：
- 三层规划：卷→弧→章
- 世界状态推演 + POV分层 + RAG快照 + 审核门禁
- 可观测性：internal/diag子系统，只诊断不修复
- 没有workflow engine/task queue/scheduler——尽量把决策权留给模型
评价：设计哲学很独特——“最小Host最肥Prompt”，和InkOS"重流程重结构"的思路正好相反。人设定契约，AI承担大部分创作决策，适合追求长篇连续性和可审计生产流水线的人。Go语言是双刃剑：性能好，但AI生态不如Python。
6.3 方寸写作（fangcun-write）— 仿写引擎路线
| 项目 | 详情 |
|---|---|
| GitHub | WindXRan/fangcun-write |
| 定位 | AI驱动的网文仿写引擎，从源书输入到全书量产 |
| 成本 | 号称¥3-5/本 |
| 核心设计 | 脱敏安全网（专名零泄漏）、层级记忆、批量调度 |
仿写管线（6阶段）：
源书 → 事件表提取 → 骨架生成 → 改编策略注入 → 90集剧本 → 番茄风小说
特点：
- 依托toonflow做非侵入式仿写注入
- 脱敏安全网：保证产出不跟原文撞车（专名零泄漏）
- 同时兼容.codex/.agents/.workbuddy/.superpowers多套技能目录
- 工作室级量产路线：30-50本长尾策略
评价：路线很务实——不是"从零写新书"，而是"基于成熟作品的骨架做改编仿写"。这恰恰是当前AI最擅长的模式：有骨架照着填，比从零写靠谱得多。其中，脱敏安全网是关键技术点，直接解决了"仿写会不会变成抄袭"的核心顾虑。
6.4 Awesome Novel Studio — Claude Code Plugin + 生产验证
| 项目 | 详情 |
|---|---|
| GitHub | MJbae/awesome-novel-studio |
| Star | 141 |
| 许可证 | Apache-2.0 |
| 定位 | 基于Claude Code的AI网文生产系统，18个专业Agent + 10个技能 |
| 开发方 | 韩文作者 |
架构：Plugin → Skills（编排器）→ Sub-agents（执行者）
核心亮点：
- novel-config.md中心配置——一份配置文件驱动全管线
- 16轴润色系统——6个Agent并行润色
- 三连墙解决方案——角色崩塌/连贯性断裂/数值不一致的系统性修复
- design-hashes变更检测——改了设计文档，自动计算影响范围并重写受影响章节
- 生产验证——用这个工作流出的网文拿到了签约，日阅读2500+/点赞1000+/订阅300+
评价：
- 为数不多的"有真实产出证据"的开源项目——拿到了签约
- 不是独立产品，是Claude Code插件，复用门槛高
- 韩文网文场景，中文适配程度未知
- Claude API成本较高
6.5 Novel Writer Skills — 零成本OpenClaw Skill路线
| 项目 | 详情 |
|---|---|
| 定位 | 3个独立OpenClaw skill + Python脚本 |
| 成本 | 号称90万字/90+章 ¥0 API成本 |
| 核心策略 | 免费API额度矩阵 + 自动fallback |
三件套：
- novel-outliner——大纲拆解
- zh-novel-writer——批量生成
- novel-quality-checker——33维质量审核（纯规则，零LLM成本）
技术亮点：
- 免费API矩阵：ModelScope / Fyra / Ph8等免费额度组合 + 自动降级
- 5层33维纯规则检查：Python实现，不花LLM钱
- 验证数据：90万字/90+章/零API费用
评价：
- 思路很接地气——不追求质量最高，追求"能跑通且不花钱"
- 质量肯定是所有方案里最低的，但成本也是零
- 适合"先跑通流程再逐步提升质量"的渐进策略
- 纯规则的33维质量检查有参考价值——即使你用强模型，规则检查作为第一道防线也很划算
七、横向对比：6条核心路线一张表
| 维度 | 产品平台 | Agent管线 | 预训练 | SFT微调 | DNA提取 | 少样本嵌入 |
|---|---|---|---|---|---|---|
| 代表项目 | 马良、NovelForge 等 | InkOS、InkFlow、NovelStudio 等 | RWKV | StyleLLM 等 | works-dna 等 | TinyStyler |
| 上手难度 | 中 | 低-中 | 高 | 中-高 | 低 | 高 |
| 风格控制力 | 弱 | 中 | 粗 | 中-强 | 最强 | 强 |
| 长篇一致性 | 中-良 | 良 | 差 | 差 | 未验证 | 未验证 |
| 中文网文适配 | 优 | 优 | 优 | 中 | 中 | 差 |
| 可解释性 | 中 | 中 | 低 | 低 | 最高 | 中 |
| 部署成本 | 中 | 低 | 高 | 中-高 | 低 | 中 |
| 产出质量 | 看人 | 中 | 中-低 | 中 | 看人 | 中（短篇） |
| 成熟度 | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ | ⭐⭐ | ⭐⭐ |
八、四条判断
判断1：InkOS是当前开源界的标杆，但不是终点
8.8k star、完整的真相文件体系、多Agent审计修订、三端交互、守护进程——InkOS的工程完成度远超其他开源项目。
但它的问题也很明显：
- 质量天花板还是基座模型决定的，系统再完善也不能突破这个上限
- AGPL许可证对商业不友好
- 真相文件的粒度还不够细（尤其是叙事结构层）
它是"当前最好的"，但离"真正能写出合格网文"还有距离。
判断2：纯训练路线（预训练/SFT）不是网文写作的最优解
理由：
- 风格粒度不够细（预训练是题材级，SFT是作品级）
- 每个风格一个模型，成本高
- 只有语言层控制，没有结构层控制
- 通用大模型进步太快，专用模型的性价比越来越低
除非：你有明确的本地部署需求、或者有极其大量的特定风格数据（1000万字以上）。
判断3：Schema/卡片/真相文件——本质都是"结构化状态"
InkOS的真相文件、NovelForge的卡片Schema、马良的知识图谱——名字不一样，本质是同一个方向：把小说从"一堆文本"变成"结构化的状态机"。
这是当前解决长篇一致性最靠谱的路线。纯RAG检索只是"翻笔记"，结构化状态才是"知道现在是什么情况"。
区别只在于：
- 粒度多细（粗的只有角色设定，细的到伏笔生命周期/信息差追踪/情绪流）
- 自动更新准不准（人维护 vs LLM自动抽取 vs 混合）
- 注入生成的方式（自然语言描述 vs DSL精确引用）
判断4：作品DNA路线现在最小众，但长期价值最大
因为它解决了一个核心问题：怎么让AI"学会"一个作者的写作方法，而不只是模仿他的文字。
现在的AI写作工具都卡在"语言层"——用词、句式、修辞手法。但网文的核心竞争力在"结构层"——节奏、人物弧光、信息差、爽点布局。DNA路线是当前唯一瞄准结构层的。
问题就是：太早期了，成熟度不够，还需要更多验证。
九、技术选型建议
不要从零做平台——InkOS、马良、NovelForge已经做了90%的工程活，不值得重复造轮子。
最值得投入的三个方向：
- 作品DNA提取 + 验证：把这个方法论做扎实，验证它能不能真正指导50+章的高质量产出
- 长篇一致性工程：所有项目都没解决，谁先解决谁就是壁垒
- 质量评估自动化：中文网文领域没有AutoCrit级别的评估工具，这是空白
可以直接利用的现有项目：
- 想做生成端：InkOS的架构思路可以直接参考（真相文件+多Agent审计）
- 想做Python生态：NovelClaw或马良（一个轻一个重）
- 想做逆向分析+生成的闭环：逆向拆解工具 + InkOS生成端对接
趋势判断（未来6-12个月，高不确定性）
以下判断基于当前信息推演，不确定性很高，仅供参考，不作为决策依据。
[开源基座模型的网文写作质量会快速提升，本地部署的可行性持续增加] — 通用大模型的能力提升速度很快，开源模型（Qwen、Llama等系列）每隔几个月就有新一代发布；同时针对中文网文的SFT微调项目在增多，模型质量提升会直接降低开源工具的使用门槛，本地部署从"技术爱好者的玩具"变成"有实用价值的选项"。
[Agent框架会走向标准化，从"各自造轮子"收敛到少数主流框架] — 当前AI小说Agent领域每个项目都有自己的管线设计，InkOS、NovelForge等各有一套架构；随着技术路线逐渐清晰（结构化状态+多Agent协作是共识方向），社区会向少数成熟框架收敛，更多人会在既有框架上做二次开发而不是从零搭建。
[开源项目的商业化探索会加速，从纯开源走向"开源核心+商业增值"模式] — InkOS等项目已经积累了大量Star和用户，但纯开源难以持续；6-12个月内会有更多开源项目尝试商业化（云服务版、企业版、高级功能付费），Open Core模式会成为主流选择，既保持社区活力又解决可持续性问题。
[结构化状态会成为开源项目的标配能力] — 当前已有多个项目独立探索出类似方向，6-12个月内预计会出现标准化的状态管理模块或SDK。
边界与局限
- 样本覆盖偏差：主要覆盖GitHub英文项目，中文开源项目和闭源项目未纳入
- 静态评估偏差：大部分项目未实际运行测试，质量判断基于文档和代码的静态分析
- 时间偏差：开源项目迭代快，6个月后的功能和状态可能已有显著变化
- 技术判断主观性：架构合理性、技术深度等维度的评估有主观成分
- 未做产出质量对比：所有项目的生成质量未做统一盲评，质量判断为定性观察
本文为《60分天花板》系列第3篇
上一篇：P2（开源项目技术路线拆解·上）
下一篇：P4（文风蒸馏与作品DNA）
482
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
