给知识工作者用的 Obsidian 插件。 把文章、闪念、剪藏丢进去，AI 自动提炼成互相链接的 wiki 知识库，支持向量检索问答。全程数据留在本地，自带 API Key 即可开始。
1. 问题本质拆解
我观察到的现象
我自己就是知识管理工具的重度用户 — Obsidian、Notion、Roam 都用过。它们都支持双向链接和标签，但用了一段时间后我发现一个普遍的困境：笔记越记越多，知识依然散的。 链接有了，结构没有。
2026 年初在深圳做这个项目时，我先系统调研了 ChatPDF。它的定位是”和 PDF 对话” — 上传文档，AI 回答问题。体验不错，但我发现一个根本性的缺口：AI 的输出是一次性的。 你问它三个问题，得到三个很好的回答，但这些回答之间没有关联，和其他文档的知识也没有关联。AI 能生成，但不能沉淀。
这意味着 ChatPDF 解决的是”和单篇文档交互”的场景，而知识管理的真正痛点是”跨文档、跨时间、跨主题的知识整合”。这是完全不同的战场。
用”5 Why”追问到本质
2. PRD 核心内容
用户画像
对 AI 辅助持开放态度，但不信任云端存储处理自己的思考内容。
场景 A：读了一篇长文，想提炼核心观点并存入知识体系 -- 但不想手动写摘要和归类
场景 B：写文章时想引用之前的某个想法 -- 但找不到、想不起
场景 C：积累了几十条笔记后，想看看自己的认知有没有冲突 -- 但没有全局视角
编译管线 5 阶段
我将知识编译拆解为 5 个阶段，对应代码中的实际编译引擎：
优先级判断
| 模块 | 优先级 | 判断依据 |
|---|---|---|
| Load + Analyze + Generate | P0 | 核心编译引擎：AI 能否把碎片变成结构？如果不能，其他都没意义 |
| Enrich（链接补全 + 缺口检测） | P1 | 提升知识体系质量，但依赖 wiki 内容积累 |
| Chat（向量检索问答） | P1 | 验证知识复用价值，基于 embedding 的 RAG 检索 |
| Wiki 预览 + 静态站发布 | P2 | 锦上添花，不影响核心编译闭环 |
非功能需求
- 信任设计：BYOK 模式（用户自带 API Key），我不持有任何密钥。所有数据本地存储，API 仅在处理时调用，发送内容不含文件路径
- 多模型支持：DeepSeek、OpenAI、Anthropic、OpenRouter，用户可选任意兼容接口
- 增量编译：基于 fingerprint 检测变更文件，只处理新增或修改的内容，不全量重跑
- 性能：单次编译（一篇长文）< 30 秒
效果评估指标
| 指标 | 定义 | 目标 |
|---|---|---|
| Schema 字段覆盖率 | 每个 wiki 页面必填字段的完整度 | > 90% |
| 编译成功率 | AI 生成的页面结构完整可用的比例 | 100%（frontmatter 覆盖率） |
| 编译频率 | 用户每周执行编译的次数 | 稳定在 1+ 次/周 |
| 向量检索命中率 | Chat 回答中标注的来源页面是否确实相关 | > 80% |
| 链接密度 | 平均每个 wiki 页面的双向链接数 | 100% 页面包含链接 |
3. 原型设计
关键交互流程
设计决策
知识编译管线详解
整个产品的核心是一套5 阶段编译管线，把”原始素材”自动编译成”可复用知识”。这不是一个聊天机器人 — 它更像一个编译器，输入确定、规则明确、输出可验证。
与竞品的本质区别：ChatPDF 是”问答工具”（输入文档 → 输出回答），传统笔记工具是”存储工具”（输入笔记 → 存着）。编译管线是”沉淀工具”（输入碎片 → 输出结构化的知识体系），输出可积累、可关联、可审计。
管线整体架构
关键技术实现
向量 RAG 检索（Chat 功能）：用户提问后，系统将问题向量化（调用 embedding API），与缓存中所有 wiki 页面的嵌入做余弦相似度计算，取 top 5 相关页面作为上下文。如果向量检索失败，自动降级到关键词搜索兜底。嵌入结果持久化到本地 JSON，避免重复计算。
Schema-first 页面生成：所有 wiki 页面严格遵守统一 frontmatter 规范（title、type、level、tags、original/reference、last_updated）。AI 不是自由生成，而是按模板填充，保证一致性。
增量编译（fingerprint）：每个 raw 文件计算 fingerprint 哈希，编译时只处理新增或修改的文件。已处理的文件直接跳过，避免重复 API 调用。这是编译管线能长期使用的关键 — 随着素材增长，编译时间不会线性增长。
来源分层机制：06-flash_notes/ 下的素材标记为 original（用户原创），其他路径标记为 reference（外部素材）。概念页中原创内容排在前面。这不是技术特性，是产品判断 — 区分”我真正理解的”和”我只是读过的”。
冲突保留而非覆盖：当新摄入的知识与旧知识矛盾时，不静默覆盖，而是创建 ## 知识冲突 区块将两种说法并存。
BYOK 隐私设计：用户自带 API Key，我不持有任何密钥。支持 DeepSeek、OpenAI、Anthropic、OpenRouter 等多个提供商，用户可选任意兼容接口。所有文件本地存储，API 调用仅发送文本内容。
管线的用户价值
| 传统工具 | Second Brain 编译管线 |
|---|---|
| 记笔记但不整理 | AI 自动提炼并归类 |
| AI 问答但输出一次性 | AI 输出沉淀进知识体系 |
| 链接靠手动维护 | Enrich 阶段自动补全双向链接 |
| 知识冲突静默存在 | 冲突区块显式保留 |
| ”我读过什么”和”我理解什么”不分 | 来源分层，原创 vs 外部明确区分 |
| 每次全量处理 | fingerprint 增量编译，只处理变更 |
与 WPS AI / Notion AI 的差异：它们是”AI 在文档里帮你写”，我是”AI 把碎片编译成知识体系”。定位不同 — 一个提升单文档的写作效率，一个提升跨文档的知识复用效率。在办公场景中，这两种能力互补。
4. 上线数据与成果
核心指标
迭代前后对比
- 15 个 wiki 页面
- 全量编译，每次重跑所有文件
- AI 静默覆盖冲突
- 扁平目录结构
- 仅支持 DeepSeek
- 28 个 wiki 页面（concepts 16 + entities 1 + sources 8 + syntheses 3）
- fingerprint 增量编译，只处理变更
- 冲突区块保留，两种说法并存
- 三级分类（核心概念 / 方法框架 / 实践经验）
- DeepSeek / OpenAI / Anthropic / OpenRouter
用数据验证假设
5. 迭代反思与收获
自用反馈驱动的迭代
核心收获
先定义 Schema，再让 AI 填充。 第一版让 AI 自由生成，格式五花八门。后来先设计好分类体系和 frontmatter 规范，让 AI 严格按模板填充。产品经理的核心能力之一：先设计约束，再释放能力。
BYOK 模式的信任设计。 不持有用户的 API Key，所有数据本地。牺牲”开箱即用”，换来信任。知识管理工具处理的是用户最私密的思考，信任是使用的前提。
增量编译是长期使用的关键。 如果每次编译都全量处理，随着素材增长用户会越来越不愿意用。fingerprint 增量编译让编译成本与变更量成正比，不是与总量成正比。
对 AI 办公产品的思考
做完这个项目，我对 AI 在办公场景中的定位有一个判断：AI 最适合做”编译”而非”创作”。编译意味着：输入是确定的、规则是明确的、输出是可验证的。知识提炼、格式转换、数据清洗都属于编译。而写作、决策、创意 — 这些需要人类判断的环节，AI 应该辅助但不应该替代。
这个判断直接适用于 WPS 的场景：文档智能排版是编译，AI 写作助手是辅助。把边界画清楚，产品的可靠性和用户信任都会提升。