webnovel-writer：AI网文的DevOps操作系统

哈喽，各位码农朋友，我是周小码——一个被Spring Boot自动配置折磨到凌晨三点、靠咖啡续命的Java老兵。今天不聊JVM调优，也不扒MyBatis源码，咱们来点新鲜的：用Claude Code写网文？！没错，就是那个让网文作者一边敲代码一边喊‘这章爆了’的webnovel-writer。

先别笑——我真试了。上周用它给《我在Spring Cloud里修仙》写了前五章大纲，结果发现：它不是个玩具，而是一套AI时代的网文操作系统。你没看错，操作系统。它不生成段落，而是调度Agent、维护记忆图谱、校验逻辑一致性、甚至追踪读者‘追读力’（对，它连读者心理都建模了）。

痛点不是“写不出来”，而是“写错之后收不了场”

AI写网文最要命的从来不是文笔——是遗忘和幻觉。主角左眼失明，第十章突然双眼炯炯有神；青玄宗在第一章立宗，第三章被改口成青玄教，还自洽得滴水不漏。这种错误不是模型能力问题，是架构缺陷：传统Prompt驱动写作，本质是无状态HTTP请求，每次调用都是“失忆式重启”。

webnovel-writer的解法很硬核：它不靠单次Prompt压榨模型，而是构建了一套分层状态机+RAG增强型Agent编排系统——就像给Claude装了个带版本控制的记忆硬盘+剧情审计员。

架构不是三层楼，是三重时空锚定

它表面是Python项目，但本质是Claude Code插件生态的深度玩家。整个架构像一座三层小楼？不，更准确地说，是三重时空锚定系统：

• 底层：CLI时态层（Python）——负责文件生命周期管理、Git钩子注入、.webnovel-current-project指针维护、章节模板预埋。它不碰LLM，只做“时间戳管理员”。
• 中层：YAML工作流层（声明式Agent编排）——每个.md文件是一个可插拔的‘剧情模块’，内嵌YAML frontmatter定义Agent角色、模型绑定、输入约束。比如：

---
name: context-agent
model: sonnet
input_schema:
  - chapter_range: "1-5"
  - check_rules: ["character_death_consistency", "faction_loyalty"]
---

• 顶层：Claude沙箱层（执行态）——所有Agent都在Claude Code提供的隔离沙箱中运行，共享统一的memory.graphml知识图谱快照，而非原始文本上下文。

这种设计，让我想起当年搞微服务时的API网关+服务注册中心+业务Pod组合——只不过这里调度的是‘世界观校验Agent’和‘反套路检测Agent’。

RAG不是加个向量库，是配了个文学批评家当副驾

最让我拍大腿的是它的RAG配置方式。它不让你瞎传文档，而是强制你填EMBED_BASE_URL和RERANK_API_KEY，背后是双路召回策略：

1. 语义嵌入层：用Qwen3-Embedding-8B对全书章节做向量化（README明确指出：在200万字长篇下，Qwen3实体泛化能力比OpenAI text-embedding-3-small高17%）；
2. 精排校验层：用Jina reranker-v3按‘人物关系密度’‘伏笔回收率’打分排序，再喂给Agent做上下文增强。

这不是RAG，这是领域感知的检索-重排-推理闭环。

来看真实配置：

EMBED_BASE_URL=https://api-inference.modelscope.cn/v1
EMBED_MODEL=Qwen/Qwen3-Embedding-8B
EMBED_API_KEY=your_embed_api_key

RERANK_BASE_URL=https://api.jina.ai/v1
RERANK_MODEL=jina-reranker-v3
RERANK_API_KEY=your_rerank_api_key

注意：EMBED_BASE_URL指向ModelScope API，RERANK_BASE_URL指向Jina AI，二者解耦——这意味着你可以把嵌入换为BGE-M3，重排换为Cohere Rerank，完全不影响CLI层和YAML工作流层。这才是真正的插件化设计。

CLI即契约：三个命令，跑通网文DevOps流水线

它把创作流程彻底工程化：

/webnovel-init
/webnovel-plan 1
/webnovel-write 1
/webnovel-review 1-5

• /webnovel-init：创建带Git钩子的书目录、初始化.webnovel-current-project指针、预埋chapters/001.md模板。终端输出✅ Project 'The Java Sage' initialized. Memory graph synced.——那一刻我恍惚以为自己在部署K8s集群。
• /webnovel-plan 1：触发‘设定策划Agent’，生成世界观文档、人物卡、势力关系图，并写入knowledge/characters.ttl（RDF格式）、knowledge/factions.graphml（图谱格式）。
• /webnovel-review 1-5：加载整个知识图谱，跑SPARQL查询揪逻辑漏洞。比如这条真实query（来自review/consistency.sparql）：

PREFIX ns: <http://webnovel.example.org/>
SELECT ?chapter WHERE {
  ?p ns:hasStatus "dead" ;
     ns:appearedIn ?chapter .
  ?chapter ns:chapterNumber ?n .
  FILTER(?n > 3)
}

查出‘已标记死亡的角色出现在第3章之后的章节’，直接报错阻断发布。

踩坑指南：GPL v3 + token爆炸 + 只读Dashboard

当然，它也有坑：

• GPL v3协议意味着你不能闭源商用——如果你打算做付费网文SaaS，得重写核心Agent调度器；
• Dashboard是只读的（基于dash库渲染），想改UI得提PR；
• model: inherit听着省事，但实际调试时，Opus写设定、Haiku写日常、Sonnet审逻辑，全混在一个会话里，token爆炸是常态。我建议新手先在.env里加一行：

CLAUDE_MAX_TOKENS=32768

如果是我来用？它就是我的网文CI/CD平台

• /webnovel-plan → 需求评审（PR描述必须含[WORLDVIEW]标签）
• /webnovel-write → 开发提交（Git commit message含[CHAPTER-003]）
• /webnovel-review → 自动化测试（CI job触发SPARQL校验）
• /webnovel-dashboard → Prometheus监控面板（暴露/metrics端点，追踪‘追读力衰减率’‘伏笔回收延迟’等指标）

甚至考虑把它和GitLab CI打通，每次git push自动触发章节合规性扫描——这才是AI原生应用该有的样子：不是比谁模型大，而是比谁的记忆管理更稳、状态流转更准、领域约束更严。

webnovel-writer不是终点，但绝对是起点。下次你再看到‘AI写作工具’，别急着点开，先问问它：你的追读力系统，上线了吗？😉