LLM Wiki 学习手册

发表于 更新于 分类于 阅读次数： 本文字数： 8k 阅读时长 ≈ 29 分钟

LLM Wiki 学习手册

文档核心说明

本文档适用于希望系统学习 LLM Wiki 技术的开发者、技术管理者、知识管理从业者。文档覆盖了从基础概念到企业级落地的完整知识体系，包含：

  • LLM Wiki 核心设计理念与范式

  • 三层架构与三个核心操作的完整实现

  • 与传统 RAG 的全面对比

  • 个人与企业级应用场景

  • 分阶段落地方案

  • 可直接使用的生产级模板

  • 全流程知识质量保障体系

一、基础概念与核心理念

1.1 什么是 LLM Wiki

LLM Wiki 是由 Andrej Karpathy 于 2026 年 4 月提出的革命性个人 / 组织知识库构建方法，它采用知识编译模式，让 LLM 主动构建和维护一个持久化、结构化的知识体系，彻底解决了传统知识管理系统 "没人维护、内容过时、难以使用" 的顽疾。

原始设计文档：karpathy/llm-wiki-gist

1.2 核心范式转变

LLM Wiki 的核心是从传统 RAG 的 \\"知识检索解释器模式"彻底转向"知识编译模式"\\：

传统 RAG（解释器模式） LLM Wiki（编译器模式）
每次查询都从原始文档中重新检索片段 知识只被 "编译" 一次，然后持续更新
没有持久化的知识结构 维护一个不断增长的结构化 Wiki
查询之间相互独立，无记忆 知识在查询和摄入过程中持续积累
每次回答都需要从头推导 基于已编译的知识快速回答
知识是碎片化的、临时的 知识是整合的、持久的

1.3 五大核心原则

  1. LLM 编写和维护 Wiki；人类阅读和提问

    • 人类负责：提供原始资料、提出问题、审核重要内容、更新规则

    • LLM 负责：创建页面、更新内容、维护链接、检查一致性

  2. 知识的一次性编译与增量演进

    • 新资料被摄入时，LLM 一次性理解消化并转化为结构化内容

    • 新信息会被整合到现有知识体系中，更新相关页面、修正矛盾

  3. 持久化的结构化知识体系

    • Wiki 是相互链接的 Markdown 文件集合

    • 知识之间的关联与知识本身同等重要

  4. 原始资料与编译知识的严格分离

    • 原始素材永远只读，确保数据完整性和可追溯性

    • 编译后的 Wiki 由 LLM 读写

  5. 探索过程本身成为知识

    • 用户的查询和探索过程本身也会被归档为新的 Wiki 页面

    • 形成 "提问 - 回答 - 积累 - 再提问" 的正向循环

二、核心架构设计

2.1 三层分离架构

LLM Wiki 采用严格的三层分离架构，这是其设计的精髓：

Text
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
┌─────────────────────────────────────────────────────────┐
│                     模式层 (Schema)                     │
│  人类读写，LLM只读                                      │
│  定义规则、模板、工作流、质量标准                        │
└─────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────┐
│                     Wiki层 (Wiki)                       │
│  LLM读写，人类只读                                      │
│  已编译的结构化知识：摘要、实体、概念、对比、综合          │
└─────────────────────────────────────────────────────────┘
                              │
                              ▼
┌─────────────────────────────────────────────────────────┐
│                     原始素材层 (Raw)                    │
│  人类读写，LLM只读                                      │
│  不可变的原始资料：论文、文章、会议记录、邮件              │
└─────────────────────────────────────────────────────────┘

2.2 原始素材层 (Raw Layer)

核心定位：整个系统的唯一真相来源，所有知识最终都来源于此。

目录结构：

Text
1
2
3
4
5
6
7
8
9
raw/
├── papers/           # 学术论文PDF
├── articles/         # 网页文章、博客
├── books/            # 书籍和章节
├── notes/            # 个人手写笔记
├── meetings/         # 会议记录、转录本
├── emails/           # 重要邮件
├── presentations/    # 演示文稿
└── data/             # 数据文件、表格、图表

关键特性：

  • 不可变性：文件一旦存入，就不会被修改

  • 元数据标准化：每个文件都包含标题、作者、日期、来源 URL 等元数据

  • 哈希校验：自动计算 SHA256 哈希值，用于检测文件修改和去重

2.3 Wiki 层 (Wiki Layer)

核心定位：已编译的知识资产，由 LLM 完全拥有和维护。

目录结构：

Text
1
2
3
4
5
6
7
8
9
10
11
wiki/
├── index.md          # 全局内容索引（必选）
├── log.md            # 操作日志（必选）
├── sources/          # 来源摘要页（每个原始资料对应一页）
├── entities/         # 实体页（人物、公司、产品、项目等）
├── concepts/         # 概念页（理论、方法、技术、框架等）
├── events/           # 事件页（会议、发布、事故）
├── comparisons/      # 对比分析页
├── synthesis/        # 综合概述页
├── explorations/     # 查询结果归档页
└── decisions/        # 决策记录页

两个特殊文件：

  • [index.md](index.md)：Wiki 的总目录，所有页面都在这里有一个条目，按类别组织

  • [log.md](log.md)：只追加的操作记录，记录 Wiki 中发生的所有事情，提供完整的时间线

页面元数据标准：所有 Wiki 页面顶部必须包含 YAML Frontmatter：

1
2
3
4
5
6
7
8
9
---
title: "页面标题"
created: YYYY-MM-DD
updated: YYYY-MM-DD
sources: ["wiki/sources/source-1.md", "wiki/sources/source-2.md"]
tags: ["标签1", "标签2", "标签3"]
confidence: 0.95 # 0.0-1.0，对内容准确性的信心程度
status: draft # draft | reviewed | verified
---

2.4 模式层 (Schema Layer)

核心定位：人机协作的契约，它告诉 LLM 如何构建和维护 Wiki，将通用的 LLM 转变为有纪律的 Wiki 维护者。

目录结构：

Text
1
2
3
4
5
6
schema/
├── CLAUDE.md         # 主规则文件（核心）
├── page-templates/   # 页面模板目录
├── workflows/        # 工作流定义
├── permissions.json  # 权限配置
└── quality.json      # 质量标准

2.5 LLM Wiki v2 社区增强

在原始设计基础上，社区在生产环境中形成了增强版：

  • 类型化知识节点：支持概念、实体、事件、主张、矛盾等多种节点类型

  • 语义化关系：支持使用、依赖、矛盾、导致、修复、取代等明确语义的关系

  • 知识图谱增强：在 Markdown 页面之上构建结构化的知识图谱

  • 知识生命周期管理：为每个知识节点添加生命周期属性，自动标记过时知识

三、核心工作流程

3.1 摄入操作 (Ingest)

将原始资料 "编译" 成结构化的 Wiki 知识，是最核心的操作。

完整步骤：

  1. 预处理：

    • 计算文件 SHA256 哈希，检查是否已处理过

    • 转换文件格式，提取元数据

  2. 深度阅读与分析：

    • 完整阅读原始文件，提取关键实体、概念、事件

    • 识别与现有 Wiki 内容的关联，检测矛盾

  3. 生成内容：

    • 创建来源摘要页，为新的实体和概念创建独立页面

    • 更新所有相关的现有页面，建立双向交叉引用

    • 标记矛盾信息和不确定的主张

  4. 更新系统文件：

    • 更新index\.md和log\.md

    • 提交所有修改到 Git

  5. 报告：向用户报告摄入结果，列出创建和更新的页面

关键特性：一个原始资料通常会触发 10-15 个 Wiki 页面的更新。

3.2 查询操作 (Query)

用户从 Wiki 中获取知识的主要方式。

完整步骤：

  1. 导航与检索：

    • 读取index\.md，找到与问题相关的页面

    • 选择最相关的 3-5 个页面进行深入阅读

  2. 综合与推理：

    • 整合多个来源的信息，构建全面准确的答案

    • 为每个关键声明添加引用

  3. 回答与归档：

    • 向用户呈现答案

    • 询问是否要将答案保存为新的 Wiki 页面

    • 如果是，创建查询结果页，更新系统文件

关键特性：查询延迟极低，因为所有知识都已经提前编译好了。

3.3 检查操作 (Lint)

维护 Wiki 健康和质量的重要操作，类似于代码的 linter。

完整步骤：

  1. 全面扫描：扫描整个 Wiki，查找问题

  2. 问题检测：

    • 矛盾：不同页面之间的冲突声明

    • 过时：被新资料取代的旧主张

    • 孤立页面：没有任何入站链接的页面

    • 缺失页面：被提及但没有自己页面的重要概念

    • 断链：指向不存在页面的链接

    • 缺失引用：没有标注来源的声明

  3. 报告与修复：

    • 生成检查报告，列出问题和修复建议

    • 自动修复简单问题（如断链、格式错误）

关键特性：建议每周运行一次，保持 Wiki 在增长过程中的健康和一致性。

四、与传统 RAG 的全面对比

4.1 核心差异总览

对比维度 传统 RAG（解释器模式） LLM Wiki（编译器模式）
核心哲学 知识是临时检索的结果 知识是持久编译的资产
处理时机 查询时处理（on-the-fly） 摄入时处理（ahead-of-time）
知识状态 碎片化、无结构、临时 结构化、相互链接、持久
知识积累 无，查询之间相互独立 有，知识持续增量演进
查询延迟 高（检索 + 生成） 极低（仅生成）
知识一致性 差，易出现矛盾 好，可自动检查修正
计算成本 查询驱动，随查询量线性增长 摄入驱动，一次性投入
可追溯性 可追溯到原始片段 可追溯到原始来源 + 知识演变过程
人机分工 人类负责整理和维护 LLM 负责整理和维护
维护负担 随数据量指数级增长 几乎为零
最佳适用场景 一次性查询、大量静态文档 长期知识积累、深度主题研究

4.2 工作流程对比

传统 RAG 工作流程：

Text
1
2
用户提问 → 生成查询向量 → 向量数据库检索Top-K相似片段 →
将片段+问题拼接成提示词 → LLM生成答案 → 返回给用户

LLM Wiki 工作流程：

Text
1
2
资料摄入 → LLM阅读理解 → 生成/更新相关Wiki页面 → 维护交叉引用 →
更新索引和日志 → 用户提问 → LLM读取相关Wiki页面 → 生成答案

4.3 各自的局限性

传统 RAG 的局限性：

  • 没有知识积累，每次查询都从头开始

  • 查询延迟高，用户体验差

  • 答案碎片化，难以提供综合分析

  • 知识一致性差，容易出现矛盾

  • 维护成本高，随数据量增长而失控

LLM Wiki 的局限性：

  • 初始摄入成本高，不适合一次性查询大量不相关文档

  • 存在 "错误传播" 风险：如果原始资料有误，错误会被编译到 Wiki 中

  • 初始设置相对复杂，需要定义合适的模式和规则

  • 不适合需要严格实时性的场景

4.4 选择指南

选择传统 RAG，如果：

  • 你需要快速搭建一个问答系统

  • 你的文档是静态的，很少更新

  • 查询量很少，且多为一次性查询

  • 你只需要基于单个文档回答问题

选择 LLM Wiki，如果：

  • 你需要深入研究某个主题数周或数月

  • 你希望知识能够持续积累和演进

  • 你需要频繁查询同一个知识领域

  • 你需要综合多个来源的信息进行分析

五、应用领域

LLM Wiki 适用于任何需要随时间持续吸收信息、建立知识关联、并希望知识资产不断增值的场景。

5.1 个人知识管理与成长

  • 个人数字花园：将所有阅读的文章、书籍、播客、视频转化为结构化笔记

  • 技能学习与职业发展：系统学习新技术，自动构建知识体系

  • 个人项目管理：记录项目上下文，保留所有决策和理由

5.2 学术与科学研究

  • 文献综述与研究追踪：批量摄入论文，自动提取关键信息，发现研究空白

  • 课题研究与实验管理：记录实验设计、数据、结果，自动关联相关理论

  • 论文写作与发表：基于已编译的知识库自动生成论文初稿

5.3 内容创作与媒体生产

  • 长篇虚构作品创作：为人物、地点、组织、事件创建独立页面，彻底避免前后矛盾

  • 系列内容生产：保持系列内容的连贯性和一致性

  • 课程设计与教材编写：快速构建完整的课程体系

5.4 企业与商业应用

  • 智能内部知识库：自动从会议记录、Slack 线程、邮件中提取信息，更新企业 Wiki

  • 项目知识管理：完整保留项目上下文，避免人员流动导致的知识流失

  • 竞争情报与市场分析：自动跟踪竞争对手的动态，生成竞争分析报告

  • 客户成功与支持：为每个客户创建 Wiki 页面，记录所有沟通历史

5.5 教育与培训

  • 学生学习助手：自动构建学科知识体系，生成个性化的复习计划

  • 教师教学资源库：自动整理和更新教学资源，分析学生的学习情况

5.6 专业服务领域

  • 法律知识管理：快速检索相关法律条文和案例，自动生成合同初稿

  • 金融分析与投资研究：自动分析公司财务状况和行业趋势，生成投资研究报告

5.7 前沿技术应用

  • AI 代理的长期记忆系统：作为 AI 代理的外部记忆，让代理拥有持久的 "记忆" 和 "身份"

  • 多智能体共享知识库：多个 AI 代理共享同一个 LLM Wiki 作为共同的知识基础

六、企业级落地方案

6.1 企业 LLM Wiki 的核心定位

企业 LLM Wiki 不是传统 Confluence 的替代品，而是企业知识的 "编译层" 和 "定调层"：

  • Wiki 负责：低频变更、高权威性、需要综合分析的内容

  • RAG 负责：高频变更、时效敏感、需要原始引用的内容

  • 传统 Wiki 负责：人类直接编写的、需要严格审批的正式文档

6.2 企业级架构设计

Text
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
┌─────────────────────────────────────────────────────────┐
│                     用户交互层                           │
│  Web界面  │  Slack/Teams机器人  │  API接口  │  移动应用  │
└─────────────────────────────────────────────────────────┘
                              │
┌─────────────────────────────────────────────────────────┐
│                     业务逻辑层                           │
│  摄入引擎  │  查询引擎  │  审核引擎  │  监控引擎  │  搜索  │
└─────────────────────────────────────────────────────────┘
                              │
┌─────────────────────────────────────────────────────────┐
│                     知识编译层                           │
│  LLM Wiki核心  │  类型化知识节点  │  交叉引用维护  │  版本控制 │
└─────────────────────────────────────────────────────────┘
                              │
┌───────────────┬───────────────────────┬─────────────────┐
│  原始素材层   │      模式与规则层     │  辅助RAG层      │
│  - 文档       │  - 页面模板          │  - 向量数据库   │
│  - 邮件       │  - 工作流规则        │  - 实时数据     │
│  - 会议记录   │  - 权限规则          │  - 临时文档     │
│  - 代码注释   │  - 审核规则          │  - 外部数据源   │
└───────────────┴───────────────────────┴─────────────────┘
                              │
┌─────────────────────────────────────────────────────────┐
│                     基础设施层                           │
│  模型服务  │  存储服务  │  权限服务  │  审计服务  │  监控  │
└─────────────────────────────────────────────────────────┘

6.3 安全与权限设计

企业 LLM Wiki 的权限控制必须遵循 \\"最小权限原则"和"零信任架构"\\：

  • 身份认证：集成企业 SSO/LDAP，强制开启 MFA

  • 细粒度授权：采用 RBAC+ABAC 混合授权模型，支持部门级、项目级、页面级权限

  • 数据安全：全部加密存储，敏感数据自动脱敏

  • 审计与追溯：全链路审计日志，完整的 Git 版本历史

6.4 分阶段落地方案

第一阶段：试点验证（1-2 个月）

目标：验证技术可行性和业务价值

  • 选择 10-20 人的试点团队（研发 / 产品 / 客服）

  • 搭建基础架构：Git 仓库、模型 API、Slack 机器人

  • 定义基础模式，导入试点团队的历史文档

  • 评估效果：信息查找时间、新人上手时间

第二阶段：部门级扩展（3-6 个月）

目标：在多个部门推广，完善企业级功能

  • 扩展到整个部门，同时在 2-3 个不同类型的部门并行推广

  • 完善权限管理，实现与 Confluence、Jira、GitLab 的集成

  • 建立知识治理体系，成立知识治理委员会

第三阶段：企业级全面推广（6-12 个月）

目标：在全公司范围内推广，成为企业核心知识平台

  • 覆盖所有部门和员工，导入所有重要历史文档

  • 开发高级功能：多语言支持、知识图谱可视化、智能推荐

  • 建立持续改进机制

6.5 与现有系统的集成方案

  • 与 Confluence 集成：单向同步文档，双向链接，权限继承

  • 与 Jira 集成：自动摄入任务信息，问题解答，知识关联

  • 与 Slack/Teams 集成：聊天机器人，自动摘要，通知推送

  • 与 GitLab/GitHub 集成：自动生成代码文档，PR 摘要，发布说明

6.6 治理与质量控制体系

知识治理组织架构：

Text
1
2
3
4
5
6
7
知识治理委员会（CEO/CTO领导）
        │
        ├─ 知识管理办公室（日常运营）
        │
        ├─ 部门知识管理员（各部门1名）
        │
        └─ 领域专家（各领域权威人士）

内容审核流程：采用 "LLM 初审 + 专家终审" 的混合审核模式

  1. 自动审核：格式检查、一致性检查、敏感信息检查

  2. 人工审核：准确性审核、完整性审核、时效性审核

  3. 发布与更新：审核通过后自动发布，定期自动检查内容时效性

6.7 成本与 ROI 分析

以 1000 人的公司为例：

  • 年投入：约 $50,000-100,000

  • 年收益：

    • 员工查找信息时间减少：每人每天节省 15 分钟，年节省 62,500 小时

    • 新人上手时间缩短：每人节省 2 周，年节省 2,000 小时

  • ROI：保守估计在 300% 以上，投资回收期约 4-6 个月

七、生产级模板与配置

7.1 [CLAUDE.md](CLAUDE.md) 主规则文件

这是模式层的核心文件，定义了 LLM 的行为规则：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# LLM Wiki 核心规则 v2.1
**最后更新**: 2026-05-11
**适用模型**: Claude 3.5 Sonnet, GPT-4o, DeepSeek V3

## 1. 核心使命与基本原则

### 1.1 你的角色
你是这个LLM Wiki的**唯一维护者和知识管理员**。你的职责是将原始资料转化为结构化、相互链接、持续演进的知识资产。

### 1.2 不可动摇的铁律
- ✅ **只读原始素材**: 你只能读取`raw/`目录下的文件，**永远不要修改它们**
- ✅ **只写Wiki目录**: 你所有的写入操作都必须在`wiki/`目录下进行
- ✅ **严格遵循模式**: 完全遵守本文件定义的所有规则和模板
- ✅ **所有声明必引用**: 每个事实声明都必须链接回对应的来源摘要页
- ✅ **诚实面对无知**: 如果你不知道答案，直接说不知道，不要编造
- ✅ **标记矛盾信息**: 当不同来源有冲突时，明确标记并呈现所有观点

### 1.3 人机分工契约
- **人类负责**: 提供原始资料、提出问题、审核重要内容、更新本规则文件
- **你负责**: 所有其他工作，包括创建页面、更新内容、维护链接、检查一致性

## 2. 目录结构规范

### 2.1 全局目录结构

llm-wiki/
├── raw/ # 原始素材（人类读写，LLM 只读）
├── wiki/ # 编译后的 Wiki（LLM 读写，人类只读）
└── schema/ # 规则和模板（人类读写，LLM 只读）
└── [CLAUDE.md](CLAUDE.md) # 本文件

Text
1
### 2.2 Wiki目录结构

wiki/
├── [index.md](index.md) # 全局内容索引（必选）
├── [log.md](log.md) # 操作日志（必选）
├── sources/ # 来源摘要页（每个原始资料对应一页）
├── entities/ # 实体页（人物、公司、产品、项目）
├── concepts/ # 概念页（理论、方法、技术、框架）
├── events/ # 事件页（会议、发布、事故）
├── comparisons/ # 对比分析页
├── synthesis/ # 综合概述页
├── explorations/ # 查询结果归档页
└── decisions/ # 决策记录页

Text
1
2
3
4
5
6
7
8
9
10
11
12
13
14
## 3. 页面元数据标准

所有Wiki页面顶部必须包含以下YAML Frontmatter：

```yaml
---
title: "页面标题"
created: YYYY-MM-DD
updated: YYYY-MM-DD
sources: ["wiki/sources/source-1.md", "wiki/sources/source-2.md"]
tags: ["标签1", "标签2", "标签3"]
confidence: 0.95 # 0.0-1.0，你对内容准确性的信心程度
status: draft # draft | reviewed | verified
---

4. 页面模板

4.1 来源摘要页模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
---
title: "来源标题"
created: YYYY-MM-DD
updated: YYYY-MM-DD
sources: ["raw/path/to/original/file"]
tags: ["来源类型", "主题"]
confidence: 1.0
status: verified
---

## 基本信息
- **标题**: 原始来源标题
- **作者**: 作者姓名
- **日期**: 发布日期
- **来源**: [原始链接](URL)
- **文件**: [[raw/path/to/original/file]]

## 核心要点
- 要点1
- 要点2

## 关键发现
- 发现1
- 发现2

## 重要引述
> "原文引述"

## 相关概念
- [[概念1]]
- [[概念2]]

4.2 概念页模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
---
title: "概念名称"
created: YYYY-MM-DD
updated: YYYY-MM-DD
sources: ["wiki/sources/source-1.md"]
tags: ["领域", "子领域"]
confidence: 0.9
status: draft
---

## 定义
什么是这个概念？用一句话清晰定义。

## 核心原理
解释这个概念的基本原理和工作机制。

## 发展历史
- YYYY: 重要事件1
- YYYY: 重要事件2

## 主要特点
- 特点1
- 特点2

## 相关概念
- [[相关概念1]]: 关系说明
- [[相关概念2]]: 关系说明

4.3 实体页模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
---
title: "实体名称"
created: YYYY-MM-DD
updated: YYYY-MM-DD
sources: ["wiki/sources/source-1.md"]
tags: ["实体类型"]
confidence: 0.9
status: draft
---

## 基本信息
- **全称**: 实体全称
- **成立/创建时间**: YYYY-MM-DD
- **创始人/作者**: 姓名
- **官网**: [链接](URL)

## 简介
一段简短的实体介绍。

## 发展历程
- YYYY-MM: 事件1
- YYYY-MM: 事件2

## 相关实体
- [[相关实体1]]: 关系说明
- [[相关实体2]]: 关系说明

4.4 对比分析页模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
---
title: "A vs B vs C"
created: YYYY-MM-DD
updated: YYYY-MM-DD
sources: ["wiki/sources/source-1.md"]
tags: ["对比", "主题"]
confidence: 0.9
status: draft
---

## 概述
简要说明对比的目的和对象。

## 核心对比表
| 维度 | A | B | C |
|------|---|---|---|
| 维度1 | 值1 | 值2 | 值3 |
| 维度2 | 值1 | 值2 | 值3 |

## 详细对比
### 维度1
详细说明三者在这个维度上的区别。

## 适用场景
- **A适合**: 场景1, 场景2
- **B适合**: 场景3, 场景4
- **C适合**: 场景5, 场景6

5. 核心操作工作流

5.1 摄入操作 (/ingest)

当用户添加新文件到raw/目录并运行/ingest命令时，执行以下步骤：

  1. 预处理：检查文件是否已经处理过，转换文件格式，提取元数据

  2. 深度阅读与分析：完整阅读整个原始文件，提取关键实体、概念、事件

  3. 生成内容：创建来源摘要页，为新的实体和概念创建独立页面，更新相关页面

  4. 更新系统文件：更新index\.md和log\.md，提交所有修改到 Git

  5. 生成报告：向用户报告摄入结果，列出创建和更新的页面

5.2 查询操作 (/query)

当用户提出问题时，执行以下步骤：

  1. 导航与检索：读取index\.md，找到与问题相关的页面

  2. 综合与推理：整合所有相关页面的信息，构建全面准确的答案

  3. 回答与归档：向用户呈现答案，询问是否要将答案保存为新的 Wiki 页面

5.3 检查操作 (/lint)

当用户运行/lint命令时，执行以下步骤：

  1. 全面扫描：扫描整个 Wiki 目录下的所有页面

  2. 问题检测：查找矛盾、过时、孤立页面、缺失页面、断链、缺失引用

  3. 生成报告：对问题进行分类和优先级排序，提供修复建议

  4. 自动修复：自动修复断链、格式错误等简单问题

6. 写作规范与质量标准

6.1 写作风格

  • 使用清晰、简洁、客观的语言

  • 避免主观评价和情绪化表达

  • 使用第三人称叙述

  • 段落简短，重点突出

6.2 引用规范

  • 每个事实声明都必须有引用

  • 使用\[\[来源名称\]\]格式进行引用

  • 不要引用原始素材文件，只引用来源摘要页

6.3 矛盾处理

  • 当不同来源有冲突时，不要选择一方

  • 明确标记矛盾：⚠️ 矛盾信息

  • 呈现所有来源的观点，注明每个观点的来源

7. Git 提交规范

所有提交必须遵循以下格式：

Text
1
2
3
4
5
6
[操作类型] 简短描述

详细说明：
- 修改了什么
- 为什么修改
- 相关页面列表

操作类型包括：ingest、update、fix、lint、archive

Text
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
### 7.2 三个核心操作的详细工作流

#### 摄入操作 (Ingest) 详细工作流
**触发方式**：用户将文件拖入`raw/`目录并运行`/ingest`命令
**前置条件**：文件已存在，格式支持，未被处理过
**输出要求**：
- 一个原始资料对应一个来源摘要页
- 每个重要的实体和概念都有自己的独立页面
- 所有页面都包含正确的元数据和引用
- 所有相关页面之间都有交叉引用

#### 查询操作 (Query) 详细工作流
**触发方式**：用户直接提出自然语言问题
**前置条件**：Wiki中至少有一个来源摘要页
**输出要求**：
- 答案直接回答用户的问题
- 信息全面、准确、基于Wiki内容
- 所有关键声明都有引用
- 结构清晰，易于阅读

#### 检查操作 (Lint) 详细工作流
**触发方式**：用户运行`/lint`命令，或系统定期自动执行
**前置条件**：Wiki目录存在且包含至少一个页面
**输出要求**：
- 报告清晰、分类明确
- 每个问题都有具体的位置和描述
- 提供可操作的修复建议
- 自动修复简单问题

### 7.3 使用提示与最佳实践
1. **从小规模开始**：先摄入5-10份核心资料，熟悉系统工作方式
2. **定期运行lint**：建议每周运行一次`/lint`命令，保持Wiki的健康
3. **及时归档查询**：将有价值的查询结果保存为Wiki页面
4. **持续优化模式**：根据使用体验，不断更新和完善`CLAUDE.md`文件
5. **使用Git分支**：对于重要的修改，使用Git分支进行测试
6. **备份原始资料**：定期备份`raw/`目录，这是你的唯一真相来源

---

## 八、知识质量保障体系

知识的准确性和可靠性是LLM Wiki的**生命线**。需要从**知识生命周期的全流程**入手，建立闭环的质量控制系统。

### 8.1 源头控制：原始素材的质量保障

#### 来源分级与准入机制
| 来源等级 | 定义 | 示例 | 可信度 | 使用限制 |
|---------|------|------|--------|----------|
| **A级（权威）** | 官方发布、经过同行评审 | 官方文档、学术论文、法律法规 | 99%+ | 无限制，可作为最终依据 |
| **B级（可靠）** | 知名机构发布、经过专业编辑 | 权威媒体报道、行业报告 | 90-99% | 可正常使用，重要声明需交叉验证 |
| **C级（参考）** | 个人发布、未经专业审核 | 普通博客、论坛帖子 | 70-90% | 谨慎使用，必须标注来源 |
| **D级（不可靠）** | 匿名发布、明显带有偏见 | 匿名爆料、谣言 | <70% | 禁止使用 |

#### 原始素材审核流程
采用"**先审核，后摄入**"的原则：
1. 提交：用户将素材上传到待审核目录
2. 初审：系统自动检查文件完整性、去重、敏感信息
3. 人工审核：评估来源可信度，确定来源等级
4. 入库：审核通过后，将文件移动到对应等级的`raw/`子目录
5. 触发摄入：通知LLM进行知识编译

### 8.2 编译过程控制：LLM生成内容的质量保障
- **模式驱动的生成**：严格的模板和规则，防止LLM自由发挥
- **多轮验证与交叉检查**：生成-验证-修正三阶段流程
- **引用强制与溯源机制**：每个知识节点都能追溯到原始来源
- **置信度评估与标注**：基于来源等级、数量、时效性评估置信度

### 8.3 存储与维护控制：知识生命周期的质量保障
- **版本控制与审计跟踪**：强制Git提交，完整的审计日志
- **增强型Lint健康检查**：
  | 检查类型 | 检查内容 |
  |---------|----------|
  | 准确性检查 | 没有引用的声明、低置信度声明 |
  | 一致性检查 | 不同页面之间的矛盾声明 |
  | 完整性检查 | 缺失的章节、孤立的页面 |
  | 时效性检查 | 超过6个月未更新的内容 |
  | 格式检查 | 不符合模板的页面、无效的引用 |
- **矛盾检测与管理**：透明地呈现和管理矛盾，而不是掩盖
- **过时信息处理**：自动标记过时内容，定期复审

### 8.4 查询过程控制：答案生成的质量保障
- **引用溯源与验证**：答案中的每个关键声明都必须有引用
- **多页面交叉验证**：综合多个相关页面的信息
- **不确定性透明化**：诚实面对无知，明确标注不确定性
- **答案审核机制**：对于高风险场景，建立答案审核机制

### 8.5 人机协作：人类专家的质量保障
- **分级审核机制**：根据风险等级采用不同的审核级别
  | 风险等级 | 审核要求 |
  |---------|----------|
  | 高风险 | 双专家审核+知识治理委员会审批 |
  | 中风险 | 单专家审核 |
  | 低风险 | LLM自动审核+事后抽查 |
- **领域专家负责制**：谁的领域谁负责
- **用户反馈闭环**：建立完善的用户反馈机制
- **质量评估与持续改进**：建立量化的质量评估体系

### 8.6 高级技术：提升可靠性的进阶方法
- **多模型交叉验证**：使用多个不同的LLM模型进行交叉验证
- **知识图谱验证**：利用知识图谱的推理能力验证知识的一致性
- **外部数据源验证**：定期将Wiki中的知识与权威的外部数据源进行比对
- **幻觉检测技术**：自动识别LLM生成内容中的幻觉

### 8.7 企业级质量控制特殊要求
- **合规与安全检查**：自动检查内容是否符合法律法规和公司政策
- **变更管理**：所有重要的内容变更都必须提交变更申请，经过审批后才能实施
- **灾难恢复与备份**：定期备份，异地存储，恢复测试

---

## 核心知识点速览

1. **LLM Wiki 核心范式**：从传统RAG的"查询时处理"解释器模式，转向"摄入时处理"的编译器模式，实现知识的持久化积累。
2. **三层分离架构**：原始素材层（真相来源）、Wiki层（编译知识）、模式层（人机契约），严格的读写分离。
3. **三个核心操作**：摄入（Ingest）将原始资料编译为知识、查询（Query）从Wiki中获取知识、检查（Lint）维护Wiki健康。
4. **人机分工契约**：人类负责提供资料、提出问题、审核内容；LLM负责所有繁琐的簿记工作。
5. **知识积累效应**：不仅摄入的资料会成为知识，用户的查询和探索过程本身也会被归档为知识。
6. **企业级定位**：LLM Wiki是企业知识的"编译层"，与传统Wiki、RAG系统互补，而非替代。
7. **分阶段落地**：从试点验证到部门级扩展，再到企业级全面推广，小步快跑逐步推进。
8. **全流程质量保障**：从源头、编译、存储、查询到维护的全流程质量控制，确保知识的准确性和可靠性。
9. **可追溯性**：所有知识都可以追溯到原始来源，所有修改都有完整的Git历史记录。
10. **广泛适用性**：适用于个人知识管理、学术研究、内容创作、企业知识管理、专业服务等几乎所有知识密集型领域。