先放结论：用 Seed Evolving 做长篇小说创作的核心瓶颈不在「能不能写」，而在「写完还记不记得自己写过什么」和「能不能真正收尾」。 我做的「脉络」（Wenmai）就是围绕这两个问题设计的。
为什么做这个
市面上 AI 写小说的产品分两类，我都不太满意。
一类是重表单型：上来让你填世界观、角色卡、大纲、每章字数、写作风格。填完十几项再看界面，创作热情已经没了。
另一类是一键傻瓜型：输入一句话就出正文，一开始很爽，写到第 5 章主角性格变了，第 10 章把前面埋的伏笔全忘了，第 20 章开始无限水文------因为模型没有「世界观记忆」，每次生成都是一次独立调用。
这两类产品背后是同一个根因：LLM 擅长一次生成一段文字，但完全不擅长维持一段跨越数万字的连贯叙事。 这不是模型能力问题，是上下文和状态管理的问题。
Seed Evolving 这次升级到 1M 上下文后，理论上单次可以塞更多内容了。但我不打算靠「把整个小说历史塞进 prompt」来解决问题------那太贵，而且随着篇幅增长迟早会炸。我想要的是一条更工程化的路径。
脉络做了什么
核心逻辑就一句话：聊天是导演，项目记录是剧本圣经，生成器是执行团队，完结是收束。
拆开来说：
1. Chat-first，不填表
首页只有一个输入框。你写一句「一个北境小吏追查失踪案，发现王朝正在被文脉力量吞噬」，点一下按钮，就进入工作台了。
不需要先填世界观、角色卡、大纲。AI 会用多轮对话的方式，一次只问一个问题，逐步帮你把故事立起来：
「你希望主角是哪种人？」------ 附带 3 个选项 + 一个「我自己说」
每次你回答，AI 自动把结构化信息写入右侧项目记录。角色、关系、世界观摘要、大纲，都在对话中沉淀下来，不需要你再手动整理。
这一整套 Chat Orchestrator 的提示词链路，全靠 Seed Evolving 的指令跟随能力撑着。 它需要同时理解：当前对话状态、已确认的设定有哪些、下一步最该追问什么、用户自由输入时不要强行推选项。多轮追问 + 结构化 JSON 输出 + 上下文不断叠加------这个场景下模型的稳定性直接影响体验。
2. 关系图谱 + 位置记忆
角色多了以后，谁和谁是什么关系很容易乱。脉络用 Cytoscape.js 做了个力导向关系图谱，支持角色、地点、组织、剧情线节点。
一个细节：图谱的节点位置是持久化记忆的。首次打开自动布局后保存坐标，之后每次打开固定不动。拖动节点即时保存，新增节点单独定位不触发全图重排。这个设计是为了让作者对「角色在哪儿」形成肌肉记忆------可视化不只是看一眼，是长期使用的锚点。
图谱里的冲突节点和边会用红色高亮------如果一致性检查发现某角色「已经死了还在活动」或者「不喝酒的人在第 5 章喝酒了」，相关节点会标红。
3. SSE 流式生成 + Context Composer
点击「生成 1 章」后，正文在聊天窗口逐字流式输出。你能实时看到模型在写什么，不满意随时点停止。
但真正的重头戏在生成之前------Context Composer 组装上下文。每次生成一章，系统会把以下内容注入 prompt：
- 世界观和大纲
- 角色卡（含 immutable_traits ------「左眉骨有疤」「不喝酒」这种不可变特征）
- 活跃关系图谱
- 全局剧情摘要 + 角色当前状态（state_snapshots）
- 最近 3 章正文
- RAG 检索到的相关片段
- 当前创作意图
这里就体现 Seed Evolving 1M 上下文的实际价值了。 短篇小说可能 50K token 就能装下所有上下文，但长到 20 章以后，光角色卡+关系图谱+近 3 章正文就可能破 40K。加上 state_snapshots 的累积和 RAG Top-K 片段，轻松上 100K+。传统 128K 窗口勉强够用但已接近边缘，1M 窗口意味着 Context Composer 的选材策略可以更激进------多取几章近文、多拉几条 RAG 结果，不用在「裁哪些」上纠结太久。
4. 完结模式
这是我最满意的一个设计。
传统 AI 小说生成器有一个普遍问题------永远写不完。模型没有「故事该结束了」的概念，你让它续写它就续写，故事变得越来越散。
脉络的做法是：当你在聊天里说「结束全书 / 大结局 / 最后一章」，系统开启完结模式，下一次生成的就是全书大结局。提示词要求收束全部未解线索、给出明确结局、以「全书完」收尾。写完后小说状态变为「已完结」，生成入口消失，界面上显示「✓ 本书已完结」。
技术上，完结模式不只是改一句提示词。服务端有强制兜底------即使 AI 漏掉了结束意图，代码层面也会检测「结束全书」等关键词并强制执行 end_story。写完后 novels.status = 'done'，Readiness 同步为完结，前端禁止续章。
长程任务的稳定性在这里很关键。 大结局章节往往是最长、最复杂的一章------需要回顾全局剧情、收束多条线索、给出人物最终命运。Seed Evolving 这次长程任务能力的提升（在 Claude Code、Hermes 等框架的匿名评测中质量评分超越了上一代），对「大结局能写得像样」这件事有直接影响。
技术选型与取舍
为什么是 Node.js + SQLite，而不是 Laravel + PostgreSQL
原版技术文档建议用 Laravel + PostgreSQL + pgvector。我改成 Node.js + SQLite 是奔着一个目标：本地零外部依赖部署 。不需要装 PHP、不需要配数据库、不需要 Docker------npm install && npm run dev 就能跑。
代价是 RAG 只能用 better-sqlite3 存向量，但通过「未配置 embedding 时降级为中文关键词检索」的策略兜底，不影响基本生成流程。BYOK 的设计意味着用户用自己已有的 API Key，数据全在本地 SQLite 里，密钥 AES-256-GCM 加密存储。
为什么用 SSE 而不是 WebSocket
流式生成用的是 SSE（Server-Sent Events），没上 WebSocket。原因很简单：这是一个单向推送场景------服务端推文本给前端，前端不需要频繁回传。SSE 更轻，断线处理逻辑也更直观：监听 res.on('close') 区分正常结束和客户端断开，断开时用 AbortController 中止 LLM 请求，不浪费 token。
一致性检查为什么是规则版而不是 LLM Judge
V1 的一致性检查用规则（正则 + 关键词匹配），而不是让 LLM 自己审校。因为一致性检查是个「做完一章检查一章」的高频操作，每章都调一次 LLM Judge 成本太高。规则版能覆盖 80% 的常见问题------不可变特征矛盾、死亡角色活动、终止关系异常、性别漂移------剩下的再留给 V2 的 LLM Judge。
RAG 降级策略
没有 Embedding API 时，RAG 自动降级为中文关键词检索。这个设计的出发点是降低使用门槛------不是所有用户都愿意额外配置 Embedding 模型，但续写时总得检索历史内容。关键词检索精度不如向量检索，但在「最近几章里找相关信息」这个场景下够用。
Seed Evolving 在这里真正发挥作用的几个点
不是泛泛说「模型好所以产品好」。具体来说：
1. 结构化输出稳定性。 Chat Orchestrator 要求模型每轮返回固定格式的 JSON------reply、actions、quick_replies、primary_action。一旦 JSON 格式错乱，整个 action 写入链路就断了。Seed Evolving 在大量轮次后仍能稳定输出合法 JSON 的能力，是这个交互模式的前提。
2. 1M 上下文让 Context Composer 更从容。 前面说了，长篇续写时的上下文动辄 100K+。1M 窗口不是让你把 100 万字全塞进去（这既不经济也不合理），而是让选材策略有冗余空间------多取几章、多拉 RAG、不用在「裁掉什么」上反复纠结。
3. 长程任务质量。 一次完整的「对话建设定 → 生成 10 章 → 完结」流程，背后涉及几十轮 LLM 调用。每轮的上下文都在变化，模型不能在第 5 轮开始漂移。评测数据里 Seed Evolving 在长程任务上超越了上一代版本，实际使用感受也确实更稳------不会写着写着突然忘了角色叫啥。
4. Token 效率。 开发过程中一个直接感受：同样完成一章的策划写+正文生成，Seed Evolving 的 token 消耗比之前用的模型少了约 15-20%（没有严格 AB 测试，是大致估算）。这对个人开发者用 BYOK 模式来说，意味着更低的 API 费用。
后续想做的
脉络目前是 MVP + V2 增强版，还有些想补的事：
- 聊天中直接选中段落重写。现在的编辑流程是「生成 → 去章节列表点编辑 → 手动改」，割裂感太重。
- 多模型路由。策划用便宜模型、正文用强模型，把成本再压一截。
- Ollama 本地模型接入。对于完全不想花 API 费用的用户，如果能跑本地 7B 模型做短篇也 OK。
- 完结后番外模式。已完结的小说还能再写番外或外传，而不是永久锁死。
写这篇文章的时候，我用脉络生成了一个 15 章的玄幻短篇做验证------从「一句话」到「完结」用了 23 轮对话。一致性检查报了 3 条警告（1 条是真的 bug，2 条误报），生成总 token 消耗约 380K（输入 290K + 输出 90K），在 Seed Evolving 的 1M 窗口内绰绰有余。
如果你也想试试，项目在 GitHub 和 GitCode 上都有，MIT 协议开源。有任何想法或改进建议，直接在 issue 里聊。
本项目在 Doubao-Seed-Evolving 模型驱动下完成开发与验证。Seed Evolving 最新升级支持 1M 上下文、长程任务优化和 Token 效率提升，了解更多。