飞签原文整理：四份设计文档与一份推广文案

上一篇飞签记忆模型分析的结论建立在两类原文上：仓库内的四份设计文档，和作者发布在鱼皮 AI 导航的产品推广文章。这篇把原文按来源集中收录，方便回头核对某一条判断究竟对应哪段原文。

整理口径有三条。仓库内文档保留原表与关键段落，标注文件名和起始行号，只做删减不做改写；推广文章不逐字转载，只还原章节结构和关键表述，全文见原链接；凡属归纳或点评的内容，写进"整理说明"段落，与引文分开。原文仓库未声明 LICENSE，此处摘录主要用于个人研究与对照。

一、材料清单

材料	版本	规模	原文位置
飞签 · 产品详细设计文档	V1.1	505 行 / 11,091 字	飞签_产品详细设计文档_V1.1.md
飞签 · 开发文档（技术设计）	V1.1	329 行 / 8,174 字	飞签_开发文档.md
飞签 · 记忆回溯检索开发设计书	V1.2	453 行 / 8,863 字	飞签_记忆回溯检索开发设计书_V1.2.md
飞签 · 手动验证清单	V0.1.0（2026-09-22）	50 行 / 1,787 字	飞签_手动验证清单.md
推广文章《告别"金鱼记忆"：我开发了一款能当"第二大脑"的浏览器 AI 助手》	2026-10-22	约 1,500–1,800 字	ai.codefather.cn/post/2113085678806941698

仓库地址是 https://gitee.com/PerFectLi7/feiqian.git，核对版本 master @ 311e789。仓库只有一次提交，四份文档与源码在同一个快照里。

二、推广文章说了什么

文章面向普通用户，六个小节，没有技术细节，也没有出现"功能画像""多轮追问"这些设计文档里的核心概念。

小节	原文讲了什么
前言：我们每天都在丢失记忆	浏览器历史只能字面匹配，"上个月看过的那篇讲 CAP 定理的英文文章"这类模糊印象搜不到；长文阅读效率低
核心功能：记忆回溯	本地语义索引，用自然语言描述即可检索；三个场景：按内容找文章、只记得功能找工具、想不起关键词时由助手追问；书签同样可检索
网页智能助手：重塑阅读体验	常驻侧边栏；一键总结长文；划词即问即答；多标签页横向对比并以表格输出
隐私优先	强调本地优先，索引与向量计算都在浏览器内完成；内置域名黑名单自动跳过敏感站点
如何获取	Chrome 应用商店与 Edge 加载项商店免费上架
结尾	口号"拒绝金鱼记忆，给你的浏览器装上第二大脑"

文章的角色是获客文案，它与设计文档的关系是"承诺面"与"设计面"。上一篇里"宣传口径需要打折"的判断，依据的是这条承诺面与 cloudEnabled 开关未落地、云端 LLM 确实会收到标题与摘要这两处事实之间的落差，不是文章措辞本身有问题。

三、产品详细设计文档 V1.1

一句话定位是"用你记忆中的模糊描述，找回你曾经浏览过的任何网页"。背景判断的关键句在第 29 行：Chrome 原生历史搜索只能做字面匹配，“标题不含关键词就完全找不到”。

层级	数据源	定位	优先级
基本查询库	历史浏览记录	覆盖所有浏览过的页面，解决"遗忘地址"	P0
扩展查询库	书签收藏	用户主动保存的高价值内容，精度更高	P1
实时上下文	当前标签页	结合正在看的页面做即时推理	P1

目标用户分了五类（第 33–39 行）：通用浏览器用户、重度收藏者、研究者/学生、产品/投资从业者、开发者。这张表决定了产品把"所有浏览器用户"而非"书签使用者"当作基本盘。

F0 记忆回溯检索的典型场景对照（第 84–89 行）把"传统历史搜索搜不到"逐条列了出来：

用户记忆	传统历史搜索	飞签
“上个月看的那篇讲数据库 CAP 定理的文章”	标题是 “Understanding the CAP Theorem”，输入"数据库"搜不到	语义匹配，直接命中
“一个讲 Rust 所有权的教程，标题好像有’Ownership’”	标题不含 “Rust” 就漏掉	结合页面内容语义
“那个蓝色调、讲设计系统的网站”	完全无法搜索	页面摘要/正文语义匹配
“大概两三周前，看了一篇关于 React 性能优化的”	需要手动翻历史	时间范围过滤 + 语义检索

同一节给出的检索策略是三分通道（第 130–134 行）：语义向量匹配为主，元数据过滤（时间、visitCount、typedCount）为辅，最后做融合排序。性能参考标注了来源 SmrutiCortex：索引体积约 4KB/页、缓存命中检索延迟约 50ms、嵌入生成 1–3 条/秒（第 138–142 行）。这三项在源码里没有对应基准，上一篇因此把它们处理为设计目标。

F2 标签页能力的技术要点列了八个环节（第 201–210 行）：DOM 获取、Readability 抽取、多标签页合并、按标题/段落分块保留锚点、语义检索加关键词命中的查找定位、结果附原文片段与锚点的溯源、PDF/图片走 OCR 或解析、超长页面分段摘要后再推理。

扩展功能四个。E1 混合上下文被写成差异化核心：同一次对话里同时引用历史、书签、标签页，回答标注 [历史]/[书签]/[标签页] 来源；原文的判断是 ChatGPT/Gemini 扩展"有标签页能力，但不碰用户的本地历史和书签"（第 240 行）。E2 主动遗忘管理针对"历史比书签更脏"，规则包括忽略搜索引擎结果页、登录页、短停留页，对超过 18 个月未打开的记录生成归档建议。E3 场景化恢复按设备与时段区分推荐策略。E4 知识闭环在关闭标签页、打开书签、新存书签三个事件上触发摘要与关联。

技术选型表（第 305–313 行）有两处后来没有按原文落地：向量索引写的是"WASM 向量库 / IndexedDB"，嵌入模型写的是 “MiniLM-L6-v2 / mxbai-embed-large” 二选一。代码最终用的是 IndexedDB 全量扫描加 all-MiniLM-L6-v2，没有引入向量库。

IndexEntry 原文 13 个字段（第 351–364 行）：id（URL 哈希）、url、title、source（history/bookmark/tab）、embedding、summary、lastVisitTime、visitCount、typedCount、tags、folder、indexedAt、archived。隐私黑名单只有 domain、reason、addedAt 三个字段，默认覆盖银行、邮箱、登录页、密码管理器、支付页面。

商业模式是三层定价：免费版（50 个书签检索/周、每周 3 次标签页引用、历史限最近 7 天）、专业版 ¥25/月、团队版 ¥68/月。竞品对比表的结论句值得单独摘出来：历史语义搜索已有竞品验证需求，但它们的共同局限是只做历史语义搜索，不做三库混合推理（第 468 行）。

路线图分四段：MVP 0–3 月做 F0+F2，V1.0 3–6 月做 F1+付费墙，V1.5 6–9 月做 E1+隐私控制，V2.0 9–12 月做 E2/E3/E4+多浏览器+端到端加密同步。成功指标里最硬的一条是"记忆回溯检索 Top-3 命中率 ≥ 70%"（第 499 行），仓库里没有对应的评估集。

四、开发文档 V1.1

七个功能点固定编号：F0 记忆回溯检索（P0）、F1 对话式书签检索（P1）、F2 标签页引用与阅读（P1）、E1 混合上下文（P1）、E2 主动遗忘管理（P2）、E3 场景化恢复（P2）、E4 知识闭环（P2）。

技术选型总览（第 29–37 行）比产品文档更具体，其中"向量索引：WASM 向量库（如 hnswlib-wasm）+ IndexedDB"和"模型调度：本地小模型 + 云端大模型"是整个架构层的承诺。模块划分给了 11 个模块，包括 ui/popup、ui/options、bg/message-router、bg/indexer、bg/extractor、bg/privacy、bg/recommender、bg/closure、core/embedder、core/vector-store、core/ranker、ai/llm。

内部消息接口原文列了 9 种：SEARCH_HISTORY、SEARCH_BOOKMARKS、READ_TAB、EXTRACT_TAB、MIXED_QUERY、GET_INDEX_STATUS、PAUSE_INDEX/CLEAR_INDEX、ADD_BLOCKLIST、GET_RECOMMEND。源码里的 message-router 实际挂了 17 种，命名与这里不完全对应。

IndexedDB 设计四张表（第 204–209 行）：entries（主键 id，索引 source、lastVisitTime、title）、blocklist（domain）、settings（key）、conversations（可选，id）。conversations 标了"可选"，最终没有实现，这也是会话状态只能留在 React state 里的直接来源。

Settings 四个字段值得原样记录，因为它们是隐私承诺的落点：indexEnabled（索引总开关）、historyDays（历史索引回溯天数）、cloudEnabled（是否允许云端推理）、defaultBlocklist（默认黑名单域）。

性能与容量验收表（第 307–312 行）：单页索引体积约 4KB、缓存命中检索延迟 ≤ 100ms、嵌入生成 1–3 条/秒、万级历史条目要求增量索引且候选集收敛。隐私验收的四条要求分别是嵌入本地完成、云端推理前取得同意、默认黑名单覆盖敏感站点、一键暂停与清空后数据可验证删除。

五、记忆回溯检索开发设计书 V1.2

这是四份文档里与实现关系最紧的一份，也是上一篇最重要的原文来源。

原文把问题定义为"功能意图 → 站点内容"的语义鸿沟（第 29 行）：用户说"我要做什么"，页面写"我是什么"。它给了两组对照句——用户侧是"我想要那个能把图片变成像素画的网站"，页面侧是 “Pixelate your photos online — free image pixelator”，并直接断言这两组文本在向量空间里的相似度往往不高。

模糊层	具体表现
用户描述模糊	"AI 聚合平台"没有区分度
站点内容稀薄	正文只有一行，抓不到功能细节（SPA 站点）
类别词泛化	"AI"在任何 AI 站点都出现，向量区分度极低

核心原则那句可以直接引：不要拿用户原话直接检索，先把用户描述翻译成"站点能力"，再匹配（第 56 行）。

功能画像字段的原文定义用 snake_case（第 79–89 行）：functional_summary、action_tags、input_types、output_types、site_category、key_differentiator、model_count、is_free、requires_login。源码在此基础上多出 operationStyle 与 source，前者在原文里只以"操作方式（一键/参数）"的形式出现在追问维度表中。

抽取管线的原文（第 93–101 行）：

页面加载
  → 抽取 title / meta / H1 / 功能按钮文案
  → LLM 生成 functional_summary（一句话说清"这个站能干什么"）
  → 抽取 input_types / output_types / action_tags
  → 判定 site_category（工具/文章/论坛/电商/...）
  → 提取 key_differentiator（从标题和描述中识别区分性特征）
  → 存入功能画像索引

原文为 SPA 站点专门给了"仅凭标题生成画像"的例子：title 为 “AI Model Hub – AI Chat, AI Image, AI Video & 500+ AI Models”，推导出功能摘要、"多模型聚合"和 model_count: 500+。这条设计后来被降级——源码的 buildProfile() 用正则与词表做同样的事，LLM 只补候选集前 6 条。

多路召回按五个方向生成 query（第 120–126 行）：类别语言、功能语言、产品语言、使用场景、同义表达。融合排序表给的是定性权重（第 130–137 行）：

通道	匹配什么	权重
功能摘要匹配	用户功能描述 ↔ functional_summary	高
输入输出匹配	“图片→像素画” ↔ input/output types	高
站点类型匹配	“网站/工具” ↔ site_category	中
关键区分特征匹配	“聚合” ↔ key_differentiator	高
行为信号匹配	用户是否用过、停留多久	中
文本向量匹配	兜底语义相似	低

第 9.4 节才给出数值（第 416–420 行）：

score = 0.5 × 功能摘要匹配
      + 0.3 × 输入输出匹配
      + 0.1 × 站点类型匹配
      + 0.1 × 文本向量相似

源码的 scoreOne() 与这个公式一致，额外把"关键区分特征"并入了功能摘要匹配，并追加行为分项（时间衰减 ≤0.06 + 频次 ≤0.04）。

泛化词降权那段原文很直接：识别 query 里的停用词/泛化词（AI、平台、工具、网站），降低它们的权重，把权重给区分性词（聚合、500+、多模型、Chat/Image/Video 统一）；检索应当对准"聚合"这类区分词，"AI"本身不提供区分信息（第 143–145 行）。

多轮对话的核心循环（第 153–162 行）是一个 while 结构：更新 MemoryProfile、用约束过滤并检索、判断收敛（候选 ≤3 且置信度高则呈现，有高信息增益维度则追问，候选多且无高增益维度则切时间线）、等待反馈。第一轮的要求是"按功能特征分组，让用户判断专门 vs 通用"，原文给了六条结果的示例：两个"专门做像素画"的、两个"通用图片编辑含像素化"的、两个"其他图像转换"的。

追问口径有一张对照表（第 190–194 行）：

不要问	要问
“你还记得标题吗”	“它是专门做这个的，还是通用工具”
“页面是什么颜色”	“操作是一键完成，还是有很多参数”
“大概什么时候看的”	“你记得它能批量处理吗”

依据句是"用户对功能的记忆，远比对内容和外观的记忆可靠"（第 196 行）。

MemoryProfile 原文结构（第 232–257 行）分三块：constraints（time_range、content_type、topic_keywords、source_hint、visual_hint、site_function、site_category）、behavior_signals（min_dwell_time、had_scroll、had_copy）、候选集状态（candidates、rejected、confirmed_features、uncertainty）。源码保留了前三类，把 behavior_signals 合进了打分项，uncertainty 被 asked 与 pending 取代；第 259 行写的"从 uncertainty 里挑一个信息增益最大的维度去问"，在实现中变成了固定顺序的瀑布。

追问优先级表（第 267–275 行）是上一篇"固定决策树"评价的直接对照物：

维度	信息增益	理由
站点功能（聚合/单一）	极高	直接区分站点类型，砍掉大部分候选
时间范围	极高	直接过滤掉大部分历史记录
域名/站点名片段	极高	最强精确信号
内容形式（文章/视频/代码）	高	区分站点类型
操作方式（一键/参数）	中	区分同功能站点的差异
主题关键词	中	已有初步语义匹配
视觉特征（颜色/布局）	低	难以索引，用户也难描述准

第 8 节的案例是 dyvip.lk888.ai：标题 “AI Model Hub – AI Chat, AI Image, AI Video & 500+ AI Models”，正文只有一行。用户说"找一个 AI 聚合平台站点"后，理想流程是先按类型分三组呈现，用户选"多模型聚合平台"，再追问"能同时做对话、图像、视频，还是只做一种"，最后命中。案例启示表的六条里，三条直接对应实现选择：别用类别词做检索要用功能特征、标题是功能型站点最可靠的信号、泛化词要降权区分词要升权。

落地优先级用 P0/P1/P2 三档列了 12 项。P0 是功能画像索引、功能意图解析、多路召回、多轮对话状态管理、硬约束过滤；P1 是功能优先排序、按功能分组呈现、结果反馈闭环、功能对比呈现；P2 是时间线视图、行为信号接入、泛化词降权。值得注意的反差：泛化词降权在设计里是 P2，在源码里却是最先落地的能力。

结尾那段"核心认知"把根本原因归到单轮描述的容量上——一次说清楚的信息量本就有限，与用户表达是否到位关系不大；多轮对话的价值，是把"一次性说清楚"变成"一步步逼近"（第 451 行）。

六、手动验证清单

清单是 2026-09-22 版本，范围覆盖 F0/F1/F2、E1 与隐私黑名单，共 12 条用例：

#	功能	预期结果
1	隐私黑名单默认展示	见默认黑名单（银行/邮箱/登录/密码管理器/支付），标注"默认"
2	手动添加域名	新增"手动"项，该域名不再参与索引与检索
3	移除默认项	该项消失，索引/检索范围恢复
4	F0 历史检索	返回带 [历史] 来源、匹配理由、访问次数与时间的卡片
5	F0 正文抽取	第二次搜索同一主题时结果质量更高
6	F1 书签检索	返回书签结果并展示 folder 路径
7	F2 标签页总结	返回总结
8	F2 内容查找与溯源	返回精炼答案 + "原文出处"片段
9	F2 一键跳转	滚动到对应段落并高亮约 3 秒
10	E1 混合上下文	回答带三种来源标注，引用来源可点击
11	E1 无结果降级	明确提示"未找到相关内容"，不报错
12	隐私控制	暂停/清空即时生效

注意事项里有六条，其中三条被上一篇引用过：正文抽取依赖匿名访问，正文少于 50 字即标记已处理并降级为标题检索；offscreen 产物约 590KB 属正常；src/shared/constants.ts 明文预置了 DeepSeek Key，“仓库提交/分享前务必移除”（第 46 行）。最后这条说明作者清楚风险，但当前快照仍带着占位 Key。

七、原文与实现的对照索引

上一篇的每条落差判断都能在两个位置找到依据：设计文档的承诺句，和对应的实现位置。

原文主张	原文位置	实现事实
WASM 向量库 + IndexedDB	开发文档第 35 行	无向量库，全量读取后暴力 cosine
多路召回，多组 query 各做向量检索	V1.2 第 118–126 行	多组 query 只参与词面匹配，embedding 只用一条
功能摘要与关键特征为主排序	V1.2 第 139 行	权重 0.5 落在功能摘要，符合原意
从 uncertainty 里挑信息增益最大的维度追问	V1.2 第 259 行	固定优先级瀑布，不按候选分布计算
索引期用 LLM 生成画像	V1.2 第 96 行	索引期纯启发式，LLM 只补前 6 条候选
conversations 存储（可选）	开发文档第 209 行	未实现，会话状态在 React state
indexEnabled / cloudEnabled	开发文档第 197–199 行	字段存在，主链路不读取
历史索引回溯天数可配	开发文档第 198 行	historyDays 从未读取，固定 1,000 条
默认预置 Key 需移除	手动验证清单第 46 行	快照仍带占位 Key

上表的"实现事实"一列来自对 src/ 的静态阅读，没有运行构建或扩展，也没有做检索质量评测。原文中属于目标值而非实测值的部分（4KB/页、50ms、1–3 条/秒、Top-3 命中率 70%），这里保留原样并标注来源，不能当作已验证的性能数据。