把长篇小说创作变成可维护的本地工程资产。

Problem

AI 写小说的主要矛盾不是模型不会写，而是长篇创作会失控。

对长篇网文作者来说，真正困难的是让剧情、状态、设定、伏笔、风格和读者承诺在数十万字后仍然可维护。 如果 AI 只输出一次性文本，作者很快会失去追踪、打回、比较和回退的抓手。

• 已有章节、摘要、世界观、状态卡和文风提示如果只留在聊天上下文里，就无法长期维护。
• 作者想试两条剧情线时，不应该靠复制文件夹，而应该能开真实剧情分支。
• 续写草稿需要审核、人工修改、打回重写和归档接棒，而不是直接覆盖正式章节。
• Agent 生成后的文件变化应该能 diff、能提交、能回退，且不污染源码仓库。
• 部署到新机器时，Dify、模型密钥、Flask 后端和本地书库必须有清晰边界。

Boundary

它不是什么：先排除几个容易误会的范式。

Architecture

总体架构：作者操作工作台，Agent 通过受控工具修改每本书。

真实工作台截图：左侧是文件资产，中间是 Markdown 工作区，右侧是 Agent / Git / 审阅操作面。

Runtime Authority

三个权威源不能混淆。

Data Objects

每本书都是一个可维护的 Markdown 工程。

novel_git_server/storage/<book_id>/
├── .git/
├── chapters/
├── summary.md
├── world_model.md
├── status_card.md
├── domain_rules.md
├── style_fingerprint.md
├── style_review.md
├── style_constraints_for_continuation.md
├── brainstorm.md
├── master_outline.md
├── arc_outline.md
├── chapter_outline.md
├── chapter_draft.md
├── error_archive.md
└── import_report.json

• summary.md 是正式章节派生的阅读档案，由后端摘要归档管线生成和重建。
• world_model.md 是长期世界规则，status_card.md 是当前章节后的状态投影。
• 四个大纲文件分层承担灵感池、长线承诺、篇章留存和可执行章节卡。
• chapter_draft.md 是续写草稿和审阅面，只有作者确认后才归档进 chapters/*.md。
• error_archive.md 用来沉淀审核问题，让续写系统能读到历史打回经验。

Production Pipeline

章节生产不是“直接写正文”，而是草稿、审核、重写和归档的交付管线。

1. 导入与初始化

   小说导入为 chapters/*.md，再由后端批处理生成摘要、世界/状态、文风和大纲底座。

2. 分层大纲

   brainstorm.md、master_outline.md、arc_outline.md 和 chapter_outline.md 分别承载灵感、长线、篇章和章节卡。

3. 滚动三章

   控制器读取已接受章节、待审草稿和章节卡，触发现有续写 Agent；控制器本身不写小说正文。

4. 审核与打回

   审核 Agent 给出剧情、设定、状态和断章风险；打回重写时，续写 Agent 需要读取审核建议、旧草稿和错误档案。

5. 作者确认归档

   作者可以直接修改草稿；确认后后端拆分章节，写入 chapters/*.md，清理草稿并更新状态桥接。

Agent Ownership

Dify 和 LangChain 不是二选一，而是分层合作。

Code Map

核心代码导读：从工作台、后端、管线到部署。

Call Chains

关键调用链：从作者动作到本地书库。

BookshelfApp
  -> frontend/src/api/tomatoImport.ts
  -> /books/tomato/*
  -> novel_git_server/agents/tomato_import.py
  -> chapters/*.md + import_report.json
  -> summary / world / style initialization
  -> nested Git commit

Workbench action / ChatPanel
  -> /api/world/deduce_stream
  -> Dify continuation Agent
  -> LoreGit ToolProvider
  -> chapter_draft.md
  -> prose delivery state

Prose delivery acceptance
  -> read .loregit/prose_delivery_state.json
  -> split accepted chapter_draft.md
  -> chapters/*.md
  -> reset chapter_draft.md
  -> status / summary bridge
  -> nested Git commit

GitBranchPanel
  -> /books/git_history_list?ref=...
  -> timeline view without checkout

explicit checkout
  -> /books/git_checkout
  -> dirty / draft guard
  -> actual branch switch

Evaluation

评估不靠“感觉能写”，而靠可验证链路。

python -m pytest novel_git_server/tests/test_v78_prose_delivery_api.py novel_git_server/tests/test_v79_public_demo_mode.py -q
python deploy/demo/deploy_doctor.py --profile local --env deploy/demo/.env
python deploy/demo/deploy_doctor.py --profile public-demo --frontend-url http://127.0.0.1:15173
git diff --check

Run

部署分本地 demo 和受控体验版，两者验收口径不同。

.\start_demo.ps1 -InitEnv
# 编辑 deploy/demo/.env
.\start_demo.ps1

python deploy/demo/deploy_doctor.py --profile local --env deploy/demo/.env --backend-url http://127.0.0.1:8000 --frontend-url http://127.0.0.1:5173

python deploy/demo/deploy_doctor.py --profile public-demo --env /etc/novel-agent-demo.env --backend-url http://127.0.0.1:18000 --frontend-url http://127.0.0.1:15173

本地画像不检查会话隔离；云端受控体验版必须检查 cookie 沙箱、配置中心只读、Dify 无 cookie 工具回调绑定和 book_id 优先级。完整步骤见 部署说明。

Release Boundary

公开仓库应该包含什么，不应该包含什么。

FAQ

常见疑问。