AI辅助网文创作理论研究初步总结（二）：完整的总结

sanshanjianke

243人浏览 · 2026-05-08 15:30:21

sanshanjianke · 2026-05-08 15:30:21 发布

目前项目只完成了30%左右，欢迎大家一起来pr，另外我建了一个QQ群：1103861504，可以一起来讨论AI写小说问题。俺基本上一天16个小时都在线，有问必回。（QAQ，加个群来讨论吧，作者单机好久了🤣）。

上次那个总结还是太浅，而且结构做的很差，这次重新总结一下。从理论总结、使用和设计思路、代码框架，三个方面进行总结。

AI辅助网文创作系统——理论总结

本文档整合了项目从理论奠基到架构演进的完整思想体系，作为所有设计文档的理论根基。阅读本文档可替代逐篇阅读笔记1-17中的理论内容。

一、核心设计哲学

1.1 第一性原理：”故事”与”叙事”分离

本系统的理论根基建立在叙事学的一个核心区分之上：

概念	定义	示例
故事（Fabula）	客观发生的事件序列	“A 打败了 B”
叙事（Discourse）	事件的呈现方式	“从 A 视角的热血复仇 vs 从 B 视角的悲情退场”

传统 AI 写作的根本问题是：用户输入模糊创意，指望 AI 一步到位写出正文。这相当于跳过蓝图设计，直接指挥工人砌砖——没有图纸，工人（AI）只能盲目堆砌材料。

如果不分离”故事”和”叙事”，AI 会在同一轮思考中既想结构又琢磨文笔，结果两头都做不好。“故事”管”讲什么”，”叙事”管”怎么讲”。同一个故事，换一种叙事策略，可以产生完全不同的阅读体验。

1.2 分层创作：从粗到细逐步推进

传统做法是用户给 AI 一段模糊创意，指望一次生成完整正文。这就像没有图纸直接盖楼——工人只能盲目堆砌材料。

本系统将创作过程分解为多个层级，每层有明确的输入输出，自顶向下、逐步细化：

不跳层：不指望从模糊创意一步跳到正文
可介入：每层结束时用户都可以审核修改
可回溯：下游发现问题可打回上游重新处理

1.3 人机协同定位：系统是”副驾驶”

本系统不是全自动生成工具。AI 的定位是辅助而非替代：

AI 提方案，人做决定
每一层都有人的决策权
全自动模式下已有 AI 监督代理人类决策，但半自动模式下阻塞是真实的——必须等用户操作

二、四层 + 卷纲层模型

2.1 模型总览

L1   种子层       故事愿景       "我要写一个什么样的故事"
L1.5 情节编排层   卷纲           "分成几卷，每卷走向如何"
L2   架构层       章纲           "每章的精确功能序列"
L3   叙事层       带标签草稿      "草稿嵌入叙事指令"
L4   渲染层       精修正文       "扩展打磨成终稿"

2.2 L1 种子层

项目	说明
角色	创作顾问
输入	用户模糊创意
输出	《故事愿景文档》
实现方式	引导式表单/对话式采集

产出内容：

核心梗/脑洞：一句话概括故事核心冲突
阅读契约：目标读者群体、核心爽点类型、风格基调（轻松/暗黑/热血/搞笑）
粗略大纲：故事的起承转合，几百字的叙事散文
核心设定：世界观、主角人设（性格+动机+成长方向）、金手指机制
热点/潮流元素（可选）：时下热点的融合方式，评估时效性
类型标签与目标平台：明确类型定位（#玄幻 #系统文 #种田文），不同平台策略不同

L1 不依赖 AI 逻辑——这一层的本质是结构化采集器，将用户脑中的模糊创意梳理成系统可读取的格式。AI 在此的角色是”聊出来”，而非”想出来”。

2.3 L1.5 情节编排层

L1 给出的粗略大纲通常是几百字的叙事散文（”主角加入宗门后慢慢变强，最后在大比夺冠”），而 L2 需要结构化的功能序列。从散文到序列的跳跃太大。软件开发不会从需求文档直接跳到函数设计——中间必定有系统设计层处理模块划分。L1.5 就是创作中的系统设计层。

项目	说明
角色	资深作者 + 读者代表（两专家会议）
输入	L1 愿景文档 + 世界书核心层
输出	卷纲 .md（每章 1-3 句方向性描述）
粒度	卷级方向决策，非功能序列

输出格式：以卷为单位，每卷包含：篇幅范围、时间跨度、主线走向、支线安排、本卷高潮、章节概要（每章核心事件+人物出场+情绪基调+衔接说明）、卷末衔接（已回收伏笔、遗留伏笔、下一卷启动条件）。

两专家分工：

专家	职责	核心关注
资深作者	创作方向把控	提出分卷方案、判断热点方向、毒点预警。例如”30章后必须开新地图，不然读者疲劳”
读者代表	体验审核	模拟读者情绪、检测疲劳点、质疑合理性。只负责提”哪里可能有问题”，不提出解决方案

L1.5 和 L2 的分工：L1.5 决定”第 31-35 章写秘境探索”，L2 决定”具体功能链怎么排来实现这个探索”。L1.5 讨论方向对不对，L2 执行落地拆解。

2.4 L2 架构层

项目	说明
角色	三专家会议（剧情架构师 + 网络编辑 + 人物设计师）
输入	L1 愿景 + L1.5 卷纲 + 世界书 + RAG
输出	《精修故事大纲》，含多维功能标注
粒度	功能→序列→情节三个层次

叙事学结构概念：

功能（Function）：故事中最小的叙事单位。如”铺垫”、”阻碍”、”转折”、”获得”。
序列（Sequence）：由功能组成的完整叙事句子，具有时间和逻辑关系。分为链状（顺序执行）、嵌入（大序列套小序列）、并列（多条并行）。
情节（Plot）：序列按继承原则（时间/因果/空间连接）或理念原则（否定/实现/中心句连接）组合而成的完整故事。

三层粒度：

层次	对应	时长	功能
微观序列（爽点/节拍）	单次”装逼打脸”、单次”系统抽奖”	几分钟到十几分钟	提供即时情绪价值
中观序列（剧情单元/副本）	“拍卖会篇”、”宗门大比篇”	几十章甚至上百章	完成中期目标，推动阶段性变化
宏观情节	整本书	全书	核心冲突与结局

2.5 L3 叙事层

项目	说明
角色	映射编译器/翻译器
输入	L2 精修大纲（含多维功能标注）
输出	带标签草稿（500-1000字章节草稿，嵌入叙事指令标签）

L3 是整个系统理论的核心创新——效果到技术的确定性映射。

理论背景：网文理论和叙事学是两套不同的语言体系：

网文理论属于”效果学”——”欲扬先抑”、”装逼打脸”描述的是读者心理反应，语言是模糊的、经验主义的。
叙事学属于”结构学”——”外聚焦视角”、”慢速扩述”、”自由间接引语”描述的是文本组织方式，语言是精确的、结构主义的。

L3 的使命是把效果学指令编译为结构学指令。这不是让 AI 临场推理哪个视角适合打脸——每次推理结果不同，质量不稳定。而是建立一套确定性的映射规则库。

带标签草稿的形态：L3 输出不是纯 JSON 指令表，而是在粗略正文草稿中嵌入叙事标签（如 <视角 type="外聚焦">、<节奏 type="慢速扩述">、<情绪 type="压抑积累" 强度="↑"> 等）。这些标签在传给 L4 之前经过正则预处理，将简写属性展开为完整提示词约束。

为什么比纯指令好：旧 L3 输出 JSON（”场景1：视角=外聚焦，字数=300”），AI 拿到表格需要自己想象场景。带标签草稿给出了上下文——AI 看到的是一段已经用外聚焦角度写好的草稿，知道”写到这个地方的时候换视角”。

2.6 L4 渲染层

项目	说明
角色	执行者
输入	L3 带标签草稿（经过预处理展开的标签）
输出	精修正文
核心约束	不是自由创作，而是带约束的文本扩展

L4 严格遵守标签中的约束：视角（只写所见不写所想）、节奏（字数控制）、话语模式（句式结构）。标签在 L3→L4 过渡时已转换为完整提示词约束，L4 不需要再次理解标签含义，只需执行。

多技能体系：L4 支持 7 种可切换的技能——初稿扩展、文风调校、删改压缩、描写增强、对话打磨、保守修复、终稿润色。用户可根据实际效果切换技能而非反复修改同一 prompt。

2.7 层间关系：迭代闭环

四层不是不可回退的单行道：

L3 发现映射困难可打回 L2 重审
L2 发现方向问题可打回 L1.5 重新编排
L1.5 可基于 L2 反馈调整卷纲
L4 发现标签约束不合理可回传 L3 调整

每一层都有人的决策权——AI 提方案，人做决定。

三、专家会议体系

3.1 为什么需要异质化专家而非单一 Agent

网文创作本质上包含三类互不隶属的能力：

能力	对应的专家	核心思维模式
结构逻辑	剧情架构师	理性推演：因果闭环、序列完整性
市场嗅觉	网络编辑	商业直觉：爽点密度、读者心理
角色共情	人物设计师	代入感：人设一致性、行为动机

在一个 prompt 里同时要求这三种能力时，它们会互相干扰：

追求逻辑时压制爽感（”这样更合理但不好看”）
追求爽感时人物崩坏（”为了打脸强行降智配角”）

三位异质化专家各挂专属知识库，各自从专业角度发言，用户担任主编拥有最终决策权——这与真实出版业的选题会模式一致。

3.2 三位核心专家

剧情架构师——故事的”骨架”：

将脑洞拆解为功能与序列，指明每个功能的剧情作用
构建因果闭环，修补逻辑漏洞
确保序列间的因果链完整：铺垫→阻碍→转折→回收

网络编辑——故事的”市场”：

审核商业卖点：识别情节是否符合类型文的”阅读契约”
把控节奏与爽点：设计期待感曲线，控制”压抑-释放”的商业节奏
反馈读者心理：模拟真实读者反应，指出”劝退”或”无趣”的段落
毒点规避：主角圣母、配角降智、节奏拖沓等常见雷区

人物设计师——故事的”血肉”：

分配行动元（主体/客体/发送者/接收者/帮助者/敌对者）
根据人物性格推导行为，防止 OOC（Out Of Character）
区分扁形人物（特性稳定、功能性强）与圆型人物（特性复杂、承载主题）
设计人物互动的张力模式

3.3 三种驱动模式

不同类型的网文有不同的约束优先级。驱动模式决定了专家发言顺序和各自权重：

模式	发言顺序	适用场景	原理
人物驱动流	人物设计师 → 剧情架构师 → 网络编辑	文青文、种田文、成长向	角色性格是硬约束，情节围绕人物展开
剧情驱动流	剧情架构师 → 人物设计师 → 网络编辑	无限流、系统文、副本向	剧情是模具，人物填充其中
市场驱动流	网络编辑 → 剧情架构师 ↔ 人物设计师	跟风热点、商业定制	爽点是硬约束，剧情和人物都为其服务

市场驱动流与其他两种不同——编辑与架构师/人物设计师之间是互相迭代的关系，而非单向传递。这是因为商业定制场景下，”什么好看”和”怎么实现”需要更紧密的来回磋商。

3.4 协作模式

模式	行为
semi_auto（半自动）	每位专家发言后暂停，用户审核决策才能继续
full_auto（全自动）	专家自动发言，用户纯旁听；用户随时可插话，插话后自动切回半自动
manual（手动）	用户指定哪一位专家发言，类似点名提问

3.5 L1.5 的两专家

L1.5 的会议结构与 L2 类似但侧重不同——这里不需要逻辑推演和 OOC 检测，需要的是方向决策：

专家	职责	约束
资深作者	热点判断、爽点方向、毒点预警、结构经验	主导，提出方向方案
读者代表	读者预期管理、疲劳度检测、代入感评估	只提”哪里可能有问题”，严禁提出”应该怎么写”——这是作者和架构师的事

读者代表必须以读者口吻发言（”我看到第XX章的时候会觉得……”），不负责解决方案。

3.6 架构演进：从独立层级到统一编排层

L1.5 和 L2 最初被设计为两个独立层级（各自有独立的 API 和专家实现）。但后期发现两者的本质相同——都是”取专家队列 → 按序发言 → 流式输出 → 格式化产出”，区别仅在专家组合和默认粒度。因此合并为统一的编排层：

不再区分 L1.5 和 L2 作为独立层的概念
专家池统一：资深作者、读者代表、剧情架构师、人物设计师、网络编辑、章节拆分师、讨论总结师
用户可在画布上自由拖拽组合专家，通过连线定义发言顺序
预置三个模板覆盖所有历史使用场景：快速审核（网编）、卷纲规划（作者+读者）、章纲设计（架构+编辑+人物）
旧的 L1.5/L2 API 保留为向后兼容，底层委托给统一引擎

四、数据支撑：长文本记忆问题

AI 创作长篇小说的核心挑战之一是记忆——前文写过什么、人物现在是什么状态、哪些伏笔还没回收。这个问题的解决方案不能是”全塞进上下文窗口”（成本 + 注意力衰减）。

系统用两套互补机制解决这个问题：

世界书 (World Book)           RAG-历史回顾
确定性状态管理                 语义检索过往记忆
"主角现在是金丹期"             "老周第45章说过..."
保证不犯错                    保证不遗忘

世界书维护的是当前已知事实——不需要”猜”，直接查就有。RAG-历史回顾检索的是前文片段的原文——当 AI 需要回想某个角色过去的具体言行时，从向量库中提取相关段落。

注意区分：L2/L3/L4 所需的写作技法知识（爽点公式、映射规则、参考范例）是另一个层面的问题——那是写作知识库，解决的是”怎么写更好”，属于第六章讨论的映射规则库和技法库。本章只讨论”故事记忆”。

4.1 世界书（World Book）

灵感来自 SillyTavern 的触发词上下文注入系统，但扩展为完整的跨层持久化状态层。

四层结构：

层	内容	特性
核心层	世界观规则、力量体系、核心设定、阅读契约	永久条目，不随剧情变化
活跃层	人物状态、活跃伏笔、当前道具、势力状态	随剧情实时更新，权重机制
归档层	已完成序列摘要、已回收伏笔、退场人物、版本历史	压缩为一句话概括
索引层	条目-章节映射、关系图、触发词索引	元数据，用于检索

关键机制：

版本链非覆写：主角修为不写”现在是元婴期”，而是 [1-30:筑基]→[31-80:金丹]→[81-今:元婴]。保留完整版本历史比只写当前状态多不了多少 token，但对 AI 理解角色成长弧光至关重要。
重要性衰减：每个条目标记权重分数——被创作引用 +1，连续 10 章未引用 -1，归零归档。防止世界书无限制膨胀。
自动压缩：已完成序列从详细描述压缩为摘要。归档层存储”一句话概括+关键数据”。
增量注入策略：世界书条目不全部注入上下文。L2 专家会议注入核心层+相关活跃层+上一序列摘要；L4 渲染层只注入当前场景相关条目。

世界书管理员 Agent：作为元层后处理，不参与创作讨论。每序列完成后：读取产出 → 提取变化 → 更新条目 → 冲突检测 → 产出变更摘要。角色类似档案管理员，而非第四位专家。唯一的主动行为是冲突检测——发现新产出与旧设定矛盾时提醒主编。

4.2 RAG-历史回顾

当小说超过百万字时，把前文全塞进上下文不可行：

成本不可接受：即使 1M 上下文窗口，每轮创作把 200 章全文塞进去，token 费用极高
注意力衰减：lost-in-middle 问题意味着模型对 prompt 中段的注意力显著低于首尾，全量塞入反而降低质量
噪音干扰：写第 300 章战斗场景时，第 5 章的日常描写只会分散注意力

RAG-历史回顾的核心价值：精准提取与当前创作相关的前文片段，让模型在有限的注意力预算内获得最相关的历史信息。

数据来源是当前作品的已生成内容，随创作过程持续增长。每完成一个序列即增量索引——先是秒级的关键词索引（保证即时可用），后台异步构建向量索引（~25分钟完成精确索引）。

4.3 多维度检索方案

单纯向量检索存在三个核心问题，本系统针对性设计了改进：

问题一：叙事完整性破坏——机械切片破坏序列逻辑，”打脸”序列被切成碎片。

解决方案：多维度语义切片。同一文本按四种维度切分：

维度	切片单位	边界	适用场景
plot（剧情）	序列/事件	序列开始/结束	剧情架构师查询完整情节
character（人物）	角色相关段落	人物出场/退场	人物设计师查询角色行为
emotion（情绪）	情绪段落	情绪转折点	网络编辑评估爽点节奏
function（功能）	叙事功能	功能边界	分析剧情结构

不同专家检索不同维度，而不是所有人都查同一套切片。

问题二：检索噪音——向量相似度不等于语义相关，中文专有名词检索效果尤其差。

解决方案：文档增强 + 混合得分。

每个序列生成 5 视角改写：情节概述、爽点分析、人物关系、情感弧线、读者问题。增加检索命中入口。
混合得分：vector_score × 0.6 + keyword_score × 0.4

问题三：检索结果碎片化——无法直接支撑决策。

解决方案：双库分离。

向量库存摘要+标签（快速检索定位）
MD 文本库存完整切片（提供完整上下文）

检索流程：查询 → 向量库定位标签 → MD 库读取完整文本 → Agent 智能压缩后注入上下文。

4.4 RAG 的局限与微调路线

RAG 存在根本局限：知识是”外挂”的——模型每次都要检索，无法内化为写作直觉。此外检索片段占用上下文空间、分散当前任务注意力。

策略：短期 RAG 为主（即时可用），中期 QLoRA 微调注入风格和语感（成本 ~100 元），长期混合使用——微调负责”直觉”（爽点判断力、语感），RAG 负责”知识”（具体概念、前文查询）。

4.5 世界书与 RAG 的分工总结

问题	世界书解决	RAG-历史回顾解决
主角修为忘了	查活跃层当前状态	查历次突破的原文详情
伏笔忘了回收	查活跃伏笔列表	查伏笔埋入时的原文
老角色再出场忘了特征	查当前状态条目	查历史出场片段+对话
角色 OOC	查核心特性+行为逻辑	查历史行为模式验证
世界观矛盾	冲突检测自动告警	查历史设定细节对照

——世界书保证”不犯错”，RAG-历史回顾保证”不遗忘”。

五、多维功能标注矩阵

5.1 设计起源

传统叙事学对”功能”的分类（如 Propp 的获得/禁令/违背/斗争/胜利/失败）只是纯动作标签——描述了”角色做了什么”，不关心”这个动作达成了什么效果”。

一个叙事单位（功能），应该从对内（故事内部发生了什么变化）和对外（读者产生了什么反应）两个维度进行标注。

5.2 标注矩阵

对内（故事世界内部）
├── 剧情轴：推进/转折/铺垫/阻碍/回收/承接
├── 人物轴：揭示特性/触发成长/确立关系/制造矛盾/展示能力/施加压力
└── 世界轴：展示设定/营造氛围/建立规则/拓展地图/强化画面感

对外（读者心理层面）
└── 读者五感：
    ├── 期待感（悬念期待/目标期待/反转期待）
    ├── 满足感（伏笔回收/压抑释放/公平回报）
    ├── 代入感（感官代入/情感代入/认知代入）
    ├── 爽感（装逼/打脸/获得/碾压/崇拜）
    └── 惊喜感（反转/揭示/新意）

5.3 标注示例

场景：”拍卖会上，鉴定师老周接过主角的晶核，仪器瞬间爆表”

传统标注：功能类型 = 获得功能

多维标注：

轴	标注
剧情轴	转折（打破质疑僵局）+ 铺垫（引出后续交易）
人物轴	揭示特性（老周的专业→震惊）、确立关系（老周从质疑→认可主角）
世界轴	展示设定（修真晶核的能量等级远超此界认知）
读者效果	目标期待（想知道值多少钱）、压抑释放（被嘲讽的憋屈开始释放）、打脸前奏（物理爆表是最直观证据）、新意（不是口头服软，而是仪器爆表）

5.4 序列级聚合

单个功能被标注后，序列层面的功能由其组成功能聚合而成：

剧情定位：以转折为核心、前后有铺垫和回收的完整因果闭环
人物作用：各角色的功能分配和弧光变化
世界作用：力量体系展示、环境设定呈现
读者效果：完整的 V 型情绪曲线，爽感密度评估，结尾是否留有新期待

5.5 标注的实际价值

暴露”空功能”：如果某个功能只在剧情轴有”推进”，其他轴空白 → 这是”功能性但不好看”的节点，编辑该介入。
检测情绪断层：如果读者效果在多个连续功能中缺失 → 该序列存在情绪断层，需要调整。
降低 L3 难度：L3 不再需要自己推断”这段产生了什么读者效果”——这是 L3 最不可靠的一步。现在 L2 直接标注好了，L3 只需查映射表。
与三专家职责对齐：

剧情轴 → 剧情架构师
人物轴 → 人物设计师
世界轴 → 架构师+人物设计师
读者效果 → 网络编辑

六、效果→技术的确定性映射

6.1 双库体系

网文创作指导需要两套知识体系，它们的语言逻辑完全不同：

	网文理论（效果学）	叙事学理论（结构学）
关注点	读者的心理反应	文本的组织形式
语言特点	模糊的、经验主义的	精确的、结构主义的
核心概念	爽感、期待感、压抑-释放、黄金三章	聚焦、时限、频率、话语模式
典型表述	“这里要欲扬先抑”	“使用内聚焦视角+慢速扩述”

L3 充当“编译器”角色，将模糊的”网文效果指令”翻译成精确的”叙事学技术指令”。这是整个系统最核心的理论创新。

6.2 核心映射规则库

映射规则是写死在数据库里的确定性知识，不是让 AI 每次临场推理。这是”配置优于实现”在创作中的应用。

示例：装逼打脸（压抑-释放）的完整映射：

阶段	效果目标	视角选择	节奏控制	话语模式	原理
压抑	积累读者的优越感和期待	反派/路人内聚焦	慢速扩述（细节展开）	大量对话+心理描写	信息差制造读者的上帝视角优势
爆发	爽感释放，逼格确立	外聚焦（客观镜头）	中速等述	短句动词密集	零度写作提升逼格，不解释
余韵	强化满足感，留下回味	自由间接引语	快速概述	震惊反应+留白	直接展示心理崩溃，不议论

其他经典映射：

效果目标	视角选择	节奏控制	核心技法
悬念铺设	限制视野 + 叙事空白	慢速扩述→关键处省略	在关键信息处中断或转移视角
战斗场面	外聚焦（开局）→ 零聚焦（全局）	扩述→等述→概述交替	视觉快慢交替，模拟电影剪辑
主角登场	感知型视角 + 陌生化	慢速扩述	通过感官描写拉读者进入现场
扮猪吃虎	内聚焦·配角视角	慢速（配角的愚蠢展开）	读者知道配角不知道，制造优越感

6.3 为什么必须”写死”映射

如果让 AI 自己判断”打脸该用什么视角”，会有三个问题：

结果不稳定：每次都不同，这次用了外聚焦下次可能用全知视角
AI 不理解原理：选择了某种写法但不知道为什么这么选，只是概率上”常见”
无法积累改进：人的经验无法固化，每次都是全新推理

将映射规则写死在数据库中后：

系统检索到”打脸”关键词，直接调出预设规则：打脸高潮 → 必须用外聚焦
这是一个确定性的过程，不依赖 AI 的随机推理
映射库可以持续积累——每发现一个新的效果→技法映射关系，就入库一条

6.4 写作技法的三层数据支撑

与第四章讨论的”故事记忆”（世界书 + RAG-历史回顾）不同，本系统的各创作层还需要写作技法知识——这解决的是”怎么写更好”，不是”之前发生了什么”。技法数据是静态知识库，不需要随创作过程动态增长。

L2 层的技法需求：

L2 三位专家需要的知识（爽点公式、编辑经验、人物设计经验、序列-功能设计经验）属于”方法论”层面，无法像视角、节奏那样从网文文本中直接提取。可能的来源包括网文理论文章、写作指南书籍、资深作者经验总结。当前策略：这类数据主要靠专家 prompt 中的内置知识和 RAG-历史回顾对同类场景的参考，独立的技法数据库暂未构建。

L3 层的技法需求——映射关系库：

L3 需要的核心技法是效果→叙事指令的映射规则（§6.2 中的表格）。这是整个系统的”翻译器”，瓶颈最大。

数据结构设计：

{
  "效果标签": "装逼打脸-压抑阶段",
  "叙事指令": {
    "视角": "内聚焦（反派/路人视角）",
    "节奏": "慢速叙事（扩述/场景）",
    "话语模式": "大量对话+环境描写"
  },
  "理由": "通过无知者的傲慢视角，制造信息差",
  "参考片段": ["..."],
  "关联网文概念": ["欲扬先抑", "期待感悬置"]
}

数据来源：从经典网文/名著中手工标注”效果-技法”对照表。冷启动用预设的核心映射条目（约 50-100 条），渐进迭代中持续补充。

L4 层的技法需求——微观技法库：

L4 需要的技法是具体的写作范例——当 L3 标签要求”外聚焦 + 短句 + 动作描写”时，提供参考文本片段供 AI 参考。

数据结构：

{
  "技法标签": ["外聚焦", "动作描写", "短句"],
  "风格": "古龙式冷硬",
  "参考文本": "光头男人敲了敲桌子...",
  "来源": "古龙《流星蝴蝶剑》",
  "适用场景": "打脸高潮、战斗爆发"
}

技法数据与故事记忆的关系：

故事记忆（第四章）               写作技法（第六章）
───────────────────            ───────────────────
世界书：当前状态                 映射规则库：效果→技法
RAG-历史：前文检索              微观技法库：参考范例
                               L2 方法论：爽点公式
                               
解决 "不犯错、不遗忘"            解决 "写得好"
数据随创作增长                   数据为静态预设

七、L3/L4 多技能体系

7.1 为什么 L3/L4 不用专家会议

L1/L1.5/L2 都有专家会议（多角色协作），但 L3 和 L4 不同——它们的任务是执行而非决策。不需要多方博弈，需要的是”面对不同情况用不同方法执行”。

类比：

L1/L1.5/L2 = 会议室（多方讨论，达成共识）
L3/L4 = 工具箱（根据情况选用不同工具）

7.2 L3 的五种技能

技能	定位	使用场景
初稿生成	首次接收 L2 章纲，产出带标签草稿	默认入口
迭代修正	在已有草稿上按用户反馈修改	用户不满意，指出具体问题
换方向重写	同一章纲，不同风格/节奏	对比不同写法
保守写作	严格控制想象空间	AI 写得太飞、设定崩了
加速模式	压缩篇幅，加快叙事节奏	某章太拖

7.3 L4 的七种技能

技能	定位	使用场景
初稿扩展	接收标签草稿，扩展打磨成精修	默认入口
文风调校	保持内容，调整语言风格	要”更古龙”或”更网文化”
删改压缩	缩短篇幅，保留核心	篇幅超了
描写增强	丰富环境、心理、感官细节	文太干瘪
对话打磨	专门优化对话部分	对话生硬
保守修复	检测不合理设定，逐条修正	AI 太异想天开
终稿润色	检查错别字、语病、节奏	内容满意，最后抛光

7.4 技能切换机制

两种模式并存：

手动切换：前端下拉菜单选当前 skill
自动推荐：系统检测到特定模式时建议切换。例如连续 3 次迭代用户还不满意 → 建议”换方向重写”；文本中出现大量修饰词 → 提示”切保守模式？”

7.5 标签语法与预处理

L3 的带标签草稿使用类似 HTML 的结构化标签包裹正文段落。标签类型包括：

标签	作用	关键属性
<视角>	切换叙事视角	type: 外聚焦/内聚焦/不定内聚焦/自由间接引语
<节奏>	控制叙事时间	type: 扩述/等述/概述/静述
<情绪>	情绪目标和强度	type, 强度(↑/↑↑)
<话语模式>	句式结构	type: 短句+动作/大量对话/心理描写/环境烘托
<限制视野>	控制信息量和视角范围	target, 规则
<省略>	告知 L4 此处不写什么	规则
<自由间接引语>	以叙述者口吻转述心理	规则
<转折点>	标记叙事节点	name

预处理流水线：

L3 草稿（含原始标签 + 正文）
     ↓
正则匹配所有 <标签名 属性>...</标签名>
     ↓
从映射表查对应完整提示词，注入提示词要求属性
     ↓
传给 L4 的标注后草稿

例如：

输入:  <视角 type="外聚焦">正文</视角>
输出:  <视角 type="外聚焦" 提示词要求="只写外部可见的行为和对话，不进入任何人物的内心。叙述者像一个客观的摄像机。">正文</视角>

八、编排画布与工作流

8.1 从固定流程到可编排流程

早期系统的层级是固定顺序（L1→L2→L3→L4），存在三个问题：

短篇不需要分卷，L1.5 多余
长篇可能想 L1→L2→L1→L2 反复迭代
无法自定义流程——想对比两种章纲方案？没法做

解决方案是将创作流程变成一个可视化的工作台：

每个功能环节（L1 种子、专家会议、L3 叙事、L4 渲染、世界书查询、RAG 检索）是画布上的一个工作节点
节点有明确的输入端口（接收什么数据）和输出端口（产出什么内容）
用箭头连接节点，就定义了数据流向和处理顺序
系统预置了默认流程（L1→编排→L3→L4），但用户可以随意增删、重组

8.2 编排画布的核心概念

专家节点：每个专家是一个可拖拽的画布节点，有独立的角色配置（主导/审核/补充）、Agent 中止条件（标签<stop>/阻塞/楼层上限）、读取文件类别配置。所有专家默认启用 Think 模式（thinkingBudget: 10000 tokens）。

群聊容器节点：将多个专家框在一起，形成群聊讨论组。交互方式为 click-to-add——先从左侧工具箱点选专家，再点击容器 body 添加。容器内专家显示为带序号、图标、名称、角色标签的卡片，× 按钮移除。容器高度随专家数量自动增长，不再需要内部连线。

容器配置项：

发言模式：顺序循环（ordered，按加入顺序依次发言）或 @提及驱动（mention_driven，专家互相 @ 形成动态讨论网络）
退出条件：手动（用户停止）/ 全员共识（全部打出<stop>）/ 多数赞同（超过 exitRatio 比例）/ 门禁专家（指定专家定稿）
上下文深度控制：按楼层（最近 N 层发言）或按 token（约 N token 最近历史），两者可同时启用取先触发者

群聊与单专家的区别：群聊中每个专家调用 speakStream()（单次 LLM 发言），而非单专家的 iterate()（多轮 Agent 自我审视）。群聊的”迭代”体现在专家之间的来回对话，而非个人内部反思。群聊产出为一份共享报告（{容器名}_群聊_report.md），合并所有专家的发言，而非每个专家各自产出独立报告。

连线类型：

data_flow：通用数据流（节点间对象传递）
单输入单输出：群聊对外暴露一个输入端口和一个输出端口，类似电路设计中的模块封装——下游只看到”群聊产出了什么”，不关心里面怎么讨论的

8.3 @提及驱动

传统固定顺序（A→B→C→A→B→C…）的局限在于无法应对讨论中自然产生的交叉回应。@提及机制允许：

用户点名：输入 @剧情架构师，指定专家立即发言
专家互相点名：专家输出中包含 @人物设计师请确认主角行为是否合理，系统自动让被点名者发言
提及驱动模式：没有固定发言顺序，专家通过互相 @ 形成讨论网络

8.4 Agent 迭代与管道模式

区别于会议模式（圆桌讨论），管道模式是一种直线传递的工作方式：

L1 愿景 .md → 资深作者 → 读者代表 → 最终 .md

按连线顺序逐节点处理——同一层有多个节点时可以并行，上层完成后才进入下层。每个节点的输出自动作为下一节点的输入参考。

Agent 迭代：单专家节点不是一次 LLM 调用，而是多轮内部迭代——生成意见 → 自我审视 → 修正定稿。所有专家默认启用 Think 模式，思考过程通过 SSE 流式展示。可配置中止条件：标签 <stop>（AI 自主打标）、阻塞中止（每隔 N 轮暂停等待用户反馈）、楼层上限（maxRounds 到后取最佳或直接接受）。

群聊：多专家在容器内同时讨论，专家之间互相 @ 或按顺序发言。讨论的”轮次”是专家之间的来回对话。退出条件可配：手动 / 全员共识 / 多数赞同 / 门禁专家。

8.5 全自动与手动微操

两种模式不互斥：

全自动：画布连线全部接好，点”运行”，数据从头流到尾
手动微操：不连线或只连部分。每完成一个模块，产出存文档库。用户手动拿文件导入下一个模块
混合：大部分连线全自动，关键环节断开让人工介入

8.6 前端聊天窗口

单专家和群聊使用不同的前端组件：

ChatPopup.vue：单专家 Agent 聊天窗口，三栏布局——文档库(左) | 迭代日志+输入框(中) | 文件队列+报告预览(右)
GroupChatView.vue：群聊专用组件，中央展示群聊消息流（发言人名称+图标），右侧展示群聊成员列表+退出条件状态+对象文件队列。不再有独立报告预览面板——用户双击文件队列中的文件即可预览内容
两者通过 BroadcastChannel 独立接收各自的事件类型（agent_* vs groupchat*），互不干扰

九、核心概念对照表

本系统概念	对应的叙事学/网文学概念	说明
故事（Fabula）	素材层	客观事件序列
叙事（Discourse）	话语层	事件的呈现方式
功能	Propp 功能/最小叙事单位	故事中最小的叙事单元
序列	Sequence	有因果逻辑的功能链
情节	Plot	序列的组合结构
行动元	Actant	角色在情节中的功能定位
内聚焦	Internal Focalization	限制在某人物的认知范围内
外聚焦	External Focalization	只写可见行为，不写心理
自由间接引语	Free Indirect Discourse	无引号的心理转述
扩述/等述/概述	Duration/Pace	叙事时间与故事时间的比例
效果→技术映射	Fabula→Discourse 编译	L3 的核心任务
世界书	World Info / Lorebook	持久化状态管理
多维标注	Multi-dimensional Annotation	功能的效果标注体系

十、理论创新总结

本系统的理论贡献可以归纳为五个层面：

分层解耦：将网文创作分解为 L1→L1.5→L2→L3→L4 五个可独立操作的层，每层有明确的理论支撑和输入输出契约。这解决了 AI 长文本生成中”叙事失控”和”一致性差”的根本问题。
异质化专家会议：不同于通用多 Agent 系统（同质 Agent 生成选项供用户选择），本系统的三位专家是异质化的——各有专业视角和专属知识库，在结构上模拟真实出版业的选题会模式。
效果→技术的确定性映射：将网文”效果学”（爽感公式）与叙事学”结构学”（视角/节奏/话语模式）通过映射规则库桥接，使模糊的商业写作经验转化为精确的可执行指令。这是整个系统最底层的理论创新。
数据协同：世界书（当前状态确定性管理）+ RAG-历史回顾（多维度语义检索）两套机制互补，解决了长篇创作中的记忆问题。独立的写作技法数据（映射规则库、微观技法库）为 L3/L4 提供确定性创作指导，与记忆系统是不同层面的支撑。
多维功能标注：将单个叙事功能的标注从一维（功能类型）扩展为四轴（剧情/人物/世界/读者效果），使抽象的大纲具有了可量化的效果评估体系，直接降低了 L3 的工作难度。

版本：v5.2
更新：2026-05-08

AI辅助网文创作系统——使用与设计思路

本文档介绍系统的使用方法和背后的设计决策。适合需要了解系统如何运作、为什么这样设计的读者。配合《理论总结》阅读可全面理解项目。

一、系统概览

本系统是一个 B/S 架构的 Web 应用：浏览器打开网页即可使用，后端在本地或服务器上运行。

后端：Node.js + TypeScript + Express.js，端口 7860
前端：Vue 3 单页应用，开发时端口 5173
通信：REST API（操作指令）+ SSE（AI 流式输出，支持 Think 模式）
存储：JSON 文件（核心数据）+ SQLite（日志）+ Chroma（向量检索）
LLM：支持所有 OpenAI 兼容接口的模型（GLM-5、DeepSeek、Claude 等）

系统零配置即可运行：不需要 Docker、不需要数据库服务。Chroma 和 SQLite 都是嵌入式运行。

二、快速开始

git clone <仓库地址> && cd talk
./start.sh        # 安装依赖、启动 Node.js 后端

前端开发模式：

cd frontend && npm install && npm run dev

首次使用需要编辑 data/user/config.yaml，填入模型 API 地址和密钥：

llm:
  primary: open_ai_compat
  model: GLM-5                    # 支持 GLM-5、DeepSeek、Claude 等
  api_key: "你的密钥"
  base_url: "https://你的API地址/v1"

三、创作流程

3.1 整体流程

创建项目 → L1 种子（聊创意、生成愿景） → 编排（专家会议讨论大纲）
         → L3 叙事（生成章纲草稿） → L4 渲染（生成正文）

每层产出存入文档库，可在侧边栏随时浏览、对比、管理。不是做完一层才能进下一层——你可以随时回到前面的层重做或调整。

3.2 L1 种子层

目的：把脑海里的模糊创意变成一份结构化的《故事愿景文档》。

操作方式：页面右侧有两个标签页——「表单」和「预览」。

表单标签页：

故事要素表单：填写核心梗、目标读者、爽点类型、主角人设、金手指、世界观等
创意对话：和 AI 聊天梳理创意，AI 会逐步引导
Skill 按钮：查看和自定义生成提示词
保存表单：把表单内容保存到文档库

预览标签页：

生成愿景文档：把表单内容提交给 AI，生成完整的 Markdown 愿景文档
Think 模式：AI 思考过程可折叠显示
流式输出：实时显示生成过程
保存/下载：保存到文档库或下载为 .md 文件

数据流：

表单内容 → 合并成提示字符串 → AI 流式生成 → Markdown 愿景文档
                                              ↓
                                      保存到文档库 / 下载

设计考虑：

表单 + 对话双模式：表单负责结构化收集，对话负责发散创意
Skill 功能：用户可自定义提示词，灵活控制 AI 行为
Think 模式：展示 AI 思考过程，帮助理解创作意图
愿景文档格式：直接输出 Markdown，方便后续编辑和导入

3.3 编排层（核心交互）

目的：通过专家会议讨论，产出精修大纲。这是系统最核心的交互环节。

三种使用方式：

预设模板（推荐新用户）：系统提供三个预设模板——

快速审核：只用网络编辑快速检查大纲质量
卷纲规划：资深作者 + 读者代表讨论分卷方案
章纲设计：剧情架构师 + 网络编辑 + 人物设计师拆解章纲

拖拽编排（进阶用户）：从左侧工具箱拖拽专家到画布，用箭头连接定义发言顺序。可以把多个专家框进一个”容器”形成群聊小组。
管道模式：不是开会讨论，而是分布式工作节点模型——每个节点独立维护任务队列，并行运行。任务对象沿 DAG 连线流动：上游节点完成后从自己队列删除，塞到下游队列。适合”不需要来回讨论，按步骤依次处理”的场景。

会议交互：

会议模式：专家轮流发言，半自动/全自动/手动三种协作模式，支持 @提及点名
管道模式 v2：任务对象沿 DAG 流动，每个专家节点是 Agent——多轮内部迭代自我审视（所有专家默认启用 Think 模式），产出报告+聊天记录。用户可随时向 Agent 发送反馈指令
群聊：多专家放入群聊容器，click-to-add 交互（先点选工具箱中的专家，再点容器 body 添加）。专家显示为带序号、图标、角色标签的卡片，× 移除。支持顺序循环或 @ 提及驱动发言，退出条件可配（共识/多数赞同/门禁专家）。群聊产出为一份共享报告
流式聊天：单专家使用 ChatPopup.vue（三栏：文档库 | 迭代日志+输入 | 文件队列+报告预览），群聊使用 GroupChatView.vue（中央消息流+输入 | 右侧成员列表+退出条件+文件队列）
断点恢复：管道中断后可从 checkpoint 恢复，自动丢弃不完整轮次
ZIP 导出：完整管道产出（配置+对象文件+报告+聊天记录）打包为 ZIP

画布设计：

从工具箱拖拽专家节点到画布，箭头连线定义 DAG 数据流
拖拽群聊容器（原”容器”）把多个专家分组，容器内配置发言模式（顺序/@ 驱动）、退出条件、上下文深度
输入源节点：添加多个 .md 文件形成输入队列
输出节点：收集全部产出，管道完成后双击打开输出页面
每个节点可配置：Agent 中止条件（标签<stop>/阻塞/楼层上限）、读取文件类别（input/report/chat_log）
画布设计可保存和加载，不同项目可复用

产出：会议结束后，讨论内容被整理为结构化的大纲。大纲包含功能序列、情绪曲线、人物行动元等信息。

流式聊天窗口：

右键节点 → 打开聊天窗口（新浏览器标签页），通过 BroadcastChannel 接收 SSE 事件
专家节点 → ChatPopup.vue：三栏布局——文档库(左 220px) | Agent 迭代日志+输入框(中弹性) | 文件队列+报告预览(右 320px)。迭代日志用 RoundCard 组件渲染——思考过程(可折叠) + 产出内容(流式更新) + 自评分。agent_complete 后自动归档报告到文件队列，清空聊天区释放 DOM
群聊节点 → GroupChatView.vue：中央消息流（发言人名称+图标+思考+产出）+ 右侧面板（群聊成员列表 + 退出条件状态 + 对象文件队列）。不再有独立报告预览——用户双击文件队列中的文件即可预览 markdown 内容
用户反馈：底部输入框，Enter 发送反馈，”采纳并停止”（专家）/ “结束群聊”（群聊）
输出页面（OutputPage.vue）：对象列表 + 专家链路 + 文件统计，支持 ZIP 下载和拖入加载
对象查看（ViewerPage.vue）：回放专家完整迭代聊天，切换专家视角，单对象/ZIP 两种模式

设计考虑：

预设模板降低了新用户的操作门槛，不需要理解专家体系就能开始
画布拖拽给了高级用户完全的自由度——想用几个专家、什么顺序、几轮，全自定义
统一引擎：L1.5/L2/管道 v2 底层共用编排引擎，API 端点保留向后兼容
管道 vs 会议：管道适合”直线加工”（对象沿 DAG 流动，节点并行处理），会议适合”讨论决策”（专家轮流发言交叉讨论）
Agent 迭代：专家不是单次 LLM 调用——多轮内部审视使产出更可靠。中止条件可配置，避免无限循环
群聊：多个专家在容器内同时讨论，适用复杂评审场景。退出条件让讨论不会失控
断点恢复：checkpoint 保存完整对象状态，中断后从中断位置继续而非重新开始
ChatPopup 三栏：逐专家清空（性能）+ 文件队列（上游文件可见）+ 报告预览（随时查看产出）

3.4 L3 叙事层

目的：将大纲转化为可执行的写作指令。

操作方式：左侧显示 L2 产出的大纲作为参考，中间是场景编辑器。每个场景可以设置：

视角（外聚焦 / 内聚焦 / 不定内聚焦 / 自由间接引语）
节奏（慢速扩述 / 中速等述 / 快速概述）
话语模式（对话为主 / 动作描写 / 心理描写 / 环境烘托）
预估字数

产出：章纲/细纲，包含每章的场景序列、每个场景的技术指令、整章的情绪曲线和钩子设计。

设计考虑：

L3 目前是纯指令模式（选择技术参数）。按理论规划，未来会升级为”带标签草稿”模式——AI 直接输出嵌入了 <视角><节奏> 等标签的草稿正文，用户可以看到标签在上下文中的效果
多技能切换能力预留：初稿生成、迭代修正、换方向重写、保守写作、加速模式——用户可根据实际效果切换策略，而不是反复修改同一个 prompt

3.5 L4 渲染层

目的：根据 L3 的写作指令生成正文。

操作方式：左侧显示 L3 章纲作为参考，点击”开始渲染”，正文以流式方式逐字出现（类似 ChatGPT 打字效果）。

产出：完整的章节正文，含字数统计。

设计考虑：

SSE 流式输出：用户无需等待全文生成，可以边看边判断方向，不满意可以随时中止
约束渲染：L4 不是自由创作——它收到的是 L3 的结构化指令（视角、节奏、字数），必须遵守这些约束
7 种技能预留：初稿扩展、文风调校、删改压缩、描写增强、对话打磨、保守修复、终稿润色

四、数据支撑功能

4.1 世界书

目的：维护故事世界的当前状态——角色修为、势力关系、活跃伏笔、道具归属等。

操作方式：世界书管理页面以表格形式展示所有条目。每个条目包含：

触发词（当上下文中出现这些词时，条目的内容会被自动注入 AI 的 prompt）
内容（条目的具体描述）
优先级（决定多个条目同时触发时的排序）
是否常驻（常驻条目永远在上下文中）

自动管理：每完成一个创作序列后，可以触发”AI 处理序列”——系统自动分析序列内容，提取新角色、状态变化、伏笔设置/回收，更新世界书条目并检测设定冲突。

版本控制：每次修改可以提交一个版本（commit），支持查看历史版本。

设计考虑：

触发词机制（借鉴 SillyTavern）：不是每次把所有条目塞进上下文——只有与当前讨论相关的条目才会被激活，节省 token 成本
自动管理 + 人工审核：AI 可以自动提取变化，但冲突检测结果会提醒用户确认，不会擅自改写设定
版本链而非覆写：角色的修为变化保留完整历史（”1-30 章筑基→31-80 章金丹→81 章至今元婴”），只比当前状态多几个 token，但 AI 能理解成长弧光

4.2 RAG 检索

目的：从已生成的前文内容中检索相关信息，帮助 AI 保持前后一致。

操作方式：

搜索栏输入查询词 → 返回相关前文片段及其相关度得分
支持按标签筛选（如只查某个角色的出场记录）
可手动索引文档（上传章节文本建立索引）

自动检索：在专家会议中，RAG 检索会根据当前讨论内容自动触发，检索结果以”机器人插话”的形式出现在聊天中。

设计考虑：

当前 RAG 配置中的 hybrid_retriever 尚未实现，实际运行的是 simple_vector（纯向量检索）
笔记 7 中已实现并测试了完整的混合检索原型（多维度切片 + 向量+关键词混合得分 + 文档增强），待集成进主系统

4.3 文档库

目的：管理所有创作产出——存档、对比、追溯、导入。

操作方式：左侧可折叠的侧边栏，以目录树形式展示所有文档。支持：

创建目录整理文档
拖拽移动文档到不同目录
右键菜单（重命名、导出、归档、删除）
导入外部 .md/.json/.txt 文件
设置某份文档为当前层的”活跃文档”（L1/L2/L3/L4 各层有自己的活跃文档指针）

溯源链：每份文档记录了它的”父文档”——这份 L2 大纲是从哪个 L1 愿景生成的。形成完整的链路：

L1 愿景 → L2 大纲 → L3 章纲 → L4 正文

正文有问题 → 顺着链找到章纲是哪份 → 再找到大纲是哪份 → 定位决策节点。

设计考虑：

双轨存储：文档库（用户视角的自由文件管理）与章节管理器（Agent 视角的结构化章节索引）分开。前者管”存档和对比”，后者管”第 N 章的状态和 RAG 索引同步”
自动入库：每次生成产出后自动在文档库存档一份，旧版本不会被覆盖
自动命名：系统根据 AI 摘要（如”废土双界倒爷 + 修真物资流”）自动命名，用户可随时重命名
旧数据迁移：启动时检测旧格式输出文件，自动迁移到文档库

五、设置与配置

系统设置页面提供：

LLM 配置：API 地址、密钥、模型选择
流水线配置：默认会议协议、协作模式、最大讨论轮次
查看已注册的模块列表（哪些 LLM 实现、哪些 RAG 策略、哪些专家可用）

自定义专家：用户可以在画布上创建自定义专家——填写名称、角色描述、提示词模板。保存后在当前项目的所有会议中可用。

六、架构设计决策

6.1 为什么选择 B/S 架构

零安装：浏览器打开即用，不需要安装任何客户端
参考 SillyTavern 模式：git clone → ./start.sh → 浏览器打开，三步入门
前后端分离：前端独立开发部署，后端专注 API 和模型调用
SSE 而非 WebSocket：系统的 AI 流式输出是单向的（服务器→客户端），SSE 更轻量，浏览器原生支持，FastAPI 一行代码实现

6.2 模块化插件体系

所有功能组件遵循”协议优先”原则：

在 protocols/index.ts 中定义 TypeScript 接口——规定”能做什么”
编写具体实现类——决定”怎么做”
通过注册函数注册（如 registerExpert('id', Class)）
配置文件选择使用哪个实现

专家系统——JSON 定义 + ConfigurableExpert：

内置 7 位专家从硬编码 TypeScript 类重构为 JSON 定义文件（experts/*.json）
ConfigurableExpert 统一类读取 JSON 定义，不再需要每个专家一个 .ts 文件
用户自定义专家：在前端画布填写 JSON，保存到项目目录，系统自动加载
expertLoader 服务管理内置/自定义专家的发现、加载、CRUD

好处：

切换 LLM 只需改配置一个 key，不需要改任何业务代码
新增专家：加一个 JSON 文件即可，无需写 TypeScript
测试时：用 MockLLM 替换真实 LLM，不消耗 API 费用

专家表（7 位内置 + 自定义）：

专家 ID	名称	角色
senior_author_v1	资深作者	创作方向把控
reader_representative_v1	读者代表	体验审核
plot_architect_v1	剧情架构师	故事骨架
character_designer_v1	人物设计师	人设一致
web_editor_v1	网络编辑	市场效果
chapter_splitter_v1	章节拆分师	卷→章翻译
discussion_summarizer_v1	讨论总结师	讨论收敛
自定义专家	用户定义	用户编写 JSON 定义

6.3 存储方案的选择

数据类型	存储方式	理由
世界书条目、项目配置、L1-L4 产出	JSON 文件	结构化文档，人类可读可编辑，量不大
会议日志、版本历史	SQLite	只追加不修改，需按时间查询，量大
向量数据	Chroma（嵌入式）	无需单独部署向量数据库服务

不用 PostgreSQL/MySQL 的理由：SillyTavern 全 JSON 也跑得好好的。对于单用户创作工具，SQLite 完全够用。

6.4 SSE 流式设计

所有 AI 生成过程使用 SSE（Server-Sent Events）流式推送：

event: expert_speak
data: {"expert_id": "plot_architect_v1", "content": "基于愿景...", "type": "chunk"}

event: done
data: {"output": {...}}

前端接收策略（两种场景）：

场景	方式	原因
POST 请求的流式响应	fetch + ReadableStream	EventSource 只支持 GET
GET 请求的流式响应	原生 EventSource	浏览器自动重连，更简单

断线处理：SSE 中断时，前端保留已接收的部分文本。用户可选择”继续”（将断点内容作为上下文续写）或”重来”。

6.5 分布式工作节点模型

编排层的核心架构：每个节点是独立 Worker，维护自己的任务队列，所有节点并行运行。

A节点队列           B节点队列           C节点队列
[对象1, 对象2]     [对象1]            [对象1]
     │                 │                  │
     │ 取出对象1        │ 取出对象1         │ 取出对象1
     │ 处理             │ 处理              │ 处理
     │ 删除，塞给B      │ 删除，塞给C        │ 删除，完成
     ▼                 ▼                  ▼

关键规则：

每个节点只看自己的队列——不感知全局状态
任务对象沿 DAG 连线流动：A 完成 → 从 A 队列删除 → 塞到所有下游节点队列尾部
所有节点并行：A 在处理对象2 的同时，B 在处理 A 已塞来的对象1
任务对象累积：每经过一个节点，节点产出追加到对象文件列表中

与集中式调度的区别：不是由一个中央调度器按拓扑层级逐个处理对象。节点不需要知道”当前是第几层”、”总共有多少对象”——只需要知道”我有上游谁、下游谁”以及”我的队列里有任务就处理”。

当前实现状态：ObjectPipelineEngine 是集中式实现，需要重构为分布式模型。

L1.5 和 L2 原本是两套独立代码——各自有 API、各自有专家实现。但底层逻辑相同：取专家队列 → 按序发言 → 流式输出 → 格式化产出。合并为统一的引擎后一套代码处理所有场景。

6.6 协作模式设计

模式	用户参与度	适用场景
semi_auto（默认）	每位专家发言后审核	需要精细把控方向的场景
full_auto	纯旁听，随时可插话	已有经验、快速出稿
manual	手动指定谁发言	深度调试、特定问题咨询

全自动模式下，用户插话后自动切回半自动——这个设计保证了”自动”不会变成”失控”。

6.7 前端技术选型

Vue 3（Composition API）：模板语法接近 HTML，降低上手难度；中文生态好
Vue Flow：用于编排画布，提供拖拽节点和连线功能
markdown-it：渲染专家发言中的 Markdown 表格和代码块。流式渲染时需要缓冲不完整的 Markdown 块，以免语法未闭合时乱码
BroadcastChannel：编排画布和弹窗聊天窗口之间的消息同步

6.8 已知限制与待完善项

问题	影响	状态
hybrid_retriever 未实现	当前只有纯向量检索，笔记 7 的混合检索方案待集成	待开发
L3/L4 多技能体系	目前仅有默认技能，5+7 技能切换未实现	待开发
WorldBook.revert() 是空方法	版本回滚功能不可用	待开发
tags API 是空桩	L3/L4 标签库端点无实际数据	待开发
L3 映射关系库	向量数据库未构建，映射规则仅靠 prompt	待开发
前端无测试	Vue 页面无自动化测试覆盖	待开发
ObjectPipelineEngine 是集中式实现	节点串行处理，非设计中的分布式并行模型	待重构
L3/L4 多技能体系	目前仅有默认技能，5+7 技能切换未实现	待开发

版本：v5.2
更新：2026-05-08

AI辅助网文创作系统——代码框架

面向开发者的代码结构参考文档。说明目录组织、关键文件职责、模块间调用关系。配合《理论总结》和《使用与设计思路》阅读可完整理解项目。

一、目录总览

talk/
├── backend-node/                   # Node.js/TypeScript 后端
│   ├── src/
│   │   ├── index.ts                # 应用入口，Express 配置，路由注册
│   │   ├── config.ts               # YAML 配置加载（支持下划线/驼峰兼容）
│   │   │
│   │   ├── protocols/              # 类型定义
│   │   │   └── index.ts            # 所有接口、枚举、类型
│   │   │
│   │   ├── models/                 # 数据模型
│   │   └── pipeline-object.ts  # PipelineObject：创建/累积/序列化/上下文构建
│   │
│   ├── services/               # 业务逻辑层
│   │   │   ├── llm.ts              # LLM 调用（支持 Think 模式）
│   │   │   ├── meeting-engine.ts   # 会议引擎 v1（专家轮流发言）
│   │   │   ├── pipeline-engine.ts  # 流水线引擎 v1（文件队列）
│   │   │   ├── object-pipeline-engine.ts  # 对象管道引擎 v2（Agent 迭代+群聊+checkpoint）
│   │   │   ├── pipeline-workers.ts    # 四种 Worker（输入源/专家/群聊/输出），AsyncQueue 轮询
│   │   │   ├── recovery-manager.ts # 断点恢复（saveCheckpoint/loadCheckpoint/cleanIncompleteRound）
│   │   │   ├── zip-exporter.ts     # ZIP 打包导出（exportPipelineToZip/parseExportZip）
│   │   │   ├── expert-loader.ts    # 专家 JSON 定义加载器（内置+自定义）
│   │   │   ├── project-manager.ts  # 项目 CRUD
│   │   │   ├── worldbook.ts        # 世界书管理
│   │   │   ├── rag.ts              # RAG 检索
│   │   │   └── library.ts          # 文档库管理
│   │   │
│   │   ├── experts/                # 专家实现
│   │   │   ├── base.ts             # 专家基类（speakStream + Agent 迭代 iterate，默认 Think 模式）
│   │   │   └── index.ts            # ConfigurableExpert（JSON 驱动）+ 注册表
│   │   │
│   │   ├── routes/                 # API 路由（Express）
│   │   │   ├── projects.ts         # 项目管理
│   │   │   ├── l1.ts               # L1 种子层（聊天+生成）
│   │   │   ├── meeting.ts          # 编排层（管道启动/反馈/恢复/导出/设计）
│   │   │   ├── l3.ts               # L3 叙事层
│   │   │   ├── l4.ts               # L4 渲染层
│   │   │   ├── worldbook.ts        # 世界书 CRUD
│   │   │   ├── rag.ts              # RAG 搜索/索引
│   │   │   ├── library.ts          # 文档库管理
│   │   │   └── settings.ts         # 系统设置
│   │   │
│   │   └── utils/                  # 工具函数
│   │       ├── sse.ts              # SSE Writer
│   │       └── queue.ts            # AsyncQueue（生产者-消费者）
│   │
│   ├── experts/                    # 专家 JSON 定义文件（7 个内置 + 用户自定义）
│   ├── senior_author_v1.json       # 资深作者
│   ├── reader_representative_v1.json  # 读者代表
│   ├── plot_architect_v1.json      # 剧情架构师
│   └── ...                         # 等 7 个 + 自定义
│
├── __tests__/                  # 单元测试（67 个）
│   │   ├── queue.test.ts
│   │   ├── sse.test.ts
│   │   ├── config.test.ts
│   │   ├── llm.test.ts
│   │   ├── experts.test.ts
│   │   ├── project-manager.test.ts
│   │   ├── worldbook.test.ts
│   │   ├── rag.test.ts
│   │   └── library.test.ts
│   │
│   ├── package.json
│   ├── tsconfig.json
│   └── vitest.config.ts
│
├── frontend/                       # Vue 3 前端
│   └── src/
│       ├── App.vue                 # 根组件 + 顶部导航 + 文档侧边栏
│       ├── main.js                 # 入口 + vue-router 路由（12 条）
│       ├── lib/sse.js              # SSE 流包装器
│       ├── pages/                  # 12 个页面
│       │   ├── Dashboard.vue       # 项目仪表盘
│       │   ├── L1Seed.vue          # L1 种子（聊天+表单+愿景预览）
│       │   ├── Orchestration.vue   # 编排画布入口（SSE + BroadcastChannel）
│       │   ├── ChatPopup.vue       # 三栏聊天弹窗（Agent 迭代/群聊）
│       │   ├── OutputPage.vue      # 输出页面（对象列表 + ZIP 下载/加载）
│       │   ├── ViewerPage.vue      # 对象查看（单对象 + ZIP 模式，切换专家）
│       │   ├── L3Narrative.vue     # L3 叙事
│       │   ├── L4Render.vue        # L4 渲染
│       │   ├── WorldBook.vue       # 世界书管理
│       │   ├── Library.vue         # 文档库详情
│       │   └── Settings.vue        # 系统设置
│       └── components/             # 组件
│           ├── OrchestrationCanvas.vue  # Vue Flow 编排画布（节点配置、连线、预设）
│           ├── ExpertNode.vue           # 专家节点
│           ├── GroupNode.vue            # 群聊容器节点（click-to-add 专家卡片）
│           ├── GroupChatView.vue        # 群聊聊天组件（消息流+成员列表+文件队列）
│           ├── RoundCard.vue            # Agent 轮次卡片（思考+产出+自评）
│           └── library/
│               └── DocumentSidebar.vue  # 文档库侧边栏
│
├── backend/                        # Python 后端（旧版，保留参考）
├── data/                           # 运行时数据
│   ├── user/
│   │   └── config.yaml             # 全局配置
│   └── projects/{id}/              # 项目数据
│       ├── project.json
│       ├── worldbook.json
│       ├── library/
│       ├── outputs/
│       └── logs/
│
└── start.sh                        # 一键启动脚本

二、后端核心机制

2.1 启动流程

index.ts
    │
    ├── 配置 CORS、JSON 解析
    │
    ├── registerAllRoutes(app)
    │   ├── registerProjectRoutes
    │   ├── registerL1Routes
    │   ├── registerMeetingRoutes
    │   ├── registerL3Routes
    │   ├── registerL4Routes
    │   ├── registerWorldbookRoutes
    │   ├── registerRAGRoutes
    │   ├── registerLibraryRoutes
    │   └── registerSettingsRoutes
    │
    └── app.listen(7860)

2.2 LLM 调用（支持 Think 模式）

// services/llm.ts
class OpenAICompatLLM implements LLMProvider {
  async *stream(prompt: string, options: LLMOptions): AsyncGenerator<LLMChunk> {
    const body = {
      model: this.model,
      messages: [{ role: 'user', content: prompt }],
      stream: true
    };
    
    // 启用 Think 模式
    if (options.thinking) {
      body.thinking = { type: 'enabled', budget_tokens: options.thinkingBudget };
    }
    
    // 流式解析响应
    for await (const chunk of response) {
      // GLM/DeepSeek 使用 reasoning_content 字段
      if (delta.reasoning_content) {
        yield { type: 'thinking', content: delta.reasoning_content };
      }
      if (delta.content) {
        yield { type: 'content', content: delta.content };
      }
    }
  }
}

2.3 异步队列（生产者-消费者）

// utils/queue.ts
class AsyncQueue<T> {
  async enqueue(item: T): Promise<void>;
  async dequeue(): Promise<T>;
  
  // 支持异步迭代器
  [Symbol.asyncIterator](): AsyncIterator<T>;
}

// 用于流水线引擎
const queue = new AsyncQueue<FileTask>();
await queue.enqueue(task);  // 生产者
const task = await queue.dequeue();  // 消费者

2.4 核心数据流

编排层采用分布式工作节点模型：每个节点（专家/群聊）是独立 Worker，维护自己的 AsyncQueue，并行运行。

用户请求 → Express 路由
              │
              ├── 获取配置：getConfig()
              ├── 获取服务：getProjectManager() 等
              │
              ├── 编排层：创建各节点 Worker
              │   ├── 每个节点：dequeue → 处理对象 → enqueue 到下游
              │   ├── 节点并行运行，不等待其他节点
              │   └── SSE 流式响应（每个节点独立推送事件）
              │
              ├── 调用 LLM → SSE 流式响应
              │     └── writer.writeData({ type, content })
              │
              └── 保存数据 → JSON 文件

任务对象流动：

输入源队列 → A节点队列 → B节点队列 → ... → 输出节点队列
  (每个节点处理完后从自己队列删除，塞到下游所有节点队列)

三、后端各层实现要点

3.1 L1 种子层（`routes/l1.ts`）

关键端点：

端点	方法	说明
/l1/chat	POST	SSE 流式聊天，支持 Think
/l1/generate	POST	SSE 流式生成愿景文档
/l1/vision	GET/POST/PUT	愿景文档 CRUD
/l1/prompt	GET	获取默认提示词
/l1/draft	GET/POST	表单草稿
/l1/chat-history	GET/POST	聊天历史

L1 聊天流程：

读取愿景文档（如果存在）
构建提示词（聊天历史 + 愿景文档）
流式调用 LLM（启用 Think）
返回 thinking + chunk 事件

L1 生成流程：

把表单内容合并成提示字符串
使用自定义或默认提示词
流式调用 LLM（启用 Think）
保存为 Markdown 格式的愿景文档

3.2 编排层（`routes/meeting.ts`）

关键端点：

端点	方法	说明
/meeting/start	POST	SSE 流式启动管道
/meeting/feedback	POST	发送用户反馈到指定节点的 Worker
/meeting/output	GET/PUT	管道产出
/meeting/design	GET/PUT	画布设计
/meeting/resume	POST	从断点恢复管道
/meeting/export/:sessionId	GET	导出 ZIP
/presets	GET	预设模板

核心引擎：

ObjectPipelineEngine：管理节点 Worker 的创建和生命周期
每个节点 Worker 独立运行：dequeue → 处理 PipelineObject → enqueue 到下游队列
节点间通过 AsyncQueue 传递任务对象
SSE 事件由各 Worker 独立推送，BroadcastChannel 广播到前端

处理流程：

构建 DAG → 为每个节点创建 Worker + AsyncQueue → 所有 Worker 并行启动
  → 各 Worker: dequeue → agent.iterate() 或 processGroupChat → enqueue 到下游
  → 对象在 Worker 间流动，累积文件 → 输出节点收集最终结果

3.3 文档库（`routes/library.ts`）

数据格式：

{
  "documents": [...],
  "directories": ["/"],
  "activeDocs": { "l1": "uid", "l2": "uid" }
}

支持操作：

文档 CRUD
目录管理
归档/取消归档
活跃文档设置
溯源链

四、前端关键组件

4.1 SSE 通信模式

// POST 流式（L1、编排层）
const response = await fetch(url, { method: 'POST', body: JSON.stringify(data) });
const reader = response.body.getReader();

while (true) {
  const { done, value } = await reader.read();
  if (done) break;
  
  // 解析 SSE 格式：data: {...}\n\n
  const data = JSON.parse(line.slice(6));
  
  if (data.type === 'thinking') {
    // 显示思考过程
  } else if (data.type === 'content' || data.type === 'chunk') {
    // 显示正文内容
  }
}

4.2 L1 页面（L1Seed.vue）

核心功能：

创意对话（聊天窗口）
表单填写（故事要素）
愿景预览（Markdown 渲染）
Skill 编辑（自定义提示词）

数据流：

表单 → 生成请求 → SSE 流式接收 → 实时显示
                     ↓
              Think 内容（可折叠）
              正文内容（实时更新）

4.3 编排层前端组件

Orchestration.vue + OrchestrationCanvas.vue：

Vue Flow 画布，拖拽专家节点/群聊容器/输入源/输出节点
箭头连线定义 DAG 数据流
群聊容器配置：发言模式（顺序/@驱动）、退出条件、上下文深度
节点配置面板：Agent 中止条件、读取文件类别
预设模板 + 画布设计保存/加载
SSE 流读取 → BroadcastChannel 广播 → ChatPopup 接收

ChatPopup.vue（单专家三栏布局）：

SSE 事件处理：pipeline_start_v2、agent_start、agent_round_start、agent_chunk（→’chunk’ 广播）、agent_complete、agent_waiting_user、object_progress、pipeline_complete
RoundCard.vue：轮次卡片——思考过程(可折叠) + 产出内容(流式更新) + 自评分
用户反馈：POST /meeting/feedback → 注入 Agent 下一轮迭代
生命周期：agent_complete → 归档报告到文件队列 → 清空聊天区释放 DOM

GroupChatView.vue（群聊专用）：

SSE 事件处理：group_chat_start、group_chat_round_start、group_chat_member_start、group_chat_chunk（thinking/content）、group_chat_member_complete、group_chat_round_complete、group_chat_complete、object_progress
中央消息流：RoundCard 复用（isGroupChat + speakerName/speakerIcon）
右侧：群聊成员列表（发言中高亮）+ 退出条件状态 + 对象文件队列（双击预览）
群聊产出为共享报告（{容器名}_群聊_report.md），非每个专家各自产出

OutputPage.vue（输出页面）：

路由 /output?projectId=xxx，双击输出节点或画布完成时进入
读取 sessionStorage ‘pipelineOutput’ 展示对象列表
每个对象行：名称、专家链路、文件统计
ZIP 下载 + 拖入 ZIP 加载（JSZip 解析）

ViewerPage.vue（对象查看）：

路由 /view?projectId=xxx&objectId=xxx（单对象）或 ?source=zip（ZIP 模式）
三栏：文档库 | 聊天+产出文档 | 专家列表
单对象模式：选专家 → 显示该专家完整迭代聊天
ZIP 模式：右侧拆分为对象列表(上) + 专家列表(下)
Markdown 渲染报告内容

五、测试

5.1 单元测试（67 个）

cd backend-node && npm test

测试文件	测试数	覆盖内容
queue.test.ts	6	异步队列
sse.test.ts	4	SSE 格式化
config.test.ts	3	配置管理
llm.test.ts	6	LLM 服务
experts.test.ts	11	专家系统
project-manager.test.ts	7	项目管理
worldbook.test.ts	9	世界书
rag.test.ts	7	RAG 检索
library.test.ts	14	文档库

六、扩展指南

6.1 添加新的 LLM 提供商

// services/llm.ts
export class MyLLMProvider implements LLMProvider {
  async invoke(prompt: string, options?: LLMOptions): Promise<string> { ... }
  async *stream(prompt: string, options?: LLMOptions): AsyncGenerator<LLMChunk> { ... }
}

6.2 添加新的专家（JSON 定义）

内置专家：在 backend-node/experts/ 目录创建 JSON 文件：

{
  "expertId": "my_expert_v1",
  "expertType": "我的专家",
  "icon": "📄",
  "description": "专家描述",
  "temperature": 0.7,
  "prompt_template": "你是一位...",
  "role_instructions": {
    "main": "...",
    "review": "...",
    "supplement": "..."
  },
  "self_review_prompt": "请审视并修正你的意见...",
  "agent_defaults": {
    "enableTagStop": true,
    "blockEveryNRounds": 0,
    "maxRounds": 3,
    "onMaxRounds": "accept_last"
  },
  "builtin": true
}

系统启动时 expertLoader.listExperts() 自动发现 /experts/ 目录下所有 JSON 文件。ConfigurableExpert 统一类读取 JSON 定义，无需写 TypeScript。

用户自定义专家：在前端画布填写 JSON → 保存到项目 user/ 目录 → 系统加载。

程序化注册（仍支持）：

// experts/index.ts
registerExpert('my_expert', ConfigurableExpert);

七、关键依赖

后端（Node.js）：

包	用途
express	Web 框架
cors	跨域支持
js-yaml	YAML 配置读写
uuid	项目 ID 生成
better-sqlite3	SQLite（日志）
chromadb	向量数据库
vitest	测试框架

前端（Node.js）：

包	用途
vue 3	前端框架
vue-router 4	路由
@vue-flow/core	编排画布
markdown-it	Markdown 渲染
jszip	ZIP 打包/解析（导出 + 前端拖入加载）
file-saver	浏览器文件下载
axios	HTTP 请求
vite 5	构建工具

版本：v5.2
更新：2026-05-08

AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

20年老程序员×AI：2小时搭建社保智能客服系统实战

摘要：本文记录了一位20年老程序员与AI协作，仅用2-3小时搭建社保智能客服系统的实战过程。系统从单轮问答升级为多轮Agent，实现了12项社保业务办理功能。开发采用真/假服务分层策略，核心功能使用真实服务，非关键模块用桩模拟。文章详细记录了14个关键问题的解决过程，包括字段校验、上下文处理、语音集成等挑战。最终系统支持多业务配置化扩展、敏感信息后置采集、移动端语音交互等特性，展示了AI辅助开发的

AtomGit开源社区

TensorFlow TPU训练超快

AtomGit开源社区

【一次调频】考虑储能电池参与一次调频技术经济模型的容量配置方法（Matlab代码实现）

规模间歇电源并网引起的电网频率问题,导致对引入储能辅助调频的研究越发迫切。提出一种考虑储能电池参与一次调频技术经济模型的容量配置方法。阐述了储能电池功率和容量设计的通用方法;通过分析储能电池在调频运行过程中的成本和效益,基于全寿命周期理论,运用净现值法结合仿真模型构建储能电池参与一次调频的技术经济模型;