看到标题点进来的朋友，我猜你的浏览器收藏夹里，至少躺着几十个“AI 神器”的仓库链接——然后呢？然后就没有然后了。收藏不等于会用，星标不等于起飞。我自己早两年就是这个状态：热门 AI 开源项目一个不落，真到要给自己的项目加一个 AI 功能时，连入口都找不到。

后来我换了个思路：不追最热的项目，改追“能串成完整工作流”的项目。先选一个能跑模型的引擎，再选一个能管模型的工具，最后选一个能把它包装成产品的框架，一个一个打通。这篇文章就把我实际用过、踩过坑之后仍然留在工具箱里的 15 个 AI 开源项目整理出来，每个都说清楚它解决什么问题、怎么上手、有什么坑，以及适合谁。以下所有项目遵循同一个原则：单点能用，组合能打。

1. 这 15 个项目是怎么筛出来的：我的选型标准与避坑原则

先说清楚筛选逻辑，不然你又会得到一份“看起来很全、实际没用”的清单。网上一搜一大把“最佳 XX 项目”，大部分是照着热门榜单抄的，把仓库装下来却不知道第一步干嘛，最后必然是吃灰。我筛项目只按四条标准。

1.1 四个筛选标准

第一，生态大于星标。一个项目 star 数高，只能说明它被很多人“看见”过，不能说明它能稳定解决你的问题。我更看重三件事：文档是否完整、社区是否还在更新、依赖是否克制。一个半年不更新、Issue 堆积如山的项目，无论当年多火，我都不敢放进生产链路。

第二，能本地落地优先。AI 项目最怕“云端能用，本地跑不起来”。我筛选时会优先看它是否支持离线部署、是否有 Docker 镜像、是否依赖很重的云服务。不是说我反对用云，而是本地能跑的项目，调试成本低、数据隐私可控，也更适合用来学习原理。

第三，单点能用，组合也能打。只看单个项目好不好用还不够，还要看它能不能和其他项目对接。比如用了 Ollama 做本地推理，需要它能对外提供 OpenAI 兼容接口；用了 Qdrant 做向量存储，需要它能接各种 embedding 模型。接口开放程度，决定了你后面能不能搭出真正可用的系统。

第四，上手成本要可控。有些项目能力很强，但配置复杂到让人怀疑人生。我倾向选那些“一条命令能跑通 demo、半小时能开始改代码”的项目，因为学习成本也是成本。一个项目如果连安装文档都写不清楚，大概率后续维护也是灾难。

1.2 15 个项目的总览与分工

我把选出来的 15 个项目按使用场景分成五层，每一层解决一个具体问题。你在跟随本文阅读时，心里可以始终带着这张地图。

这 15 个里有 14 个是代码型工具，还有一个 BGE-M3 是模型，但因为它是整个检索链路的核心，我把它当作项目来对待。下面我们按“从底层到上层”的顺序逐个聊。

2. 第一步先把模型跑在自己电脑上：本地推理三件套

所有 AI 应用的核心是“模型调得动”。很多新手第一步就卡在模型下载和环境依赖上。本地推理三件套解决的是“如何在你的电脑上把模型跑起来”，分别对应入门、性能和上线三种需求。

2.1 Ollama：一行命令把大模型带回家

Ollama 是我目前最推荐的入门工具。它把“下载模型、管理模型、启动服务、提供 API”这几件事压缩成了一两行命令，极大降低了本地跑大模型的认知门槛。你不需要理解 CUDA、不需要手动编译，甚至不需要知道模型文件放在哪个目录。

# 拉取并运行一个 7B 量级的模型 ollama pull qwen2.5:7b ollama run qwen2.5:7b

跑起来之后，它会默认监听 11434 端口，你可以在另一个终端里用 curl 直接测试：

curl http://localhost:11434/api/generate -d '{"model":"qwen2.5:7b","prompt":"介绍你自己"}'

Ollama 最大价值在于它把模型封装成了“OpenAI 兼容 API”。这意味着上面所有需要调大模型的工具（Dify、FastGPT、Open WebUI、LangChain、Continue 等）都可以直接通过http://localhost:11434/v1访问它，整个生态一下就通了。

实际使用中有两个细节值得注意。第一，默认模型目录会放在系统盘，大模型动辄几个 GB，建议通过OLLAMA_MODELS环境变量把目录指到大容量磁盘，不然系统盘很快会爆。第二，显存不够时优先选量化版模型，比如名字里带q4_K_M的版本，效果损失可接受，但内存占用能小一大半。

2.2 llama.cpp：被 Ollama 藏在底下的性能引擎

如果你只想舒舒服服跑模型，Ollama 已经够了。但如果你想进一步理解“模型是怎么被跑起来的”，或者想把模型部署到树莓派这类边缘设备上，就必须认识 llama.cpp。

llama.cpp 是一个纯 C/C++ 实现的推理引擎，它最出名的贡献是定义了 GGUF 模型格式。你可以把 GGUF 理解成一个“把模型权重、量化参数、tokenizer、超参信息全部打包进一个文件”的容器格式。Ollama 的底层推理能力，很大一部分就来自 llama.cpp。

当你需要更精细控制推理行为时，可以直接用llama-server启动服务：

llama-server -m ./models/qwen2.5-7b-instruct-q4_K_M.gguf --port 8080

其中-m指定模型文件，--port指定端口。它同样提供 OpenAI 兼容 API，所以暴力替换 Ollama 也能接上之前的工具链。

关于量化参数，我用一个不严谨但好理解的类比：GGUF 量化就像给图片做压缩，q8_0接近原图，文件大；q4_K_M是平衡了体积和画质的 JPEG，日常首选；q2_K是糊到快不能看的缩略图，除非内存实在不够，否则不建议用。在显存不足又想跑大模型时，调低量化档位往往是性价比最高的方案。

2.3 vLLM：上线服务时的并发利器

Ollama 和 llama.cpp 解决“单机跑起来”，vLLM 解决“并发请求来了不崩”。如果模型要作为 API 提供给团队或外部用户使用，单线程的推理方式很快会成为瓶颈。vLLM 的核心创新叫 PagedAttention，简单说就是让显存里的缓存可以被多个请求动态共享，从而大幅提高吞吐量。

vLLM 的部署非常直接：

pip install vllm vllm serve Qwen/Qwen2.5-7B-Instruct --gpu-memory-utilization 0.9

--gpu-memory-utilization 0.9的意思是允许 vLLM 占用最多 90% 的显存，这个值要根据你的实际显存大小调整。它启动后同样暴露 OpenAI 兼容接口，地址是http://localhost:8000/v1。

我的建议是：个人调试玩模型用 Ollama，真正提供服务用 vLLM。两者不冲突，甚至可以在同一台机器上并存——Ollama 跑小模型做实验，vLLM 跑主力模型给业务用。这个组合我用了很久，稳定且顺手。

3. 让模型变成产品：应用框架与可视化搭建的关键选择

模型跑起来之后，下一步是“怎么把它变成能用的产品功能”。这里有三条路线：写代码用 LangChain 系列、拖拽用 Dify、专注知识库用 FastGPT。它们各有侧重，我建议根据团队构成和需求来选。

3.1 LangChain 与 LangGraph：写代码时的主线框架

LangChain 是最早把“大模型应用开发”这件事标准化的一套框架。它把模型调用、提示词模板、工具调用、输出解析、记忆管理这些高频操作封装成统一接口，让你不用每次都从零开始写胶水代码。

一个最简的“链”是这样：

from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI from langchain_core.output_parsers import StrOutputParser llm = ChatOpenAI( model="qwen2.5:7b", base_url="http://localhost:11434/v1", api_key="ollama", ) prompt = ChatPromptTemplate.from_template("用三句话解释：{topic}") chain = prompt | llm | StrOutputParser() print(chain.invoke({"topic": "RAG"}))

这个例子里的“管道符”语法叫 LCEL，是 LangChain 推荐的写法。它把提示词、模型、输出解析器串成一条流水线，理解起来直观，组合能力也很强。

但 LangChain 有一个常年被吐槽的问题：版本迭代太快，网上搜到的旧教程代码经常跑不通。我的建议是，新手不要一上来就啃全部概念，只掌握 Runnable、提示词模板、输出解析器这三个概念就可以开始做东西了。等业务逻辑变得复杂，出现分支、循环、多步决策时，再引入 LangGraph。

LangGraph 把应用的执行流程定义成一个状态图，节点是处理步骤，边是跳转条件。它比“链”更贴近真实业务逻辑，适合做 Agent、多轮工具调用、需要人工介入审核的流程。你可以把它理解成“给代码流程画了一张可以执行的地图”。

3.2 Dify：不写代码也能搭出 AI 应用

如果说 LangChain 是给程序员用的，那 Dify 就是给“整个团队”用的。它是一个可视化的大模型应用开发平台，支持拖拽编排工作流、内置 RAG、Agent、知识库管理、模型接入管理，而且可以自托管。

Dify 的部署很省心：

git clone 对应仓库 cd dify/docker docker compose up -d

起来之后，在设置里添加模型供应商。如果你本地跑着 Ollama，只需要填一个 OpenAI 兼容地址：http://host.docker.internal:11434/v1。这样团队里不懂代码的同事也能搭建一个带知识库的问答机器人，效率非常可观。

我见过很多小团队用 Dify 两天就拼出一个内部工具原型，这在以前至少需要两周。但要注意，Dify 的可视化编排有一个隐性成本：流程太复杂之后，节点之间跳来跳去，排错会非常痛苦。我的经验是，超过五个节点的核心流程，仍然值得用代码把关键逻辑写在自定义代码节点里，方便调试和复用。

3.3 FastGPT：把知识库问答做透

FastGPT 的核心定位和 Dify 有重叠，但它在“知识库问答”这个垂直场景上做得更深。它内置了文档导入、分段、QA 自动提取、多路召回、引用来源展示等一整套 RAG 能力，对于“给用户回答问题并告诉他依据是什么”的场景，体验比通用平台好很多。

FastGPT 同样可以通过 Docker 编排部署。配置好模型后，你只需要建一个知识库，上传文档，它就会自动完成切片和向量化，然后在对话流程里把召回结果带着原文引用一起返回给模型。

如果你要做的是“答用户问”的产品，比如售后助手、企业内网问答、文档解读工具，FastGPT 是更省事的选择。我的项目经验是：面向终端客户的知识库，优先 FastGPT；面向内部流程的万能助手，优先 Dify。这两个项目互补大于竞争，不必纠结二选一。

4. 给 AI 装上“记忆”：RAG 检索与向量存储的实战要点

要让大模型回答“你私有文档里的问题”，光靠通用知识不够，需要让模型先“查到”相关内容再生成回答，这就是 RAG（检索增强生成）的路径。这一层有两个关键角色：向量从哪来（Embedding 模型），向量存到哪（向量数据库）。

4.1 Qdrant：语义检索的仓库

当数据量变大，用遍历的方式找“语义最接近的文本”是不可接受的，这时就轮到向量数据库登场。Qdrant 是用 Rust 写的向量数据库，性能好、部署简单、文档清晰，是我在中小规模项目里的首选。

from qdrant_client import QdrantClient from qdrant_client.models import VectorParams, Distance client = QdrantClient(host="localhost", port=6333) client.create_collection( collection_name="knowledge_base", vectors_config=VectorParams(size=1024, distance=Distance.COSINE), )

这里有两个极其容易踩的坑。第一，size必须和你使用的 embedding 模型的输出维度一致。比如 BGE-M3 输出 1024 维，如果你写成 768，后面写入向量时直接报错。第二，distance选 COSINE（余弦相似度）是大多数文本检索场景的默认选择，不建议随意换。

写入和查询的代码大致是这样：

from qdrant_client.models import PointStruct client.upsert( collection_name="knowledge_base", points=[ PointStruct(id=1, vector=vector, payload={"text": "原文内容", "source": "文档A"}), ], ) hits = client.query_points( collection_name="knowledge_base", query=query_vector, limit=5, ).points

有人会问：数据量不大时是不是没必要上向量库？我的看法是，几千条以内其实可以用内存向量计算，没必要引入额外组件。但如果估计后面要增长到几十万条，或者需要按文档来源过滤、做多租户隔离，那就趁早用 Qdrant，省得后面迁移。

4.2 BGE-M3：先解决“向量从哪来”

向量数据库再快，也得有高质量的向量喂进去。BGE-M3 是目前中文场景里非常能打的开源 embedding 模型，支持多语言、多粒度、长文档，而且同时输出稠密向量和稀疏向量，方便做混合检索。

使用方式非常简洁：

from FlagEmbedding import BGEM3FlagModel model = BGEM3FlagModel("BAAI/bge-m3", use_fp16=True) docs = ["开源项目推荐", "大模型本地部署与推理"] out = model.encode(docs) vectors = out["dense_vecs"]

得到vectors后就可以写入 Qdrant 了。我在实践中习惯把文档先切成 300 到 500 字的小段，相邻段落保留 50 字左右的重叠，这样既保证每个片段语义完整，又能防止关键信息正好被切在边界。这个技巧比选什么模型更影响最终检索效果。

另外，RAG 检索不是“召回就结束”。推荐在召回后加一步重排（rerank），用 BGE-reranker 对候选结果重新打分。召回阶段宁可多召回一些，重排阶段再精准筛选，整体效果会明显好于直接取 TopK。

4.3 检索管线中容易被忽略的文件解析

很多 RAG 项目跑通了 demo，一上真实文档就效果崩盘，问题往往不在模型和向量库，而在“文件解析”这一步。PDF 里的表格、扫描件、图片型文档，如果解析不当，切出来的全是乱码，后面所有环节都白做。

我的习惯组合是：常规 Word/PDF 文本用解析库直接抽文本；带表格的 PDF 用专门的表格解析工具；扫描版 PDF 先过一层 OCR，比如 PaddleOCR。千万别觉得 OCR 就一定是大工程，很多扫描件用现成 OCR 模型跑一遍，几分钟就能把文字抽出来。文件解析这步不做好，RAG 的上限就被锁死了，后期再怎么调提示词也救不回来。

5. 从聊天到干活：Agent 协作框架怎么选、怎么用

大模型能聊天之后，大家自然希望它能“干活”：查资料、写报告、调工具、完成任务。Agent 就是让模型具备“目标分解、工具调用、循环执行”能力的方案。这 15 个项目里，有两个 Agent 框架我实际用过且感受深刻。

5.1 CrewAI：让多个角色 Agent 一起干活

CrewAI 的设计理念很朴素：把一次复杂任务拆给多个“角色”去完成，每个 Agent 有明确的角色、目标和背景，Agent 之间通过任务衔接。它的概念非常轻，用代码描述一个“调研员 Agent”和一个“写作员 Agent”大概是这样：

from crewai import Agent, Task, Crew, Process researcher = Agent( role="调研员", goal="找出三个适合本地部署的AI开源项目", backstory="你是一名技术选型顾问，擅长对比工具", ) writer = Agent( role="写作员", goal="把调研结果写成一篇简洁的短文", backstory="你是一名科技博主，文风清晰直接", ) research_task = Task( description="调研三个项目并输出优缺点对比", agent=researcher, ) write_task = Task( description="基于调研结果写一篇300字短文", agent=writer, ) crew = Crew( agents=[researcher, writer], tasks=[research_task, write_task], process=Process.sequential, ) result = crew.kickoff() print(result)

CrewAI 的易用性让它适合作为 Agent 框架的入门选择。但我要提醒的是：Agent 不是越多越好。多一个 Agent，就多一层信息传递损耗和出错可能。我的实践是先让一个 Agent 单干，跑通之后再加角色。如果你发现两个 Agent 协作时经常互相矛盾，先检查是不是任务描述不够具体，而不是急着加第三个 Agent。

5.2 MetaGPT：一组 Agent 模拟一家软件公司

MetaGPT 走的是另一条路：把软件开发流程标准化，让多个 Agent 扮演产品经理、架构师、项目经理、工程师，按固定流程产出文档和代码。你给它一句话需求，它可能还给你一份 PRD、一张任务拆分表和一版原型代码。

metagpt "写一个带登录功能的待办事项应用"

MetaGPT 的启发在于：Agent 框架的本质不是“让模型自己随便想”，而是“把人类成熟的协作流程固化成角色分工和产出物标准”。当你把流程定义得足够清楚，每个步骤的产出物有明确验收标准时，多个 Agent 的协作质量会稳定很多。

但也要清醒认识它的边界。生成的代码适合作为第一版原型，离生产级还有距离。依赖关系、异常处理、安全设计这些工程问题，仍需要人来把关。我会把它当“自动写初稿的实习生”，而不是“能独立交付的工程师”。

5.3 我对 Agent 框架的观察与建议

我在实际项目里发现，Agent 框架最大的风险不是“跑不起来”，而是“跑起来但不可控”。它有状态、有循环、会调用工具，一旦某个步骤产生了错误中间结果，后面可能一路错下去。

所以我的建议是：给 Agent 的每个关键步骤设置验证环节，比如让中间结果经过一次“人工确认节点”或“格式校验节点”。同时，凡是 Agent 要执行外部副作用操作（发邮件、改数据库、删文件），务必加上明确的授权机制。别让 Agent 的权限大于它应该拥有的权限。这个原则在我做过的小型自动化工具里，帮我避掉了很多次灾难。

6. 一天 8 小时都在用的体验层：对话界面与 AI 编程工具

模型、框架、RAG、Agent 都齐了，但日常使用还需要好用的“入口”。对我来说，入口分两类：一个是对话界面，一个是编程工具。它们决定了你每天实际和 AI 打交道的效率。

6.1 Open WebUI：给本地模型一个 ChatGPT 界面

Ollama 默认只有命令行，自己写前端又太耗时。Open WebUI 的存在就是为了解决这个问题：它提供一个类似 ChatGPT 的网页界面，支持多用户、多模型切换、历史会话、文件对话、知识库管理，还能对接 Ollama 和 vLLM。

部署命令如下：

docker run -d --name open-webui \ -p 3000:8080 \ --add-host=host.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ ghcr.io/open-webui/open-webui:main

启动后浏览器打开http://localhost:3000，在设置里把 Ollama 的地址填成http://host.docker.internal:11434，它就能自动列出你本地已有的模型。

如果你在团队内部署，有几件事要提前想好：是否开放注册、是否需要管理员审核、历史会话会保存在服务器上。我见过有人把 Open WebUI 直接暴露到公网，结果第二天就被陌生人注册了账号，白白消耗了本地显卡资源。这个坑希望你别踩。

6.2 Aider：终端里的结对编程搭档

Aider 是我近半年使用频率最高的 AI 编程工具。它跑在终端里，核心能力是“读代码、改代码、自动提交”，并且和 Git 深度集成。你只需要用自然语言告诉它需求，它会直接修改多个文件，然后给出 diff。

一个典型的使用流程是这样：

# 进入项目目录，启动 Aider aider --model ollama_chat/qwen2.5:7b

然后在 Aider 交互界面里输入：“把订单列表按创建时间倒序排列”。Aider 会读取相关代码、修改文件、生成 diff，你可以确认后再让它提交。这种“先看 diff 再提交”的节奏，比让 AI 直接改完就完事安全得多。

我给你的建议是：用 Aider 之前务必先确保工作区是干净的，至少要让 Git 处于你了解的状态。AI 改代码的速度很快，但因为快，它也可能把你不希望动的地方一并改了。有 Git 兜底，你就可以大胆试，错了就回滚，这是 Aider 正确用法的基础。

6.3 Continue：把 AI 助手装进编辑器

如果说 Aider 适合“整块任务”，那 Continue 适合“边写边改”。它是一个 IDE 插件，支持在 VS Code 和 JetBrains 系列编辑器里使用，提供代码补全、行内编辑、侧边栏聊天、斜杠命令等功能，同样可以接本地模型。

配置方式和 Aider 类似：在扩展配置里添加一个模型，指向 Ollama 的本地地址，我就用http://localhost:11434作为 base URL。之后写代码时按一下快捷键，Continue 会基于当前文件和选中代码给出建议补全。

一个提升效果的细节：在项目根目录放一份说明文档，简单描述项目结构、技术栈和编码约定。Continue 在生成建议时会读取上下文，这份文档能让它的回答更贴合你的项目，而不是泛泛地写一段模板代码。

7. 声音和画面也能“起飞”：多模态项目的落地场景

前面聊的都是文本模型。但实际业务里，语音转写、图像生成同样是高频需求。这个部分我挑了两个使用门槛低、上限高的开源项目。

7.1 Whisper：把语音变成文字

Whisper 是开源的语音识别模型，支持多种语言，对中文的识别效果在开源模型里属于第一梯队。最直接的应用是音频转录：开完会录一段音，直接让 Whisper 转成文字，再交给大模型生成会议纪要和待办事项。

一条命令就能跑：

whisper meeting.m4a --language zh --model medium --output_dir ./out

--model可以选tiny、base、small、medium、large，模型越大识别越准，但耗时和内存也更高。如果没有 GPU 或时间有限，从small或medium开始是比较平衡的选择。

实际使用中，我发现噪音环境下的识别率会明显下降。建议先对音频做预处理，比如统一转成 16kHz 单声道 wav，再做转写。如果一段音频特别长，Whisper 在大段上有时会出现“脑补”内容，稳妥的做法是分段转写，再按时间戳拼接。想要更快的在线转写，可以关注 faster-whisper 这类 CTranslate2 版本，速度能提升好几倍。

7.2 ComfyUI：把图像生成变成可控的工作流

ComfyUI 表面上看是个画图工具，本质上是一个节点式图像生成工作流引擎。你通过连线的方式把“提示词编码、采样器、VAE 解码、图像保存”这些节点串起来，每一步都可见、可调、可复用。这种控制力是它相比其他图形界面最大的优势。

第一次使用时的路径大概是：下载安装包，把下载的大模型文件放进models/checkpoints目录，启动服务后用默认的“文生图”工作流跑出一张图。基本节点无非是 Load Checkpoint、CLIP Text Encode、KSampler、VAE Decode、Save Image，花半小时试一遍就能理解它们的作用。

我最喜欢 ComfyUI 的一点是，工作流本身可以导出为 JSON 文件。这意味着你调好一套“角色一致、风格统一”的流程后，可以保存下来反复使用，也可以分享给同事。它把图像生成从“碰运气”变成了“可复现的工程”。显存不够的话，先用 SD1.5 系列小模型搭配 LoRA 控制风格，效果也能做到不错。

8. 不只会单点使用：把 15 个项目串成一条 AI 工作流

把项目一个个讲完之后，我想换个角度，把它们当成积木拼起来。因为你很可能不只想要“某个工具”，而是想搭一套能解决真实问题的系统。这里分享三个我搭过的组合，以及对应的硬件和避坑建议。

8.1 组合一：私有知识库问答

这是最经典、也最容易上手的组合，目标是让 AI 基于你自己的文档回答问题，并给出引用来源。

• 对话模型：Ollama 跑 Qwen2.5 7B 量化版，负责生成回答。
• 向量模型：BGE-M3，负责把文档切片转成向量。
• 向量库：Qdrant，负责存储和召回。
• 应用编排：FastGPT，负责知识库管理、工作流编排和引用展示。
• 访问入口：Open WebUI，负责让团队成员用浏览器对话。

数据流是：上传文档到 FastGPT → 自动切片 → BGE-M3 生成向量 → 写入 Qdrant → 用户提问 → FastGPT 从 Qdrant 召回相关片段 → 把片段交给 Ollama 里的模型生成带引用的回答 → Open WebUI 展示。

这套组合我跑通过一次之后，后面所有新知识库项目都复用同一套模板，效率很高。

8.2 组合二：会议录音到结构化纪要

这是一个“效率飞轮”式的组合：把录音变成文字，再把文字变成结构化文档。

• 转写：Whisper 把录音转成带时间戳的文字稿。
• 总结：Ollama 或 vLLM 部署的模型，把文字稿整理成“讨论要点、结论、待办事项、负责人”四段式纪要。
• 分发：用 Dify 搭一个内部流程，把 Markdown 纪要自动生成并发送到团队群（通过 Webhook 接入）。

这套流程最大的收益不是省了打字时间，而是让每场会议的结论都有据可查。我会把原始文字稿和整理后的纪要一起归档，之后任何人对某个决策有疑问，都可以回听录音、回看纪要。

8.3 组合三：内容生产的流水线

做技术博客或产品文档时，可以用这套组合大幅缩短从想法到成品的周期。

• 写作辅助：Aider / Continue 负责辅助写代码和改文档结构。
• 配图：ComfyUI 生成示意图、封面图或产品概念图。
• 内容改写：用 FastGPT 或 Dify 搭建一个“改写润色”工作流，把初稿处理成风格统一的终稿。

具体做法是先用 Aider 把文章里的代码示例调试跑通，再把代码块交给大模型改写注释和讲解，最后用 ComfyUI 出一张与主题匹配的配图。整个流程下来，从一小时憋一段开头，到半小时能出一篇初稿，差距还是很明显的。

8.4 起步硬件与避坑清单

以上组合对硬件的要求不一样，我按经验给一个参考：

最容易踩的五个坑，我列在前面给你打预防针：

1. 向量维度不匹配：BGE-M3 是 1024 维，换模型不换 Collection 尺寸，写入必定报错。
2. 端口冲突：Ollama 用 11434，vLLM 用 8000，Open WebUI 用 3000，部署前先确认都没被占用。
3. Docker 磁盘膨胀：日志和镜像堆积会把系统盘塞满，定期docker system prune清理。
4. 显卡不识别：Ollama 默认用 CPU 也能跑，但速度很慢。如果发现显存没被调用，先检查驱动和加速库。
5. 不同框架对模型格式要求不同：Ollama 直接拉取的模型已经处理成 GGUF，但自己下载的 HF 格式模型需要转换才能被部分工具识别，别硬塞。

9. 一些装机后的真心话

先交代一个事实：这 15 个项目我并不是同一天认识的，而是从“只想在自己电脑上跑个聊天机器人”开始，一路踩坑踩过来的。头几次尝试特别狼狈，不是缺这个依赖，就是端口被别人占了，跑通一个 demo 能开心一晚上。

现在回头看，真正让我从“收藏家”变成“使用者”的转折点，不是某个特别厉害的项目，而是我接受了一件事：不要试图一次把全家桶全装上。更好的路径是挑一条最小链路先跑通。比如只装 Ollama 和 Open WebUI，花一个晚上跟本地模型聊上几句，你就完成了从“围观 AI”到“使用 AI”的第一步。之后再缺知识库，就加 FastGPT；缺检索，就加 Qdrant；缺 Agent，就玩 CrewAI。每加一个工具，都应该是为了解决一个具体问题，而不是因为它被很多人点赞。

最后分享一个小技巧：学着去读你正在使用的开源项目的官方文档，哪怕每天只读十分钟。网上的二手教程永远滞后，而开源项目迭代太快。当你习惯了从官方文档里找答案，你会发现自己不再怕踩坑，因为你知道怎么去定位问题的源头。这 15 个项目只是起点，真正让你 AI 起飞的，是你愿意动手去跑、去改、去折腾的那几个小时。

祝你在自己的机器上，早日听到模型回话的声音。