1. 项目全景我在搭一个什么样的“博客知识库”1.1 一句话讲清项目在做的事我给自己定了这样一个目标用AI编程把一个博客站点从零搭起来并且让博客自带一个能问答的RAG知识库。这个知识库不是花架子而是要真的能回答我积累的文章、笔记、技术资料里的具体问题。简单拆一下就是两件事。第一博客本身得有内容展示能力能写文章、能归档、能搜索最好还好看。第二博客里要挂一个对话入口用户问了问题之后系统先去知识库里检索最相关的片段再让大模型基于这些片段生成回答。整个过程跑通之后我的博客就不只是“展示文章”而是一个能主动答疑、能沉淀知识的站点。1.2 为什么值得做一次这样的实战我观察到一个很普遍的现象很多人写了大量技术文章、积累了海量本地笔记但真到要找某个结论的时候还是靠CtrlF或者凭记忆翻目录。博客更惨文章多了之后访客根本不知道你写过什么搜索框一搜还经常搜不到重点。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实战笔记 二级标题向量化流程 正文第一步将文本转成向量... 切分结果块1RAG实战笔记 向量化流程 第一步将文本转成向量...这个结构能让检索结果自带“出处上下文”生成阶段引用起来也更准确。做这块时我直接用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实战中的常见报错下面这几个问题我在不同阶段都碰到过如果你也在做类似项目大概率会遇到。问题现象解决办法向量库索引为空检索结果为空问答答“不知道”检查文档解析是否有报错确认切分后块数量大于0回答明显照抄某段话答案长而空洞没有归纳检查上下文是否过多降低TopK或调整提示词引用来源与回答无关模型用别的片段撑答案提高上下文精确率优先用重排序过滤Dify升级后无法保存知识库修改知识库报Internal Server Error升级后重置向量库索引参数尤其是模型维度配置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效果时始终不满意不妨试试把用户问题改写成更标准化的一句描述再检索比如用户问“博客打不开怎么办”先让模型生成一句改写“如何解决博客无法访问的问题”再做向量检索。这个简单的先改写后检索技巧往往比换模型、调参数更能带来惊喜。最后我建议大家不要把知识库当成一次性的项目来做它就是你的第二大脑需要持续往里喂内容定期清理失效信息重新评估检索效果。随着文章越来越多你会发现知识库的价值不是线性增长而是滚雪球式的增长。