企业官网建设流程全解析

1. 项目全景：我在搭一个什么样的“博客+知识库”

1.1 一句话讲清项目在做的事

我给自己定了这样一个目标：用AI编程把一个博客站点从零搭起来，并且让博客自带一个能问答的RAG知识库。这个知识库不是花架子，而是要真的能回答我积累的文章、笔记、技术资料里的具体问题。

简单拆一下就是两件事。第一，博客本身得有内容展示能力，能写文章、能归档、能搜索，最好还好看。第二，博客里要挂一个对话入口，用户问了问题之后，系统先去知识库里检索最相关的片段，再让大模型基于这些片段生成回答。整个过程跑通之后，我的博客就不只是“展示文章”，而是一个能主动答疑、能沉淀知识的站点。

1.2 为什么值得做一次这样的实战

我观察到一个很普遍的现象：很多人写了大量技术文章、积累了海量本地笔记，但真到要找某个结论的时候，还是靠Ctrl+F或者凭记忆翻目录。博客更惨，文章多了之后，访客根本不知道你写过什么，搜索框一搜还经常搜不到重点。

RAG（检索增强生成）恰好能解决这个问题。它先把文档切成小块、转成向量，用户提问时先从库里把最相关的片段捞出来，再让大模型结合这些片段组织答案。这样一来，答案有出处、逻辑能追溯，比纯靠大模型“背答案”靠谱得多。而AI编程又能大幅降低搭建门槛，博客框架、接口、前端交互，很多代码可以直接让AI工具生成，我只需要做校验、拼接和调参。

1.3 这个项目适合谁

如果你是这样的人，这个项目可以直接照抄思路：

• 有一个博客或打算建博客，但不想手动折腾前端细节；
• 平时用Obsidian、Notion或Markdown积累了大量笔记，想给它们加一个问答入口；
• 想学RAG但不想只看概念，需要一条能落地的完整路径；
• 想试试AI编程到实战程度，而不是只在对话里让AI写个几行的demo。

我自己就是这类人。整个过程走下来，最大的感受是：AI编程解决的是“我从0到1写好代码”的效率问题，RAG解决的是“知识从零散到系统”的组织问题，两个结合起来，个人站点的价值会被放大很多。

2. 第一战：让AI帮我从零搭博客

2.1 选型：博客框架和AI编程工具

动手前先定技术栈。博客这一层，我优先考虑的不是好看，而是“生成代码后容易维护”和“部署成本低”。很多人的选择是Hugo或VitePress，前者是静态站点生成器，后者是Vue驱动的文档站点工具。我最终用了VitePress，原因是它的结构足够简单，核心是Markdown文件加一个配置文件，AI生成的代码量小，我改起来也容易。

AI编程工具方面，我选的是Cline，它能直接读取项目文件，在终端里执行命令，还能按我的指令批量改代码，适配VitePress这类结构化项目很顺手。用这类工具的时候，有个细节要记住：不要让它一次性把整个项目“脑补”出来，而是分阶段下指令，重构、纠错、再重构。

2.2 第一轮构建指令该怎么写

很多人用AI编程犯的第一个错，是“帮我做一个博客”，这句话太宽了。我实际第一轮指令是这样的：

在空目录下初始化一个VitePress项目，采用默认主题， 首页需要展示文章列表，右上角有文章归档和知识库问答两个入口， 配置文件使用TypeScript格式，路由用现有文件结构自动生成。

这个指令明确了两件事：一是项目类型，AI可以直接按VitePress的标准结构创建文件；二是页面骨架，AI知道需要哪些导航和布局。第一轮我不要求它写出完整样式，先把结构立起来。

生成之后，我手动补了一句npm install，等依赖装完，再让它跑一次npm run dev。我始终不建议在指令里让AI“顺便把依赖都装好”，因为不同环境网络状况不同，装依赖的失败信息千奇百怪，让AI去猜不如自己掌控。

2.3 迭代调试：从能跑到能看

骨架跑起来之后，我开始加功能。归档页、标签页、文章列表的摘要展示，这些功能在VitePress里大多有现成配置或主题支持，我只需要让AI改对应的.md文件或.vue组件。

这个阶段最容易出现的问题是“AI把代码改崩了”。我有一次让它加一个“最近更新”模块，它直接把首页布局组件给重构了，运行后控制台报错，整个页面白屏。我当时的处理办法是让AI先回滚到最近一次可用版本，再单独为“最近更新”写一个独立组件，引入到首页而不是改动原有组件。把这个原则翻译一下就是：增量功能用独立模块，不要动主骨架。这条经验在AI编程里特别值钱，因为它能有效兜住AI爱把文件改得面目全非的毛病。

2.4 写博客内容时如何让AI协助更高效

博客内容本身就是知识库的原材料，所以这里值得多说一句。我写作时用Obsidian，每篇文章顶部写好元信息，包括标题、标签、摘要、日期。这个习惯一开始是为了美观，后来发现它对RAG切分和检索特别友好，因为元信息本身就可以作为检索时的过滤条件。

章节标题我尽量写得“像问题”，比如“为什么RAG需要切分文档”“如何选择Embedding模型”，这样知识库被检索到时，更容易匹配用户的问题语义。这一点是我摸索出来的：知识库的质量从写作阶段其实就已经决定了，不是向量化阶段才开始的。

3. 重头戏：RAG知识库完整流水线

3.1 为什么RAG不是“把文件塞进向量库”

很多人对RAG的理解是：把PDF往Dify里一传，等索引完成，就能问答了。这是工具的用法，但不是工程的做法。真实的RAG流水线包含加载、切分、清洗、向量化、存储、检索、重排、生成八个环节，每一步出问题，最终效果都会打折。

我有一次给一个文档搭RAG，文件本身是HTML格式，里面全是导航、推荐位、页码这些无关内容。如果不清洗就直接向量化，检索出来的片段很可能是一段页面导航文字，大模型还会一本正经地引用它，答案自然一塌糊涂。所以，数据预处理必须放在第一位，这里省时间，后面只会在“检索不准”上花更多时间。

3.2 数据准备与切分策略

我博客和笔记的内容以Markdown为主，清洗起来相对简单。我的做法是：先按文章为单位保留元信息，再把正文按二级标题切成块。切分颗粒度是RAG效果的关键之一。

块太大，检索到的片段包含太多无关内容，大模型的答案会发散；块太小，语义不完整，模型难以理解上下文。我的实践值是每个块大概300到500字，重叠窗口设30到50字，确保标题能和正文一起被切进同一个块里。举个例子：

文章标题：RAG实战笔记 二级标题：向量化流程 正文：第一步，将文本转成向量... 切分结果块1：RAG实战笔记 > 向量化流程 > 第一步，将文本转成向量...

这个结构能让检索结果自带“出处上下文”，生成阶段引用起来也更准确。做这块时我直接用LangChain的MarkdownHeaderTextSplitter，它比普通字符切分强很多，因为它知道Markdown的层级结构，不会把一个二级标题下的内容拆得七零八落。

3.3 向量库选择与Embedding衔接

向量库我用的是轻量级的Chromadb，原因很朴素：它是纯本地运行，不需要单独起服务，也没有烦人的鉴权配置，对一个个人博客级别的RAG系统足够了。如果你有更高的并发或分布式需求，再考虑升级到pgvector或Milvus，但对个人项目来说，先用轻量方案跑通流程最重要。

Embedding模型的选择同样关键。我用的是开源下发的本地模型，这样数据不出本地，也避免每次调用外部API的延迟和费用。选模型时要关注两个指标：一是支持的最大序列长度，至少要覆盖分块后的文本长度；二是向量维度，维度太低可能丢失语义，太高了存储和计算压力大，一般768或1024维是常见选择。

3.4 检索层：让召回更准的三个动作

知识库检索最怕的就是“召回了看似相关、实际跑题”的片段。我做了三个动作来改善：

第一，混合检索。不要只用向量相似度，还要配合关键词匹配。有的问题语义明确，比如“Dify安装”，关键词打分比语义向量更靠谱；有的问题描述模糊，比如“这个配置我改坏了该怎么办”，向量检索更优。两者加权合并，效果比我单独用向量检索明显更好。

第二，重排序。第一轮检索可以多召回一些候选片段，比如20条，然后用重排序模型在本地对这20条按相关性重新打分，只取前5条送进大模型。这一步能显著提高答案的精确度，代价是多花几十毫秒的时间，个人博客完全能接受。

第三，过滤条件。如果你准备了元信息，那就在检索前把范围缩小，比如“只查2024年之后的文章”“只查RAG分类下的笔记”。我后来发现这步尤其有用，它从源头降低干扰，模型回答时也更聚焦。

如果你用的是Dify这类成熟平台，它内部其实已经封装了召回和重排序的选项，但你要理解每一个开关的含义，而不是一股脑开成最高配置。实际经验是，配置越复杂，调试时越难定位问题。

3.5 生成层：提示词与引用溯源

检索完之后就是生成回答。提示词的写法直接影响回答质量。我用的核心模板是这样的：

你是博客的知识问答助手。请根据以下资料回答问题。 如果资料中没有相关答案，请明确说“知识库中还没有相关内容”， 不要编造。回答末尾附上引用资料的标题和二级标题。 资料： {context} 问题： {question}

这个模板有三个关键点：第一，限制模型不能编造，这对RAG来说比什么都重要；第二，要求引用来源，我可以展示给用户看，增加信任感；第三，告诉模型没找到就直接说，避免无中生有的幻觉。

引用溯源还有一个好处，就是让用户能回到原文阅读，知识库和博客本身就是一体的，点击引用可以直接跳到对应文章，体验会自然很多。

3.6 RAG测评：别靠感觉，用指标说话

知识库搭完之后，不能我问两个问题觉得“还行”就收工。我针对自己的知识库，整理了一套测评方法。

我用的指标是RAGAS框架里的三类：忠实度（答案有没有瞎编）、相关性（答案有没有偏离问题）、上下文精确率（召回的片段里到底有多少是真正有用的）。把它们跑一遍，比我主观判断靠谱得多。

操作上，我准备了一批测试问题集，每类知识至少三四个问题，然后单独调用知识库无向量检索模式对比召回结果，再把答案拿去评测。如果发现某些问题召回不到相关片段，优先怀疑切分颗粒度和检索TopK设置；如果召回到了但答案差，那就要检查提示词和生成模型。

这套方法建议每个打算认真做RAG的人都要走一遍。网上很多教程教你怎么搭一个RAG，却不教你怎么判断它好不好，结果就是上线了才发现答案离谱，体验非常崩。

4. 把知识库接进博客，并让检索更准

4.1 从本地服务到博客页面

最早RAG流水线只是在本地Python脚本里跑，通过命令行问答，但这显然没办法给博客访客用。于是我把RAG模块封装成一个独立的API服务，提供两个接口：一个用于上传或同步文章，一个用于问答请求。

问答接口的流程是：接收用户问题，去向量库检索相关片段，拼装提示词，调用大模型接口生成回答，最后把回答和引用文章列表返回前端。博客前端在“知识库问答”页面里调用这个接口，用Markdown渲染答案，同时展示引用来源。

这里我踩了个坑，就是前端直接请求本地API会碰到跨域问题。解决办法是给API服务加上CORS允许来源配置，把博客域名放进去。如果是部署在服务器上，还需要用Nginx把API路径反向代理到博客同域名下，顺便把HTTPS证书挂上，这样才能保证页面里是够安全地调用。

4.2 查不准？按这个顺序排查

在实际使用中，我几乎每天都会遇到几个“检索不准”的问题。经过一段时间的排查，我把步骤固定下来了。

第一，先看召回片段本身有没有问题。我会在测试页面里把每次回答对应的上下文片段打印出来，如果片段明显不对，那说明切分或检索有问题。第二，检查用户问法和知识库内容表述是否差异过大，比如用户说“博客部署不上”，但文章标题写的是“VitePress发布流程”，这时可以考虑给文档起别名，或增强同义词替换。第三，检查向量模型是否匹配，有些模型对短文本不友好，或者分块长度超过模型上限导致后半截被截断，这些都是隐性问题。

有一个特别经典的坑：更新了知识库文档之后，问答结果还是旧内容。很多向量库不会自动删除过期文档，而是直接追加新向量，导致旧版本内容仍然能被检索到。解决办法是在写入新文档前先按文档ID删除旧记录。这问题我在Dify升级后也遇到过，后来我都是在同步前做一次明确的清理操作。

4.3 几个RAG实战中的常见报错

下面这几个问题我在不同阶段都碰到过，如果你也在做类似项目，大概率会遇到。

4.4 别急着上Graph RAG和Agentic RAG

热词里经常能看到Graph RAG、Agentic RAG这样的新概念。我建议个人项目先不要追。

Graph RAG确实擅长处理实体关系的多跳推理，比如“张三发明了A技术，A技术被用在B产品里”，但代价是建图、抽取、存储的复杂度都很高，配置不好反而拖慢检索。Agentic RAG更激进，让智能体自己决定怎么检索、调什么工具，数据处理正确性和可控性要求更高，出错时排查的难度也更大。

我把它们当作后续演进方向，但当前阶段先把基础的“检索-重排-生成”链路做扎实，系统稳定了再考虑升级。做工程切忌一上来就想着用最先进的架构，先用简单方案跑通再谈优化。

5. 踩坑实录与我的复盘硬经验

5.1 这套方案真正值钱的三个资产

复盘下来，这个项目给我留下的不只是两个可运行的系统，而是三样能复用的东西。

第一是内容资产。我在搭知识库的过程中，把散落在各个地方的文章、笔记、代码片段全部集中整理了一遍，格式统一了、元信息补全了，这些内容本身就是长期积累的财富。

第二是调试方法论。对于“AI生成代码”和“RAG问答效果”这两件不确定性强的事，我形成了固定排查顺序：先缩小问题范围，再分模块打日志验证，最后才改参数或重构。这套方法用到其他项目中同样有效。

第三是提示词资产。我给AI编程、给RAG生成、给知识库问答都写了一套稳定的提示词模板，后续再开新项目可以直接复用，不用从零摸索。

5.2 哪些环节别迷信AI自动完成

我虽然一直在用AI编程，但有几个环节坚持人工把控。

安全相关配置不能全部交给AI。比如API密钥、数据库密码、服务器防火墙规则，这些让AI自动生成有风险，万一它把密钥硬编码进前端代码，或者把端口完全对外开放，后果不堪设想。

数据处理细节也不能全权交给AI。文档清洗、切分策略、元信息格式，这些需要结合自己的内容特点来定，AI不了解你的业务背景。你可以让AI生成代码，但清洗规则如何定、保留哪些字段，必须自己决定。

部署上线流程建议手动走一遍。我第一次用AI写Dockerfile和Nginx配置，结果端口映射写错，容器内部服务监听在127.0.0.1上，外面一直访问不到。手动过一遍部署流程，能让你对系统每个环节有一个明确的认知，出了故障也不至于慌。

5.3 我的几点真心体会

这个项目做完之后，我最深的体会是：工具进步改变的只是体力部分——生成代码、跑通流水线、组合组件，这些确实快了很多；但真正决定上限的，还是你自己对内容的理解和对问题本质的把握。

小技巧我再分享一个：如果你在调RAG效果时始终不满意，不妨试试把用户问题改写成更标准化的一句描述再检索，比如用户问“博客打不开怎么办”，先让模型生成一句改写：“如何解决博客无法访问的问题”，再做向量检索。这个简单的先改写后检索技巧，往往比换模型、调参数更能带来惊喜。

最后，我建议大家不要把知识库当成一次性的项目来做，它就是你的第二大脑，需要持续往里喂内容，定期清理失效信息，重新评估检索效果。随着文章越来越多，你会发现知识库的价值不是线性增长，而是滚雪球式的增长。