NovelForge：用 JSON Schema 和 @DSL 约束百万字长篇的 AI 写作工具
AI辅助长篇小说创作，卡片式创作，支持基于 JSON Schema的结构化 AI 生成与上下文引用，可扩展性强。
秒懂
- 它是什么？
- 这是一个把卡片结构、结构化生成和上下文引用绑在一起的长篇创作工具，Python 后端，AGPL-3.0。它的价值在于把「模型自由发挥」换成「按你定义的结构填字段」，代价是工作流系统仍处于探索阶段，旧数据升级不保证成功。
- 适合谁用？
- NovelForge 适合已经能自己搭 Python 环境、并且愿意先定义卡片 Schema 再动笔的长篇作者，尤其是需要把角色、关系、场景状态跨几十万字保持一致的人。不适合只想打开网页就让模型写一章、不愿维护结构化数据的用户，也不适合无法接受 AGPL-3.0 传染性条款的闭源商业产品。
- 能商用吗？
- 可以，但条件严格。AGPL-3.0 是网络 copyleft 许可证：如果别人通过网络使用你修改过的版本（例如作为托管服务），你必须以同一许可证向他们提供源代码。
- 还在维护吗？
- 在维护。仓库最近一次提交在 14 天前。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
长篇写作里真正难的不是生成，是三个月后还记得角色断了几根手指
短篇生成是一个无状态问题：给提示词，拿文本。长篇不是。写到第 40 万字时，模型需要知道的不只是「主角叫林昭」，还有她此刻在哪个场景、属于哪个组织、手里有什么物品、和谁的关系刚刚破裂。这些信息散落在前面几百章正文里，靠把全文塞进上下文既贵又不可靠。
NovelForge 把这个问题拆成两层。第一层是卡片：角色卡、关系卡、场景卡、组织卡、物品卡、概念卡，每张卡有自己的结构。第二层是引用：写作时通过 @DSL 把需要的卡片数据拉进提示词。README 把这一组设计概括为四大理念，模块化卡片、可自定义的动态输出模型、上下文注入、知识图谱一致性。
目标用户因此相当具体：写长篇、愿意在写作之外维护一份结构化设定、并且能接受本地部署的人。它不解决「没有灵感」，它解决的是「有灵感但前后矛盾」。
Schema-first：让模型填字段，而不是让它写作文
NovelForge 最值得看的设计是生成流程的粒度。README 的更新日志里，v0.9.0 把 AI 卡片生成从「点击后等待整段结果」改成「输入要求，对话框内字段粒度生成，确认或反馈继续生成」。也就是说，模型不是一次性吐出一整张角色卡，而是按 Schema 定义的字段逐个流式填充，你在中途就能叫停或纠正。
这个改动解决的是结构化输出最常见的失败模式：模型返回的 JSON 看起来完整，但某个字段塞了不该有的内容，或者类型不对，等到落库才发现整张卡要重来。字段级填充把校验前移，错误在生成过程中就暴露。
代价是交互变重。你要盯着一轮轮填充做确认，而不是等一个结果然后整体审阅。README 里也写明了这个能力的边界：它只作用于当前这张卡片，关闭生成对话框后本次会话就结束，不保留跨会话的续生成状态。
@DSL 与关系图：上下文注入的具体形态
上下文注入在 NovelForge 里是一个显式动作，不是自动的向量检索。你用 @DSL 在提示词里写明要引用哪些项目数据，系统据此组装上下文。这个选择把控制权交给作者：你决定这一章要带进哪些角色状态、哪些关系。代价是你得记得带，忘了带，模型就不知道。
关系图负责存储角色之间的关系。v0.9.1 的更新日志写明关系图存储新增 SQLite 支持并兼容 Neo4j，同时增加了筛选、批量修改、导入导出。这意味着小项目可以只用一个 SQLite 文件，不需要额外跑图数据库；需要图查询能力的场景再换 Neo4j。
v0.9.4 把记忆层扩展到角色、关系、场景、组织、物品、概念六类，并统一成「先预览、后确认」的流程：基于当前章节正文发起提取，展示预览，允许手动调整，确认后才写回卡片或图谱。这个设计是必要的，因为模型从正文里抽取的状态经常过度推断。README 自己也提醒，这些轻量状态能力按需使用，不一定全都要用上，避免增加上下文复杂度。这句话值得当真：每多挂一类实体，每次生成的提示词就更长。
把它跑起来：端口、环境变量和启动方式
项目主语言是 Python，默认分支 main。README 的「运行指南」章节存在，但提供给我的材料里只有目录锚点，没有具体命令内容，所以这里只能给出材料中确实出现过的配置项。
v0.9.7 的更新日志写明，后端端口可通过 backend/.env 中的 APP_PORT 自定义，默认端口是 54321，并带有 1-65535 的范围校验。也就是说后端默认监听 54321，改端口要在 backend/.env 里改 APP_PORT，而不是改代码。
v0.8.2 的更新日志提到灵感助手的工具调用自动重试次数可通过 .env 文件配置，但没有给出具体键名。v0.9.2 提到「前后端一键启动」，同样没有在材料中给出命令。v0.8.6 增加了 Web 版本适配。
模型配置方面，v0.8.5 的建议是把 DeepSeek、Qwen 之类的模型提供商设为 OpenAI 兼容，OpenAI 则只配 GPT 5 等官方模型。v0.9.6 在 LLM 配置页加入了模型能力检测，可测试基础对话、流式、结构化输出、工具调用等兼容情况。对 NovelForge 来说，结构化输出这一项是硬门槛，因为卡片生成依赖它。
代码式工作流：为什么放弃 DAG，以及这个选择留下了什么麻烦
v0.9.0 把工作流从 DAG 式编辑器迁移到代码式工作流，用 Python 风格语句加特殊标记 DSL 表达，并逐步移除旧 DAG 方案。README 罕见地同时列了优缺点，这点值得引用：优点是逻辑更线性，顺序、等待（Logic.Wait）、异步（async=true）语义贴近真实执行过程；同一个功能代码式几十行就能表达，而 DAG 配置经常需要几百行节点与连线。缺点是不如 DAG 直观，而且对字符串和代码格式更敏感，参数序列化、字典字段类型、变量引用这些细节更容易引发校验或运行错误。
这段自述其实指出了工作流系统当前的真实使用门槛：它更适合能读懂 Python 风格语句的人，对纯图形化操作的用户反而变难了。v0.9.5 的更新日志还提到把拆书工作流改为默认指令流模式以提高成功率，说明基于结构化输出的工作流在稳定性上仍在调。
工作流 Agent 允许用自然语言描述需求，由 Agent 生成或修改工作流代码并校验，支持先预览再应用。README 对它的措辞是「可能还有些bug」，这是项目自己的判断，不是我的推测。节点级进度与中断恢复在材料中标注为 Beta。
字数控制：两种模式，一份 token 账单
章节正文续写的字数控制在 v0.9.3 收敛为两种模式。提示词约束只在提示词层面做字数限制，README 说文本更自然、成本更低，适合对字数要求不严格的场景。控制模式按目标总字数切分为多轮并分配预算，字数控制更稳，但会消耗更多 token。v0.9.3 的说明指出控制模式当前采用固定多轮预算策略。
这是一个明确的取舍，没有免费选项。如果你在写需要严格对齐出版字数要求的章节，控制模式的多轮预算是必要开销；如果你只是想让章节别太短，提示词约束就够了，不必为每章多付几轮调用。
审核功能在 v0.9.3 统一为「先生成审核草稿，再确认创建或更新审核结果卡片」，结果卡片自动归档到根级「审核结果」文件夹。v0.9.2 增加了章节审核、阶段审核和审核历史查看。v0.9.1 为润色和修改加了接受与拒绝操作，降低误替换风险。这一串改动的方向是一致的：所有会改动正文的 AI 操作都要经过一次人工确认。
什么时候不该用它，以及可以换成什么
NovelForge 最明显的不适用场景是短篇和一次性写作。你要先建项目、定义卡片结构、维护关系图，才能拿到结构化生成的好处。写一篇五千字的短篇，这套前期投入收不回来。
另一个不适用场景是模型能力不足。卡片生成依赖结构化输出，灵感助手的工具调用依赖函数调用能力。v0.8.5 为工具调用能力不强的模型补了 ReAct 模式，通过文本格式实现工具调用，但 README 自己说这个实现较为粗糙、可能存在 bug，建议优先使用原生工具调用支持较好的模型。如果你的模型连结构化输出都不稳定，NovelForge 的卡片流程会退化成反复重试。
作为对比，SillyTavern 走的是另一条路：它围绕角色卡和对话上下文组织，靠世界书（World Info）在关键词命中时插入设定，不要求模型返回符合 Schema 的结构，也不做字段级校验。它的强项是对话与角色扮演的即时体验，弱项是缺乏对长篇正文的结构化约束。NovelForge 反过来，把约束放在生成之前，代价是配置更重、对模型要求更高。选哪个取决于你要的是「和角色聊天」还是「把四十万字的设定管住」。
维护成本、许可证，以及升级前必须先备份的那个文件
这个项目的迭代节奏相当快。材料中的发布记录显示 v0.9.5-1 到 v0.9.7 集中在 2026 年 5 月底到 8 月底之间，三个月内三个版本，且每个版本都带功能改动而非纯修复。跟版本意味着持续跟进。
升级风险在 v0.9.0 的说明里写得很直白：由于该版本更新变动较大，旧版本数据库可能无法直接使用，请尝试用发布的迁移脚本进行迁移，不保证成功，建议提前做好数据库 db 文件备份。这是项目方自己的表述。v0.9.2 又加入了自动检查模型元数据与数据库现有表结构差异、补齐可安全追加的缺失列的能力，说明 Schema 演进带来的表结构漂移是这个项目需要长期处理的问题。
许可证是 AGPL-3.0。对个人使用没有影响。如果你打算把它嵌进一个对外提供服务的闭源产品，AGPL 的网络服务条款通常要求向用户提供对应源码，这需要你和法务确认具体边界，我不给法律意见。
最后一条来自 v0.9.7 的更新日志：内置提示词和知识库增加了安全约束，避免误删内置资源或覆盖用户修改，并区分自定义、内置和已修改三种状态。如果你打算长期改提示词，注意这个状态区分，它决定了你的修改在下次版本更新时会不会被重置。
编辑结论
NovelForge 适合已经能自己搭 Python 环境、并且愿意先定义卡片 Schema 再动笔的长篇作者，尤其是需要把角色、关系、场景状态跨几十万字保持一致的人。不适合只想打开网页就让模型写一章、不愿维护结构化数据的用户，也不适合无法接受 AGPL-3.0 传染性条款的闭源商业产品。动手前先确认三件事：你的模型是否通过 v0.9.6 的 LLM 配置页能力检测（结构化输出和工具调用两项），你的关系图要落在 SQLite 还是 Neo4j，以及你是否要沿用旧版本数据库，因为 v0.9.0 的发布说明明确写了旧库可能无法直接使用、迁移脚本不保证成功，建议先备份 db 文件。
社区笔记