企业官网建设流程全解析

LLM Wiki、DeepSeek Harness、知识图谱、可溯源问答、增量编译、在线评估这几个词放在一起，通常意味着你要做的不是普通文档问答，而是一套由大模型参与维护的知识工程系统。我按这条链路做过一轮完整验证，核心结论是：这套流程能跑通，但能不能跑到“工业级”，关键不在模型强不强，而在文档拆解、图谱建模、增量更新和评估反馈这些工程环节有没有闭环。适合看这篇文章的，是想把团队内部文档、技术资料、研究报告做成可检索、可溯源、可持续更新知识库的人。整个流程不要求顶配机器，但如果要本地部署模型，显存和内存一定要提前算清楚。

下面按实际落地顺序拆开讲，重点不是把功能列表复述一遍，而是把每一步为什么要这么做、跑到什么程度算通过、卡住时先看哪里，尽量说透。

1. 先搞清楚 LLM Wiki 和 DeepSeek Harness 到底解决什么问题

1.1 LLM Wiki 不是“用 ChatGPT 总结网页”

很多人看到 LLM Wiki 第一反应是：把一堆文档丢给大模型，让它能回答文档里的问题。这个理解不算错，但会把后面的工程设计带偏。

普通文档问答是“你问我答”：模型检索到相关片段，然后生成回答。它不关心文档之间有什么关系，也不关心同一个概念在不同文档里有没有矛盾，更不关心修改一篇文档后，哪些回答会受影响。

LLM Wiki 的思路更像是让大模型参与维护一个“持续演化的维基百科”。它不只是回答问题，还会把分散在文档里的实体、关系、观点抽出来，建立索引和链接，并且随着源文档变化不断更新。Andrej Karpathy 在社区里提过类似范式，核心价值不是做一个聊天机器人，而是把知识沉淀成一个可查询、可追溯、可增量更新的结构。

所以，判断你是否真的需要 LLM Wiki，可以看一个问题：你的知识库是不是经常更新？如果文档一年都不变一次，全量重建也能接受。如果每周都有新文档、旧文档被修订，那就需要增量编译。如果多个文档讲同一个项目或同一套系统，还需要知识图谱来记录它们之间的引用和依赖。

1.2 DeepSeek Harness 在流程里承担什么角色

DeepSeek Harness 不是一个能直接给出答案的模型，它更像一个编排层，负责把多轮提示、知识图谱写入、增量编译、在线评估这些环节串起来。面向 DeepSeek 这类模型，Harness 可以管理调用方式、提示模板、输出校验和任务队列。

可以这样理解：模型解决“这段文字怎么理解”，Harness 解决“这段理解怎么落进知识库、怎么更新、怎么验证”。如果你自己写代码也能做，但会花很多时间在处理流程上。Harness 的价值是让你把精力集中在业务文档和质量调优上。

不过这里要补充一个边界：不同版本的 DeepSeek Harness 在功能范围、插件机制、Web 界面和桌面版支持上不完全一样。安装之前，最好先看一下仓库或官方文档里的说明，确认它支持的是 API 接入还是本地模型部署，避免装完之后发现跑不通。

2. 环境准备：从安装到第一条任务跑通

2.1 安装前先看依赖和版本边界

我的建议是先装一个最简环境，不要一上来就配全套。

DeepSeek Harness 这类基于 Node.js 生态的工具，通常依赖 Node.js、pnpm，还有可能依赖 Docker 和 Neo4j。Node.js 版本对构建影响比较大，版本过老或过新都可能导致依赖安装失败。可以先按项目文档指定的版本装，再用node -v和pnpm -v确认。

知识图谱部分如果选择 Neo4j，最常见的做法是用 Docker 起一个容器，方便重置和备份。命令类似：

# 示例，实际端口、账号、版本以你的环境为准 docker run -p 7474:7474 -p 7687:7687 \ -e NEO4J_AUTH=neo4j/yourpassword \ neo4j:latest

这里最容易忽略的是：Neo4j 的 HTTP 端口 7474 和 Bolt 端口 7687 是否都被放行。如果只放行 7474，网页能打开，但程序连接会失败。

模型接入有两种方式。一种是使用 DeepSeek API，省去本地显存压力；另一种是本地部署模型，把模型权重放到本地，通过 OpenAI 兼容接口或本地推理服务暴露给 Harness。如果你的机器配置不高端，建议先走 API 方式跑通流程，再考虑本地部署。

如果本地部署，还要留意模型精度问题。fp16、bf16、fp32 是常见的权重精度，fp32 占用最高，fp16 和 bf16 能省显存，但不同硬件对 bf16 的支持不一样。不要只看模型参数量，还要看量化后实际需要的显存。一个常见思路是：先小模型跑通，再逐步切换到大模型，对比回答质量和资源占用。

2.2 常见的“卡住”不是死机

安装过程中，很多人会遇到pnpm dsh web卡住不动。这种情况不见得是死机，更常见的是首次启动 Web 界面时要下载前端依赖、编译静态资源或连接数据库。如果机器网络一般，耗时会比较长。

判断方法是：先看 CPU、内存、网络流量。如果程序还在产生 CPU 占用或网络流量，就再等一段时间。如果完全没有任何活动，再考虑清理 pnpm 缓存或重新安装依赖。

可以通过日志确认卡在哪一步，通常排查顺序是：

1. 看启动命令是否进入服务监听状态。
2. 看是否在下载依赖，网络是否稳定。
3. 看 Neo4j 是否已经启动，连接信息是否正确。
4. 看端口是否被占用，程序没有报错但访问不了页面。
5. 如果以上都没问题，换一个 pnpm 镜像源或重新执行安装命令。

2.3 先把最小链路跑通

安装完成之后，不要直接导入整批文档，先跑一条最小链路。比如只处理一个 Markdown 文件：

1. 把它加入文档目录。
2. 触发一次构建。
3. 确认文档被解析出来。
4. 确认实体和关系被写入图谱。
5. 在问答界面问一个与该文档直接相关的问题。
6. 确认回答里能提供来源。

这一步全通过，后面再扩大规模。如果第一步就跑不通，问题一般出现在格式解析、文件路径或模型接口上，先处理这些基础问题。

注意：不要一开始就开大并发批量处理。做知识库构建不是越快越好，因为很多错误会在批量处理时被放大，到时候你很难判断是文档问题、模型问题还是流程问题。

3. 知识图谱建模：文档怎么变成实体和关系

3.1 实体和关系不是越多越好

知识图谱不是要把文档里所有名词都变成节点。那样做出来的图看似庞大，提问时却很难用。真正有价值的是围绕“问答和溯源”来建模。

我一般会保留五类基础节点：

• 文档节点：记录文件路径、标题、更新时间、MD5。
• 片段节点：一段可以被单独引用的内容，比如段落、章节。
• 实体节点：项目、系统、模块、人名、组织、产品等。
• 关系节点/关系边：表示实体之间的关联，比如“依赖”“负责”“引用”“属于”。
• 观点或结论节点：记录文档里提出的结论、判断、疑问。

这样设计的好处是：当用户问“A 模块会不会影响 B 模块”，回答可以从关系边中找到依赖链，再由关系边找到对应的片段节点，最后回到原文。如果你的内容涉及股权关系、科研论文引用这类场景，这套结构会特别有用，因为它能把“谁提到谁”“谁依赖谁”这种隐性信息显式化。

创建节点时，最好给每个片段一个唯一 ID。这个 ID 同时要写进图谱和文档索引里，后续溯源问答直接靠它回查原文。

3.2 用提示词让模型做结构化抽取

从文档生成图谱，不是让模型写一段总结，而是让模型返回结构化数据。下面是一个通用提示模板方向：

请从下面的文档片段中抽取实体和关系。 要求： 1. 只抽取明确出现在原文中的信息。 2. 每个实体必须有名称和类型。 3. 每个关系必须有两个实体、关系类型和一句话依据。 4. 不确定的信息不要输出。 5. 返回 JSON，不要附加解释。

模型输出可以是：

[ { "entity": "A服务", "type": "系统", "aliases": ["服务A"] }, { "entity": "B服务", "type": "系统", "aliases": ["服务B"] }, { "source": "A服务", "relation": "依赖", "target": "B服务", "evidence": "A服务在启动时会调用B服务的接口" } ]

拿到 JSON 之后，不要直接入库。要做两步校验：格式校验和冲突校验。格式校验可以看 JSON 能不能解析、字段是否完整。冲突校验看图谱里是不是已经有同名但不同类型的问题。

这一步最容易出现的问题是模型会脑补关系。比如原文只说“A 和 B 部署在同一台机器”，模型可能输出“A 依赖 B”。解决方式很直接：提示里必须要求“依据原文”，并且在入库前检查 evidence 字段是否真的在原文片段里出现，如果没有就不要写入。

3.3 用 Neo4j 承载图谱

Neo4j 适合保存这类实体关系数据。写入图谱的 Cypher 示例可以这样组织：

// 示例：创建实体节点 MERGE (e:Entity {name: 'A服务'}) SET e.type = '系统' // 示例：创建关系 MATCH (a:Entity {name: 'A服务'}) MATCH (b:Entity {name: 'B服务'}) MERGE (a)-[r:DEPENDS_ON]->(b) SET r.evidence = 'A服务在启动时会调用B服务的接口'

这里用MERGE而不是CREATE，是为了避免重复创建。每次增量编译时，旧的实体可能已经存在，用MERGE可以保留身份，只更新属性和关系。

需要注意的是，Neo4j 不是必需项。文档量很小，用邻接表或者 JSON 文件也能跑。但一旦文档超过几千个片段，关系查询、引用链追踪和增量更新会变得很麻烦。图数据库真正的价值在“多跳查询”场景，比如“C 模块间接依赖哪些服务”，用关系型数据库要写递归查询，图数据库会更直观。

4. 10 轮提示编排：把一次生成拆成可验证流水线

4.1 为什么要用多轮而不是一段超长提示

“10 轮提示”是标题里最容易被误解的部分。它不是让你连续问模型十个问题，而是把一个复杂的知识构建任务拆成 10 个有输入、输出、校验步骤的环节。

拆开的好处有三个：

1. 错误容易定位。如果最后问答不对，可以回看是哪一轮的抽取、清洗、建模出了问题。
2. 上下文不会无限膨胀。每一轮只需要处理当前任务，不用把整个文档塞进一次提示。
3. 可以插入规则校验。每一轮输出之后，先跑校验，再进入下一轮。

如果只用一段超长提示让模型一次性完成“抽取实体、构建图谱、生成问答、设计溯源”，很可能输出格式混乱，也很难做局部重跑。

4.2 十轮流程的参考拆分

下面是一个面向 LLM Wiki 构建的通用十轮流程，可以根据自己的文档类型调整：

这个流程的重点不是轮次数量固定，而是每一轮都有明确的“可验证出口”。如果第 4 轮抽出来的实体质量差，后面的关系抽取也会跟着乱。所以我建议每一轮输出都保留日志。

4.3 每轮提示都要有输出规范和校验方式

提示里不能只写“请认真分析”，要写清楚输出格式。尤其是涉及 JSON 或结构化数据时，最好在提示里给出一个模板，并说明字段含义。

校验也不是可选项。我自己调试时，经常看到第 6 轮报错，最后发现是第 3 轮输出的片段切分有问题，很多片段之间缺少上下文。这样的问题，只有在每轮都留校验日志时才能快速定位。

可以使用的通用校验规则：

• 文本类型字段不能为空。
• 实体名称不能超过 50 个字符。
• 关系必须有 source、relation、target 三个字段。
• 证据片段必须能在原文中找到近似匹配。
• 同一个文档的片段 ID 不能重复。

这些规则可以用一个简单的脚本执行，不通过就丢回给模型重试，或者跳过该片段并记录到日志。

在实际项目里，10 轮可能不够，也可能用不了那么多。更合理的做法是把流程做成可插拔的 Worker：每一轮就是一个小模块，模块之间通过文件或数据库传递数据。这样即使以后换模型，也不用推翻整个流程。

5. 增量编译：源文档变了，只重建受影响部分

5.1 全量重建虽然简单但扩展性差

第一次构建知识库时，全量编译最省事。把几百个文档全部处理一遍，生成图谱和索引，再跑一遍评估，结果清晰。

但全量重建不适合长期维护。原因有三个：

1. 耗时：文档数量增长后，每次全部重跑会浪费大量算力。
2. 资源占用：批量推理会让 GPU 或 API 调用量飙升，成本不好控制。
3. 不可控：全量重跑时，原本已经稳定的内容可能因为模型输出波动而发生变化，导致线上回答不稳定。

增量编译的目标是：源文档只改了一小部分，系统也只重算这一小部分，并且把影响传递给相关的问答和评估结果。

5.2 增量编译的判断依据

增量编译常见依据有三种：

• 文件修改时间：文件变了就重新处理。
• 文件哈希：内容变了才重新处理，避免只改权限也触发全量。
• 依赖关系：某个实体或片段变更后，所有引用它的问答对都要重新评估。

建议至少用文件哈希，因为修改时间不可靠。比如 git 切换分支后文件 mtime 会变，但内容可能没变。哈希方式更稳。

可以用类似下面的流程：

扫描文档目录 -> 计算每个文件的 MD5 -> 对比上一次构建记录 -> 如果 MD5 没变，跳过 -> 如果 MD5 变了，重新解析该文件 -> 找出与该文件相关的实体、关系、问答对 -> 只重建这些节点和索引

5.3 变更传播的最小示例

假设你有一份项目周报，里面有一段提到“A 服务已经完成升级，不再依赖 B 服务”。这个文档变更后，影响的不仅是这一段本身，还包括所有基于“A 依赖 B”生成的问答。

增量编译需要做的是：

这里最容易漏的是“旧关系没有被删除”。如果只新增A 不再依赖 B的关系，却没有删除旧的A DEPENDS_ON B关系，图里会同时存在矛盾信息。所以增量编译不能只做加法，还要做差集比较。

5.4 增量编译常见坑

第一个坑是只更新文档，不更新摘要和实体。这样会出现“文档内容已经是新的，但图谱里还是旧数据”的情况，问答自然会出错。

第二个坑是节点残留。文档被删除后，图谱里的实体和关系如果没有同步清理，会导致回答引用一个不存在的文档。建议在构建记录里保存“文档 ID -> 实体 ID、关系 ID”的映射，删除文档时连带清理。

第三个坑是覆盖范围不确定。一个实体被多个文档引用时，修改其中一个文档，不能只重算这个文档。要沿着关系边找出所有引用了该实体的片段，一起加入重建队列。

增量编译跑完之后，最好输出一份变更报告，包括处理了哪些文件、新增了多少实体、更新了多少关系、删除了哪些节点。报告积累多了，你就能看清系统在哪些地方反复变动，也能提前发现数据质量问题。

6. 可溯源问答：回答怎么带证据

6.1 没有溯源的问答在工程里很难信任

在大模型知识库里，最怕的不是回答不了，而是答错了还一本正经。为了让回答可验证，可溯源问答应作为默认要求：每个回答都必须附带证据链，证据链要能指向具体文档、具体片段，最好还能指向知识图谱中的具体关系。

如果不做溯源，用户看到一个回答，只能凭感觉判断对不对。做了溯源之后，即使模型偶尔答错，也能快速定位错在哪：是文档本身矛盾，还是模型理解错了，还是检索召回错了。

6.2 回答结构设计

不要直接让模型输出纯文本，而是输出一个带证据字段的结构。这个字段可以是 JSON，也可以是你定义的 Markdown 扩展语法。

参考输出：

{ "answer": "A 服务目前在启动时会调用 B 服务接口。", "confidence": 0.87, "evidence": [ { "doc_id": "20250410-weekly", "chunk_id": "20250410-weekly-003", "text": "A 服务在启动时会调用 B 服务的接口来完成初始化。", "entities": ["A服务", "B服务"] } ], "links": [ { "source": "A服务", "relation": "DEPENDS_ON", "target": "B服务" } ] }

用户在前端看到答案时，可以把证据片段折叠或展开，点击后跳到原文对应位置。这个“点击回原文”的能力，是 LLM Wiki 和单纯聊天工具的核心差异之一。

6.3 从图谱到证据的检索路径

可溯源问答的检索路径一般分三步：

1. 从用户问题里抽取关键实体。
2. 在图谱中找到匹配的实体节点。
3. 沿着关系边找到相关片段，再回到文档原文。

比如用户问“A 服务现在还需要 B 服务吗”，系统先识别出实体“A 服务”“B 服务”，然后在 Neo4j 中找到它们之间的关系边，最后把关系边上的 evidence 字段对应片段拿出来，作为回答依据。

这种方式的优点是回答不是基于“模糊相似度”，而是基于“明确关系链”。如果图谱中没有这条关系边，系统可以直接告诉用户“目前没有找到 A 服务和 B 服务之间的依赖记录”，而不是强行生成一个回答。

6.4 溯源失败时怎么办

溯源失败有三种常见情况：

• 实体匹配不到。可以尝试别名扩展，比如“A服务”和“服务A”要能映射到同一个节点。
• 关系存在但证据片段为空。这是数据质量问题，应该把该关系标为“低置信度”，在回答里提示用户。
• 检索到多个互相矛盾的证据。这时不要只取一个，应该把矛盾点展示出来，说明不同文档的说法不一致。

我的原则是：宁可让回答显得保守，也不要让模型强行把人眼已发现的问题掩盖掉。一个能说“我没找到明确依据”的系统，比一个硬编答案的系统更可靠。

7. 在线评估：怎么证明系统一直可用

7.1 离线和在线评估要分开

很多人只在开发时测几个问题，就认为系统“已经可用”。这套胶水方案能支撑 Demo，但撑不住长期迭代。

离线评估是固定的测试集，在每次构建或增量编译后跑一遍，用来发现回归。在线评估是用户真实使用时的反馈，用来发现离线测试集覆盖不到的盲区。

两者要同时做。离线评估保证“改完没有变差”，在线评估保证“真实用户场景里能回答问题”。

7.2 可以跟踪的核心指标

下面这些指标比较适合 LLM Wiki：

不需要一开始就追求所有指标都很高。建议先盯“溯源命中率”和“用户反馈通过率”，这两个指标直接反映可溯源问答做得如何。

7.3 评估数据从哪来

评估数据可以从三处收集：

1. 历史问答日志：用户真的问过的问题，长期积累最有价值。
2. 人工标注集：由业务人员编写一批标准问题和参考答案，覆盖核心场景。
3. 失败案例回流：用户觉得回答不对时，把该问题加入评估集，防止以后再次踩坑。

在在线评估模块里，应该允许用户对回答标注“有用”“无用”“证据不对”“文档过期”等选项。不要只是收集一个点赞数，还要记录用户跳转到哪些证据片段，这个行为能帮助判断检索和排序是否合理。

7.4 把评估接入增量编译流程

增量编译跑完之后，不要只看“构建成功”，还要自动跑一遍回归测试集。如果某个原本通过的问题在这次增量后失败了，系统应该能定位到变更内容，判断是修改文档导致的正常变化，还是构建流程引入的 bug。

可以设计一个简单的回归流程：

1. 增量编译完成。
2. 从变更报告里提取受影响的实体和问答对。
3. 只跑这些问答对的回归测试。
4. 如果失败，则回滚当前增量或单独修复。
5. 更新在线评估日志，记录本次失败案例。

这相当于给知识库做了一个持续集成。每次改动都有验证，每次验证都会反馈回数据。在线评估不是“上线后看数据”的被动功能，而是和增量编译绑定在一起的主动质量闸门。

8. 从 Demo 到“工业级”还要补哪些东西

8.1 工业级不是模型强，而是可运维

很多团队在 Demo 阶段能跑通，到了生产环境就崩，问题通常出在可运维性上。

至少需要补这些能力：

• 日志：每一轮提示、每次模型调用、每次图谱写入都要有日志。
• 任务队列：批量处理时不能一个线程硬跑到底，要用队列控制并发和重试。
• 错误重试：模型调用超时、Neo4j 连接闪断、文件编码异常，都要有重试策略。
• 权限控制：不同角色能访问哪些知识库，至少要有基础限制。
• 备份恢复：图谱、文档索引、构建记录要定期备份。
• 输出一致性：同一个问题在不同时间回答不能差异过大。可参考做法是固定模型温度，并把关键结果缓存。

这些能力听上去很基础，但缺一个都可能在长期运行时变成事故。

8.2 需要注意的模型精度与部署边界

本地部署时，模型精度直接影响资源占用和回答效果。fp32、fp16、bf16 的区别主要在于数值范围和显存占用。fp32 最保守但显存占用高；fp16 能省一半显存但某些硬件上可能出现数值溢出；bf16 在部分新硬件上更稳，但老硬件不一定支持。

不要只看“模型支持 bf16”就盲目开启，先确认你的显卡和推理框架兼容性。更稳妥的方式是用一个包含数字、日期、单位、代码的测试集，在不同精度下各跑一遍，对比关键内容是否出错。

如果使用 DeepSeek API 方式，模型由服务端管理，本地主要关注请求并发、超时和成本控制。建议设置一个请求速率上限，避免某个批量任务把整个调用额度耗尽。

8.3 插件、桌面版和团队协作的选择

如果是个人学习，可以用 DeepSeek Harness 的桌面版或 Web 界面，把构建过程可视化，方便跟踪。

如果是团队使用，我建议优先考虑命令行和配置文件方式。因为桌面版适合演示，不适合脚本化、自动化和权限管理。插件机制则可以帮你扩展文档解析格式、评估指标、通知渠道等能力。

另外，如果你只是需要一个轻量的本地文档问答工具，AnythingLLM 这类产品会更省事。它不是要替代什么，而是定位不同：AnythingLLM 偏重“上传文档直接聊天”，LLM Wiki 偏重“结构化、可溯源、增量更新”。先想清楚自己到底要哪种，再选工具，能少走很多弯路。

8.4 最后的落地建议

如果让我重新做一遍这个项目，我会严格按照下面的顺序推进：

1. 先用 5 个文档跑通最小链路。
2. 人工检查实体、关系、问答质量和溯源链。
3. 加入增量编译，模拟修改一个文档，验证受影响内容是否被重建。
4. 固定 20 到 50 个测试问题，跑离线评估。
5. 上线给少量用户使用，收集反馈。
6. 根据反馈不断修正提示模板和抽取规则。
7. 最后才扩大到全量文档。

不要跳过第 2 步。很多人觉得模型能力强，不需要人工检查，结果生成了一堆错误事实，后面纠正成本更高。

最后留一个判断标准：如果你能回答“最近一次增量编译改了哪些内容、影响了哪些问答、评估指标是升还是降”这三个问题，这套 LLM Wiki 才算真正进入了可用状态。否则它只是一堆自动化流程的堆叠，离“工业级”还有距离。