Dochub 文档知识库

痛点：内部文档沉淀之后，很难被真正复用

团队积累了大量 Word、Excel 资料，常见处理方式是继续堆目录，或临时搭一套向量检索。前者让找资料变成逐层翻找，后者引入嵌入管道，却仍然保留原文件格式、没有结构化知识，还增加了运维成本。一旦上下文窗口有限，回答要么漏关键段落，要么引用了过期版本。

Dochub 如何工作：编译成三层 Markdown

Dochub 采用 Karpathy 三层架构：

• raw/：原始文档仓库，作为真相来源，LLM 只读不写
• wiki/：由 LLM 维护的结构化 Markdown，包括源文档摘要、_index.md、_overview.md、_log.md
• _schema.md：人与 LLM 共同迭代的治理规则

初始化（dochub init） 会先把文档移动到 raw/，规范文件名；只转换 .docx 和 .xlsx，优先使用 python-docx + openpyxl，生成 wiki/sources/ 下的 Markdown；最后建立两级索引。检索时先读 wiki/_index.md，再用 grep 定位匹配页，需要细节再回到 wiki/sources/ 验证。

增量更新（dochub update） 从 update/ 目录扫描新文档，判断新增、更新或未变化，转换并归入已有分类；级联更新索引、概览和受影响页面，随后把原始文件移入 raw/。

检索问答（dochub search） 遵循渐进式披露：先读索引，再搜索关键词，只加载匹配页面。回答必须引用 [[wikilinks]]，不编造内容；发现矛盾要标注，有长期价值的内容会主动提议保存为概念页、实体页或对比页。

健康检查（dochub lint） 输出 wiki/_lint-{YYYY-MM-DD}.md，检查页面间矛盾、孤立页面、缺失概念、updated 超过 90 天的过期声明、低置信度高引用页面、YAML frontmatter 与交叉引用格式，以及知识缺口。

适用边界

该技能直接使用资料中的固定 Python 路径与依赖组合；.doc、.xls、.pdf、.pptx、.txt、.jpg 等格式会跳过转换，但仍会进入 raw/ 并被索引。所有写入知识库的内容必须已脱敏。它面向文档编译与维护，不负责通用文件同步，也不承诺访问不可解析的格式。