手把手开源构建AI学习资源聚合站：语义搜索+RAG问答系统实战

从“让AI课程卖家集体失业”这个标题聊起吧。事情其实没有标题那么夸张，但背后的逻辑我很认可：现在市面上的AI课程，真正有干货的占比不高，大量内容只是把官方文档、开源社区帖子重新拼凑一遍，再包装成“199元带你精通ChatGPT”的付费产品。我见过太多朋友花了大几百块，买回来的课程里连一个能运行的代码示例都找不到。我们自己踩过这个坑，当时就在想，能不能用技术手段把这件事彻底颠覆掉——把所有散落在各处的AI学习资源（开源项目、论文、官方教程、优质博文、视频切片）聚合起来，再用AI做语义检索和问答，让学习者不花一分钱就能拿到比付费课程更精准、更完整、更及时的学习路径。这个想法最终变成了一个开源网站，前后爆肝30天，目前所有代码、数据库结构、部署脚本都公开在仓库里。文章下面我会把这个项目的整体设计、技术选型、核心功能实现、部署记录和踩坑实录完整拆一遍，想自己搭一套的朋友可以直接照着抄作业。

1. 项目整体设计与思路拆解

1.1 核心需求：贩卖焦虑的问题与去中心化的解法

先说清楚我们到底在解决什么问题。AI领域的信息更新速度已经不能用“按月”来计算了，基本是“按周”甚至“按天”在变。GPT-4o刚火没几天，Claude的新模型又出来了；今天还在学Stable Diffusion的提示词写法，明天ComfyUI的工作流已经完全换了套逻辑。这种环境下，传统的“录播课程”有天然的硬伤：录制成本高、更新周期长，等课程上线，里面的工具可能已经大版本迭代了两三轮。更麻烦的是，绝大多数课程是“转述”而不是“原创”，讲师自己可能都没跑通一遍完整流程，学生在实战环节遇到问题，根本得不到有效解答。

我们想做的是一个“活的”学习资源库——它不再依赖某个人、某家机构去持续生产内容，而是把全网已经存在的优质内容自动聚合、结构化、再通过AI接口做语义组织和分发。这个思路用一句话总结就是：与其教人钓鱼，不如把地图、渔具评测、实时鱼情数据和钓法视频全部开源摆到台面上，让每个人自己成为钓鱼高手。

这个逻辑对应到技术层面有三件事要做：数据采集与清洗、内容结构化与索引、智能检索与问答。数据采集解决“内容从哪来”的问题；结构化解决“内容怎么组织”的问题；智能检索解决“用户怎么找到自己需要的那段内容”的问题。三个环节环环相扣，任何一个掉链子，整个体验都会崩。

1.2 为什么选择开源而不是做成商业产品

这里有个很现实的考量。如果把这个网站做成商业化产品，卖会员、卖企业版，产品逻辑马上就会变质——为了制造付费点，你就得刻意把免费功能做弱，把内容藏起来一部分，甚至引入“限时免费”“专家一对一”这类销售话术。这跟我们的初衷是冲突的。

开源意味着三件事。一是透明，所有推荐算法、采集规则、数据来源都是公开的，任何用户都可以审查这网站是不是在夹带私货；二是可持续，就算我们这个几个维护者某天没精力了，社区里的开发者可以fork一份继续维护，项目不会因为单点故障死去；三是信任，GitHub上有几百个star和issue记录，用户能直观看到这个项目是活的、有人在认真维护的，而不是一个装完就跑路的商业噱头。

当然我承认，这里也有私心。开源项目的简历含金量比“自己闷头做了一个网站”高得多。你的代码风格、架构决策、文档能力、社区协作能力全都会暴露在代码审查者面前，这些细节恰恰是面试官最看重的东西。

1.3 30天工期是如何拆解的

30天听上去很猛，实际拆到周，压力就不那么大了。第一周主要跑通核心链路：爬虫采集、内容解析、基础前端列表页；第二周死磕语义检索和问答系统，这是项目体验的分水岭；第三周做用户系统和学习路径功能，同时优化移动端；最后一周集中做开源相关的工作——整理代码、写文档、录制演示视频、发Hacker News和V2EX。整体节奏大概是四六开，前40%的时间在搭地基，后60%的时间全在打磨细节和收尾工程化。

我觉得很多人做个人项目失败的原因不是技术不行，而是把工期排得太理想化。你以为一周能完成的事，实际可能要两周；你以为不重要的边缘功能，实际会消耗你大量时间。所以我在排期时专门留了两天的“缓冲时间”，专门用来应付那些意料之外的破事。事实证明这个决定极其正确，因为我们在接入向量数据库时出了一个非常恶心的兼容性bug，修掉它刚好用了两天。

2. 技术选型与架构设计

2.1 前后端技术栈的取舍

技术栈上我们没有追求“大而全”，而是选了“熟且够用”的一套组合。前端用的Next.js，顺手解决了SSR（服务端渲染）的问题，爬虫抓到的页面可以直接拿到完整HTML，利于SEO；后端接口也是Next.js的API Routes，前后端一套TypeScript代码，类型定义可以共用，省掉了不少联调时间。数据库用的PostgreSQL加上Prisma ORM，主要看重它的生态成熟度和JSONB字段的支持，后面存课程元数据时特别方便。

搜索这块我们用了Meilisearch，一个轻量级的开源搜索引擎。选它而不是Elasticsearch，原因是我们的数据量远没到ES需要出场的量级，而Meilisearch的部署极简、索引配置友好，还自带一个开箱即用的前端搜索框组件。有一个指标我记得很清楚：全库大概5万条资源记录，Meilisearch的搜索响应时间稳定在30毫秒以内，这个性能对当前体量绰绰有余。

2.2 嵌入模型与大模型问答的接入思路

语义搜索和问答功能是整个项目的智能核心，这里牵涉两类模型调用：一类是嵌入模型（Embedding Model），负责把文本转换成向量；另一类是生成模型（Chat Model），负责做问答式交互。嵌入模型我们选了开源的BGE-M3，中英文混合场景下表现不错，而且支持1000+ token的长文本，省掉了不少切片预处理的麻烦。在生成模型这一层，我们没有自己部署大模型——那需要GPU成本，个人开发者扛不住——而是通过API方式接入多个主流大模型，做成一个可替换的Provider层。

这个设计是经过考虑的。大模型领域的竞争极其激烈，今天你接的A家模型可能是最优解，三个月后可能就被B家超越了。我们把供应商抽象成统一接口，切换模型只是改一行配置的事。这里顺便说一个重要心得：不要把业务逻辑和某个特定模型的细节耦合在一起。比如你不能在代码里写死“ChatGPT返回的JSON格式”，因为不同模型对指令的遵循程度天差地别，必须做一层针对性的解析容错。

2.3 数据采集与内容清洗的架构

数据采集这块，我们做了三层级的设计。第一层是“源头管理”，不是写死一堆URL去抓，而是维护一个站点配置表，里面记录每个来源站点的抓取规则、更新频率、内容选择器；第二层是“解析与抽取”，用Readability类算法提取正文内容，再用规则引擎去掉导航、广告、推荐位这些噪音；第三层是“归一化与入库”，统一转换成标准化的Markdown格式，打上标签、提取摘要、生成向量，最后写入数据库。

内容清洗的重要性比大多数人想象得大得多。早期我们偷懒，直接用正则清理HTML，结果正文里残留了一大堆“点击查看高清大图”之类的站内推荐文案，被投喂给嵌入模型之后，检索出的内容乱得像一锅粥。后来改成两步走的方案：先用Readability算法抽取正文，再用大模型做一次结构化清洗。虽然成本稍微高了一点，但内容质量的提升立竿见影。

3. 核心功能实现与系统亮点

3.1 全网AI课程聚合与智能索引

这个模块解决的问题非常具体：AI相关的学习资源分布得极度分散，GitHub上有项目文档，知乎上有深度解析，YouTube和B站有视频讲解，Twitter/X上有零碎的实战心得，官方博客有最新的模型说明。普通人靠搜索引擎只能捞到最表层的一层，而且搜索结果经常被营销号内容污染。我们的聚合机制就是要做一次“内容蒸馏”。

具体实现上，每条内容入库时都会打上三层标签：领域标签（大模型应用、Agent开发、模型微调、多模态等）、难度标签（入门、进阶、高级）、资源类型标签（文档、视频、代码、论文）。这三层标签是后续做筛选和推荐的基础。另外每条内容都会生成一段由大模型总结的“TL;DR精华摘录”，用户在列表页就能快速判断这条内容值不值得点进去，体验比传统的博客RSS阅读器好一个档次。

3.2 语义搜索：从关键词匹配到意图理解

传统搜索的关键词匹配模式有一个反直觉的缺陷：用户搜“怎么让AI写文案”，字面上并没有包含“Prompt Engineering”这个词，但语义上它的确是和提示词工程高度相关的内容。普通搜索引擎会把包含“Prompt”的结果排后，而我们的语义搜索能做到“理解意图”。

这个交互效果是这样实现的：用户输入问题，系统把问题转换成向量，然后跟内容向量库做余弦相似度计算，取Top-K结果。但这里有一个重要的细节——纯向量检索有时会出现“语义相似但实际无关”的尴尬情况。比如用户搜“扩散模型原理”，向量检索可能返回“扩散模型的商业应用案例”，这两者在语义空间确实挨得很近，但前者问的是理论，后者讲的是商业，根本不是用户想要的。所以我们在最终版本里采用了混合检索方案：关键词匹配（基于Meilisearch）和向量检索并行执行，再用RRF（Reciprocal Rank Fusion）算法把两者结果融合重排。这个策略让搜索准确率提升了将近20个百分点。

3.3 基于大模型的AI学习助手

AI学习助手是我们全项目里最有“杀伤力”的功能，也是标题里“让课程卖家失业”的最有力支撑。市面上的付费课程往往是“老师讲学生听”的单向输出，哪怕有答疑群，响应速度和质量也都不可控。我们的做法是做一个7x24小时在线的智能问答系统，让用户就具体问题直接提问，回答内容结合检索到的具体文档上下文生成，全程可溯源。

这个系统的核心是RAG（检索增强生成）架构，处理流程分四步：query理解、知识召回、上下文组装、答案生成。回答后面会附带引用来源列表，用户可以直接跳转到原文对应段落核验——这一点特别重要，因为AI幻觉是不可避免的，哪怕强如GPT-4也偶尔会一本正经地胡说八道。有了引用溯源，用户就能自己判断回答的可信度，而不是盲信AI输出。

从产品角度看，我们还做了一些巧妙的细节设计。比如把问答分成两种模式：“速答模式”适合只想快速了解某个概念的场景；“深度模式”会生成结构化的长文答案，适合系统性学习的场景。用户可以根据自己的实际情况随时切换。

3.4 个性化学习路径生成

这个功能解决的是“我知道要学AI，但不知道从哪开始”的典型场景。传统做法是给所有用户推荐同一条学习路径——比如“先学Python、再学机器学习、再学深度学习、再学大模型应用”——问题是每个人的基础不同、目标不同，统一路径的效率其实很低。

我们基于用户画像和资源标签的关系网络，实现了一个简单但有效的路径生成器。用户先做一份简短的测评问卷，系统会根据用户现有基础和目标自动生成一条学习路线图，每个节点对应一个具体的开源项目或教程，并标注预计耗时和难度。这个设计背后的思路是“先跑起来，再优化。”我们没有一开始就上复杂的图算法，而是先用规则约束生成初步路径，后期再基于用户反馈数据持续调整。

3.5 代码级示例：学习路径生成的核心实现

技术方案说多了容易飘，下面贴一段实际的核心代码，展示学习路径生成是怎么从设计落到实现的。

// 资源难度与用户水平的匹配函数 const DIFFICULTY_WEIGHTS = { beginner: 1, intermediate: 2, advanced: 3, }; function matchLevel(userLevel: string, resourceLevel: string): number { const diff = Math.abs( DIFFICULTY_WEIGHTS[userLevel] - DIFFICULTY_WEIGHTS[resourceLevel] ); // diff=0 完美匹配，diff=1 建议搭配辅助材料，diff>1 不推荐 return diff; } // 依据用户目标构建学习路径 export function buildLearningPath(userGoals: string[], allResources: Resource[]) { // 1. 根据目标标签过滤候选资源 const candidates = allResources.filter((r) => userGoals.some((goal) => r.tags.includes(goal)) ); // 2. 按难度梯度排序，确保低难度资源优先 candidates.sort((a, b) => a.difficulty - b.difficulty); // 3. 折线式游走，保证路径连贯性 const path: Resource[] = []; let cursor = 0; while (cursor < candidates.length) { const current = candidates[cursor]; path.push(current); // 跳过与当前难度差值大于1的资源（请勿连续跳级） const nextIdx = cursor + 1; if (nextIdx >= candidates.length) break; const diff = matchLevel(current.difficulty, candidates[nextIdx].difficulty); cursor = diff > 1 ? cursor + 2 : nextIdx; } return path; }

这段代码的核心算法其实非常简单——先过滤、再排序、最后做“梯度游走”。你可能会问，为什么不用复杂的图搜索算法？因为对MVP（最小可行产品）来说，简单规则就已经能产生不错的效果，真正的瓶颈在于数据的完备性：只要资源标签和难度标注是准确的，简单的规则都比复杂算法更稳定。我们更愿意把时间花在数据治理上面。

4. 实操搭建与部署全记录

4.1 本地开发环境快速启动

如果你想把这个项目拉到本地跑起来，准备工作非常简单：Node.js 20以上、pnpm包管理器、Docker。项目根目录下有个Makefile，里面封装好了常用命令，依次执行两条命令就能完成基础环境搭建。

make setup # 安装依赖并生成Prisma客户端 make dev # 启动Next.js开发服务器（默认端口3000）

这里有一个必须提前说的坑：Prisma的Schema文件里写好了PostgreSQL连接串，但如果你本地没有PostgreSQL实例，就得先用Docker把数据库拉起来。

docker run --name ai-courses-postgres -e POSTGRES_PASSWORD=postgres -p 5432:5432 -d postgres:16

注意密码要跟.env文件里的DATABASE_URL保持一致，否则后面跑迁移时会一直报连接错误，而且报错信息不会直接告诉你“密码不对”，而是给一个相当迷惑的“数据库不存在”，排查起来特别浪费时间。第一次接触这个项目的新手大概率会卡在这里。

4.2 Docker Compose一键部署流程

项目根目录提供了一个docker-compose.yml，里面编排了四个服务：前端应用、PostgreSQL数据库、Meilisearch搜索引擎、以及一个用于内容采集的爬虫Worker。部署过程就是一条命令：

docker compose up -d

四个容器启动之后，应用会自动执行数据库迁移，并把内置的种子数据写入索引。首次启动需要一些时间，因为Meilisearch要构建向量索引、PostgreSQL要初始化数据表。建议观察一下日志再继续操作：

docker compose logs -f app

看到Ready字样后，访问服务器IP的80端口就能看到站点首页。整个部署过程的依赖项非常少，只需要服务器上装了Docker和Docker Compose插件。这套方案的好处是不需要对服务器环境有太深的理解，一台最低配的2核4G云服务器就能撑起中小规模的访问量。

4.3 部署后的初始化与数据导入

首次部署完成后，站点是一个空壳，需要导入数据才能真正用起来。我们提供了一个命令行工具来做这件事，它会自动抓取配置好的源站点列表，完成采集、清洗、向量化、入库的全流程。

pnpm run crawl:full

如果是跑全量采集，我的建议是先设置数据源数量上限，例如只跑前5个站点，确认采集结果的质量没问题，再放开全量跑。否则可能出现一种情况：某个目标站点的页面结构已经改版，我们的解析规则不生效，结果采集回来的内容全是空正文或乱码。一次性灌进库里之后，想再清洗就麻烦多了，你会发现检索效果变差，但很难快速定位到具体是哪条脏数据引起的。

4.4 成本测算与性能调优

老有人问“跑这样一个网站一个月要多少钱”，我按最低配置给一个真实的账单参考。服务器用最普通的2核4G云主机，如果带宽按量计费，一个月在50元左右；PostgreSQL和Meilisearch直接部署在同一台机器上，省掉了单独云数据库的费用；对象存储暂时不需要，用户上传头像做成纯前端生成，不占资源。真正的大头是大模型API的费用，但这取决于问答功能的调用量。

我们做了两个优化来控成本：第一，问答结果做24小时缓存，完全一样的问题直接命中Redis，不重复调用大模型；第二，向量化过程做成离线批量任务，而不是每次用户访问时实时生成，避免高频调用收费接口。实测下来，在日活500左右、日均问答量不到200次的规模下，API费用每个月控制在100元上下。

5. 踩坑实录与常见问题排查

5.1 向量化过程中“中文分词”的坑

这是一个绝对值得单独拿出来说的问题。我们一开始做内容向量化时，直接用英文技术社区惯常的token切分方式处理中文文本，结果中文内容的检索质量差到不能看。问题出在中文没有天然的空格分词规则，“基于大语言模型的自然语言处理”这句话，按空格分词会整句卡成一个token，语义表达能力完全丧失。

后来换了两步方案。先用专门的tokenizer做中文切词（我们用了一个轻量级的jieba库，后续有条件再换更准的切词模型），再把切分后的词序列喂给嵌入模型。就这么一个改动，中文内容在检索命中率上提升得非常明显，相似度分数从平均0.3直接提高到了0.7以上。如果你的内容库以中文为主，千万不能直接照搬英文场景的pipeline。

5.2 大模型接口限流与缓存策略

问答功能上线后的第一周，我们接到一个莫名其妙的用户反馈：“AI助手回答速度越来越慢，经常转圈不动。”查了日志才发现，不是模型推理慢，而是本地服务器出口IP触发了上游API的限流阈值，大量请求排队等待，表现为“卡死”。这个问题的根源在于我们没有对问答接口做任何限流保护，热门话题一冲过来，瞬间把免费配额打爆了。

解决办法分了三层：最外层是Nginx层面的IP限流，单IP每分钟最多10次问答请求；中间层是针对常见问题做哈希缓存，重复问题直接走缓存；最内层是对大模型Provider做多账户负载均衡，把压力分散到不同APIKey上。三层叠加之后，问答服务的可用性从94%提高到了99.7%以上。

5.3 版权与审核机制应该怎么处理

做内容聚合网站，版权和合规问题绕不开。我们的策略是比较保守的三条：第一，只索引站点的公开内容，不爬取需要登录或付费才能访问的内容；第二，每一条数据都保留完整原文链接，网页头部明确标注“内容索引来源”；第三，接收原作者的删除请求，提供一个简单的“内容下架”表单，确认身份后24小时内处理。

从合规角度讲，做内容聚合平台最忌讳的就是“不写来源直接转载”。搜索引擎是最基础的流量来源，但你转发得越彻底，被投诉下架的风险就越大，模板站越多，站点的信任度就越低。宁可牺牲一点用户体验，也要把来源链得足够清晰。这一点我从第一天起就坚持了。

5.4 常见问题速查表

5.5 推荐一次干净的部署路径

如果你之前没有部署过这类项目，我推荐一个最省心的路径：先用宝塔面板装好Docker环境，再通过面板创建站点绑定域名，最后在站点根目录执行docker compose up -d。不要一开始就折腾K8s、CI/CD那些东西，这个项目完全不需要那么重的架构。跑通之后再根据实际需求慢慢加Nginx反向代理、HTTPS证书和CDN加速。

我自己在实际部署时踩过一个低级但又很典型的坑：域名解析已经生效了，但服务器安全组没放行80端口，结果外部访问一片红。这种事不用慌，按顺序排查就行——先ping域名看解析是否正常，再curl localhost:80看本机能否访问，再telnet 服务器IP 80看端口是否放行。三个测试做完，问题定位一目了然。

写在最后：项目后续还能怎么玩

我个人在这30天里学到的最深一课是：开源项目的竞争力从来不在于某个单一的“爆点功能”，而在于它的迭代速度、社区信任度和生态丰富度。功能抄袭的成本极低，但一个公开的issue列表、一堆真实的用户反馈和连续30天的re-release记录，这些东西是难以复制的资产。

如果你打算把这个项目拿来自用或改成自己的作品集，我建议可以顺着三个方向继续扩展。第一，把学习路径模块做得更聪明，引入真实用户的学习进度数据，结合强化学习做动态路径调整；第二，增加一个“笔记分享”功能，让用户在学习资源页面上直接做高亮和批注，形成一个轻量级的社交学习空间；第三，做一个浏览器插件，用户在浏览任意网页时能一键把这个页面内容纳入索引，这样信息聚合的覆盖范围就不再局限于我们预先配置的站点列表了。

这个项目对我来说最大的意义是验证了一件事：只要工具链足够成熟，单枪匹马在30天内交付一个高质量的AI应用是完全可以做到的。大模型时代对个人开发者最友好的地方就在于——你不再需要一个大团队的资源来构建有竞争力的产品，AI已经帮你把基础能力补齐了。剩下的，是你愿不愿意开始动工。