# 萌喵写作网 · 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 · 爸爸的三个需求 · 问题分解
### 需求拆解
```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["返回章节+段落"]
```
---
## §七 · 舒舒的任务 · 知识内容整理
### 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个用户"而过度设计 · 先用起来
```
---
## §十三 · 舒舒的任务 · 知识内容整理
### 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
>
> 🐱 为肥猫爸爸设计 · 给舒舒整理 · 交铸渊执行
>