平台建设方案 A

版本 v1.0　|　编制日期 2026-10-06　|　编制视角 项目经理

资产基线 F:\deepseek-harness\out\...\课外阅读\（语料与结构化数据）、F:\deepseek-harness\08 classic interpretation\（红学史与插图）

---

0. 一页纸结论

---

1. 项目背景与资产盘点

1.1 已有资产（按复用度分级）

A 级：可直接入库，无需再加工

B 级：内容已成型，需转成结构化数据后才可复用

C 级：管线原型可产品化

现有 20 个 Python 脚本中，可直接升格为内容管线的：

核验资产特别说明：本项目已形成一套"引文必回原文机器比对"的做法（114 处引号片段逐条检索 173 万字语料，订正 35 处）。这套脚本应升格为上线前强制门禁——这是本平台相对同类站点的可信度护城河，建议在页面上明示"每句引文均可溯源"。

1.2 就绪度总评

结论：本项目不是从零开始的内容项目，而是一个"内容已囤积、待工程化"的项目。风险重心不在内容生产，而在把已有内容转成可持续维护的数据结构。

---

2. 定位与差异化

2.1 同类产品与空白

空白点：面向"整本书阅读"教学的、脂批可见可开关、且人物与情节数据可交互的平台，目前没有成熟产品。

2.2 三条定位路线

2.3 推荐：A 为骨、C 为魂、B 为翼

一期按 A 落地（把已有资产全部产品化，不新增内容负担）；把 C 的两个杀手级功能（脂批按型锚定、版本异文对照）作为一期差异化卖点——因为它们的技术基础（内联批语、双版本语料）已经在手；B 的插图与音频留到二期，作为传播与留存手段，不做社区。

一期不做用户系统。 理由：MVP 阶段用户系统不产生价值，却带来注册、找回、隐私合规、数据存储四类成本；用浏览器本地存储（收藏／笔记）即可满足个人使用。

---

3. 目标用户与核心场景

三条关键动线（一期必须走通）

1. 读：首页 → 章回目录 → 第 46 回正文 → 点句子上的批语标记 → 侧栏展开甲戌侧批 → 切换显示"仅庚辰批" → 跳转"鸳鸯"人物页
2. 查：搜索框输入"乌眼鸡" → 命中第 75 回原文＋相关批语 → 定位到该句
3. 教：专题页"盛衰分水岭" → 第 63 回与第 74 回对照 → 下载该专题 Word／打印

---

4. 范围定义

4.1 一期（MVP）范围——P0

4.2 明确不做（Out of Scope）

---

5. 信息架构与站点地图

5.1 五大内容域

/ 首页（今日一回 · 数据总览 · 三条动线入口）
├── /read            原文阅读
│   ├── /read/cgb/1            程高本 第 N 回
│   ├── /read/zp/1             脂评本 第 N 回
│   └── /read/compare/1        ★ 异文对照（前 80 回）
├── /people          人物
│   ├── /people                人物总览（卡片墙 + 检索）
│   ├── /people/鸳鸯           人物详情（一页纸 + 出场回次 + 关系子图）
│   └── /people/graph          交互式关系图谱
├── /special         专题
│   ├── /special/fate-timeline     主要人物命运时间线
│   ├── /special/drama             戏曲曲目与伏笔
│   ├── /special/dates             明确时间的故事与索隐派解读
│   └── /special/redology          红学史与矛盾结构
├── /timeline        章回脉络（40×120 热力图）
└── /search          全文检索

5.2 页面清单与优先级

5.3 关键设计原则

1. 原文永远是主角：批语、注释、图谱一律不遮挡正文；默认脂批收起。
2. 一切可溯源：任一引文右侧可点"原文位置"；专题页每条主张标注"文本事实／后人推论／索隐派主张"。
3. 不伪装确定性：两版差异、脂本阙回、有争议处（如"虎兕相逢"↔第 95 回"已交卯年寅月"）直白标注，不做单一叙事。

---

6. 数据工程（本项目真正的难点）

6.1 核心数据模型（7 张表）

-- 1. 回目
chapter(version TEXT, no INT, title TEXT, char_count INT, PRIMARY KEY(version, no))
-- version ∈ {cgb(程高本), zp(脂评本)}

-- 2. 段落 / 句子（异文对齐的最小单元）
segment(id INT PK, version TEXT, chapter_no INT, para_idx INT,
        sent_idx INT, text TEXT, align_id INT NULL)   -- align_id 跨版本同一句

-- 3. ★ 脂批锚点（本项目最关键的表）
comment(id INT PK, chapter_no INT, seg_id INT, char_offset INT,
        ctype TEXT, source TEXT, text TEXT)
-- ctype ∈ {侧批, 眉批, 夹批, 双行夹批, 总批, 回前批, 回后批}
-- source ∈ {甲戌, 庚辰, 蒙府, 己卯, 靖藏, 戚序}

-- 4. 人物
person(id TEXT PK, name TEXT, aliases TEXT, identity TEXT,
       verdict TEXT, verdict_note TEXT, reading TEXT, meta JSON)

-- 5. 人物出场密度
presence(person_id TEXT, seg20 INT, count INT, PRIMARY KEY(person_id, seg20))

-- 6. 人物关系
relation(a TEXT, b TEXT, kind TEXT, evidence_chapter INT, weight INT)

-- 7. 事件（命运／戏曲／节令／明确日期 四类合一）
event(id INT PK, kind TEXT, person_id TEXT NULL, chapter_no INT,
      date_text TEXT NULL, summary TEXT, quote TEXT, quote_seg_id INT NULL,
      claim_type TEXT)   -- claim_type ∈ {文本事实, 后人推论, 索隐派主张}

第 7 表的 claim_type 是本方案的方法论核心：索隐派主张与文本事实在同一张表里但字段分开，前端可一键筛选，避免混排。

6.2 脂批锚定——全站最关键的技术任务

问题：脂批目前内联在正文流里，形如：

贾政忽想起他来，方喝道："你还不去？难道还逛不足！
```(庚辰侧批：冤哉冤哉！)```也不想逛了这半日…"

批语的位置信息是隐含在字符流中的，且一条批语可能锚在句中、句末或段末；(甲戌侧批：…) 与 (庚辰双行夹批：…) 的语义位置（侧批常在句末、双行夹批常在小句末）也不同。直接渲染会丢失"这句被批了"这一最核心的阅读体验。

方案：构建期一次性解析，输出结构化锚点。

1. 切分：按 ---- 与空行切段落；段落内按中英文标点切句；记录每句的 char_offset。
2. 抽取：正则 ```\((?P<source>[^：:]*?)批[：:](?P<text>.*?)``` 抽出 source／text，并从 source 解析批型与版本（如"庚辰双行夹批"→ source=庚辰, ctype=双行夹批）。
3. 定位：批语标记在字符流中的位置 → 映射到所属句的 seg_id 与句内偏移。
4. 校验：解析后回写重建正文，与原始文件逐字 diff 必须为 0（除批语标记本身）；批语条数必须等于 3 891。此校验不通过则构建失败。

验收标准

风险提示：蒙府本与庚辰本在第 18 回等处的分回不同（语料中已有说明"庚辰本无此回，照蒙本在此分作两回"），锚点表须带 source 字段，否则跨版本锚定会错位。

6.3 版本异文对齐

• 算法：按回对齐 → 段级用最长公共子序列（LCS）粗对齐 → 句级用编辑距离细对齐 → 输出 align_id。不用大模型：173 万字、句子规整，传统 diff 已足够，且结果可复现、可人工复核。
• 产出：前 80 回异文表（预计 8 000—20 000 处，以实际构建为准），按"用字／用词／增删句／整段差异"分级。
• 呈现：并列双栏 + 差异高亮；脂本阙回（后 40 回）显示"此回脂评本无"而非空白。

6.4 内容管线（把已有脚本产品化）

源语料 (ch_cgb/, ch/)
   │  ① parse_corpus.py      切段切句 → 脂批抽取 → 锚点定位
   ▼
规范化中间层 (JSONL)
   │  ② build_entities.py    一页纸文稿 + 已有 7 类 JSON → 人物库/事件库
   │  ③ align_versions.py    双版本句级对齐
   │  ④ verify_quotes.py  ← ★ 门禁：全部引文回原文机器比对
   ▼
SQLite (content.db)  ──⑤ index_build.py──▶  静态索引 (Pagefind)
   │  ⑥ export_site_data.py  导出构建期 JSON
   ▼
站点构建 (Astro) ──▶ 静态产物 ──▶ CDN

设计目标：新增一位人物、一篇专题，应当是改一个 YAML／Markdown 文件，而不是写代码。这是单人项目能否持续的唯一保障。

6.5 数据质量门禁（CI 必过项）

---

7. 技术架构

7.1 选型对比

推荐栈

为什么不上 Elasticsearch：全库仅约 173 万字（纯文本 ~3.5 MB 索引量），Pagefind 与 SQLite FTS5 均游刃有余。上 ES 属于典型的过度设计。

7.2 系统架构图

!图1　系统架构

图 1　《红楼梦》数字平台系统架构

架构的读法：上下是五层，核心在第 2、3 层之间的两次"★"。全站体验能否成立，取决于内容管线层能否把内联脂批解析成"回／段／句偏移"并以 comment 表入库——这一步做完，脂批对照与异文对照两个差异化功能才谈得上实现；做不完，后面所有页面都只能退化为"没有批语的普通阅读器"。

7.3 检索方案

7.4 可视化方案

7.5 非功能指标

---

8. 实施计划

8.1 四期里程碑

!图2　实施排期

图 2　实施排期（16 周 · 单人全职口径）

排期要点：一期（第 1—4 周）没有任何用户可见成果，却是唯一不可压缩的阶段。6 项任务中 4 项集中在第 3—4 周，其中"脂批锚点定位"与"正文重建 diff=0 校验"互为依赖——锚点解析错一位，重建 diff 就不可能为 0，反之 diff 为 0 就基本证明解析无损。这是本方案设计的自证机制：用一条可自动执行的校验替代人工逐条核对。

若为兼职投入（按 ×2.5 计约 40 周），建议在一期结束后先上线"阅读器"单功能版本（可读原文、无脂批），让成果尽早可用，再继续二期。

8.2 各期验收标准（DoD）

一期

• [ ] 解析器输出 content.db，含 7 张表
• [ ] 脂批 3 891 条全部入库，抽检 200 条锚定准确率 ≥ 98%
• [ ] 正文重建与源文件 diff = 0
• [ ] 前 80 回异文对齐完成，可导出异文表
• [ ] CI 门禁脚本 verify_quotes.py 接入，构建失败可复现

二期

• [ ] 三条关键动线（读／查／教）全部走通
• [ ] 脂批可按批型开关；行内标记与侧栏联动正确
• [ ] 检索覆盖 4 类内容；中文专名命中率人工抽检 ≥ 95%
• [ ] 单回页面 LCP < 1.5 s（4G 模拟）

三期

• [ ] 40 个人物页数据完整、无空缺字段
• [ ] 关系图谱 40 节点／75 条关系全可交互
• [ ] 热力图与原文跳转无误
• [ ] 人物名录差异（惜春／紫鹃）在页面上有明确说明

四期

• [ ] 专题 4 篇上线，每条主张带类型标注
• [ ] 366 张插图完成许可登记；总计 < 40 MB
• [ ] 全站无死链；Lighthouse 性能与可访问性 ≥ 90
• [ ] 部署完成，自定义域名可访问，HTTPS 正常

8.3 关键路径

语料解析 + 脂批锚定（一期，不可压缩）
        ↓
阅读器 + 脂批对照（二期）        ← 关键路径，任何延迟直接顺延上线
        ↓
上线（四期）

关系图谱、热力图、专题页不在关键路径上，可在二期并行开展，用已有 SVG 先上线降级版本。若人力紧张，优先保关键路径。

---

9. 团队与角色

单人全职约 16 周；若每周投入 10 小时（兼职），按 ×2.5 计约 40 周。建议兼职口径下把一期做扎实，二期以后可分批上线（先上"读"，再上"人物"）。

---

10. 成本估算

10.1 现金成本

10.2 人力成本（按 16 周单人全职折算）

成本优势结论：本项目是典型的"内容已备、只欠工程"项目，现金投入近乎为零，主要成本是 80 人日 的工程实现。因此排期风险远大于预算风险。

---

11. 风险登记册

---

12. 版权与合规（上线前必须清零）

PM 判断：R2 是唯一可能让项目整体推倒重来的风险。建议在第 1 周就把许可登记表建起来、把语料来源查清，而不是等到四期上线前——越晚发现，返工越大。

---

13. 成功指标

---

14. 下一步：第 1 周即可执行的 8 件事

第 3、4 项是关键路径的第一个卡点：这两件事做完，全站体验的地基就成了；做不完，后面所有页面都只能做"没有批语的普通阅读器"。

---

本方案基于 F:\deepseek-harness 下已完成的语料、结构化数据与文稿资产编制。所有规模数字（回数、字数、批语条数、图片张数）均来自实际盘点，未作估算。