LLM Wiki实战：DeepSeek Harness构建工业级知识编译管线-平芜编程栈

很高兴能和你一起拆解“LLM Wiki”这个最近热度很高的方向。如果你关注过 Andrej Karpathy 提出的 LLM Wiki 范式，或正在寻找一套能把知识库、知识图谱和大模型问答结合起来落地的方案，那么这篇实战笔记会非常匹配你的需求。文章会从概念入手，逐步拆解 DeepSeek Harness 的核心能力，然后围绕“10 轮提示打磨内容管线”“知识图谱构建”“可溯源问答”“增量编译”“在线评估”五个关键模块，给出完整的流程、示例代码和常见坑点，无论你是刚接触大模型应用开发，还是已经在做 RAG 落地，都能从中找到可以直接复用的思路。

1. 背景与核心概念：为什么需要“LLM Wiki”这种范式

1.1 从 Karpathy 的 LLM Wiki 想法说起

大模型应用开发中有一个绕不开的问题：幻觉。模型生成内容时，如果完全依赖参数化记忆，很容易出现“看上去合理、实际错误”的答案。于是大家开始做 RAG（检索增强生成），把外部知识库接进来，让模型基于检索结果回答。RAG 确实是有效方案，但它更多是在“对话时”做检索，知识库本身的构建质量并没有被严格约束。

Andrej Karpathy 在 2025 年提出的LLM Wiki范式，核心思路是换一个角度使用大模型：不要只让模型“生成”新内容，而是让它把已有的网页、文档、事件流“编译”成结构化的 Wiki 条目。也就是说，LLM 的角色从“写手”变成“编译器”——输入是大量真实存在的网页和资料，输出是结构严谨、可溯源、可增量更新的知识条目。

这个想法和传统 Wiki 的差异在于：传统 Wiki 靠人工维护，成本高、更新慢；LLM Wiki 靠大模型批量处理，同时通过“编译”而不是“创作”来最大限度降低幻觉风险。每一条内容都锚定到原始来源，读者可以点击溯源，系统可以按来源变化触发增量更新。

1.2 DeepSeek Harness 是什么

DeepSeek Harness可以理解为 LLM Wiki 范式的一个工程化落地工具。它不是一个单纯的聊天机器人，也不是传统 RAG 框架，而是一套围绕“知识编译”设计的完整工作台。

从当前社区的信息来看，它通常具备以下能力：

能力模块	作用
Web 工作台	通过浏览器管理知识库、配置编译任务、查看 Wiki 结构
插件机制	扩展不同来源的采集、解析和清洗能力
知识图谱	把 Wiki 条目中的实体和关系抽取出来，形成可查询的图谱
溯源问答	回答问题时附带来源引用，支持回溯原始文档
增量编译	只处理变更的文档，避免全量重复编译，节省成本
在线评估	对 Wiki 条目和问答效果进行持续评测，发现问题后迭代提示词

需要说明的是，DeepSeek Harness 作为一个活跃迭代的开源工具，不同版本的界面和接口可能略有差异。本文会以“思路 + 通用实现”为主，尽量做到即使你用的不是最新版本，也能看懂流程并迁移到自己的项目里。

1.3 为什么“10 轮提示”很关键

很多人在构建知识库时，只写一条“系统提示词”就期望模型产出高质量结构化内容。但在工业级场景中，“提示词”不是一次性写出来的，而是需要多轮迭代打磨的。

10 轮提示不是固定要跑 10 次，而是一种方法论：每一轮对上一轮的输出进行质检和反馈，逐步补齐格式规范、实体抽取规则、溯源格式、边界条件等细节。最终得到的提示词不是一段“魔法文本”，而是一套经过验证的“编译规则”。

2. 环境准备与版本说明

2.1 运行环境

本文示例以常见开发环境为例，具体版本请根据你的实际项目调整：

操作系统：Windows 10/11、macOS 或 Linux 均可
Node.js：建议使用 LTS 版本（如 20.x 或更高，以官方要求为准）
包管理器：pnpm（如果你看到pnpm dsh web这类命令，说明工具链基于 Node 生态）
Python：3.10+（用于知识图谱处理和 Neo4j 操作示例）
数据库：Neo4j Community Edition 5.x（用于图谱存储）
向量数据库：根据项目需要选择，本文示例以文件索引为主

2.2 安装 DeepSeek Harness

这里给出通用的安装思路。由于工具仍在迭代，建议以官方 README 为准。

# 克隆或下载 Harness 项目 git clone <your-harness-repo-url> cd <harness-project-directory> # 安装依赖 pnpm install # 启动 Web 工作台 pnpm dsh web

如果在pnpm install或pnpm dsh web阶段卡住，通常是网络或 Node 版本问题，后面第 8 节会给出排查清单。

2.3 示例项目结构

为了便于后续实战演示，我们先约定一个项目结构：

llm-wiki-industrial/ ├── config/ │ ├── prompts/ │ │ ├── round_01_initial.md │ │ ├── round_03_entity_rules.md │ │ └── round_10_final.yaml │ └── settings.yaml ├── data/ │ ├── sources/ # 原始采集文档 │ ├── compiled/ # 编译后的 Wiki 条目 │ └── graph/ # 图谱导出文件 ├── src/ │ ├── collector/ # 文档采集 │ ├── compiler/ # Wiki 编译核心 │ ├── graph/ # 知识图谱构建 │ ├── qa/ # 溯源问答 │ └── evaluation/ # 在线评估 └── tools/ └── eval_runner.py

3. 核心原理拆解：一条 LLM Wiki 内容管线是怎么跑的

3.1 整体流程

LLM Wiki 的完整管线可以拆成 6 个阶段：

采集：从网络、本地文件、API 等渠道获取原始文档。
清洗：去除广告、导航、HTML 标签，提取正文内容。
结构化编译：调用大模型，将清洗后的内容编译成 Wiki 条目。
图谱抽取：从 Wiki 条目中抽取实体和关系，写入知识图谱。
索引与存储：将 Wiki 条目写入索引，支持检索。
评估与更新：对编译结果进行质量评估，发现问题后迭代提示词。

3.2 什么是“可溯源问答”

可溯源问答的核心要求是：答案的每一个关键结论，都要能对应到 Wiki 条目和原始文档。

为了让溯源可行，Wiki 条目的 schema 中必须包含source_url、source_paragraph、compiled_at等字段。问答系统在生成回答时，不能只返回最终答案，还要返回引用的条目 ID 和原始段落。

{ "entry_id": "wiki-tech-000123", "title": "DeepSeek Harness 安装步骤", "content": [ { "section": "环境要求", "text": "安装 DeepSeek Harness 需要 Node.js 和 pnpm。", "source_url": "https://example.com/docs/harness/install", "source_paragraph": "Prerequisites: Node.js 20+, pnpm 8+" } ], "entities": ["DeepSeek Harness", "Node.js", "pnpm"], "compiled_at": "2025-06-01T10:00:00Z" }

这种设计让用户在阅读答案时，可以点击“来源”跳转到原始文档，从而验证模型是否忠实于资料。

3.3 增量编译为什么省成本

全量编译在知识库较小时没问题，但当文档量达到数万甚至数十万，每次全量调用大模型都是巨大开销。增量编译的思路是：

记录每个 Wiki 条目的source_hash。
每次采集新文档后，计算新文档的哈希值。
若哈希无变化，则跳过编译。
若文档变更，则只重新编译该文档对应的条目，并更新依赖它的索引。

import hashlib import json from pathlib import Path def content_hash(text: str) -> str: return hashlib.sha256(text.encode("utf-8")).hexdigest() def should_recompile(source_file: Path, state_file: Path) -> bool: content = source_file.read_text(encoding="utf-8") new_hash = content_hash(content) if not state_file.exists(): return True, new_hash state = json.loads(state_file.read_text(encoding="utf-8")) return state.get("hash") != new_hash, new_hash

3.4 在线评估的设计思路

在线评估不是等上线后再做，而是嵌入在编译管线中。每轮编译完成后，抽取一部分样本进行人工或模型评估，指标包括：

字段完整性：所有必填字段是否都有值
格式正确性：JSON 或 Markdown 是否符合 schema
溯源覆盖率：有多少条目缺少有效的source_url
实体准确率：抽取出的实体是否与原文一致

评估结果会反馈到提示词迭代中，形成闭环。

4. 完整实战：10 轮提示打磨工业级 Wiki 内容管线

4.1 第 1-2 轮：定义 Wiki 条目的 Schema 和格式

第一轮提示不需要追求完美，核心目标是让模型输出一个基本可用的结构化条目。

# config/prompts/round_01_initial.md 你是 Wiki 编译助手。请把下面的原始文档编译成结构化 Wiki 条目。 要求： 1. 输出 JSON 格式。 2. 必须包含 title、summary、sections、source_url 字段。 3. sections 是数组，每个元素包含 section_title 和 section_content。 原文： {source_text}

第一轮跑完，你会发现输出可能有格式问题，比如 JSON 中有多余的换行、字段缺失等。第二轮可以在提示词中加入“输出规范”和一个 one-shot 示例。

# config/prompts/round_02_with_example.md 你是 Wiki 编译助手。请把原始文档编译成结构化 Wiki 条目。 输出规范： - 必须输出合法 JSON。 - 不允许出现 Markdown 代码块包裹。 - title 不超过 30 个汉字。 - summary 不超过 100 个汉字。 - sections 中的每个 section_content 不超过 500 个汉字。 示例： 输入：一个介绍 Neo4j 安装的网页。 输出： {"title": "Neo4j 安装指南", "summary": "介绍 Neo4j 的安装步骤和注意事项。", "sections": [{"section_title": "环境要求", "section_content": "Neo4j 需要 Java 17 环境。"}], "source_url": "https://example.com"} 原文： {source_text}

4.2 第 3-4 轮：加入实体抽取规则

当基本格式稳定后，第 3 轮开始引入知识图谱所需的实体抽取。

# config/prompts/round_03_entity_rules.md 你是 Wiki 编译助手。请把原始文档编译成结构化 Wiki 条目，并抽取实体。 实体抽取规则： - 只抽取专有名词：技术产品、人名、机构名、工具名。 - 不抽取通用名词，如“软件”“系统”“方法”。 - 每个实体保留在 entities 数组中，使用中文名称。 - 如果实体出现英文全称和缩写，取全称，缩写放入 aliases 字段。 JSON 结构： { "title": "...", "summary": "...", "sections": [...], "entities": [ {"name": "...", "type": "TOOL|PRODUCT|PERSON|ORG", "aliases": ["..."]} ], "source_url": "..." }

第 4 轮要做的是：让模型抽取实体时，同时抽取实体之间的关系。这是知识图谱构建的关键一步。

# config/prompts/round_04_relation_rules.md 在原有实体抽取基础上，额外抽取关系。 关系规则： - ONLY 抽取实体之间的、在原文中明确出现的关系。 - 不要推断原文没有的关系。 - 关系三元组格式：{"head": "实体A", "relation": "关系词", "tail": "实体B"} - relation 使用动词短语，如“依赖于”“支持”“发布于”。 输出新增字段： "relations": [ {"head": "DeepSeek Harness", "relation": "依赖", "tail": "Node.js"} ]

4.3 第 5-6 轮：补充溯源信息

工业级 Wiki 最容易被忽略的就是溯源。第 5 轮开始，提示词中加入“逐段溯源”要求。

# config/prompts/round_05_traceability.md 溯源要求： - 每个 section 必须包含 source_url 和 source_paragraph。 - source_url 必须来自原文中实际存在的链接。 - source_paragraph 摘录该小节依据的原文段落，最多 100 字。 - 禁止编造 URL。 JSON 结构： { "title": "...", "summary": "...", "sections": [ { "section_title": "...", "section_content": "...", "source_url": "https://原文中的真实链接", "source_paragraph": "原文章节的关键句" } ], "entities": [...], "relations": [...] }

第 6 轮可以做“溯源缺失自检”。让模型在输出后，自己检查每个 section 的source_url是否为空，为空则补写"traceability": "missing"。这样评估系统能快速定位低质量条目。

4.4 第 7-8 轮：处理边界情况和长文档

实际文档不会都像示例那么规范。第 7 轮加入边界情况处理规则。

# config/prompts/round_07_edge_cases.md 边界处理规则： - 如果原文是空内容，输出 {"error": "empty_source"}。 - 如果原文内容少于 50 字，输出 {"error": "content_too_short"}。 - 如果原文明显是广告或 404 页面，输出 {"error": "invalid_source"}。 - 长文档超过 3000 字时，拆分为多个 section，每个 section 独立溯源。

第 8 轮加入“多轮对话式修正”。即：模型在第一次编译后，如果评估系统发现error字段，则带着错误信息再次调用模型，让模型重新编译。

# 伪代码：带修正的编译调用 def compile_with_retry(source_text: str, max_retries: int = 2): prompt = load_prompt("round_08") result = call_llm(prompt.format(source_text=source_text)) parsed = parse_json(result) if "error" in parsed and max_retries > 0: prompt = load_prompt("round_08_fix") result = call_llm(prompt.format(previous=result)) parsed = parse_json(result) return parsed

4.5 第 9-10 轮：固化提示词与质检清单

第 9 轮把所有散落的规则整理成一个主提示词，第 10 轮附上质检清单，让模型在输出时逐项自检。

# config/prompts/round_10_final.yaml system: | 你是工业级 Wiki 编译助手。你的任务是把原始文档编译成结构化 Wiki 条目。 你必须严格遵守以下规则，任何规则缺失都视为编译失败。 rules: - 输出合法 JSON，不包含代码块包裹。 - 所有 section 必须包含 source_url + source_paragraph。 - source_url 必须是原文真实链接，禁止编造。 - entities 只抽取专有名词，不推断关系。 - relations 只保留原文明确出现的关系。 - 原文为空或过短时，输出对应的 error 字段。 self_check: - 检查是否所有 sections 都有 source_url。 - 检查 entities 是否都是专有名词。 - 检查 relations 是否都能在原文中找到依据。 - 检查 JSON 是否合法且没有多余字段。 input_format: | 原始文档： {source_text}

到这里，10 轮提示的核心工作量就完成了。你会发现，最后得到的提示词更像一份“编译规格说明书”，而不是简单的一段话。

4.6 知识图谱构建：从 Wiki 到 Neo4j

编译完成后，我们需要把entities和relations写入知识图谱。这里以 Neo4j 为例演示 Python 调用。

# 文件路径：src/graph/neo4j_writer.py from neo4j import GraphDatabase class WikiGraphWriter: def __init__(self, uri: str, user: str, password: str): self.driver = GraphDatabase.driver(uri, auth=(user, password)) def close(self): self.driver.close() def upsert_entity(self, tx, entity: dict): query = """ MERGE (e:Entity {name: $name}) SET e.type = $type, e.aliases = $aliases """ tx.run(query, name=entity["name"], type=entity.get("type", "UNKNOWN"), aliases=entity.get("aliases", [])) def upsert_relation(self, tx, relation: dict): query = """ MATCH (h:Entity {name: $head}) MATCH (t:Entity {name: $tail}) MERGE (h)-[r:RELATES_TO {type: $relation}]->(t) """ tx.run(query, head=relation["head"], tail=relation["tail"], relation=relation["relation"]) def write_entry(self, entry: dict): with self.driver.session() as session: session.execute_write(self._write_entry_tx, entry) @staticmethod def _write_entry_tx(tx, entry: dict): for entity in entry.get("entities", []): query = """ MERGE (e:Entity {name: $name}) SET e.type = $type, e.aliases = $aliases """ tx.run(query, name=entity["name"], type=entity.get("type", "UNKNOWN"), aliases=entity.get("aliases", [])) for rel in entry.get("relations", []): query = """ MATCH (h:Entity {name: $head}) MATCH (t:Entity {name: $tail}) MERGE (h)-[r:RELATES_TO {type: $relation}]->(t) """ tx.run(query, head=rel["head"], tail=rel["tail"], relation=rel["relation"])

调用示例：

# 文件路径：src/graph/run_writer.py from neo4j_writer import WikiGraphWriter writer = WikiGraphWriter("bolt://localhost:7687", "neo4j", "your-password") entry = { "entities": [ {"name": "DeepSeek Harness", "type": "TOOL", "aliases": ["DSH"]}, {"name": "Node.js", "type": "TOOL", "aliases": []} ], "relations": [ {"head": "DeepSeek Harness", "relation": "依赖", "tail": "Node.js"} ] } writer.write_entry(entry) writer.close() print("图谱写入完成")

这里使用了MERGE而不是CREATE，目的是避免重复创建相同节点和关系，保证增量编译时图谱的幂等性。

4.7 可溯源问答的实现

有了 Wiki 条目和图谱后，问答流程可以设计为三步：

根据用户问题，在图谱或索引中检索相关条目。
将条目内容作为上下文，拼接提示词交给大模型生成回答。
强制要求模型在回答末尾附上[来源]列表，引用条目 ID 和 URL。

# 文件路径：src/qa/traceable_qa.py def build_qa_prompt(question: str, entries: list) -> str: context_parts = [] for idx, entry in enumerate(entries): context_parts.append( f"### 条目 {idx + 1}\n" f"标题：{entry['title']}\n" f"内容：{entry['summary']}\n" f"来源：{entry.get('source_url', 'N/A')}\n" ) context = "\n".join(context_parts) prompt = f""" 你是一个基于 Wiki 知识库的问答助手。请根据以下资料回答问题。 资料： {context} 问题：{question} 要求： 1. 只能基于资料回答，不得使用资料之外的知识。 2. 如果资料不足以回答问题，请回答“资料不足”。 3. 回答结束后，必须列出引用的来源 URL。 回答： """ return prompt

4.8 在线评估流程

在线评估分为两个层面：条目质量评估和问答质量评估。

条目质量评估可以使用规则加模型双重判断：

# 文件路径：src/evaluation/entry_eval.py def evaluate_entry(entry: dict) -> dict: issues = [] if not entry.get("title"): issues.append("缺少 title 字段") if not entry.get("summary"): issues.append("缺少 summary 字段") if not entry.get("sections"): issues.append("缺少 sections 字段") for i, section in enumerate(entry.get("sections", [])): if not section.get("source_url"): issues.append(f"sections[{i}] 缺少 source_url") if not section.get("source_paragraph"): issues.append(f"sections[{i}] 缺少 source_paragraph") return { "entry_id": entry.get("entry_id"), "passed": len(issues) == 0, "issues": issues }

问答质量评估可以引入“溯源命中率”指标：

模型生成的回答中包含 N 条来源。
人工抽查或模型自动判断：这 N 条来源是否真的支持对应结论。
命中率 = 有效来源数 / 总来源数。

4.9 运行与验证

将管线串起来后，运行流程如下：

# 1. 采集新文档 python src/collector/fetch_docs.py # 2. 增量检测并编译 python src/compiler/run_compile.py --incremental # 3. 写入 Neo4j 图谱 python src/graph/run_writer.py # 4. 启动问答服务 python src/qa/server.py # 5. 运行评估 python tools/eval_runner.py --sample 100

预期输出包括：编译日志、图谱写入条数、评估统计表。增量编译模式下，未变更的文档不会出现在日志中，可以直接观察耗时差异。

5. 深度解析：大模型精度（FP16、FP32、BF16）对 Wiki 编译的影响

在跑大规模编译任务时，你可能会遇到编译结果不稳定、格式偶尔出错的情况。除了提示词本身，大模型的推理精度也是一个不容忽视的因素。

这里简单梳理三种常见精度的特点：

精度	内存占用	数值范围	适用场景
FP32	高	大，精度最高	训练、初始权重存储
FP16	中	范围较小，小数值易溢出	推理加速，但需注意溢出
BF16	中	与 FP32 范围一致，精度略低	大模型推理/训练的主流选择

在 DeepSeek Harness 这类工具中，如果你直接用 GPU 跑编译任务，默认可能使用 BF16 或 FP16。大部分情况下没有问题，但如果你发现长文本编译时 JSON 输出偶尔缺少括号或字段，可以尝试：

升级到更高精度的推理配置
或在提示词中加入“输出前检查 JSON 合法性”的自检项
或在代码层加入 JSON 修复兜底逻辑

# 简单的 JSON 修复兜底 import json import re def safe_parse_json(text: str) -> dict: try: return json.loads(text) except json.JSONDecodeError: match = re.search(r"\{.*\}", text, re.DOTALL) if match: try: return json.loads(match.group(0)) except json.JSONDecodeError: return {"error": "json_parse_failed", "raw": text[:200]} return {"error": "no_json_found", "raw": text[:200]}

6. 常见问题与排查思路

以下是 DeepSeek Harness 及 LLM Wiki 管线开发中的高频问题汇总。

问题现象	常见原因	解决思路
`pnpm dsh web`启动卡住	Node 版本过低或依赖下载不完整	切换 Node LTS，删除`node_modules`和锁文件重新安装
JSON 输出偶尔不合法	模型精度或提示词约束不足	增加 JSON 自检提示，代码层加入`safe_parse_json`兜底
实体抽取错误率高	提示词中实体规则不明确	在提示词中增加正例和反例，缩小实体类型范围
`relations`出现推断关系	未限制模型只能抽取原文显式关系	在提示词中强调“禁止推断”，并加入模拟错误样例
增量编译没有生效	未保存`source_hash`或哈希比较逻辑有误	检查状态文件是否写入、哈希字段是否与文档内容一致
问答溯源链接失效	原始文档 URL 已失效	采集时保存快照，或额外存一份正文摘要
Neo4j 写入慢	每次写入开启新事务且未使用 MERGE	使用批量事务，对不变实体使用`MERGE`
评估结果不稳定	样本量太小或评估标准不一致	固定评估样本集，多个模型或人工交叉评审

这里特别提醒：在写知识图谱数据时，一定要先在小数据集上验证MERGE的行为，尤其在实体名称大小写、空格差异较大的情况下，否则可能出现重复节点。

7. 最佳实践与工程建议

7.1 提示词版本管理

不要直接在配置文件里改提示词。建议把每一轮的提示词都提交到 Git，并附带评估结果。

config/prompts/ ├── round_01_initial.md ├── round_02_with_example.md ├── round_03_entity_rules.md ├── round_04_relation_rules.md ├── round_05_traceability.md ├── round_06_self_check.md ├── round_07_edge_cases.md ├── round_08_retry_fix.md ├── round_09_merge_rules.md └── round_10_final.yaml

每次改动提示词，跑完评估后把指标记录在evaluation_log.md。这样你才能知道哪些改动是有效的，哪些反而引入了回归。

7.2 增量编译的状态管理

增量编译的核心是状态文件。建议用一个独立目录保存每个文档的编译状态，例如：

data/state/ ├── doc_001.json ├── doc_002.json └── doc_003.json

每个状态文件内容：

{ "source_path": "data/sources/doc_001.html", "hash": "sha256...", "compiled_at": "2025-06-01T10:00:00Z", "entry_id": "wiki-tech-000001" }

注意：状态文件不应存放在临时目录，否则增量编译会失效。

7.3 知识图谱的幂等写入

生产环境写入 Neo4j 时，务必使用MERGE而不是CREATE。同时，建议为实体节点建立唯一约束：

CREATE CONSTRAINT entity_name_unique IF NOT EXISTS FOR (e:Entity) REQUIRE e.name IS UNIQUE;

7.4 安全与合规边界

涉及文档采集时，要注意版权和授权。不要采集违反平台规则的页面，也不要将受限内容写入知识库。在生产环境中，所有涉及外部文档抓取的模块都应当：

设置合理的请求频率和 User-Agent。
遵守目标站点的 robots 协议。
只处理你有权加工和展示的内容。

7.5 评估样本的固定性

在线评估最怕“今天测 100 条、明天测另外 100 条”，导致指标不可比。建议准备一个固定的金样集（golden set），每次评估都先跑金样集，再跑随机样本。

# 文件路径：tools/eval_runner.py GOLDEN_SET = [ "data/samples/golden_001.html", "data/samples/golden_002.html", "data/samples/golden_003.html", ] def run_evaluation(sample_size: int = 100): samples = load_golden_set() + load_random_samples(sample_size) results = [evaluate_entry(compile_sample(s)) for s in samples] return summarize(results)

7.6 日志与监控

编译管道中，每条文档的处理日志至少要包含：

文档 ID 或路径
处理耗时
调用的模型与提示词版本
输出是否含有 error 字段
是否走了重试逻辑

这样，当某一天评估指标突然下滑时，你能快速定位是数据源变更、提示词变更还是模型版本变更导致的。

8. 实战经验：从“能跑”到“工业级”的关键差异

很多初学者搭建的 LLM Wiki 也能跑通，但在数据量上去后就会暴露问题。这里总结几个关键差异点。

8.1 提示词从“描述”变成“规格”

初版提示词往往是“把文档变成 JSON”，最后稳定版提示词则像“编译规格说明书”。差异在于：规则明确、异常路径清晰、有自检清单。

8.2 评估不是事后行为

工业级管线中，评估是每次编译后的自动动作。只要发现条目缺来源、格式错误、实体异常，就要立刻触发修复或告警。

8.3 图谱不是装饰

知识图谱如果只构建不查询，就没有意义。你应该设计几个核心查询场景：例如按实体关联度找相关 Wiki 条目、按关系追踪某个技术产品的上下游依赖等。图谱的价值最终体现在问答和知识发现的效率上。

// 查询与“DeepSeek Harness”直接相关的实体 MATCH (e:Entity {name: "DeepSeek Harness"})-[r]-(related) RETURN e.name, r.type, related.name LIMIT 20;

9. 总结与下一步学习方向

本文围绕“LLM Wiki”这个范式，完整梳理了从概念到 DeepSeek Harness 实战的路径。你学到的关键内容包括：

LLM Wiki 的核心是“编译”而不是“生成”，通过结构化输出和溯源机制降低幻觉风险。
DeepSeek Harness 是一套集成知识采集、编译、图谱、问答、增量更新和评估的工程化工具。
10 轮提示的核心是逐轮迭代：从基础 schema 到实体抽取、关系抽取、溯源、边界处理、自检清单，最后固化为稳定规格。
知识图谱构建中，MERGE的幂等写入是工业级落地的关键。
增量编译通过状态文件和内容哈希大幅降低重复调用成本。
在线评估需要固定金样集，并建立提示词版本与评估指标之间的关联。

下一步你可以继续深入的方向：

多模态 Wiki：尝试将图片、表格也纳入编译流程，让模型输出结构化的图片描述和表格摘要。
自动化提示词回归测试：建立一套 CI 流程，每次修改提示词或模型配置后自动跑金样集，防止回归。
图谱增强问答：在检索阶段先查询图谱，找到相关实体所在的 Wiki 条目，再进入回答阶段，提升答案的关联性。
面向特定领域的深度优化：例如金融、法律或医疗文档，这些场景对溯源和准确率的要求更高，也更有挑战性。

最后想说的是，LLM Wiki 目前仍然是一个快速演进的领域，工具和框架的接口都可能在变。比起死记命令，更重要的是理解这条内容管线的设计哲学：用提示词交付规格、用图谱沉淀关系、用溯源锚定事实、用评估驱动迭代。把这套思路吃透，换任何工具你都能快速上手。