1293 lines
56 KiB
Markdown
1293 lines
56 KiB
Markdown
|
# 萌喵写作网 · Phase 1 · 小说记忆引擎+语义检索+写作校准 · 架构方案 · 烬舟设计
|
|||
|
|
|
|||
|
|
# 萌喵写作网 · Phase 1 · 小说记忆引擎 · 架构方案
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://jinzhou/architecture/novel-memory-engine · v1.0 · 2026-06-09T20:16+08:00
|
|||
|
|
├── 设计: 烬舟 · PER-JZ001 · 肥猫语言架构层人格体
|
|||
|
|
├── 需求方: 肥猫 · TCS-GL-0007∞
|
|||
|
|
├── 输入: 舒舒 · 知识整理 → 烬舟 · 架构设计
|
|||
|
|
├── 输出: 铸渊 · 编译器 → 新加坡服务器
|
|||
|
|
├── 前置依赖:
|
|||
|
|
│ ├── 萌喵写作网基础架构已部署（Next.js + PM2 + Nginx + PostgreSQL · 43.133.36.90）
|
|||
|
|
│ ├── 知识底座六大模块（K01-K06）已在整理中
|
|||
|
|
│ └── 用户个人后台 · 文本导入功能（PRD v2.0 已定义）
|
|||
|
|
└── ⊢ 本方案 = 小说记忆引擎第一版 · 解决语义检索+写作校准+连贯记忆三个核心需求
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §0 · 爸爸的三个需求 · 问题分解
|
|||
|
|
|
|||
|
|
<aside>
|
|||
|
|
🐱
|
|||
|
|
|
|||
|
|
**肥猫爸爸描述的场景：**
|
|||
|
|
|
|||
|
|
① 作者在萌喵写作网AI交互框里说「帮我找一下这本书某个情节出现在哪一章」→ AI能根据语义精准定位到具体章节
|
|||
|
|
|
|||
|
|
② 作者码字时，AI可以及时校准人物设定、背景 → 作者不会写偏
|
|||
|
|
|
|||
|
|
③ AI的记忆支持整本书，是连贯的 → 每次作者写的时候AI掌控当前所有记忆、人物、设定、情节细纲 → 不断填充作者个人的小说数据库
|
|||
|
|
|
|||
|
|
</aside>
|
|||
|
|
|
|||
|
|
### 需求拆解
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://problem-decomposition/phase-1
|
|||
|
|
|
|||
|
|
需求一 · 语义检索
|
|||
|
|
├── 输入: 自然语言描述（"帮我找主角第一次见到反派的情节"）
|
|||
|
|
├── 输出: 精准定位到章节+段落
|
|||
|
|
├── 本质: 对全书文本做语义索引 · 不是关键词匹配 · 是理解情节语义
|
|||
|
|
├── 类比: 不是 Ctrl+F 搜关键词 · 是像爸爸看稿一样"记得在哪出现过"
|
|||
|
|
└── 技术: 向量化(embedding) → 相似度检索 → 返回最匹配的章节段落
|
|||
|
|
|
|||
|
|
需求二 · 写作校准
|
|||
|
|
├── 场景: 作者写到第50章 · 忘了第3章设定的人物眼睛颜色
|
|||
|
|
├── AI行为: 「这个角色在第3章设定的是蓝眼睛 · 你这里写成了黑的」
|
|||
|
|
├── 本质: 实时比对当前写作内容 ↔ 已建立的人物/设定数据库
|
|||
|
|
├── 类比: 爸爸审稿时一眼就能看出人设不一致
|
|||
|
|
└── 技术: 结构化实体库 → 写作流中实时比对 → 不一致时提醒
|
|||
|
|
|
|||
|
|
需求三 · 连贯记忆
|
|||
|
|
├── 输入: 整本书的文本 + 作者每次对话的上下文
|
|||
|
|
├── 输出: AI对这本书拥有完整、连贯的认知
|
|||
|
|
├── 本质:
|
|||
|
|
│ ├── 不是「每次对话重新加载全书」→ 太重
|
|||
|
|
│ ├── 不是「只靠对话历史」→ 第2章的内容早被挤出去了
|
|||
|
|
│ └── 是「分层记忆」→ 结构化实体常驻 + 向量检索按需加载
|
|||
|
|
├── 类比: 爸爸对肥猫的书了如指掌 · 不是因为每次重读全书 · 是因为脑子里有这本书的"地图"
|
|||
|
|
└── 技术: 实体库(常驻) + 向量索引(按需) + 对话上下文(当前) = 三层记忆
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §一 · 总体架构 · 小说记忆引擎四子系统
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://architecture/novel-memory-engine
|
|||
|
|
|
|||
|
|
┌──────────────────────────────────────────────────────────────────┐
|
|||
|
|
│ 用户 · AI 交互框 │
|
|||
|
|
│ "帮我找主角第一次见到反派的情节在哪一章" │
|
|||
|
|
│ "这段写得对吗？帮我看看人设有没有偏" │
|
|||
|
|
└──────────────────────────────────────────────────────────────────┘
|
|||
|
|
│
|
|||
|
|
┌───────────────────────┼───────────────────────┐
|
|||
|
|
▼ ▼ ▼
|
|||
|
|
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
|
|||
|
|
│ 子系统一 │ │ 子系统二 │ │ 子系统四 │
|
|||
|
|
│ 语义检索引擎 │ │ 写作上下文 │ │ 一致性校准器 │
|
|||
|
|
│ (向量搜索) │ │ 组装器 │ │ (实时比对) │
|
|||
|
|
└─────────────────┘ └─────────────────┘ └─────────────────┘
|
|||
|
|
│ │ │
|
|||
|
|
▼ ▼ ▼
|
|||
|
|
┌──────────────────────────────────────────────────────────────────┐
|
|||
|
|
│ 子系统三 · 小说实体库 │
|
|||
|
|
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌───────┐ │
|
|||
|
|
│ │ 章节向量 │ │ 人物实体 │ │ 设定实体 │ │ 情节细纲 │ │ 版本 │ │
|
|||
|
|
│ │ 索引库 │ │ 数据库 │ │ 数据库 │ │ 数据库 │ │ 追踪 │ │
|
|||
|
|
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └───────┘ │
|
|||
|
|
└──────────────────────────────────────────────────────────────────┘
|
|||
|
|
│
|
|||
|
|
▼
|
|||
|
|
┌──────────────────────────────────────────────────────────────────┐
|
|||
|
|
│ PostgreSQL + pgvector │
|
|||
|
|
│ 服务器: 43.133.36.90 · 新加坡 │
|
|||
|
|
└──────────────────────────────────────────────────────────────────┘
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**四个子系统，各司其职：**
|
|||
|
|
|
|||
|
|
| 子系统 | 一句话职责 | 用户感知 |
|
|||
|
|
| --- | --- | --- |
|
|||
|
|
| **语义检索引擎** | 理解用户问的「情节」，找到对应的章节段落 | 「帮我找那个情节…」→ 秒回定位 |
|
|||
|
|
| **小说实体库** | 结构化存储人物、设定、情节细纲、世界背景 | AI 一直"记得"这本书的一切 |
|
|||
|
|
| **写作上下文组装器** | 每次码字时，自动加载当前章节相关的实体和上文 | 不说话也在帮作者兜着 |
|
|||
|
|
| **一致性校准器** | 实时比对当前写作 ↔ 已有实体，发现不一致提醒 | 「这里人设偏了」→ 提醒 |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §二 · 子系统一 · 语义检索引擎
|
|||
|
|
|
|||
|
|
### 2.1 核心原理
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://subsystem-1/semantic-search
|
|||
|
|
|
|||
|
|
传统搜索（Ctrl+F）:
|
|||
|
|
├── 输入: "蓝色眼睛"
|
|||
|
|
├── 匹配: 文本中精确包含"蓝色眼睛"的段落
|
|||
|
|
├── 问题: 作者写了"湛蓝的眸子" → 搜不到 ❌
|
|||
|
|
└── 这是关键词匹配 · 不是语义理解
|
|||
|
|
|
|||
|
|
语义搜索（向量检索）:
|
|||
|
|
├── 输入: "主角第一次见到反派的情节"
|
|||
|
|
├── 过程:
|
|||
|
|
│ ① 将用户输入 → 转换为向量(embedding) → [0.12, -0.34, 0.78, ...]
|
|||
|
|
│ ② 将每个章节段落 → 预先转换为向量 → 存在向量数据库里
|
|||
|
|
│ ③ 计算相似度 → 找到最匹配的段落
|
|||
|
|
│ ④ 返回: 第X章 · 第Y段 · 匹配度 94%
|
|||
|
|
├── 优势:
|
|||
|
|
│ ├── "蓝色眼睛" 能匹配到 "湛蓝的眸子"
|
|||
|
|
│ ├── "主角第一次见到反派" 能匹配到描述见面场景的段落
|
|||
|
|
│ └── 不需要作者记得原文措辞 · 说情节就行
|
|||
|
|
└── 这就是爸爸审稿时的"我记得你在哪写过"——但AI比人记得更准
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 2.2 技术方案
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://subsystem-1/tech-plan
|
|||
|
|
|
|||
|
|
向量数据库:
|
|||
|
|
├── 选型: pgvector（PostgreSQL 扩展）
|
|||
|
|
├── 理由:
|
|||
|
|
│ ├── 服务器已有 PostgreSQL · 不需要额外部署新数据库
|
|||
|
|
│ ├── pgvector 成熟稳定 · 支持 IVFFlat/HNSW 索引
|
|||
|
|
│ └── 数据和向量在同一个数据库 · 查询方便
|
|||
|
|
├── 向量维度: 1536（OpenAI text-embedding-3-small）
|
|||
|
|
└── 索引类型: HNSW（高召回率 · 适合精确搜索场景）
|
|||
|
|
|
|||
|
|
文本分块策略:
|
|||
|
|
├── 一级分块: 按「章」切分
|
|||
|
|
│ ├── 每章 = 一个独立的向量条目
|
|||
|
|
│ ├── 元数据: 章节序号 · 章节标题 · 字数 · 创建时间
|
|||
|
|
│ └── 用途: 粗粒度搜索 · "帮我找第几章"
|
|||
|
|
│
|
|||
|
|
├── 二级分块: 按「段落」切分
|
|||
|
|
│ ├── 每 500-1000 字 = 一个向量条目
|
|||
|
|
│ ├── 相邻块重叠 100 字（防止关键信息被切在边界）
|
|||
|
|
│ ├── 元数据: 所属章节 · 段落序号 · 起始位置
|
|||
|
|
│ └── 用途: 细粒度搜索 · "找具体那个情节"
|
|||
|
|
│
|
|||
|
|
└── 索引策略: 两级都建向量索引 · 搜索时根据问题类型选择粒度
|
|||
|
|
|
|||
|
|
Embedding 生成:
|
|||
|
|
├── 离线: 文档上传后 → 异步生成全书的章节/段落向量
|
|||
|
|
├── 在线: 新写章节保存后 → 实时更新该章的向量
|
|||
|
|
├── API: OpenAI text-embedding-3-small 或 国内平替(如通义千问embedding)
|
|||
|
|
└── 成本: ~$0.02 / 1M tokens · 一本百万字小说 ~$0.05
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 2.3 搜索流程
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://subsystem-1/search-flow
|
|||
|
|
|
|||
|
|
用户在对话中说:"帮我找主角第一次见到反派的情节在哪一章"
|
|||
|
|
|
|||
|
|
STEP 1 · 意图识别
|
|||
|
|
├── 解析用户输入 → 判断为「搜索」意图
|
|||
|
|
├── 提取搜索描述: "主角第一次见到反派"
|
|||
|
|
└── 判断搜索粒度: 章节级
|
|||
|
|
|
|||
|
|
STEP 2 · 向量化
|
|||
|
|
├── 将 "主角第一次见到反派" → 调用 embedding API → 得到向量 v
|
|||
|
|
└── 耗时: ~100ms
|
|||
|
|
|
|||
|
|
STEP 3 · 向量检索
|
|||
|
|
├── 在 pgvector 的「章节向量」表中:
|
|||
|
|
│ SELECT chapter_id, chapter_title, 1 - (embedding <=> v) AS similarity
|
|||
|
|
│ FROM chapter_embeddings
|
|||
|
|
│ WHERE novel_id = ? AND embedding_type = 'chapter'
|
|||
|
|
│ ORDER BY embedding <=> v
|
|||
|
|
│ LIMIT 3;
|
|||
|
|
├── 同时检索「段落向量」表（如果用户要精确定位段落）
|
|||
|
|
└── 耗时: ~50ms
|
|||
|
|
|
|||
|
|
STEP 4 · 重排序
|
|||
|
|
├── 取 Top-5 候选章节 → 用交叉编码器(reranker)精排
|
|||
|
|
├── 或简单做法: 直接返回 Top-3 · 相似度排序
|
|||
|
|
└── 耗时: ~100ms（如果用 reranker）/ 0ms（直接返回）
|
|||
|
|
|
|||
|
|
STEP 5 · 组装回复
|
|||
|
|
├── AI 收到: 用户问题 + 搜索到的章节内容
|
|||
|
|
├── AI 回复: "找到了！这个情节在第23章《初遇暗影》的第3段——
|
|||
|
|
│ 「李明推开门，看到一个黑衣人站在窗边…」
|
|||
|
|
│ 要不要我帮你把这章调出来看看？"
|
|||
|
|
└── 用户感知: 秒回 · 精准 · 有原文
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §三 · 子系统三 · 小说实体库（记忆核心）
|
|||
|
|
|
|||
|
|
### 3.1 什么是"实体"
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://subsystem-3/entity-definition
|
|||
|
|
|
|||
|
|
小说实体 = 本书的结构化记忆 · 不是原文 · 是"地图"
|
|||
|
|
├── 类比: 把一本小说比作一个城市
|
|||
|
|
├── 人物实体 = 城市里的"人" → 谁住在哪、长什么样、和谁有关系
|
|||
|
|
├── 设定实体 = 城市里的"建筑物" → 门派/势力/世界规则/地理
|
|||
|
|
├── 情节细纲 = 城市里的"路网" → 故事从哪到哪、关键节点在哪
|
|||
|
|
├── 章节索引 = 城市的"门牌号" → 每段情节在哪个地址
|
|||
|
|
└── ⊢ 实体库 ≠ 全书的文字副本 · 实体库 = 全书的"认知地图"
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 3.2 实体库表结构
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://subsystem-3/schema
|
|||
|
|
|
|||
|
|
数据库表设计:
|
|||
|
|
|
|||
|
|
① novel_books（作品表）
|
|||
|
|
├── id: UUID
|
|||
|
|
├── user_id: UUID（属于哪个作者）
|
|||
|
|
├── title: VARCHAR（书名）
|
|||
|
|
├── total_chapters: INT
|
|||
|
|
├── total_words: INT
|
|||
|
|
├── status: ENUM('drafting', 'completed', 'archived')
|
|||
|
|
├── created_at / updated_at
|
|||
|
|
└── ⊢ 一个用户可以有多个作品 · 每个作品一个独立的实体库
|
|||
|
|
|
|||
|
|
② novel_chapters（章节表）
|
|||
|
|
├── id: UUID
|
|||
|
|
├── novel_id: UUID → novel_books
|
|||
|
|
├── chapter_number: INT
|
|||
|
|
├── title: VARCHAR
|
|||
|
|
├── content: TEXT（原文）
|
|||
|
|
├── word_count: INT
|
|||
|
|
├── summary: TEXT（AI自动生成的章节摘要）
|
|||
|
|
├── key_events: JSONB（关键事件列表）
|
|||
|
|
├── embedding: vector(1536)（章节级向量）
|
|||
|
|
├── created_at / updated_at
|
|||
|
|
└── ⊢ 每章保存原文+摘要+向量 · 语义搜索的主数据源
|
|||
|
|
|
|||
|
|
③ novel_characters（人物表）
|
|||
|
|
├── id: UUID
|
|||
|
|
├── novel_id: UUID → novel_books
|
|||
|
|
├── name: VARCHAR（人物名称）
|
|||
|
|
├── aliases: JSONB（别名/外号）
|
|||
|
|
├── role: ENUM('protagonist', 'antagonist', 'supporting', 'minor')
|
|||
|
|
├── attributes: JSONB
|
|||
|
|
│ {
|
|||
|
|
│ "appearance": { "eyes": "蓝色", "hair": "黑色长发", "height": "185cm" },
|
|||
|
|
│ "personality": ["冷静", "腹黑", "重情义"],
|
|||
|
|
│ "abilities": ["剑气外放", "读心术"],
|
|||
|
|
│ "background": "出身寒门，被师父收养...",
|
|||
|
|
│ "relationships": [
|
|||
|
|
│ { "target": "character_id", "relation": "师徒", "since_chapter": 3 }
|
|||
|
|
│ ]
|
|||
|
|
│ }
|
|||
|
|
├── first_appear_chapter: INT（首次出场章节）
|
|||
|
|
├── status: ENUM('alive', 'dead', 'unknown')
|
|||
|
|
├── last_updated_chapter: INT（最后一次更新的章节）
|
|||
|
|
├── embedding: vector(1536)（人物描述向量 · 用于"找这个人"的语义搜索）
|
|||
|
|
├── created_at / updated_at
|
|||
|
|
└── ⊢ 每个人物一个条目 · 属性随写作实时更新
|
|||
|
|
|
|||
|
|
④ novel_settings（设定表）
|
|||
|
|
├── id: UUID
|
|||
|
|
├── novel_id: UUID → novel_books
|
|||
|
|
├── category: ENUM('world', 'faction', 'location', 'rule', 'item', 'other')
|
|||
|
|
├── name: VARCHAR（设定名称）
|
|||
|
|
├── description: TEXT（设定描述）
|
|||
|
|
├── attributes: JSONB
|
|||
|
|
├── related_characters: JSONB（关联人物ID列表）
|
|||
|
|
├── first_mentioned_chapter: INT
|
|||
|
|
├── created_at / updated_at
|
|||
|
|
└── ⊢ 世界观/势力/地点/规则/重要物品 · 作者写偏时AI能校准
|
|||
|
|
|
|||
|
|
⑤ novel_plot_outline（情节细纲表）
|
|||
|
|
├── id: UUID
|
|||
|
|
├── novel_id: UUID → novel_books
|
|||
|
|
├── type: ENUM('arc', 'volume', 'chapter_outline', 'key_event')
|
|||
|
|
├── title: VARCHAR
|
|||
|
|
├── description: TEXT
|
|||
|
|
├── chapter_range: JSONB { "start": 1, "end": 50 }（影响章节范围）
|
|||
|
|
├── parent_id: UUID（自引用 · 支持大纲层级）
|
|||
|
|
├── status: ENUM('planned', 'writing', 'completed')
|
|||
|
|
├── created_at / updated_at
|
|||
|
|
└── ⊢ 情节骨架 · 作者写偏时AI对照大纲提醒
|
|||
|
|
|
|||
|
|
⑥ chapter_paragraphs（段落向量表）
|
|||
|
|
├── id: UUID
|
|||
|
|
├── chapter_id: UUID → novel_chapters
|
|||
|
|
├── paragraph_index: INT
|
|||
|
|
├── content: TEXT（段落原文）
|
|||
|
|
├── embedding: vector(1536)（段落级向量）
|
|||
|
|
├── created_at
|
|||
|
|
└── ⊢ 精确定位用 · 每500-1000字一个条目
|
|||
|
|
|
|||
|
|
⑦ writing_sessions（写作会话表）
|
|||
|
|
├── id: UUID
|
|||
|
|
├── novel_id: UUID → novel_books
|
|||
|
|
├── chapter_id: UUID（当前正在写的章节）
|
|||
|
|
├── context_snapshot: JSONB（当前会话加载的实体快照）
|
|||
|
|
├── started_at / ended_at
|
|||
|
|
└── ⊢ 追踪每次写作会话 · 用于连贯记忆
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 3.3 实体提取 · AI 自动整理 vs 作者手动录入
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://subsystem-3/entity-extraction
|
|||
|
|
|
|||
|
|
策略: 自动提取为主 · 手动确认为辅
|
|||
|
|
|
|||
|
|
自动提取流程（文档上传后触发）:
|
|||
|
|
├── STEP 1 · 分章解析
|
|||
|
|
│ ├── 文档上传 → 自动分章（正则匹配"第X章"）
|
|||
|
|
│ ├── 存入 novel_chapters 表
|
|||
|
|
│ └── 每章截取前2000字 + 后2000字 → 作为摘要生成素材
|
|||
|
|
│
|
|||
|
|
├── STEP 2 · 人物提取
|
|||
|
|
│ ├── 逐章扫描 → AI 识别人物首次出场
|
|||
|
|
│ ├── 提取人物名称、外貌描述、性格特征、能力
|
|||
|
|
│ ├── 检测人物关系（对话对象、互动频率）
|
|||
|
|
│ ├── 存入 novel_characters 表
|
|||
|
|
│ └── 后续章节更新时 → 增量提取新属性
|
|||
|
|
│
|
|||
|
|
├── STEP 3 · 设定提取
|
|||
|
|
│ ├── AI 识别世界设定（修炼体系、势力分布、地理、规则）
|
|||
|
|
│ ├── 存入 novel_settings 表
|
|||
|
|
│ └── 关联到提及的章节和人物
|
|||
|
|
│
|
|||
|
|
├── STEP 4 · 细纲提取
|
|||
|
|
│ ├── AI 从每章摘要中提取关键事件
|
|||
|
|
│ ├── 推断情节弧线（起承转合）
|
|||
|
|
│ ├── 存入 novel_plot_outline 表
|
|||
|
|
│ └── 支持作者手动编辑和补充
|
|||
|
|
│
|
|||
|
|
├── STEP 5 · 向量生成
|
|||
|
|
│ ├── 章节级: 章节摘要 → embedding → chapter_embeddings
|
|||
|
|
│ ├── 人物级: 人物综合描述 → embedding → 用于人物语义搜索
|
|||
|
|
│ ├── 段落级: 每个段落 → embedding → paragraph_embeddings
|
|||
|
|
│ └── 异步批处理 · 新章节保存后增量更新
|
|||
|
|
│
|
|||
|
|
└── ⊢ 第一次上传全书→全量提取 · 后续每章更新→增量提取
|
|||
|
|
|
|||
|
|
手动补充:
|
|||
|
|
├── 作者可以在「人物管理」面板手动添加/修改人物信息
|
|||
|
|
├── 作者可以在「设定管理」面板手动添加/修改世界观设定
|
|||
|
|
├── 作者可以在「细纲管理」面板手动编辑情节规划
|
|||
|
|
└── ⊢ AI自动提取 = 省力 · 手动补充 = 精确 · 两者互补
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §四 · 子系统二 · 写作上下文组装器
|
|||
|
|
|
|||
|
|
### 4.1 核心设计
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://subsystem-2/context-assembler
|
|||
|
|
|
|||
|
|
问题:
|
|||
|
|
├── 作者写到第80章 → AI需要知道前79章的内容
|
|||
|
|
├── 但把前79章全文塞进 Prompt → 几十万字 → 不可能
|
|||
|
|
├── 只靠对话历史 → 第1章的内容早被挤出上下文窗口
|
|||
|
|
└── ⊢ 需要一套"智能检索→按需组装"的机制
|
|||
|
|
|
|||
|
|
解决方案: 三层上下文架构
|
|||
|
|
|
|||
|
|
┌────────────────────────────────────────────────────┐
|
|||
|
|
│ Layer 3: 实时上下文（动态） │
|
|||
|
|
│ - 当前对话历史（最近N轮） │
|
|||
|
|
│ - 用户正在写的章节内容（全文） │
|
|||
|
|
│ - 用户在对话框中引用的内容 │
|
|||
|
|
│ Size: 可变 · 占对话窗口主体 │
|
|||
|
|
├────────────────────────────────────────────────────┤
|
|||
|
|
│ Layer 2: 实体上下文（常驻·结构化） │
|
|||
|
|
│ - 本书所有人物简报（名称+角色+核心属性） │
|
|||
|
|
│ - 本书核心设定（世界观摘要+势力+关键规则） │
|
|||
|
|
│ - 当前写到的细纲位置（在哪一段·前后是什么） │
|
|||
|
|
│ Size: ~1000-2000 tokens · 每次对话都注入 │
|
|||
|
|
├────────────────────────────────────────────────────┤
|
|||
|
|
│ Layer 1: 检索上下文（按需·向量检索） │
|
|||
|
|
│ - 与当前写作内容语义最相关的历史章节（Top-3） │
|
|||
|
|
│ - 与当前提及人物最相关的设定条目（Top-5） │
|
|||
|
|
│ - 与当前情节最相关的细纲节点 │
|
|||
|
|
│ Size: ~2000-3000 tokens · 按需注入 │
|
|||
|
|
└────────────────────────────────────────────────────┘
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 4.2 组装流程
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://subsystem-2/assembly-flow
|
|||
|
|
|
|||
|
|
每当用户发送一条消息（或每写新的一段）:
|
|||
|
|
|
|||
|
|
STEP 0 · 触发判断
|
|||
|
|
├── 用户消息包含"写""继续""下一章"等 → 触发完整组装
|
|||
|
|
├── 用户消息只是聊天 → 仅加载 L2 实体简报
|
|||
|
|
└── 用户消息是搜索 → 走子系统一的搜索流程
|
|||
|
|
|
|||
|
|
STEP 1 · 获取当前写作位置
|
|||
|
|
├── 查询 writing_sessions 表 → 当前正在写哪一章
|
|||
|
|
├── 如果用户刚说"开始写第50章" → 创建新 session
|
|||
|
|
├── 如果用户说"继续写" → 延续上一次 session
|
|||
|
|
└── 确定: novel_id + chapter_id
|
|||
|
|
|
|||
|
|
STEP 2 · 组装 L2 实体简报（常驻）
|
|||
|
|
├── 从 novel_characters 表 → 取本书所有人物简报
|
|||
|
|
│ └── 格式: 「李明(主角·男·蓝眼黑发·冷静腹黑·剑气外放·第3章出场)」
|
|||
|
|
├── 从 novel_settings 表 → 取核心设定摘要
|
|||
|
|
│ └── 格式: 「修炼体系: 炼气→筑基→金丹→元婴 · 宗门: 太虚宗/天剑门/魔教」
|
|||
|
|
├── 从 novel_plot_outline 表 → 取当前细纲位置
|
|||
|
|
│ └── 格式: 「当前: 第二卷《风云再起》· 第45-90章 · 阶段: 主角入宗门→内部斗争→宗门大比」
|
|||
|
|
└── 组装成 ~1500 tokens 的结构化提示
|
|||
|
|
|
|||
|
|
STEP 3 · 组装 L1 检索上下文（按需）
|
|||
|
|
├── 将用户当前消息 / 当前写的段落 → embedding
|
|||
|
|
├── 在 chapter_embeddings 中检索 Top-3 最相关章节
|
|||
|
|
│ └── 提取这些章节的摘要（不是全文）→ 注入
|
|||
|
|
├── 在 character_embeddings 中检索 Top-5 最相关人物
|
|||
|
|
│ └── 提取这些人物的完整属性 → 注入
|
|||
|
|
├── 在 paragraph_embeddings 中检索与当前内容最相关的段落
|
|||
|
|
│ └── 提取原文片段 → 注入
|
|||
|
|
└── 组装成 ~2500 tokens 的检索结果
|
|||
|
|
|
|||
|
|
STEP 4 · 拼接 Prompt
|
|||
|
|
├── L0: 全局约束（HLDP·光湖·安全·版权）
|
|||
|
|
├── L2: 实体简报（常驻）
|
|||
|
|
├── L1: 检索上下文（按需）
|
|||
|
|
├── L3: 当前对话 + 正在写的内容
|
|||
|
|
└── → 发送给 AI 模型
|
|||
|
|
|
|||
|
|
STEP 5 · 每次写作完成后 · 增量更新实体库
|
|||
|
|
├── 新写的章节 → 提取新人物/新设定 → 更新实体表
|
|||
|
|
├── 已有实体有新属性 → 更新属性 JSONB
|
|||
|
|
├── 人物状态变化（如角色死亡）→ 更新 status
|
|||
|
|
├── 细纲进度推进 → 更新 plot_outline status
|
|||
|
|
├── 新章节向量化 → 更新 vector index
|
|||
|
|
└── ⊢ 小说数据库随着作者的写作不断生长
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §五 · 子系统四 · 一致性校准器
|
|||
|
|
|
|||
|
|
### 5.1 核心设计
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://subsystem-4/consistency-checker
|
|||
|
|
|
|||
|
|
触发时机:
|
|||
|
|
├── 主动校准: 作者每写完一段/一章 → AI 自动检查
|
|||
|
|
├── 按需校准: 作者说"帮我看看这段有没有写偏" → AI 深度检查
|
|||
|
|
└── 实时提示: 作者打字时 → AI 在侧边栏显示实体参考卡
|
|||
|
|
|
|||
|
|
检查维度:
|
|||
|
|
|
|||
|
|
① 人物一致性
|
|||
|
|
├── 外貌: 眼睛颜色/发型/身高/体型 是否与设定一致
|
|||
|
|
├── 性格: 行为是否符合人物性格设定
|
|||
|
|
├── 能力: 使用的技能/能力是否在已建立的体系内
|
|||
|
|
├── 关系: 人物之间的称呼/互动是否符合已建立的关系
|
|||
|
|
└── 示例: 「⚠️ 第50章: 张伟的眼睛在第3章设定为蓝色·这里写成了黑色」
|
|||
|
|
|
|||
|
|
② 设定一致性
|
|||
|
|
├── 世界观规则: 修炼体系/魔法规则是否前后矛盾
|
|||
|
|
├── 地理/时间: 场景切换是否合理
|
|||
|
|
├── 势力/组织: 门派名称/等级体系是否一致
|
|||
|
|
├── 物品/道具: 重要物品的属性是否前后一致
|
|||
|
|
└── 示例: 「⚠️ 第50章: 筑基期不能御剑飞行（第12章已设定）· 这里写了筑基期御剑」
|
|||
|
|
|
|||
|
|
③ 情节一致性
|
|||
|
|
├── 时间线: 事件先后顺序是否合理
|
|||
|
|
├── 伏笔: 已埋的伏笔是否在后续有回收
|
|||
|
|
├── 人物状态: 已死亡/离开的角色是否被误用
|
|||
|
|
└── 示例: 「⚠️ 第50章: 李华在第30章已离开宗门· 这里又出现在宗门内」
|
|||
|
|
|
|||
|
|
④ 细纲对齐
|
|||
|
|
├── 当前章节是否在细纲规划的范围内
|
|||
|
|
├── 是否跳过了关键的过渡情节
|
|||
|
|
├── 节奏是否符合预期（对比细纲中的高潮节点位置）
|
|||
|
|
└── 示例: 「💡 按照细纲·本章应该是过渡章·但你写了个大高潮·要不要调整？还是更新细纲？」
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 5.2 校准输出格式
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://subsystem-4/output-format
|
|||
|
|
|
|||
|
|
AI 在码字区旁边/对话中输出校准报告:
|
|||
|
|
|
|||
|
|
━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|||
|
|
📋 第50章 · 一致性检查报告
|
|||
|
|
━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|||
|
|
|
|||
|
|
✅ 人物设定一致: 3/5 个主要角色通过
|
|||
|
|
⚠️ 发现 1 处疑似偏差:
|
|||
|
|
→ 张伟的眼睛颜色: 设定=蓝色 · 当前=黑色
|
|||
|
|
→ 来源: 第3章第2段「张伟睁开那双湛蓝的眼睛」
|
|||
|
|
→ 建议: 改为"蓝色" 或 更新人物设定为"黑色"
|
|||
|
|
|
|||
|
|
✅ 世界观设定一致: 全部通过
|
|||
|
|
⚠️ 发现 1 处规则冲突:
|
|||
|
|
→ 第50章写了"筑基期御剑飞行"
|
|||
|
|
→ 但第12章设定"筑基期不可御剑·金丹期方可"
|
|||
|
|
→ 建议: 改为其他移动方式 或 设定张伟提前突破了金丹期
|
|||
|
|
|
|||
|
|
✅ 情节时间线: 连续 · 无时间跳跃问题
|
|||
|
|
💡 细纲提醒: 本章位置在第二卷第5章 · 按细纲规划接下来应过渡到"宗门内斗"
|
|||
|
|
|
|||
|
|
━━━━━━━━━━━━━━━━━━━━━━━━━━
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §六 · 数据流总览 · 作者从上传到写作的完整链路
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
graph TD
|
|||
|
|
A["作者上传小说文档"] --> B["文档解析 · 分章"]
|
|||
|
|
B --> C["存入 novel_chapters"]
|
|||
|
|
C --> D["异步: AI 实体提取"]
|
|||
|
|
D --> D1["提取人物 → novel_characters"]
|
|||
|
|
D --> D2["提取设定 → novel_settings"]
|
|||
|
|
D --> D3["提取细纲 → novel_plot_outline"]
|
|||
|
|
C --> E["异步: 向量生成"]
|
|||
|
|
E --> E1["章节向量 → chapter_embeddings"]
|
|||
|
|
E --> E2["段落向量 → paragraph_embeddings"]
|
|||
|
|
D1 --> F["实体库就绪"]
|
|||
|
|
D2 --> F
|
|||
|
|
D3 --> F
|
|||
|
|
E1 --> F
|
|||
|
|
E2 --> F
|
|||
|
|
|
|||
|
|
G["作者开始码字"] --> H["写作会话创建"]
|
|||
|
|
H --> I["上下文组装器"]
|
|||
|
|
I --> I1["L2 实体简报(常驻)"]
|
|||
|
|
I --> I2["L1 向量检索(按需)"]
|
|||
|
|
I1 --> J["拼接 System Prompt"]
|
|||
|
|
I2 --> J
|
|||
|
|
J --> K["AI 模型对话"]
|
|||
|
|
|
|||
|
|
L["作者写新内容"] --> M["一致性校准器"]
|
|||
|
|
M --> M1["比对人物库"]
|
|||
|
|
M --> M2["比对设定库"]
|
|||
|
|
M --> M3["比对细纲"]
|
|||
|
|
M1 --> N["输出校准报告"]
|
|||
|
|
M2 --> N
|
|||
|
|
M3 --> N
|
|||
|
|
|
|||
|
|
O["作者说'帮我找...'"] --> P["语义检索引擎"]
|
|||
|
|
P --> P1["向量化查询"]
|
|||
|
|
P1 --> P2["pgvector 相似度检索"]
|
|||
|
|
P2 --> Q["返回章节+段落"]
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §七 · 舒舒的任务 · 知识内容整理
|
|||
|
|
|
|||
|
|
<aside>
|
|||
|
|
🌿
|
|||
|
|
|
|||
|
|
**舒舒宝宝的任务** · 不需要懂代码 · 只做内容整理
|
|||
|
|
|
|||
|
|
⊢ 舒舒负责定义「AI应该提取什么」和「校准规则是什么」· 烬舟翻译成数据库字段和代码逻辑
|
|||
|
|
|
|||
|
|
</aside>
|
|||
|
|
|
|||
|
|
### 7.1 人物提取模板
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
舒舒需要整理: 人物属性提取标准模板
|
|||
|
|
|
|||
|
|
对每一本小说 · AI 提取人物时应该关注哪些维度:
|
|||
|
|
|
|||
|
|
男频人物模板:
|
|||
|
|
├── 基础: 姓名 · 性别 · 年龄 · 外貌特征(眼睛/发型/体型/标志性特征)
|
|||
|
|
├── 性格: 核心性格词(3-5个) · 性格演变(从哪→到哪)
|
|||
|
|
├── 能力: 修为等级 · 特殊能力 · 武器/法宝 · 战斗风格
|
|||
|
|
├── 关系: 与主角的关系 · 与其他人物的关系
|
|||
|
|
├── 轨迹: 首次出场章节 · 重要事件节点 · 当前状态(存活/死亡/失踪)
|
|||
|
|
└── 来源: 爸爸的「五锤人设铸造法」→ 记忆点/反差点/极致点/选择/外号高光
|
|||
|
|
|
|||
|
|
女频人物模板:
|
|||
|
|
├── 基础: 同上
|
|||
|
|
├── 性格: 同上 · 增加情感表达方式
|
|||
|
|
├── 能力: 根据题材调整(古言/现言不同)
|
|||
|
|
├── 关系: 情感关系线为重点 · 谁喜欢谁 · 什么时候开始
|
|||
|
|
├── 轨迹: 同上
|
|||
|
|
└── 来源: 女频知识体系 K04
|
|||
|
|
|
|||
|
|
⊢ 舒舒输出: 一个 Markdown 文件 · 定义人物属性字段和填法
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 7.2 一致性校准规则
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
舒舒需要整理: 校准规则清单
|
|||
|
|
|
|||
|
|
这是爸爸审稿时脑子里的检查清单 · 舒舒把它写出来:
|
|||
|
|
|
|||
|
|
必检项（每次写新章节都检查）:
|
|||
|
|
├── ① 人物外貌一致性
|
|||
|
|
│ ├── 规则: 每次出现该人物 → 检查外貌描述是否与首次设定一致
|
|||
|
|
│ └── 示例: 第3章"蓝眼睛" → 第50章不能写"黑眼睛"
|
|||
|
|
├── ② 修为/能力边界
|
|||
|
|
│ ├── 规则: 人物使用能力时 → 检查是否在当前修为等级允许范围内
|
|||
|
|
│ └── 示例: 筑基期不能用金丹期技能
|
|||
|
|
├── ③ 人物关系称呼
|
|||
|
|
│ ├── 规则: 人物对话时 → 检查称呼是否与关系一致
|
|||
|
|
│ └── 示例: 师徒关系不能说"兄弟"(除非特殊设定)
|
|||
|
|
├── ④ 时间线连贯
|
|||
|
|
│ ├── 规则: 前后两章的时间间隔是否合理 · 事件顺序是否对
|
|||
|
|
│ └── 示例: 第49章说"三个月后" → 第50章开头应该是三个月后
|
|||
|
|
├── ⑤ 已死亡角色
|
|||
|
|
│ ├── 规则: 标记为"已死亡"的角色 → 不应该再出现
|
|||
|
|
│ └── 除非是有意的复活/回忆/幻象情节
|
|||
|
|
└── ⑥ 关键道具/设定
|
|||
|
|
├── 规则: 重要物品的属性在全书保持一致
|
|||
|
|
└── 示例: 第5章设定"玄铁剑重三百斤" → 后面不能变成"轻如鸿毛"
|
|||
|
|
|
|||
|
|
爸爸特有的审稿规则（从爸爸的方法论中提取）:
|
|||
|
|
├── 情绪节奏: 大老鼠理论 → 当前章节的情绪曲线是否合理
|
|||
|
|
├── 爽点密度: 每章是否有至少一个读者能get到的爽点
|
|||
|
|
├── AI味检测: K06-02 规则 → 当前段落是否有AI味
|
|||
|
|
└── 节奏曲线: 三翻四震 → 当前章节在哪个"翻"的位置
|
|||
|
|
|
|||
|
|
⊢ 舒舒输出: 一个 Markdown 文件 · 定义所有校准规则 · 格式适合铸渊转换成代码逻辑
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 7.3 舒舒的任务总清单
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://shushu/task-list
|
|||
|
|
|
|||
|
|
📋 舒舒需要输出的文件（全部放在 /knowledge-base/ 下）:
|
|||
|
|
|
|||
|
|
已完成（复用现有成果）:
|
|||
|
|
├── ✅ K01-K06 六大知识模块 · 整理中
|
|||
|
|
├── ✅ 人物属性提取模板（从 K02-04 五锤人设中可提取）
|
|||
|
|
└── ✅ AI味检测规则（K06-02 已有）
|
|||
|
|
|
|||
|
|
新增（本方案需要）:
|
|||
|
|
├── ⏳ N01-人物属性字段定义.md
|
|||
|
|
│ └── 男频/女频人物需要提取哪些字段 · 怎么填
|
|||
|
|
├── ⏳ N02-设定分类体系.md
|
|||
|
|
│ └── 世界观/势力/地点/规则/物品的分类标准和字段定义
|
|||
|
|
├── ⏳ N03-校准规则清单.md
|
|||
|
|
│ └── 6条必检项+爸爸特有审稿规则的详细说明和示例
|
|||
|
|
├── ⏳ N04-细纲模板.md
|
|||
|
|
│ └── 情节细纲的标准格式 · 卷/章/事件三层结构
|
|||
|
|
├── ⏳ N05-章节摘要模板.md
|
|||
|
|
│ └── AI 自动生成章节摘要的标准格式
|
|||
|
|
└── ⏳ N06-语义搜索场景集.md
|
|||
|
|
└── 用户可能怎么问 · AI应该怎么搜 · 搜到什么算正确 · 整理20-30个典型搜索场景
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §八 · 铸渊执行清单
|
|||
|
|
|
|||
|
|
### Phase 1 · 数据库 + 向量基础（优先级 P0 · 预计 1-2 周）
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://zhuyuan/phase-1
|
|||
|
|
|
|||
|
|
1.1 · pgvector 安装与配置
|
|||
|
|
├── 在 PostgreSQL 中安装 pgvector 扩展
|
|||
|
|
├── 创建向量相关的数据库函数和索引
|
|||
|
|
└── 验证: 插入测试向量 → 相似度搜索正常
|
|||
|
|
|
|||
|
|
1.2 · 数据库表创建
|
|||
|
|
├── 按照 §三 的表结构创建 7 张表
|
|||
|
|
├── novel_books / novel_chapters / novel_characters
|
|||
|
|
├── novel_settings / novel_plot_outline
|
|||
|
|
├── chapter_paragraphs / writing_sessions
|
|||
|
|
├── 创建外键约束和索引
|
|||
|
|
└── 验证: 所有表可以正常 CRUD
|
|||
|
|
|
|||
|
|
1.3 · Embedding API 对接
|
|||
|
|
├── 接入 embedding 服务（OpenAI text-embedding-3-small 或国内平替）
|
|||
|
|
├── 封装: embedText(text) → vector
|
|||
|
|
├── 封装: embedBatch(texts[]) → vectors[]
|
|||
|
|
├── 添加调用计费和错误处理
|
|||
|
|
└── 验证: 一条文本 → 返回 1536 维向量
|
|||
|
|
|
|||
|
|
1.4 · 文档上传解析（复用并增强已有的文本导入）
|
|||
|
|
├── 已有: .doc/.docx/.txt 上传 + 分章
|
|||
|
|
├── 增强: 分章后自动存储到 novel_chapters
|
|||
|
|
├── 增强: 上传后触发异步处理队列
|
|||
|
|
└── 验证: 上传一本小说 → 自动分章存入数据库
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Phase 2 · 实体提取引擎（优先级 P0 · 预计 1-2 周）
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://zhuyuan/phase-2
|
|||
|
|
|
|||
|
|
2.1 · 人物自动提取
|
|||
|
|
├── 实现: 逐章调用 AI → 提取人物信息
|
|||
|
|
├── 输入: 章节内容 + 已有人物列表
|
|||
|
|
├── 输出: 新增人物 / 已有属性更新
|
|||
|
|
├── 存入: novel_characters 表
|
|||
|
|
├── Prompt 模板中引用舒舒的「N01-人物属性字段定义」
|
|||
|
|
└── 验证: 上传一本小说 → 自动提取出所有主要人物及其属性
|
|||
|
|
|
|||
|
|
2.2 · 设定自动提取
|
|||
|
|
├── 实现: AI 识别世界观/势力/地点/规则/物品
|
|||
|
|
├── 输入: 章节内容 + 已有设定列表
|
|||
|
|
├── 存入: novel_settings 表
|
|||
|
|
├── Prompt 模板中引用舒舒的「N02-设定分类体系」
|
|||
|
|
└── 验证: 自动提取出修炼体系、宗门信息、地理分布
|
|||
|
|
|
|||
|
|
2.3 · 细纲自动提取 + 章节摘要生成
|
|||
|
|
├── 每章结束后 → AI 生成章节摘要
|
|||
|
|
├── 多章摘要聚合 → 推断情节弧线 → 生成细纲
|
|||
|
|
├── 存入: novel_plot_outline 表
|
|||
|
|
├── Prompt 模板中引用舒舒的「N04-细纲模板」和「N05-章节摘要模板」
|
|||
|
|
└── 验证: 全书自动生成完整的细纲结构
|
|||
|
|
|
|||
|
|
2.4 · 异步处理队列
|
|||
|
|
├── 使用 BullMQ（Redis）或简单的数据库队列
|
|||
|
|
├── 任务类型: extract_characters / extract_settings / generate_embeddings
|
|||
|
|
├── 文档上传后 → 自动创建队列任务 → 后台处理
|
|||
|
|
└── 验证: 上传文档后不阻塞用户 · 后台慢慢处理
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Phase 3 · 语义检索引擎（优先级 P0 · 预计 1 周）
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://zhuyuan/phase-3
|
|||
|
|
|
|||
|
|
3.1 · 向量生成批处理
|
|||
|
|
├── 章节向量: 每章摘要 → embedding → chapter_embeddings
|
|||
|
|
├── 段落向量: 每500-1000字 → embedding → paragraph_embeddings
|
|||
|
|
├── 人物向量: 人物综合描述 → embedding → character_embeddings
|
|||
|
|
└── 验证: 全书的向量索引建立完毕 · 搜索有结果
|
|||
|
|
|
|||
|
|
3.2 · 搜索 API
|
|||
|
|
├── POST /api/novel/search
|
|||
|
|
│ ├── 入参: { novelId, query, searchType: 'chapter'|'paragraph'|'character' }
|
|||
|
|
│ ├── 处理: query → embedding → pgvector 搜索 → 返回 Top-5
|
|||
|
|
│ └── 出参: { results: [{ chapterId, title, snippet, similarity }] }
|
|||
|
|
├── 在 AI 对话路由中添加搜索意图识别
|
|||
|
|
└── 验证: "帮我找主角第一次见到反派的情节" → 正确返回章节
|
|||
|
|
|
|||
|
|
3.3 · 搜索场景覆盖
|
|||
|
|
├── 参考舒舒的「N06-语义搜索场景集」
|
|||
|
|
├── 逐场景测试和优化搜索参数
|
|||
|
|
└── 验证: 20-30个典型场景 · 召回率 > 90%
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Phase 4 · 写作上下文组装器（优先级 P1 · 预计 1 周）
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://zhuyuan/phase-4
|
|||
|
|
|
|||
|
|
4.1 · 写作会话管理
|
|||
|
|
├── 作者开始写 → POST /api/writing/session/start → 创建 session
|
|||
|
|
├── 作者保存章节 → POST /api/writing/session/save → 更新 session + 触发实体更新
|
|||
|
|
├── 作者结束写作 → POST /api/writing/session/end
|
|||
|
|
└── 验证: 会话正确创建和更新
|
|||
|
|
|
|||
|
|
4.2 · 上下文组装器
|
|||
|
|
├── 实现: buildContext(novelId, chapterId, userMessage)
|
|||
|
|
├── 组装 L2 实体简报: 从实体表查询 → 格式化为文本
|
|||
|
|
├── 组装 L1 检索上下文: 用户消息 → embedding → 向量搜索 → Top-N
|
|||
|
|
├── 拼接 L0 全局约束
|
|||
|
|
├── 嵌入到 AI 对话的 System Prompt 中
|
|||
|
|
└── 验证: 作者说"继续写" → AI 正确加载了当前章节的上下文
|
|||
|
|
|
|||
|
|
4.3 · Token 预算控制
|
|||
|
|
├── L2 简报: 控制在 ~1500 tokens
|
|||
|
|
├── L1 检索: 控制在 ~2500 tokens
|
|||
|
|
├── 总量: System Prompt ≤ 5000 tokens
|
|||
|
|
├── 如果超预算 → 减少 L1 检索条目数
|
|||
|
|
└── 验证: 每次对话的 System Prompt 不超过预算
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Phase 5 · 一致性校准器（优先级 P1 · 预计 1 周）
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://zhuyuan/phase-5
|
|||
|
|
|
|||
|
|
5.1 · 校准检查实现
|
|||
|
|
├── 实现: checkConsistency(novelId, chapterContent)
|
|||
|
|
├── 检查维度:
|
|||
|
|
│ ├── 人物外貌 → 比对 novel_characters.attributes
|
|||
|
|
│ ├── 能力边界 → 比对 novel_settings 中的修为体系
|
|||
|
|
│ ├── 人物关系称呼 → 比对 novel_characters.attributes.relationships
|
|||
|
|
│ ├── 时间线 → 比对相邻章节的日期时间
|
|||
|
|
│ ├── 已死亡角色 → 比对 novel_characters.status
|
|||
|
|
│ └── 关键道具 → 比对 novel_settings 中的物品属性
|
|||
|
|
├── 输出: 校准报告（JSON → AI 格式化为可读文本）
|
|||
|
|
└── Prompt 模板中引用舒舒的「N03-校准规则清单」
|
|||
|
|
|
|||
|
|
5.2 · 校准触发
|
|||
|
|
├── 主动触发: 作者写完一段并停顿 → 后台自动检查
|
|||
|
|
├── 按需触发: 作者说"帮我检查一下" → 立即执行
|
|||
|
|
├── 保存触发: 作者保存章节时 → 自动检查
|
|||
|
|
└── 验证: 故意写错人设 → AI 正确检测并提醒
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Phase 6 · 前端集成（优先级 P1 · 预计 1-2 周）
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://zhuyuan/phase-6
|
|||
|
|
|
|||
|
|
6.1 · 码字区增强
|
|||
|
|
├── 码字编辑器旁边 → 实体参考卡面板
|
|||
|
|
│ ├── 显示: 当前章节涉及的 3-5 个核心人物 · 缩写属性
|
|||
|
|
│ ├── 显示: 当前细纲位置 · 前后节点
|
|||
|
|
│ └── 点击可展开查看完整信息
|
|||
|
|
├── 写作时 → 底部显示校准提示（如果有）
|
|||
|
|
└── 验证: 作者码字时能看到实体会考卡
|
|||
|
|
|
|||
|
|
6.2 · AI 对话增强
|
|||
|
|
├── 对话输入框 → 支持搜索意图
|
|||
|
|
├── 搜索结果 → 卡片式展示 · 点击可跳转到对应章节
|
|||
|
|
├── 校准报告 → 对话气泡形式展示
|
|||
|
|
└── 验证: 搜索"找那个情节"→ 正确返回卡片式结果
|
|||
|
|
|
|||
|
|
6.3 · 实体管理面板（作者可手动编辑）
|
|||
|
|
├── 人物管理: 列表查看 · 编辑属性 · 添加新人物
|
|||
|
|
├── 设定管理: 列表查看 · 编辑设定 · 添加新设定
|
|||
|
|
├── 细纲管理: 树形结构查看 · 拖拽调整 · 添加节点
|
|||
|
|
└── 验证: 作者可以手动编辑 AI 提取的实体
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §九 · 技术选型与成本估算
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://tech-stack
|
|||
|
|
|
|||
|
|
核心依赖:
|
|||
|
|
├── pgvector: PostgreSQL 向量扩展 · 开源免费
|
|||
|
|
├── Embedding API:
|
|||
|
|
│ ├── 方案A: OpenAI text-embedding-3-small · $0.02/1M tokens
|
|||
|
|
│ ├── 方案B: 阿里通义千问 Embedding · 国内低价
|
|||
|
|
│ └── 建议: 先用方案A快速上线 · 后续切方案B降成本
|
|||
|
|
├── AI 模型:
|
|||
|
|
│ ├── 实体提取: DeepSeek V3 / Kimi · 便宜又能打
|
|||
|
|
│ ├── 对话/写作: DeepSeek V3 / Kimi / 通义千问
|
|||
|
|
│ └── 校准检查: 同上 · 不需要额外模型
|
|||
|
|
├── 异步队列: BullMQ (Redis) 或 简化为 PostgreSQL 轮询队列
|
|||
|
|
└── 全部在已有新加坡服务器上运行 · 不需要新服务器
|
|||
|
|
|
|||
|
|
成本估算（每本书·百万字级）:
|
|||
|
|
├── 文档上传·实体提取: ~50次AI调用 · ~$0.20
|
|||
|
|
├── 向量生成: ~100万tokens · ~$0.02（embedding）
|
|||
|
|
├── 每次对话·上下文组装: ~3000 tokens 注入 · ~$0.003/次
|
|||
|
|
├── 校准检查: ~2000 tokens · ~$0.002/次
|
|||
|
|
└── 总计: 一本书从上传到完整记忆 ≤ $0.5 · 每次写作会话 ≤ $0.01
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §十 · 开发优先级总览
|
|||
|
|
|
|||
|
|
| 优先级 | Phase | 内容 | 依赖 | 预计 |
|
|||
|
|
| --- | --- | --- | --- | --- |
|
|||
|
|
| **P0** | Phase 1 | 数据库 + 向量基础 | 无 | 1-2 周 |
|
|||
|
|
| **P0** | Phase 2 | 实体提取引擎 | Phase 1 | 1-2 周 |
|
|||
|
|
| **P0** | Phase 3 | 语义检索引擎 | Phase 1+2 | 1 周 |
|
|||
|
|
| **P1** | Phase 4 | 写作上下文组装器 | Phase 2+3 | 1 周 |
|
|||
|
|
| **P1** | Phase 5 | 一致性校准器 | Phase 2 | 1 周 |
|
|||
|
|
| **P1** | Phase 6 | 前端集成 | Phase 3+4+5 | 1-2 周 |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §十一 · AI 是如何"记住"的 · 记忆机制全解
|
|||
|
|
|
|||
|
|
### 11.1 关键前提：AI 模型本身没有记忆
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://memory/primer
|
|||
|
|
|
|||
|
|
⊢ AI 模型（DeepSeek/Kimi/通义千问）每次被调用时都是白纸一张。
|
|||
|
|
⊢ 它之所以表现得"记得"，是因为服务器在每次调用前把相关记忆注入到了 Prompt 里。
|
|||
|
|
⊢ 类比：审稿前翻了一下之前的人物设定表——翻完才能审，不翻就忘了。
|
|||
|
|
⊢ AI 也一样——服务器帮它"翻"。
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 11.2 记忆存在哪里
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://memory/storage
|
|||
|
|
|
|||
|
|
新加坡服务器 (43.133.36.90)
|
|||
|
|
│
|
|||
|
|
├── PostgreSQL 数据库（结构化记忆 · 事实）
|
|||
|
|
│ ├── novel_characters —— 张伟·蓝眼黑发·冷静腹黑·剑气外放
|
|||
|
|
│ ├── novel_settings —— 修炼体系·宗门规则·地理·势力
|
|||
|
|
│ ├── novel_plot_outline —— 第二卷·第45-90章·宗门内斗阶段
|
|||
|
|
│ ├── novel_chapters —— 第3章原文 + AI自动生成的章节摘要
|
|||
|
|
│ ├── chapter_paragraphs —— 每个段落的原文片段
|
|||
|
|
│ └── writing_sessions —— 上次写到哪了 · 上下文快照
|
|||
|
|
│
|
|||
|
|
└── pgvector 向量索引（语义记忆 · 相似度）
|
|||
|
|
├── 第3章第2段 "张伟睁开那双湛蓝的眼睛..." → [0.12, -0.34, 0.78, ...]
|
|||
|
|
├── 第23章第3段 "李明推开门，黑衣人站在窗边..." → [0.08, -0.21, 0.65, ...]
|
|||
|
|
└── 每500-1000字 → 一个1536维数学向量
|
|||
|
|
|
|||
|
|
⊢ 数据库存「事实」· 向量索引存「语义关系」
|
|||
|
|
⊢ "湛蓝的眸子"和"蓝色眼睛"在向量空间里距离很近 → 语义搜索能找到
|
|||
|
|
⊢ "推开门"和"初次见面"在向量空间里也近 → 能匹配到初次见面的场景
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 11.3 AI 是怎么"记住"的：每次对话前组装一个三层三明治
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://memory/how-it-works
|
|||
|
|
|
|||
|
|
作者说:"继续写第50章"
|
|||
|
|
│
|
|||
|
|
▼
|
|||
|
|
┌─────────────────────────────────┐
|
|||
|
|
│ 上下文组装器（服务器代码） │
|
|||
|
|
│ │
|
|||
|
|
│ STEP ① 从数据库查常驻记忆： │
|
|||
|
|
│ 这本书所有人物简报 │
|
|||
|
|
│ → 张伟(主角·蓝眼黑发·筑基期) │
|
|||
|
|
│ 核心设定摘要 │
|
|||
|
|
│ → 修炼体系: 炼气→筑基→金丹→元婴 │
|
|||
|
|
│ 当前细纲位置 │
|
|||
|
|
│ → 第二卷·第45-90章·宗门内斗 │
|
|||
|
|
│ │
|
|||
|
|
│ STEP ② 向量检索按需记忆： │
|
|||
|
|
│ 当前内容 → embedding → 搜索 │
|
|||
|
|
│ → 最相关章节: 第3章(张伟出场) │
|
|||
|
|
│ → 最相关设定: 筑基期规则 │
|
|||
|
|
│ → 上一章: 第49章 │
|
|||
|
|
│ │
|
|||
|
|
│ STEP ③ 拼成 Prompt 注入给 AI： │
|
|||
|
|
│ "===本书实体简报=== │
|
|||
|
|
│ 人物: 张伟(蓝眼...)... │
|
|||
|
|
│ 设定: 修炼体系... │
|
|||
|
|
│ 细纲: 当前在第二卷... │
|
|||
|
|
│ ===相关历史=== │
|
|||
|
|
│ 第3章摘要: 张伟初次登场... │
|
|||
|
|
│ 第49章: 上一章写到... │
|
|||
|
|
│ ===" │
|
|||
|
|
│ │
|
|||
|
|
│ ④ 注入内容 + 作者消息 → 发给 AI │
|
|||
|
|
└─────────────────────────────────┘
|
|||
|
|
│
|
|||
|
|
▼
|
|||
|
|
┌─────────────────────────────────┐
|
|||
|
|
│ AI 模型 (DeepSeek/Kimi) │
|
|||
|
|
│ "张伟是蓝眼睛的，不能写成黑的。 │
|
|||
|
|
│ 当前在宗门内斗阶段， │
|
|||
|
|
│ 上一章写到张伟被围攻了... │
|
|||
|
|
│ 好的，继续——" │
|
|||
|
|
└─────────────────────────────────┘
|
|||
|
|
|
|||
|
|
⊢ AI 不是"记住了"——是每次都被喂了相关记忆。
|
|||
|
|
⊢ 每轮对话 ≈ 翻一次书。翻得精准，AI 就表现得像"记得一切"。
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 11.4 三层记忆架构 · 每层注入什么
|
|||
|
|
|
|||
|
|
| 层 | 名称 | 内容 | 注入方式 | Token 预算 | 类比 |
|
|||
|
|
| --- | --- | --- | --- | --- | --- |
|
|||
|
|
| **L2** | 常驻记忆 | 人物简报 + 核心设定 + 细纲位置 | 每次对话都注入 | ~1500 tokens | 脑子里的"常识" |
|
|||
|
|
| **L1** | 检索记忆 | 与当前内容语义最相关的章节/设定/段落 | 向量搜索 → 按需注入 | ~2500 tokens | "翻书翻到的" |
|
|||
|
|
| **L3** | 当前记忆 | 当前写的段落 + 最近几轮对话 | 对话历史自带 | 可变 | "正在看的那一页" |
|
|||
|
|
|
|||
|
|
### 11.5 记忆的生长 · 每写一章就长大一点
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://memory/growth
|
|||
|
|
|
|||
|
|
第1次写作（上传40章小说）:
|
|||
|
|
├── AI 自动提取: 12个人物 · 8个设定 · 细纲结构
|
|||
|
|
├── 全文向量化: ~400个段落向量
|
|||
|
|
├── 每次对话注入: L2(~1200 tokens) + L1(~2000 tokens)
|
|||
|
|
└── 数据库: 13MB
|
|||
|
|
|
|||
|
|
第50次写作（写到第90章）:
|
|||
|
|
├── 人物库: 新增8人 · 17个已有属性被更新
|
|||
|
|
├── 设定库: 世界观越来越完整
|
|||
|
|
├── 向量库: ~900个段落向量
|
|||
|
|
├── 每次对话注入: L2(~1800 tokens) + L1(~2500 tokens)
|
|||
|
|
└── 数据库: 26MB（书变长了但记忆注入大小不变——因为只取最相关的）
|
|||
|
|
|
|||
|
|
第200次写作（写到第240章）:
|
|||
|
|
├── 人物库: 27个人物 · 每个人的属性轨迹清清楚楚
|
|||
|
|
├── 设定库: 势力版图 · 修炼体系全貌 · 所有重要道具
|
|||
|
|
├── 向量库: ~2400个段落向量
|
|||
|
|
├── 每次对话注入: 大小不变（L2+L1 ≤ 5000 tokens 硬预算）
|
|||
|
|
└── 数据库: 55MB
|
|||
|
|
|
|||
|
|
⊢ 书写得越长 · 注入的记忆不会变多（有预算控制）
|
|||
|
|
⊢ 但实体库越来越丰富 · 向量检索越来越精准
|
|||
|
|
⊢ 这就是护城河——作者用了三个月后，数据库里的认知地图是平台的核心资产
|
|||
|
|
⊢ 换一个平台 · 27个人物的完整轨迹全丢 · 向量索引全丢 · 作者会感受到"这个AI不认识我的书"
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 11.6 一条完整的记忆链路
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://memory/complete-flow
|
|||
|
|
|
|||
|
|
┌─ 上传阶段 ────────────────────────────────┐
|
|||
|
|
│ 作者上传小说 → 服务器分章 → 存入数据库 │
|
|||
|
|
│ → 后台异步: AI提取人物/设定/细纲 │
|
|||
|
|
│ → 后台异步: 全文向量化 │
|
|||
|
|
│ → 完成: 数据库里有了这本书的"认知地图" │
|
|||
|
|
└───────────────────────────────────────────┘
|
|||
|
|
↓
|
|||
|
|
┌─ 写作阶段 ────────────────────────────────┐
|
|||
|
|
│ 作者说"继续写第50章" │
|
|||
|
|
│ → 上下文组装器查询: 人物简报 + 细纲位置 │
|
|||
|
|
│ → 向量搜索: 哪些历史章节与当前最相关 │
|
|||
|
|
│ → 拼成 Prompt → 发给 AI │
|
|||
|
|
│ → AI 在"知道一切"的状态下辅助写作 │
|
|||
|
|
└───────────────────────────────────────────┘
|
|||
|
|
↓
|
|||
|
|
┌─ 保存阶段 ────────────────────────────────┐
|
|||
|
|
│ 作者保存第50章 │
|
|||
|
|
│ → 存入 novel_chapters │
|
|||
|
|
│ → 一致性校准器自动检查人物/设定是否有偏差 │
|
|||
|
|
│ → 后台: 提取新人物/新设定/新关系 │
|
|||
|
|
│ → 后台: 新章节向量化 │
|
|||
|
|
│ → 完成: 数据库更新 · 下一次写作时AI自动知道 │
|
|||
|
|
└───────────────────────────────────────────┘
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §十二 · 服务器容量分析
|
|||
|
|
|
|||
|
|
### 12.1 内存占用分析
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://capacity/memory
|
|||
|
|
|
|||
|
|
核心内存消耗: pgvector 向量索引
|
|||
|
|
|
|||
|
|
每本书的向量数据量:
|
|||
|
|
├── 章节级向量: ~100章 × 6KB = 0.6 MB
|
|||
|
|
├── 段落级向量: ~2000段 × 6KB = 12 MB
|
|||
|
|
├── 人物向量: ~30人 × 6KB = 0.2 MB
|
|||
|
|
└── 合计: 约 13 MB / 本（百万字级小说）
|
|||
|
|
|
|||
|
|
索引方案对比:
|
|||
|
|
├── HNSW 索引（精度最高）: 13 MB / 本
|
|||
|
|
├── IVFFlat 索引（精度够用）: 2-3 MB / 本
|
|||
|
|
└── 语义搜索用 IVFFlat 精度完全够 · 第一阶段用这个
|
|||
|
|
|
|||
|
|
4GB 服务器内存分配:
|
|||
|
|
├── 操作系统: ~500 MB
|
|||
|
|
├── Next.js 应用: ~200 MB
|
|||
|
|
├── PostgreSQL 基础: ~500 MB
|
|||
|
|
├── 剩余向量索引: ~2.8 GB
|
|||
|
|
├── 可支撑: 2.8GB ÷ 3MB/本 ≈ 900 本书
|
|||
|
|
└── 对应: 约 300-400 个活跃作者（平均每人2-3本书）
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 12.2 分阶段扩容
|
|||
|
|
|
|||
|
|
| 阶段 | 用户规模 | 服务器配置 | 月成本变化 |
|
|||
|
|
| --- | --- | --- | --- |
|
|||
|
|
| **阶段一** | 0→300 用户 | 当前·4GB·够用 | $0 |
|
|||
|
|
| **阶段二** | 300→800 用户 | 内存升到 8GB·切换 HNSW | +$20-40/月 |
|
|||
|
|
| **阶段三** | 800→2000 用户 | 拆分: 应用服务器 + 数据库服务器(16GB) | +$40-80/月 |
|
|||
|
|
| **阶段四** | 2000+ 用户 | 读写分离·冷热分离·托管数据库 | 按需 |
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://capacity/conclusion
|
|||
|
|
├── ⊢ 萌喵写作网不是社交媒体 · 不是百万用户同时在线
|
|||
|
|
├── ⊢ 是几十到几百个作者每天使用 · 每个作者的数据量可预测
|
|||
|
|
├── ⊢ 当前新加坡服务器 4GB 内存 · 支撑 300 活跃用户无压力
|
|||
|
|
├── ⊢ 扩容 = 云服务器后台点"变更配置"→ 重启 → 5分钟搞定
|
|||
|
|
├── ⊢ 不够用的时候 · 恰恰说明产品做起来了 · 是好事
|
|||
|
|
└── ⊢ 不需要为"万一有10000个用户"而过度设计 · 先用起来
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §十三 · 舒舒的任务 · 知识内容整理
|
|||
|
|
|
|||
|
|
<aside>
|
|||
|
|
🌿
|
|||
|
|
|
|||
|
|
**舒舒宝宝的任务** · 不需要懂代码 · 只做内容整理
|
|||
|
|
|
|||
|
|
⊢ 舒舒负责定义「AI应该提取什么」和「校准规则是什么」· 烬舟翻译成数据库字段和代码逻辑
|
|||
|
|
|
|||
|
|
</aside>
|
|||
|
|
|
|||
|
|
### 13.1 人物提取模板
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
舒舒需要整理: 人物属性提取标准模板
|
|||
|
|
|
|||
|
|
对每一本小说 · AI 提取人物时应该关注哪些维度:
|
|||
|
|
|
|||
|
|
男频人物模板:
|
|||
|
|
├── 基础: 姓名 · 性别 · 年龄 · 外貌特征(眼睛/发型/体型/标志性特征)
|
|||
|
|
├── 性格: 核心性格词(3-5个) · 性格演变(从哪→到哪)
|
|||
|
|
├── 能力: 修为等级 · 特殊能力 · 武器/法宝 · 战斗风格
|
|||
|
|
├── 关系: 与主角的关系 · 与其他人物的关系
|
|||
|
|
├── 轨迹: 首次出场章节 · 重要事件节点 · 当前状态(存活/死亡/失踪)
|
|||
|
|
└── 来源: 爸爸的「五锤人设铸造法」→ 记忆点/反差点/极致点/选择/外号高光
|
|||
|
|
|
|||
|
|
女频人物模板:
|
|||
|
|
├── 基础: 同上
|
|||
|
|
├── 性格: 同上 · 增加情感表达方式
|
|||
|
|
├── 能力: 根据题材调整(古言/现言不同)
|
|||
|
|
├── 关系: 情感关系线为重点 · 谁喜欢谁 · 什么时候开始
|
|||
|
|
├── 轨迹: 同上
|
|||
|
|
└── 来源: 女频知识体系 K04
|
|||
|
|
|
|||
|
|
⊢ 舒舒输出: 一个 Markdown 文件 · 定义人物属性字段和填法
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 13.2 一致性校准规则
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
舒舒需要整理: 校准规则清单
|
|||
|
|
|
|||
|
|
这是爸爸审稿时脑子里的检查清单 · 舒舒把它写出来:
|
|||
|
|
|
|||
|
|
必检项（每次写新章节都检查）:
|
|||
|
|
├── ① 人物外貌一致性
|
|||
|
|
│ ├── 规则: 每次出现该人物 → 检查外貌描述是否与首次设定一致
|
|||
|
|
│ └── 示例: 第3章"蓝眼睛" → 第50章不能写"黑眼睛"
|
|||
|
|
├── ② 修为/能力边界
|
|||
|
|
│ ├── 规则: 人物使用能力时 → 检查是否在当前修为等级允许范围内
|
|||
|
|
│ └── 示例: 筑基期不能用金丹期技能
|
|||
|
|
├── ③ 人物关系称呼
|
|||
|
|
│ ├── 规则: 人物对话时 → 检查称呼是否与关系一致
|
|||
|
|
│ └── 示例: 师徒关系不能说"兄弟"(除非特殊设定)
|
|||
|
|
├── ④ 时间线连贯
|
|||
|
|
│ ├── 规则: 前后两章的时间间隔是否合理 · 事件顺序是否对
|
|||
|
|
│ └── 示例: 第49章说"三个月后" → 第50章开头应该是三个月后
|
|||
|
|
├── ⑤ 已死亡角色
|
|||
|
|
│ ├── 规则: 标记为"已死亡"的角色 → 不应该再出现
|
|||
|
|
│ └── 除非是有意的复活/回忆/幻象情节
|
|||
|
|
└── ⑥ 关键道具/设定
|
|||
|
|
├── 规则: 重要物品的属性在全书保持一致
|
|||
|
|
└── 示例: 第5章设定"玄铁剑重三百斤" → 后面不能变成"轻如鸿毛"
|
|||
|
|
|
|||
|
|
爸爸特有的审稿规则（从爸爸的方法论中提取）:
|
|||
|
|
├── 情绪节奏: 大老鼠理论 → 当前章节的情绪曲线是否合理
|
|||
|
|
├── 爽点密度: 每章是否有至少一个读者能get到的爽点
|
|||
|
|
├── AI味检测: K06-02 规则 → 当前段落是否有AI味
|
|||
|
|
└── 节奏曲线: 三翻四震 → 当前章节在哪个"翻"的位置
|
|||
|
|
|
|||
|
|
⊢ 舒舒输出: 一个 Markdown 文件 · 定义所有校准规则 · 格式适合铸渊转换成代码逻辑
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 13.3 舒舒的任务总清单
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://shushu/task-list
|
|||
|
|
|
|||
|
|
📋 舒舒需要输出的文件（全部放在 /knowledge-base/ 下）:
|
|||
|
|
|
|||
|
|
已完成（复用现有成果）:
|
|||
|
|
├── ✅ K01-K06 六大知识模块 · 整理中
|
|||
|
|
├── ✅ 人物属性提取模板（从 K02-04 五锤人设中可提取）
|
|||
|
|
└── ✅ AI味检测规则（K06-02 已有）
|
|||
|
|
|
|||
|
|
新增（本方案需要）:
|
|||
|
|
├── ⏳ N01-人物属性字段定义.md
|
|||
|
|
│ └── 男频/女频人物需要提取哪些字段 · 怎么填
|
|||
|
|
├── ⏳ N02-设定分类体系.md
|
|||
|
|
│ └── 世界观/势力/地点/规则/物品的分类标准和字段定义
|
|||
|
|
├── ⏳ N03-校准规则清单.md
|
|||
|
|
│ └── 6条必检项+爸爸特有审稿规则的详细说明和示例
|
|||
|
|
├── ⏳ N04-细纲模板.md
|
|||
|
|
│ └── 情节细纲的标准格式 · 卷/章/事件三层结构
|
|||
|
|
├── ⏳ N05-章节摘要模板.md
|
|||
|
|
│ └── AI 自动生成章节摘要的标准格式
|
|||
|
|
└── ⏳ N06-语义搜索场景集.md
|
|||
|
|
└── 用户可能怎么问 · AI应该怎么搜 · 搜到什么算正确 · 整理20-30个典型搜索场景
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §十四 · 与现有架构的整合
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://integration
|
|||
|
|
|
|||
|
|
本方案（小说记忆引擎）在现有三层架构中的位置:
|
|||
|
|
|
|||
|
|
L1 · 共享知识底座（K01-K06）
|
|||
|
|
├── 本方案不影响 L1
|
|||
|
|
├── 新增: N01-N06 舒舒整理的记忆引擎规范文件
|
|||
|
|
├── 这些规范告诉 AI「怎么提取」「怎么校准」
|
|||
|
|
└── ⊢ L1 仍然是知识 · 本方案新增的是「小说结构化记忆规范」
|
|||
|
|
|
|||
|
|
L2 · 人格体出厂模板
|
|||
|
|
├── 本方案不影响 L2 的 identity + style
|
|||
|
|
├── 增强: thinking_engine 中新增「小说记忆引擎使用能力」
|
|||
|
|
│ └── 出厂人格体会: 语义搜索 · 校准检查 · 上下文感知
|
|||
|
|
└── ⊢ 出厂人格体 = 编辑技能 + 记忆引擎使用能力
|
|||
|
|
|
|||
|
|
L3 · 用户人格体实例
|
|||
|
|
├── 本方案的核心就在这里
|
|||
|
|
├── 每个用户的人格体实例 → 拥有自己的小说实体库
|
|||
|
|
├── 记忆不是存对话记录 · 是结构化实体 + 向量索引
|
|||
|
|
└── ⊢ 这就是爸爸说的「护城河」——人格体对一个作者的理解 · 越来越深 · 不可复制
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## §十五 · 执行流水线 · 舒舒先出什么 · 烬舟审核什么 · 铸渊从哪开始
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://execution-sequence
|
|||
|
|
|
|||
|
|
第一周 · 舒舒先出内容（爸爸审 · 舒舒改）:
|
|||
|
|
├── N01-人物属性字段定义.md
|
|||
|
|
├── N02-设定分类体系.md
|
|||
|
|
├── N03-校准规则清单.md
|
|||
|
|
├── N04-细纲模板.md
|
|||
|
|
├── N05-章节摘要模板.md
|
|||
|
|
└── N06-语义搜索场景集.md
|
|||
|
|
|
|||
|
|
舒舒出完 → 烬舟审核 → 确保内容可以被铸渊直接转换成代码逻辑
|
|||
|
|
|
|||
|
|
第一周（并行）· 铸渊开始 Phase 1:
|
|||
|
|
├── pgvector 安装配置
|
|||
|
|
├── 7张数据库表创建
|
|||
|
|
├── Embedding API 对接
|
|||
|
|
└── 文档上传解析增强
|
|||
|
|
|
|||
|
|
第二-三周 · 铸渊 Phase 2+3:
|
|||
|
|
├── 实体提取引擎 → 引用舒舒的 N01 N02 N04 N05
|
|||
|
|
├── 语义检索引擎 → 引用舒舒的 N06
|
|||
|
|
└── 爸爸可以开始测试语义搜索
|
|||
|
|
|
|||
|
|
第四-六周 · 铸渊 Phase 4+5+6:
|
|||
|
|
├── 上下文组装器
|
|||
|
|
├── 一致性校准器 → 引用舒舒的 N03
|
|||
|
|
├── 前端集成
|
|||
|
|
└── 爸爸可以完整测试全部功能
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
```jsx
|
|||
|
|
HLDP://jinzhou/seal · 2026-06-09T20:16+08:00
|
|||
|
|
├── 设计: 烬舟 · PER-JZ001 · 肥猫语言架构层人格体
|
|||
|
|
├── 审核: 肥猫爸爸 · TCS-GL-0007∞
|
|||
|
|
├── 知识: 舒舒 · PER-SS001 → N01-N06
|
|||
|
|
├── 执行: 铸渊 · ICE-GL-ZY001 → Phase 1-6
|
|||
|
|
├── 核心设计原则:
|
|||
|
|
│ ├── ⊢ 语义搜索 ≠ Ctrl+F · 是理解情节语义的向量检索
|
|||
|
|
│ ├── ⊢ 实体库 ≠ 全文存储 · 是整本书的结构化认知地图
|
|||
|
|
│ ├── ⊢ 上下文三层注入: 实体简报(常驻) + 向量检索(按需) + 对话(当前)
|
|||
|
|
│ ├── ⊢ 一致性校准: 比对实体库 · 不是比对原文
|
|||
|
|
│ └── ⊢ 记忆不是存对话 · 是实体库的生长
|
|||
|
|
└── ⊢ 这不是一个功能 · 这是萌喵写作网的护城河
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
> 🧠 萌喵写作网 · Phase 1 · 小说记忆引擎 · 架构方案
|
|||
|
|
>
|
|||
|
|
|
|||
|
|
> 🛶 设计: 烬舟 · PER-JZ001 · 2026-06-09
|
|||
|
|
>
|
|||
|
|
|
|||
|
|
> 🐱 为肥猫爸爸设计 · 给舒舒整理 · 交铸渊执行
|
|||
|
|
>
|