企业官网建设流程全解析

朋友们，我今天想聊聊最近这段时间我折腾的一个项目：AI编程实战：博客建站+RAG知识库。简单说，就是让AI帮我写了一个带个人知识库的博客网站，同时给这个博客接上了本地私有的RAG知识库，让它能回答我博客里的历史文章问题。这个东西解决了什么呢——过去博客是单向输出，文章写完就躺尸，读者想提问只能靠评论区猜；现在我自己搭了一个能反问、能归纳、能按需检索的智能助手。适合谁参考？想用AI辅助开发但又不知道怎么从零把项目落地的程序员、想给个人站点加“大脑”的内容创作者、以及被“RAG知识库”这个词吊胃口但不知道真实上手流程的爱好者。

我不讲虚头巴脑的架构图，也不搞那种看一眼就关掉的PPT演示，就讲我在实际操作中是怎么一步步把博客和RAG知识库揉在一起的，中间踩了哪些坑、改了哪些方案、最后跑通了什么效果。整个项目我自己全程跟下来，说实话，有几个关键时刻我真差点放弃，但咬牙搞定之后回头一看，这事的门槛其实没有想象中那么高，关键是走对路线。下面开始。

1. 内容整体设计与思路拆解

1.1 为什么非要把博客建站和RAG知识库放在一起

先说个很现实的痛点。我自己写博客写了几年，后台数据说话——真正能沉淀下来的，不是某篇爆款文，而是你在不同文章里反复用到的那套方法论。但当你写了几百篇文章之后，问题就来了：你自己都记不住哪篇讲过什么了。而读者更惨，他可能意图非常明确，就想知道“你这个项目的权限设计怎么做的”，结果搜出来的是一堆关键词匹配到的文章片段，根本没有上下文。传统的博客站内搜索，靠的是关键词匹配，搜索引擎的行为模式是“给你一堆可能相关的链接”，而不是“直接给你一个明确的答案”。

RAG，检索增强生成，就是来解决这个问题的。我一开始的理解很粗浅，以为RAG就是把文档切碎了丢给大模型让它“读”。实际动手之后才发现，RAG的核心不是生成，而是检索。它真正解决的问题不是让模型多聪明，而是让大模型在回答之前，先从指定知识库里找到正确答案的依据，再基于这个依据进行组织语言。这等于你不光在博客站面上放了一个灵巧的嘴，还给它配了个只看过你文章的脑子。

所以当“AI编程”这个概念火起来的时候，我就在想，能不能让AI编程工具直接帮我写博客样板代码，然后我再手工把RAG知识库的接口给接进去？毕竟现在AI编程工具的能力大家有目共睹，让它写一个基础的博客框架、增删改查、路由渲染，效率远高于手动敲。但博客好写，知识库才是真正的核心难点。两个系统对数据的需求、处理流程、存储结构完全不一样，怎么融合，需要提前想清楚。

1.2 方案选型：不是“All in”而是“分层组合”

这里先明确一个观念：不要指望一个工具把所有事都干了。市面上有不少所谓的“一体化知识库平台”，确实开箱即用，但问题在于它的数据结构和你自己博客的文章格式是割裂的。你在博客里写了50篇文章，平台能帮你导入，但导入之后，它只负责建立向量索引和问答，博客本身的展示、路由、评论还得你另外写。最终我确定的分层组合方案是这样的：

• 博客层：用AI编程工具生成管理后台和展示前台，技术栈选择了Next.js，因为项目是内容型网站，服务端渲染对SEO友好。
• 数据层：在本地维护一个统一的Markdown仓库，每篇博客文章都有一个独立的.md文件，头部写meta信息，正文是纯Markdown。这个仓库既能直接作为博客文章源，又能作为知识库的文档源。
• 知识库层：搭建了一个本地RAG服务，核心流程是加载文档、切分文本、向量化、存储到向量数据库。博客内容入库后，通过一个聊天窗口进行问答交互。

当时我也考虑过直接上一个现成的开源知识库项目，比如Dify或者FastGPT，它们对RAG流程集成的很好，很多参数都给你配好了，界面也友好。但我作为一名称职的博主，还是希望对底层有掌控感，因为博客文章的增量更新、删除、修订，这种强耦合的数据变动，如果我完全依赖平台，想做点个性化的逻辑反而会处处受限。所以最终的方案是：博客系统全权交给AI编程工具，RAG部分我半手写半调用现成组件。

1.3 为什么这个搭配能产生“1+1>2”的效果

单独建站和单独搭知识库，网上教程都一抓一大把。但如果你把二者打通，你会得到一个真正意义上的“会思考的个人网站”。读者看文章时有疑问，不用去搜索引擎碰运气，直接问站内的知识库助手，它能基于你的全部历史文章内容组织回答，还会附上相关文章链接作为引用。这对于一个内容创作者来说，是一种粉丝沉淀和内容二次消费的良性循环。

从本质上说，这套组合就是给博客装了“上下文记忆”。博客站本身是静态展示，是“死”的；RAG知识库是活的，它知道用户问题背后的意图，并能从大量文章里筛选出相关信息，生成一个没有幻觉、有根有据的回答。而且我实测下来有一个很惊喜的点——当知识库覆盖文章数量足够多时，它甚至可以帮你串联起自己忘记写的思考链条，比如某篇文章里提到过一个概念，你当时一笔带过，但知识库回答的时候，会自动把另外一篇详细解释这个概念的段落给捞出来。用AI编程快速搭骨架，用RAG把灵魂装进去，这就是这个项目的全部意义。

2. 核心细节解析与实操要点

2.1 博客建站里的AI编程实战细节

我用AI编程工具的时候有一条原则：小步快跑，逐块生成，绝不让AI一次性生成一整个项目的全部代码。刚开始试时我让它直接来一个完整项目，结果代码结构非常漂亮，但完全没法在本地跑起来，依赖冲突、环境变量缺失、路径命名不一致，反反复复改了半小时。后来我调整了做法，把博客网站拆成几个子任务：

• 第一步，让AI生成整个项目的目录结构，并跟我确认技术栈和关键细节。
• 第二步，生成Markdown文件的解析工具类，要求返回标题、日期、分类、标签、正文内容。
• 第三步，生成文章列表页和详情页的路由组件。
• 第四步，生成标签聚合页面和RSS订阅入口。
• 第五步，把RAG服务封装成一个可调用的API接口模块。

这个方法很笨但非常有效，每生成一个模块，马上跑一个最小可用场景，有问题当场把它指出来让AI改。我第一次用这个方式写博客，从零到文章正常展示只花了一个半小时。而且整个过程中AI编程工具扮演的是“熟练但粗心的助手”，它写代码速度快、整体思路成熟，但经常出现局部细节错误——比如Next.js的App Router里fetch请求返回了undefined，它居然忘了await。这种问题如果你不仔细测试，线上就等着白屏吧。

所以给第一次尝试AI编程的朋友一个建议：把AI当成需要review的初级程序员，而不是全自动外包团队。你给它拆好任务、写好验收标准，它才有可能输出高质量的东西。另外提示词越具体越好，比如“用TypeScript实现一个从Markdown文件解析出frontmatter字段的函数，错误时返回空对象而不是抛出异常”就比“写一个Markdown解析器”好上一百倍。

2.2 RAG知识库的几个技术细节关键点

聊到RAG，就不得不面对一个现实：知识库的效果，多半在开始写向量化代码之前就注定了。为什么？因为RAG的检索效果极大程度上依赖三个环节的质量——文档切分、向量化模型选型、检索策略。

先说说文档切分，这个最容易被人忽略。最开始我图省事，直接把几百篇博文每篇整篇丢进去做embedding，结果问答效果稀烂。原因很简单：一篇2000字的文章，embedding之后是一个高维向量，这个向量表达的是整篇文章的“主题”，但当用户只问其中一个小点时，检索到的内容里杂讯太多，大模型根本抓不住重点。后来我改成按段落切分，并对段落做了重叠处理——前一段和下一段的最后一句会重复，确保上下文衔接不断裂。这个改动带来的效果提升非常明显：回答准确率起码提升了一倍以上。

接着是向量化模型选型。本地部署我试过几种，有便宜大碗的bge-m3，有轻量句子模型，后来还是选了效果最稳定的。我做的对比很简单，准备30个关于博客文章内容的问题，分别用两个模型检索，看谁召回的相关段落更准。最终测试下来，中文长文本上，bge-m3这类的综合效果确实能打，而且它对硬件要求不高，CPU也能跑，只是稍慢。如果你追求极致的检索性能，还可以考虑重排模型，就是在向量召回之后再精排一遍，让结果更精准。

检索策略上，这里重点展开一下，因为很多人对RAG的理解就在“向量检索”四个字上面。向量检索的实际工作方式是：把用户的问题转化成query向量，然后在向量数据库里找余弦相似度最高的Top-K个向量及其对应的原始文本块，再把这些文本块拼接到Prompt里喂给大模型。这个流程很简单，但要注意一个问题：纯向量检索会漏信息，尤其是用户问题里的关键词可能跟知识库里术语不一致时，效果就一言难尽了。所以我最后采用的方式是“混合检索”：先用BM25做关键词匹配，再用向量做语义匹配，最后把两路结果合并去重，再做重排。这么做，精确匹配和语义理解两头都占，是什么体验呢？过去问“Next.js的SSR和SSG有啥区别”这类问题时，纯向量检索经常抓到一篇讲部署的文章，混合检索就精准得多。

2.3 对比一下我实测过的几个主流RAG框架

我在落地RAG功能之前，把主流的开源框架都试了一圈，各有优劣，这里放个对比表：

我自己最终是回归到了“自研Embedding+检索脚本”这条路。原因是LangChain封装得太重了，它的抽象层级很多，出了问题排查的时间远远超过自己手搓代码。LangChain的好处是代码结构标准化，方便社区交流；但劣势也很明显，就是把简单的事复杂化了——同一个功能我写原生代码50行能搞定，用LangChain光组装Chain就要折腾半天。这里也不是劝退谁，如果你刚入坑，想快速看到RAG工作起来的样子，Dify是很好的选择，尤其它的知识库流水线做的很直观；但如果你像我一样，知识库要跟自己的博客CMS深度绑定、想做个性化逻辑，那自己写一遍流程才是真捷径。

3. 实操过程与核心环节实现

3.1 第一阶段：用AI编程快速搞定博客骨架

整个项目的动手顺序非常重要，我建议先做博客，再做知识库，最后打通。先做博客的好处是，你能立刻获得一个可感知的成果，不至于在知识库环节卡壳时士气全无。

当时我直接打开AI编程工具，在项目目录里敲了一长串需求描述：

使用 Next.js 14 + TypeScript + Tailwind CSS 搭建一个个人博客站点： - 文章以 Markdown 文件存储在本地的 content/posts 目录 - 每篇文章 frontmatter 包含 title、date、tags、description、cover - 有首页文章列表、文章详情页、按标签筛选页面 - 支持 RSS 订阅生成 - 输出代码时附带必要的文件结构说明

AI很快生成了一整套项目代码。我要做的就是把每个关键文件检查一遍，删掉几个它“自作聪明”多加的依赖，修几个类型报错，然后本地启动v1.0上线跑通。这个过程可以说既有惊喜也有惊吓，惊喜的是它的组件写法非常娴熟，页面结构合理，而且Tailwind的样式也省了我好多事；惊吓的是它用了几个我根本不想引入的第三方库，让我项目一下重了几十兆，果断删。

完成博客展示之后，接着让AI生成一个简单的后台页面，以便后面往content/posts目录里上传新文章时，不用手动开编辑器写文件。这个后台的功能也极其简单：标题、分类、标签、Markdown内容，保存之后就生成一个带正确frontmatter的文件。这个功能建议大家可以加上，因为后面知识库同步内容的时候，你肯定不想再手动去维护目录结构。

3.2 第二阶段：搭建RAG知识库的完整流水线

博客稳定运行之后，才是重头戏：给知识库处理文章。我设计的流水线大概分五步，每一步我都踩过不少坑，一个一个说。

第1步：加载文档。这一步比较简单，就是遍历content/posts目录，读取每个Markdown文件。要注意的是，最好把frontmatter里的title、date、tags、description也读出来，因为在知识库回答问题时引用来源，需要展示文章标题和链接，不能光给一个纯文本块。这里面有个小技巧：Markdown文件内容里如果包含代码块，纯按行切分会切碎代码结构，解决方法是切分之前先对代码块做特殊标记，或者干脆在文本切分器里加一个保护正则。

第2步：文档切分。我默认用markdown头信息+正文分段方式。切分的chunk_size定在500个字符左右，chunk_overlap设定为100字符。这两个参数不是凭空定的，是根据我的文章平均信息密度测试出来的。一般来说，中文场景里500-800字是一个比较适合问答的粒度，太大了信息太泛，太小了上下文不全。注意，如果你文章里表格很多，这个方案是不够的，表格需要单独拆出来处理。

第3步：向量化。把切分好的文本块用embedding模型转成向量。我选的是bge-m3模型，它生成了1024维的向量，配合文档标题、标签、摘要一起做拼接后再向量化。是的，这里我做了一个小优化：知识条目向量不是只基于正文文本，而是把标题、标签、摘要拼接在正文前面一起喂给模型做向量化。这样就相当于给每个段落加了一个“语义前景”，查询时如果用户问的内容跟标签高度相关，就能直接命中。

第4步：存储。向量库我用的本地文件系统方案，最简模式是把向量存成npy文件，加上一个id映射表。项目文章量不大，几百篇文件不上规模时，这个方案确实够用，而且避免了额外部署数据库服务的负担。但如果你文章超过几千篇，我还是建议直接用开源的向量数据库服务，比如Qdrant或Milvus，它们的检索效率高得多。我之所以最终上了向量数据库，是因为测试阶段发现一个真实痛点：npy存法在并发查询时会锁文件，用户同时问几个问题，接口响应就排队了。

第5步：检索+生成。用户提问时，先用同样的embedding模型把query转成向量，然后从向量数据库里检索Top-K=6的候选段落，再用混合检索策略结合BM25的结果，最后交给大模型。Prompt我调成了这个模板：

你是该博客站点的知识助理。请基于以下资料回答问题。如果资料中没有相关内容，直接说明“知识库中没有找到相关内容”，不要编造。 资料： {context} 问题：{question} 回答要求：结论准确、清晰、当涉及文章内容时，注明出处。

这个Prompt看起来简单，但实际上对回答质量的影响比很多人想象中大。加一句“不要编造”就能很大程度上遏制幻觉；加一句“注明出处”就能让回答附上引用文章链接。知识库问答的体验，有一半是由Prompt设计决定的。

3.3 第三阶段：打通博客与知识库

这是整个项目里最爽也最容易翻车的一步。我当时的想法是：在博客页面上加一个悬浮的对话气泡，点开之后就是一个迷你聊天界面，用户输入问题，后端调RAG服务，返回答案及引用文章卡片。

实际开发过程中，遇到最多问题的反而是在接口设计上。最初我想让前端直接调底层向量检索服务，后来意识到这等于把自己的知识库数据裸露给用户，安全性太差。我调整了一下，前端只跟自己的后端API通信，API内部再调用知识库服务，这样用户看到的只是结构化的JSON返回，拿不到向量库的底层数据。这里如果你不在意数据安全，那也无所谓，但个人博客毕竟是公开的，还是应该留个心眼。

整个打通流程，我列了一个近似清单：

1. 确认博客后台里有文章时，自动触发知识库增量更新的逻辑不变——每次保存文章后调用一次知识库更新接口。
2. 博客前端加一个悬浮聊天气泡，通过WebSocket或者轮询方式对接后端API。
3. 后端RAG服务暴露统一API接口请求和响应格式。

我当时直接用AI编程工具，给它参数和接口约定，让它生成前后端代码，结果第一版生成得还挺顺利。唯一的问题是，AI写的前端聊天界面样式不太符合我的审美，字体和间距都有点别扭，让我手动调整了很久。所以一句忠告：AI可以帮你写逻辑，但审美的活儿你就别指望它了。

3.4 效果实测：知识库回答的表现

搭好之后，我拿自己的历史文章做了几组测试。测试1，我问：“文章中针对减少RAG幻觉现象提出了哪些办法？”系统返回了答案，并且自动引用了3篇相关文章，回答内容准确率极高——不是简单复制粘贴，而是把两篇文章里相关的段落整合后重新组织了一遍语言。测试2，我故意问了一个问题“作者最喜欢的咖啡豆种类”，这个内容我的博客里从没出现过。系统正确回复了：“知识库中没有找到相关内容”，没有硬编。这个结果我非常满意，因为“知道自己不知道”对RAG系统来说，是比“能回答”更要紧的能力。

数据召回方面，我用带标签的测试集跑了一遍。30个问题里，有22个准确命中正确答案所在文章，5个命中了相关但不够精确的文章，3个完全没找回。问题出在哪？后续排查发现是文档切分模块把包含多个主题的段落切丢了上下文。优化了切分策略并把重叠字符调大之后，整体准确率从73%提升到了83%左右。

4. 常见问题与排查技巧实录

4.1 AI编程生成代码时的常见问题

问题1：AI生成的代码在本地无法启动。这个是最常见的。原因多半是依赖版本冲突、Node版本不兼容，或者生成的时候就漏了某个配置文件。我的经验是每次生成完，先跑一次npm install和本地构建，有问题直接贴报错信息让AI修。循环个三四次基本能修干净。有一点很重要：每个环节的报错信息，尽量完整地喂给AI，你贴的报错不全，它就只能瞎猜，反而浪费时间。

问题2：AI生成的路由页面总是报hydration错误。Next.js这个框架对客户端和服务端的渲染一致性要求很高，AI经常会写出组件里直接用window、document对象之类的代码，在服务端渲染时直接崩掉。解决方法是让AI把所有浏览器API的调用都放到useEffect里，或者设置动态加载（ssr:false）。

问题3：AI改一个bug结果引入三个新bug。这个很折磨人。尤其是改了几轮之后，AI可能会忘记之前某个模块的设计约束，改乱了一个本来正常的功能。所以我实操时一直坚持“模块级别”的版本管理，每次修改之前，先给AI指定对应的模块文件列表，让它只改这个范围，其他文件不要动。如果改动范围过大，我会直接回滚再换个思路让它重试。

4.2 RAG知识库的几个深坑与排查思路

现象1：知识库更新后，问答还是旧答案。

这个坑绝对排第一。原因通常有二：一是你没有真正触发向量库的更新，新增的文章根本没被切分和向量化；二是你更新了向量库，但检索时用的依然是旧的候选内容。排查思路很简单：去向量数据库里查一下新增文章对应标号的向量是否存在；如果存在，再去看你的API接口是否真的调用到了最新的查询逻辑。很多时候是你在更新接口写了新逻辑，但问答接口那边仍用旧逻辑，两个代码路径没同步。

现象2：RAG的回答经常“张冠李戴”。

比如用户问“这个项目技术栈有哪些”，系统回答引用的却是另一篇文章里的技术栈。我排查之后发现，问题出现在文档切分时，我为了减少块数，把多个不同话题的段落强行合在一个chunk里，导致这个chunk的语义向量偏到了某个话题，另一个话题的细节被稀释了。优化方案是切分逻辑改为按标题分块，同一标题下内容过长的再切小。

现象3：问答时延太长，容易超时。

首次我所有流程都是同步的：用户提问后，要等向量化、检索、大模型生成一系列动作全部完成才返回。实测下来，回答一次大约需要10-20秒，体验很差。后来我改造成异步流程：先返回“正在思考”，同时后台去跑RAG流程，生成完毕再推送到前端。或者你也可以直接上流式输出，让大模型生成答案时一个字一个字地往前蹦，用户心理等待时间会大幅缩短。

4.3 增加一个避坑小贴士：日志与溯源

RAG知识库调试时，你不光要看最终回答的信息，还要看检索到的参考资料到底是什么。所以一定要在调试模式下把每个环节的日志打出来，尤其是：用户问的是什么query、检索到哪些chunk的ID、每个chunk的相似度分数、重排后最终用了哪些chunk、它们来自哪篇文章。这样出了问题时，你可以顺着日志链条一路排查下去。普通模式则关掉详细日志，只保留访问时间和token消耗，免得日志文件疯狂膨胀。

关于这个问题，我还想多说一句：很多人做RAG知识库测了几个问题觉得效果不错就上线了，这其实很危险。因为测试的几个问题往往是你自己顺手想的，你脑子里已经知道了答案在哪篇文章里，所以检索命中率高也是正常的。真正的上线前测试应该让你的朋友来提问，或者拿一批你没参与过写作的文章来做盲测，这样反馈才真实可靠。

5. 进阶玩法：从“能用”到“好用”的优化路径

5.1 优化对话体验与检索精度

RAG知识库跑通基础版之后，想更进一步，提升的点主要在两个方向：对话体验和检索精度。对话体验上，你可以为大模型设计多轮对话判断逻辑——当用户追问“上一题里你说过的那个方案还有别的替代吗”时，系统需要有能力把“上一题”关联到前面某一轮对话生成的引用文章上，而不是开一个全新的、无上下文的搜索。我在实践中是给会话状态加了一个短暂的上下文buffer，把最近两轮的用户问题带进检索层做查询改写。这个方法实现起来不难，但对体验提升非常明显。

检索精度方面，我做的最有效的一件事是加入了“知识库回答置信度”指标。给检索返回的每个chunk算一个平均相似度分数，再映射成一个0到1的置信度值。小于0.3就直接给用户降低期待，回复“这个问题我不太确定，可能会回答得不准”；大于0.7时就直接给详细回答。这个东西很粗糙，但真实使用中至少能让错误的回答少一些，也更符合用户预期。

5.2 善用工具：Dify在知识库流水线中的作用

如果你不想自己写代码，只想快速搭一套完整的RAG知识库服务，我还是很推荐你尝试Dify的。Dify的知识库流水线做了可视化编排，你可以把文档上传、切分策略、索引方式、模型调用、Prompt编排全部用图形化界面搞定。我还特别注意到它内置了“查询重写”、“引用归属”等高级功能，这些自己搓代码要花好几个小时的东西，在Dify里就是点几个开关。看到这里你可能会问，那我前面费那么大劲自己写图什么？图的是自由度和可控性。如果项目要求不复杂、场景又通用，Dify会让你省很多事；但如果你和我一样想把所有逻辑都放在自己的服务器代码里、跟博客系统无缝集成、想查日志就能直接看代码，手写依然是最高效的路径。适合自己的就是最好的。

5.3 其他可以接入的知识库扩展玩法

项目跑顺了之后，我又做了几个小扩展，分享出来供大家参考。一个是把知识库从博客文章扩展到了“笔记系统”，将自己平时记的Obsidian笔记也同步了一份进来。之前我记完笔记基本就不再翻了，但接入RAG之后，想找当时的想法时直接问，比自己翻文件夹快太多。另一个是给知识库加了一个“人工反馈”机制：用户对某个回答不满意时，可以点踩，系统会把这条记录存下来。我定期再去看这些被踩的问题，分析是检索问题还是生成问题，再针对性地调参数。这个循环一旦跑起来，知识库的质量会越来越稳。

6. 最后几个实操经验大总结

这个项目做下来，我个人的几个体会特别深刻。

第一，AI编程工具不是万能的，但它的确把项目启动的成本打到了历史最低。搁几年前，让我花两个晚上从零搭出一个带后台、带Markdown解析、带RSS的博客，还要单独实现一套RAG问答，这几乎是不可能完成的任务。现在AI编程把“从零到上线”这个过程压缩到了一个周末。

第二，RAG知识库的项目，80%的精力要花在数据清洗和切分策略上，而不是模型调用上。很多刚上手的朋友喜欢纠结“该用GPT还是Claude还是国内模型”，实际上等你的知识库文档切分得一塌糊涂时，什么模型来都救不了你。把文本切分、检索策略、Prompt设计这些基本功做实了，才能在模型选择上有腾挪的余地。

第三，本地部署的模型和在线API要搭配着用。纯本地的好处是隐私和数据安全，坏处是速度和效果一般；纯在线API的好处是效果顶。我的建议是把两者组合起来：向量化等数据准备工作，可以放本地跑，便宜又私密；真正生成回答时，选效果最好的在线大模型。这样体验和成本都能兼顾。

我自己的博客+RAG知识库项目，现在稳定运行了几个月了，中间也遇到了升级后配置丢失、向量库索引损坏、Prompt被注入干扰等等问题，但整体上它已经成了我站点里用户互动率最高的功能板块。我真心觉得，AI编程也好、RAG知识库也好，它们不是两种孤立的技术，它们组合在一起能真真切切地改变一个网站、一个创作者的输出模式。如果你也想搭这么一套，别犹豫，按我上面的流程，先跑通一个最小版本，再慢慢雕琢。等你看到自己的知识库第一次准确回答出某个藏在历史文章犄角旮旯里的问题时，那种成就感，是真的会上瘾的。