一个面向长篇小说创作的 AI Native 开源项目。
当前开发主线：
Creative Hub + 自动导演开书 + 整本生产主链 + 写法引擎
这是一个面向长篇小说的 AI 生产系统。
它不再是“你写一句，AI补一句”的聊天模式，而是：
- 👉 从一个想法出发
- 👉 自动构建世界观、人物、剧情结构
- 👉 管理知识与设定（RAG）
- 👉 控制写作风格与叙事一致性
- 👉 最终生成完整章节甚至整本小说
很多 AI 写作工具的使用方式其实差不多：
- 你输入一句 Prompt
- 它回你一段正文
- 不满意就重试
- 写短篇还行，写长篇容易越写越散
这个仓库是“AI 导演式长篇小说生产系统”，而不是传统的写作聊天壳子。
它最核心的产品判断是：
- 目标用户优先是完全不懂写作的新手，而不是熟悉结构设计的资深作者。
- 优先解决“如何把整本书写完”，再逐步优化“写得多精巧”。
- AI 不只是一个补全文本的模型，而是参与规划、判断、调度、执行和追踪的系统角色。
如果你正在找的是下面这种项目，这个仓库会更值得关注：
- 想验证 AI 是否真的能参与整本小说生产，而不是只写单段文案。
- 想研究 AI Native Product、Agent Workflow、LangGraph 编排怎样落到真实创作业务。
- 想把世界观、角色、拆书、知识库、写法控制和章节生成串成一套稳定工作流。
- 可以从一句模糊灵感直接进入自动导演，不必先自己把世界观、主线、角色和卷纲全想完；系统会先整理项目设定、对齐书级 framing，再生成多套整本方向和对应标题组。
- 方案选择不再只是“满意就确认、不满意就整批重来”。如果第一轮方向不够准，可以继续生成下一轮；如果已经偏向某一套，也可以只让 AI 修这套方案，或者只重做这套的标题组。
- 自动导演创建时已经支持三种推进方式：
按重要阶段审核、自动推进到可开写、继续自动执行前 10 章。对应链路会把书级方向、故事宏观规划、角色准备、卷战略、节奏拆章和章节执行接成一条连续流程。 - 这条链路已经支持检查点恢复、现有项目接管、页内继续推进和换模型重试。到
front10_ready之后，不仅能直接进入章节执行，也可以继续让 AI 自动执行前 10 章的写作、审校和修复。 - 自动导演里的角色阶段也不再无条件把第一套阵容直接落库。现在会优先生成可直接进入正文的人物资产；如果角色名仍像功能位、缺少身份锚点或质量不够稳定，系统会停在角色审核点，而不是继续把坏阵容带进后续卷规划和拆章。
Creative Hub现在已经不只是一个聊天页，而是在往统一创作中枢收：对话、追问、规划、工具调用、执行状态和回合总结都在往这里并。- 系统里已经有了比较明确的 Planner、Tool Registry、Runtime、审批节点、状态卡片和中断恢复链路，说明这个项目现在关注的已经不是“AI 会不会写字”，而是“AI 能不能组织一条真实的创作工作流”。
- 如果你关心的是 AI Native Product 怎么落地，这一块已经不是零散按钮拼盘了，而是开始长出一套值得继续往下做的骨架。
- 单章运行时、章节执行和整本批量 pipeline 现在都在往同一条主链上收，不再是“这里一个试写入口，那里一个批量按钮”的割裂状态。
- 已经可以从结构化规划、章节目录和资产准备状态出发，启动整本写作任务，并持续查看当前阶段、失败原因和下一步建议。
- 它当然还不是那种完全不用管的一键出书机，但也已经不是“只能演示几张截图”的阶段了，至少主链是真的能往前推。
- 写法现在不再只是提示词里的一段长说明，而是可以保存、编辑、绑定、试写和复用的长期资产。
- 可以从现有文本里提取写法特征，并把原文样本一起保存下来，后面不是只能靠记忆去猜“当时那个味道到底怎么来的”。
- 提取出来的特征会沉淀成可见特征池，进入编辑页以后可以逐项启用、停用和组合，写法规则也会跟着同步重编译，便于后续试写、修正和整本绑定。
- 这意味着写法引擎现在已经开始真的参与生成、检测和修正链路，而不是一个摆在侧边栏里的概念功能。
- 世界观已经不只是大段设定文本，而是支持创建、分层设定、快照、深化问答、一致性检查和小说绑定的结构化资产。
- 角色体系也不再只是静态角色卡，已经开始往动态角色资产走，会把关系阶段、卷级职责、缺席风险和候选新角色一起带进后续规划与生成。
- 拆书结果可以继续发布到知识库，再回灌到续写、规划和正文生成；知识库本身也已经支持文档管理、向量检索、关键词检索和重建任务追踪。
- 换句话说，这一块现在已经开始像“长期记忆系统”，而不是做完一次设定就丢在那里的资料堆。
- 已经支持 OpenAI、DeepSeek、SiliconFlow、xAI 等多提供商配置，规划、正文、审阅这些链路可以按路由拆开配。
- 前后端已经完成 Monorepo 拆分，适合本地持续开发，也比较适合继续往 Prompt Registry、Workflow Registry 和 Runtime 这条路上扩。
- 默认使用 SQLite 就能把主链先跑起来；如果你要完整体验知识库 / RAG，再按需接 Qdrant 就行，不需要一上来就把所有基础设施堆满。
- 在小说创建页输入一句灵感，先让 AI 自动导演给出整本方向候选。
- 进入
项目设定，先把题材、卖点、目标读者感受和前 30 章承诺定下来。 - 用
故事宏观规划、角色准备和世界观资产，把整本主线、角色网和世界边界补到能写。 - 进入
卷战略 / 卷骨架决定怎么分卷，再到节奏 / 拆章把当前卷落到章节列表和单章细化。 - 按需绑定拆书结果、知识库文档和写法资产，让后续正文不只是靠一次性提示词。
- 进入
章节执行逐章写作、审计、修复，必要时回到卷工作台做再平衡和重规划。 - 想加速推进时，再启动整本生产任务，持续查看状态、失败原因和回灌结果。
- 开书定盘负责先把这本书“要写成什么样”说清楚，避免后面越写越散。
- 整本控制层和卷级规划层负责把长篇拆成可推进、可回看、可调整的结构，而不是一次性写死。
- 角色、世界观、写法、知识库和质量控制一起托住单章生成，让每一章都尽量还在同一本书里。
- 每写完一章，系统都会把新状态回灌回去，继续影响后续章节、卷级节奏和必要时的重规划。
完整历史更新见 docs/releases/release-notes.md。
重大更新：小说工作台开始同时补强“从当前真实步骤继续推进”和“把当前成果直接导出留档”这两条主链，自动导演接管、章节执行状态反馈和整书资产导出都更完整了。
- 当前步骤接管更顺：编辑页会更明确告诉你现在位于哪一步，并支持从当前步骤重新交给 AI；如果章节自动执行批次本来就在跑，系统也会更清楚地区分是在恢复旧批次，还是按当前范围新开一批。
- 章节状态更好判断：正文生成后的收尾、资产同步和结果反馈补得更完整，连续执行多章时更容易看懂现在是在写作、同步还是等待处理，不会只看到一个笼统状态。
- 结构化链路更稳：状态抽取、角色动态、审计和相关规划链路在面对模型输出边界不整齐、字段偏长或结构轻微漂移时，更不容易整步失败，长链路自动推进更稳定。
- 导出能力补齐：现在可以按当前步骤或整本书直接导出
Markdown / JSON，把项目设定、故事宏观规划、角色准备、卷战略、节奏拆章、章节执行和质量修复内容一起带走，更适合留档、协作和二次加工。 - 工作台里的 AI 接管入口更贴近当前步骤了：如果自动导演正在恢复或等待，编辑页不会再重复塞一个容易误导的接管面板；当系统还在加载可接管状态时，也会先给出明确的加载按钮提示。
- 角色形象图生成更适合直接上手了：弹窗现在会先把原链路实际发送给图片模型的完整 prompt 展示出来，并支持一键把角色描述优化成更适合出图的中文或英文 prompt；如果你采用 AI 优化结果，系统会直接把优化后的 prompt 发给图片接口，不再继续叠加原链路内容。
统一承载对话、规划、工具执行和创作推进的创作中枢。
从一句想法出发，先选整本方向，再决定是阶段审核、自动推进到可开写，还是直接继续自动执行前 10 章。
先把题材、卖点、读者预期和前 30 章承诺讲清楚，再把后续规划和生成都建立在同一条开书控制轴上。
从整本走向、阶段升级和长线兑现出发，先把长篇主线搭稳，再继续卷级和章节级规划。
围绕主角团、关系网和卷级职责做角色准备，减少开书后角色断档、功能位缺失和关系推进失速。
先决定怎么分卷、哪些卷要硬规划，再把每卷使命、升级节点和卷尾钩子钉稳。
先看当前卷节奏，再把节奏落实成章节列表和单章细化，卷内推进链路更适合连载网文的追读节奏。
章节执行页把章节导航、当前结果和 AI 快捷操作放进同一工作流里，适合逐章推进、审计和修复。
在正文编辑页里直接回看当前章、修正文案，并继续衔接任务单、审计结果和修复链路。
从这里进入开书、管理、编辑和整本生产。
把参考作品拆成结构化知识，再回灌给后续创作链路。
统一管理文档、索引、重建任务和检索能力。
世界观不再只是描述文本，而是能被绑定、检查和持续维护的结构化资产。
统一维护角色基础档案与小说内角色信息。
集中维护题材与类型资产，让故事规划、角色准备和正文生成共享同一套题材语言。
把推进模式、兑现方式和冲突边界收成可复用的流派模式资产，让整本书更容易保持读者预期。
批量生成、筛选和微调书名与标题方向，降低新手在开书命名阶段的试错成本。
统一管理写法资产、风格约束和反 AI 规则，让正文更像作品本身，而不是模板式补全文本。
查看拆书、知识库重建和其他后台任务的排队、执行与失败状态。
为不同能力配置不同模型，减少一套模型硬吃所有任务的成本。
- Node.js
^20.19.0 || ^22.12.0 || >=24.0.0推荐直接使用20.19.x LTS - pnpm
>= 9.7 - 至少一组可用的 LLM API Key 也可以先把项目跑起来，再在页面里配置
- 如果你要完整体验知识库 / RAG，再额外准备可用的 Qdrant
pnpm install如果你在 Windows 上执行 pnpm install 时卡在 prisma preinstall，通常先检查这两类问题：
- Node 版本过低
Prisma 7 目前要求 Node
^20.19.0 || ^22.12.0 || >=24.0.0。如果你还在20.0 ~ 20.18，建议先升级到20.19.x LTS再安装。 script-shell被配置成了交互式 shell 如果全局npm/pnpm script-shell被设成了cmd.exe /k之类会保留提示符的形式，Prisma 的 lifecycle script 可能不会自动退出，看起来就像安装“卡死”在：node_modules/.../prisma>
可以先运行下面几条命令自查：
node -v
pnpm config get script-shell
npm config get script-shell如果 script-shell 返回的是带 /k 的 cmd.exe，建议删除这项配置后重新打开终端：
npm config delete script-shell
pnpm config delete script-shell然后重新执行：
pnpm install这个仓库通过 pnpm workspace 分别启动前后端，所以环境变量也是按子包读取的：
- 服务端运行在
server/工作目录，默认读取server/.env - 前端运行在
client/工作目录，默认读取client/.env/client/.env.local - 根目录
.env.example目前更适合当“总览参考”，不是pnpm dev默认读取的主入口
先复制服务端示例文件：
# macOS / Linux
cp server/.env.example server/.env
# Windows PowerShell
Copy-Item server/.env.example server/.env最少建议先确认这些项目：
DATABASE_URL默认就是本地 SQLite，可直接使用RAG_ENABLED如果你暂时不接知识库，建议先设为falseQDRANT_URL、QDRANT_API_KEY只有要启用 Qdrant / RAG 时才需要
注意：
OPENAI_API_KEY、DEEPSEEK_API_KEY、SILICONFLOW_API_KEY这类变量可以先留空- 项目启动后，也可以在页面中配置模型供应商和默认模型
大多数本地开发场景，其实不需要单独创建前端 env。
因为前端开发模式下默认会把 API 指到：
http(s)://当前页面 hostname:3000/api
这也包括“同一台机器启动服务，然后用局域网 IP 在别的设备上访问”的场景。
例如页面开在 http://192.168.0.37:5173，前端默认会自动把 API 指到：
http://192.168.0.37:3000/api
只有在这些场景下，才建议创建 client/.env：
- 前端和后端不在同一台机器
- 你想把前端显式指向别的 API 地址
- 你需要固定
VITE_API_BASE_URL
如果你已经复制了 client/.env.example，又发现浏览器请求都跑到了 http://localhost:3000/api，通常就是因为你把 API 显式固定死了。对同机 / 局域网访问，建议直接删除或注释掉 VITE_API_BASE_URL。
示例：
# macOS / Linux
cp client/.env.example client/.env
# Windows PowerShell
Copy-Item client/.env.example client/.env内容通常只需要：
# 同机 / 局域网访问时，通常不需要这一行
# VITE_API_BASE_URL=http://localhost:3000/api当前项目已经支持在页面里配置模型相关设置：
/settings配置供应商 API Key、默认模型、连通性测试/settings/model-routes给不同任务分配不同 provider / model/knowledge?tab=settings配置 Embedding provider、Embedding model、集合命名和自动重建策略
所以环境变量里的 OPENAI_MODEL、DEEPSEEK_MODEL、EMBEDDING_MODEL 等，更适合当作：
- 启动默认值
- 数据库里还没保存设置时的回退值
pnpm dev如果你已经复制好了 server/.env 和 client/.env，默认就是直接运行这一条。
不需要在首次启动前手动再执行 prisma generate、prisma db push 或 pnpm db:migrate。
默认情况下：
- 前端：
http://localhost:5173 - 后端：
http://localhost:3000 - API：
http://localhost:3000/api
首次启动服务端时，会自动执行 Prisma generate 和 db push。
只有在你自己修改了 Prisma schema，或者要处理正式迁移流程时，才需要手动使用 Prisma / 数据库相关命令。
建议第一次启动后先做这几步：
- 打开
http://localhost:5173/settings，至少配置一组可用的模型供应商 API Key - 打开
http://localhost:5173/settings/model-routes，检查各任务实际使用的模型路由 - 如果要启用知识库，打开
http://localhost:5173/knowledge?tab=settings，保存 Embedding / Collection 设置
如果你只是先体验主流程，其实可以先跳过 Qdrant，直接在 server/.env 里设：
RAG_ENABLED=false如果你要启用 Qdrant Cloud，可以按下面的最小流程来：
- 到 Qdrant Cloud 注册账号。
- 在
Clusters页面创建一个集群。 测试阶段用 Free cluster 就够了。 - 集群创建完成后，到集群详情页复制 Cluster URL。
- 在集群详情页的
API Keys中创建并复制一个 Database API Key。 这个 key 创建后通常只展示一次，建议立即保存。 - 把它们写入
server/.env：
QDRANT_URL=https://your-cluster.region.cloud.qdrant.io:6333
QDRANT_API_KEY=your_database_api_key- 启动项目后，再去
知识库 -> 向量设置页面选择 Embedding provider / model，并保存集合设置。
对这个项目来说，QDRANT_URL 建议直接填 REST 地址，也就是带 :6333 的地址。
如果你想手动验证连通性，可以用：
curl -X GET "https://your-cluster.region.cloud.qdrant.io:6333" \
--header "api-key: your_database_api_key"你也可以把集群地址后面拼上 :6333/dashboard 打开 Qdrant Web UI。
Qdrant 官方文档：
下面这些都不是首次启动 pnpm dev 的前置步骤：
pnpm db:seed
pnpm db:studiopnpm dev
pnpm build
pnpm typecheck
pnpm lint
# 仅在你开发/调整 Prisma schema 时再手动使用
pnpm db:migrate
pnpm db:seed
pnpm db:studio
pnpm --filter @ai-novel/server test
pnpm --filter @ai-novel/server test:routes
pnpm --filter @ai-novel/server test:book-analysis| 层级 | 技术 |
|---|---|
| 前端 | React 19、Vite、React Router、TanStack Query、Plate |
| 后端 | Express 5、Prisma、Zod |
| AI 编排 | LangChain、LangGraph |
| 数据库 | SQLite |
| RAG | Qdrant |
| 工程形态 | pnpm workspace Monorepo |
client/ React + Vite 前端
server/ Express + Prisma + Agent Runtime + Creative Hub
shared/ 前后端共享类型与协议
images/ README 与产品预览截图
scripts/ 启动和辅助脚本
docs/ 设计文档、阶段检查点、模块计划与历史归档
更细的文档分区说明可以看 docs/README.md。
Creative Hub负责统一创作中枢与 Agent 运行时体验Novel Setup / Director负责从一句灵感走到整本可写Novel Production负责整本生成主链Style Engine负责写法资产、特征提取、绑定和反 AI 协同Knowledge / Book Analysis / World负责长期上下文沉淀与回灌
当前最重要的不是继续堆零散功能，而是提高“小白把整本书写完”的成功率。
- 把自动导演、Novel Setup、整本生产主链进一步收拢成稳定闭环
- 让用户从一句灵感进入“整本可写”状态
- 降低新手在写法、世界观、角色和章节规划上的认知负担
- 提高整本一致性、节奏稳定性和人物成长质量
- 让写法资产、世界观约束、章节重规划和审阅反馈形成闭环
- 让系统更擅长“持续掌控整本书”，而不只是“生成某一章”
- 继续强化多阶段 Agent 协同
- 完善更自动化的生产调度、回合记忆和整本质量控制
如果你想反馈问题、交流使用体验，或者讨论自动导演、整本生产主链、写法引擎等方向，可以扫码加入 QQ 群。
如果你想参与这个项目，最有价值的贡献方向包括：
- 提升整本生产稳定性
- 改善新手开书体验和自动导演成功率
- 强化写法引擎、知识库回灌和世界观一致性链路
- 补充测试、错误回放和运行时可观察性
欢迎直接提 Issue 或 Pull Request。
感谢提交修复 Pull Request 的贡献者 @ystyleb。
- 这是一个持续快速迭代中的 AI Native 创作系统，功能边界仍在演化。
- README 优先描述当前最值得体验、最能代表方向的能力，而不是列出全部历史实现细节。
- 如果你更关心阶段目标、优先级和后续优化计划，请直接查看 TASK.md。
This project is licensed under the MIT License. See LICENSE for details.