企业官网建设流程全解析

周末我在家把电脑里的旧显卡重新翻了出来，把聊天问答、文档知识库、联网搜索、网页交互这整条链路全部搬到了本地跑通：不需要订阅云端服务，不往别人服务器传私人资料，模型推理、向量检索、搜索接口都在自己家这台机器上完成。这个项目我给它起名叫“零成本本地 AI 全栈”，核心就一句话:用已有的家用电脑和开源软件，搭一套从模型到底层搜索再到前端交互的完整 AI 应用环境。

这套东西适合谁看？平时想折腾大模型但不想被各种云端服务绑定的人，有一点代码基础但不是专业算法工程师的人，或者纯粹想把闲置显卡和内存利用起来的人。它能解决的问题很直接：大模型不再是网页上的一个对话框，而是你家里随时可以调用、可以按需替换、可以接入自己数据的私有 AI 服务。

1. 本地AI全栈的整体设计：不是搭一个模型，而是搭一套链路

1.1 “本地AI全栈”与“本地模型”的区别

很多人一听说本地部署 AI，第一反应就是跑一个 Ollama，敲一条ollama run llama3，能对话就算成功。但标题里的“全栈”远不止这一步。在软件行业里，“全栈”常指前端加后端加数据库都能做；而本地 AI 全栈，指的是从最底层的模型推理、到中间的 API 服务和知识库、再到最上层的搜索入口和网页界面，整条链路都在本机运行。

也就是说，如果只部署了一个模型，你得到的只是一个能聊天的终端窗口。真正可用的本地 AI 系统至少包含四层：模型层负责理解和生成；服务层把模型封装成标准 API；数据层负责喂给模型你的私人文档和知识；应用层负责和用户交互，并接入外部信息源比如搜索引擎。缺了任何一层，都只能算一个玩具，不能算一个“全栈”项目。

这个理解很重要，因为它直接决定了你的技术选型。如果你只想要一个 Chat 窗口，那选择就简单了；但如果你想要的是“AI 能回答我的问题并引用我自己的文档”“AI 能帮我去查最新资料再总结”，那你必须考虑模型的上下文窗口、向量库的召回质量、搜索结果的清洗、前端如何展示引用链接，这每一个环节都得打通。

1.2 为什么选择零成本家用路线

最直接的原因是隐私和成本。把文档、聊天记录、邮件甚至家庭照片描述发给公网 AI 服务，确实方便，但也意味着你要信任对方的隐私政策。而本地部署的核心优势不是“离线也能用”这种极端场景，而是数据不出门。

在成本上，我要给“零成本”先下一个准确定义：软件订阅费用为零，网络服务费用为零，存储和算力用的是家里已经有的设备。家用电脑的电费、平常开着机器多出的几瓦功耗，这些我不纳入计算，因为机器本来就要开。如果你的硬盘老、显卡旧、内存小，可能需要换配件，那属于硬件升级，不在零成本范围内。

所以我在项目里用的选型原则很明确：优先选免费的开源组件，优先选能在普通电脑上跑得动的模型，优先选单机可部署、不依赖外部账号的软件。如果某些功能必须依赖外部服务，比如搜索引擎结果，那就选公开、合法、不涉密的接口，把隐私泄露面控制在最小范围。

1.3 我需要准备哪些硬件和软件

先给一个我自己的“工作机配置”，你不是必须一样，但可以参考这条基线：CPU 是 AMD 的八核处理器，内存 32GB，显卡是好几年前的 8GB 显存型号，没有独立 GPU 的机器也能跑但速度慢一些，后面章节我会再说如何取舍。硬盘留了大概 60GB 空间给模型和向量库。

软件方面，我全部使用了当前社区常用的开源方案：模型管理用 Ollama，API 层直接用 Ollama 自带的 OpenAI 兼容接口；向量库用开源的 Chroma；搜索入口用自托管的元搜索引擎 SearXNG；页面和后端是一个简单的 Flask 应用。整条技术栈没有一个需要付费授权，也没有一个需要注册云端账号。这样安排的一大好处是，以后哪个组件不满意，可以单独替换，不会造成整套系统推倒重来。

如果你刚开始搭建，我的建议是先不要碰 Agent 和复杂编排，先按“模型层 → 服务层 → 数据层 → 应用层”的顺序一层层搭起来。每搭完一层就测试一层，这样出了问题你能很快定位，不至于所有服务一起跑起来后，报错都不知道该查哪个日志。

2. 模型层落地：选对模型并用 Ollama 让家用电脑跑起来

2.1 本地模型怎么选，别只盯着“最大最强”

模型是整个系统的大脑，也是最容易让人犯选择困难症的部分。热词里出现了“本地部署 deepseek”“ollama 本地部署”这些高频词，可见大家都想在自己电脑上跑出接近云端的效果，但现实是——家用电脑的算力和显存有限，不是所有模型都适合本地部署。

我在选模型时主要看三个指标：参数量大小、量化版本、上下文长度。参数量越大的模型智商表现通常越好，但需要的显存和内存也成倍增加；量化是压缩模型体积的技术，最常用的是 4-bit 量化（Q4），在损失少量推理质量的情况下能把显存占用降到一半以下；上下文长度则决定了模型能“记住”多少对话和资料。

针对家用电脑这档配置，我分了三个层级来选：

• 轻量日常档：7B-8B 参数量的模型，量化后大约 4-6GB，适合 8GB 显存或者纯 CPU 16GB 内存的机器。代表性选择是qwen2.5:7b和llama3.1:8b。日常问答、写代码、总结文本，速度都在可接受范围。
• 进阶能力档：14B 左右，量化后约 9-10GB，16GB 显存或者 32GB 内存可以运行。这个级别在推理和中文能力上比 7B 好一截，qwen2.5:14b、deepseek-r1:7b这类模型可以处理更复杂的任务。
• 高端重载档：32B 以上。坦白讲，除非你的显卡显存超过 24GB，否则我不建议家用机器跑这个级别。我有一次尝试 32B 模型，CPU 推理速度掉到了每秒两三个字，体验非常差，不如选用小模型搭配知识库来弥补。

给一张参考表会更直观：

2.2 从安装 Ollama 到加载模型完整步骤

Ollama 是目前本地跑模型最省心的工具，相当于大模型领域的 Docker。它帮你解决了模型下载、推理进程管理、显卡调用这些最麻烦的事。完整步骤分三步：

第一步，安装 Ollama，直接到官网按对应系统下载安装包即可。安装完在终端执行ollama run qwen2.5:7b，它会自动拉取模型文件。注意默认下载路径在用户目录下，如果你系统盘空间紧张，可以先设置一个环境变量OLLAMA_MODELS，指到大容量硬盘目录，再启动服务。

第二步，验证模型是否工作。执行完拉取并运行后，命令行会出现>>> Send a message的提示，输入一句“你好”试试。如果回复正常，说明模型推理链路没问题，按/bye退出交互终端，但 Ollama 服务会在后台继续运行，默认监听 11434 端口。

第三步，让 Ollama 能接受外部连接。如果你只想本机用，默认配置就行；但如果你想在局域网里其他设备上访问，就需要设置一下环境变量，让服务监听0.0.0.0，并且加上允许的来源。这里要注意，监听所有网卡意味着局域网内任何人都能访问你的模型，家庭网络环境还好，但最好不要直接暴露到公网。

2.3 模型推理参数与调用方式解析

很多人会把模型跑起来后就开始对话，完全忽略了推理参数。实际上推理参数直接影响回答质量，做应用时尤其重要。最常用的两个参数是temperature和num_ctx。temperature控制随机性，值越高回复越多样，值越低越稳定。做知识问答和代码生成，我一般设到 0.1-0.3；做创意写作才调到 0.7 以上。num_ctx是上下文的 token 数，默认时常只有 2048，这在今天看来太短了，问答稍微长一点就会截断。我会在请求中显式设置到 4096 或 8192，代价是占用更多显存。

Ollama 的调用方式非常简单，本机直接走 HTTP API。一个典型的 chat 请求是这样：

curl http://localhost:11434/api/chat -d '{ "model": "qwen2.5:7b", "messages": [ {"role": "user", "content": "解释一下什么是RAG"} ], "options": { "temperature": 0.2, "num_ctx": 8192 } }'

实际上你不需要记住这个 JSON 格式，因为 Ollama 提供了 OpenAI 兼容接口，地址是http://127.0.0.1:11434/v1，任何支持 OpenAI SDK 的前端框架和脚本都可以直接对接，把base_url改成本地地址即可。这是整个全栈设计里非常关键的一环，直接决定了上层应用可以用标准方式调用本地模型，而不是为每个模型写一套私有协议。

2.4 我在模型层踩过的坑

关于模型层，我最有价值的一条经验是：不要在一开始就追求在纯 CPU 上跑一个大模型。CPU 推理确实可行，但速度会让你怀疑人生。我之前在一台只有核显的笔记本电脑上跑 7B 模型，输出的速度大概每秒钟三四个 token，也就是生成一段 100 字的话要等 40 秒，根本没法做交互。如果你的机器有 8GB 及以上显存的 NVIDIA 显卡，记得安装最新显卡驱动；如果没有独立显卡，那就老老实实选 1.5B 或 3B 这类小模型，或者把 Ollama 的OLLAMA_NUM_GPU相关配置关掉，别让它强行调用不支持的硬件。

还有一点，显存和内存的分配经常被忽略。模型加载时不仅要占显存，推理过程中的 KV Cache 也要占显存，上下文越长占得越多。我遇到过明明模型只有 5GB，但跑着跑着爆显存的情况，十有八九是num_ctx设太高。直接把上下文调到 4096，问题立刻缓解。

3. 服务层与数据层：从“能对话”到“能干活”

3.1 用 API 封装把模型变成后端服务

模型层搭建好后，很多教程就到这里结束了，但距离“本地 AI 全栈”还差很远。为了让模型能给别人用、能被网页后端调用，需要有一个稳定的 API 封装。Ollama 自带的 HTTP 接口就能干这件事，尤其它提供的 OpenAI 兼容端点让一切变得异常轻松。

在 Python 里，你只需要这样配置客户端：

from openai import OpenAI client = OpenAI( base_url="http://127.0.0.1:11434/v1", api_key="ollama" # 本地服务，这个值是占位符 ) response = client.chat.completions.create( model="qwen2.5:7b", messages=[{"role": "user", "content": "写一段Python代码读取CSV文件"}], temperature=0.1 ) print(response.choices[0].message.content)

注意，本地 API 的api_key随便填一个字符串就行，因为 Ollama 默认不校验密钥，但这样也意味着你最好别把服务暴露到公网。从全栈角度看，这个 API 封装的价值极大：前端不用关心模型到底是什么，后端也不用管模型怎么部署，只要约定好标准请求格式，整个业务系统就能像调用云端大模型一样调用本地模型。

3.2 给本地模型配上知识库：RAG 完整思路

模型在训练完成时知识就固定了，你刚下载的模型不会知道你上周写的产品方案，更不会知道你电脑里存的操作手册。解决这个问题最主流的技术是 RAG，也就是检索增强生成。核心思路不复杂：先把你自己的文档切成小块，给每块做向量化，存进向量数据库；当用户提问时，先从向量库中检索最相关的几块内容，把它们拼到提示词里，再让模型基于这些内容生成回答。

我用的向量化模型是nomic-embed-text，体积小、中文效果尚可，通过 Ollama 就可以直接加载。向量库我选了 Chroma，因为它是嵌入式数据库，不需要额外起一个服务端进程。整个流程串起来，一个简化版的 Python 代码是：

import requests import chromadb # 1. 对文档片段做向量化 def embed_text(text): resp = requests.post("http://localhost:11434/api/embeddings", json={ "model": "nomic-embed-text", "prompt": text }) return resp.json()["embedding"] # 2. 存入 Chroma client = chromadb.Client() collection = client.create_collection("my_docs") doc_chunks = ["文档第一段", "文档第二段"] # 真实场景要切块 for i, chunk in enumerate(doc_chunks): collection.add(ids=[str(i)], embeddings=[embed_text(chunk)], documents=[chunk]) # 3. 检索 results = collection.query(query_embeddings=[embed_text("我想找的内容")], n_results=3) print(results["documents"])

这里的重点在于切块策略和召回策略。切块太小，语义不完整，召回一堆碎片；切块太大，向量不精准，还浪费上下文。我一般按段落切，并带上前后文的标题信息，每块控制在 500 到 800 个 token；召回时返回 3-5 块，然后把检索到的原文直接拼进 system prompt，再让模型输出。

3.3 Agent 能力：让模型使用工具而不是只会聊天

有了模型和知识库，下一步是让它能调用外部工具。很多人被“Agent”这个词吓到，把它理解成很玄的东西，其实本质就是一个循环：模型在回答前先判断自己需不需要工具，如果需要，就输出一个结构化调用请求，你的代码去执行工具并把结果返回给模型，模型再基于工具结果生成最终回答。

整个过程完全可以用非常朴素的方式实现。最稳妥的做法是利用模型对 JSON 输出的能力：你定义若干工具函数，比如search_web()和search_kb()，在 system prompt 里告诉模型“如果你不确定答案，输出{"action": "search_web", "query": "句式优化后的关键词"}”；后端代码解析到这段 JSON 后就执行对应工具，把结果插入对话后再让模型续写。这种方式不依赖复杂的 Function Calling 协议，只要模型遵循指令能力强，在本地小模型上也很可靠。

我在实践中的体会是：本地小模型直接输出函数调用的格式不是很稳定，经常多输出解释性文字导致 JSON 解析失败。所以后来我在后端加了一层“内容清洗”，用正则把{"action":...}这段单独提出来再解析，成功率才能达到 95% 以上。这个坑非常典型，自己实现 Agent 时一定要在协议解析层多做容错。

4. 本地搜索这层怎么实现：从模型到搜索的最后一环

4.1 “本地搜索”不是离线搜索

标题里强调“从模型到搜索”，很多人会想当然，以为完全离线的搜索引擎连 Google 都不用访问。实际上，个人电脑不可能把全网网页都爬取下来建索引，这不现实。本地搜索的含义，更准确说是自托管搜索服务：你把搜索这个动作从浏览器里直接访问搜索引擎，变成通过你自己的服务统一转发和整理。这样做一来可以在各家搜索引擎之间切换，二来请求不会直接暴露在浏览器各种插件追踪下，三来让模型可以通过这个服务的接口自动发起搜索并读取结果摘要。

我在项目中使用的方案是 SearXNG。它是一个开源的元搜索引擎，部署后就是一个网页应用，同时提供 JSON 格式的 API。默认配置里已经列了一批公共搜索引擎条目，你不需要自己挨个对接每家搜索平台，只需要在配置里勾选可用的条目即可。SearXNG 收到搜索请求后，会去对应搜索引擎抓结果，清洗后以统一格式返回标题、链接和摘要。

4.2 SearXNG 部署与常用配置

用 Docker 部署 SearXNG 是最省事的方式：

docker run -d -p 8080:8080 -v "${PWD}/searxng:/etc/searxng" searxng/searxng

启动后先访问http://localhost:8080确认界面能打开，然后编辑目录下的settings.yml。需要修改两处：一是设置server.secret_key，否则服务会拒绝启动，随便生成一串随机字符填入即可；二是把search.formats里加上json，因为让模型端调用搜索时需要 JSON 输出。

修改完重启容器，然后测试 JSON 接口：

curl "http://localhost:8080/search?q=本地AI部署&format=json"

正常的话会返回包含results数组的 JSON，数组里每项有title、url和content字段。这个接口就是本地模型搜索能力的入口。实际使用中，SearXNG 有一些搜索引擎条目会因为验证码、反爬或者地区政策不可用，这很常见，我的处理办法是在配置里把不可用的条目禁用，保留运行稳定的几个。

4.3 把搜索变成模型可调用的工具

有了 SearXNG 的 JSON 接口后，下一步就是把搜索和模型连起来。前面提到过 Agent 的工具调用，搜索就是最典型的一个工具。我在后端实现了一个搜索函数：

import requests def search(query): resp = requests.get("http://localhost:8080/search", params={"q": query, "format": "json"}, timeout=10) results = resp.json().get("results", []) return [{"title": r.get("title"), "url": r.get("url"), "content": r.get("content")} for r in results[:5]]

当用户提问涉及最新资讯、实时数据或者模型内部知识没法覆盖的内容，我就触发这个函数，把返回的几条结果压缩成简要文本，连同“以下内容来自实时搜索结果”的提示，一起拼进模型的上下文。这里有个要点：直接把一长串搜索结果原文全部塞给模型，模型根本读不完。我前几次测试就是这么干的，效果很差。后来改成只取前五条，每条只保留 title 和 content 的前 150 个字符，模型反而能给出干净答案。

4.4 搜索增强与隐私分界线的个人思考

当整条链路打通后，我发现本地全栈的真正价值不在“离线”，而在“可控”。模型是谁、什么时候更新、请求发了哪些数据、结果存在哪里，所有这些我都清楚。搜索方面，虽然最终关键词还是要交给公网搜索引擎，但至少不需要把用户名、浏览记录、历史对话一起暴露出去。

对于那些需要登录的网盘搜索或特殊资源搜索，我没有把它纳入这个项目的范围。因为自托管搜索是用来服务日常问答和知识获取的，不是用来破解限制或者绕开机制的。做一个真正好用、合法、可持续发展的本地 AI 工具，边界感非常重要，这一点希望读者也能有同样的意识。

5. 前端和后端的完整串联：一个能演示的全栈例子

5.1 目标场景：家庭知识库与搜索问答

所有技术最终都要落到应用上。我给自己定的目标是做一个简单的 Web 页面：用户在文本框问一个问题，后端先去知识库里查有没有相关文档，如果知识库内容够，就基于文档回答并标注来源；如果问题明显是“最近发生了什么”，就触发网络搜索，基于新闻结果回答。整个系统全程不依赖云端大模型 API。

这个场景听起来很小，但覆盖了全栈的每个环节：模型层是 Ollama 加开源模型，数据层是向量库，外部信息层是 SearXNG 搜索，后端 API 是 Flask，前端就是一张简单的 HTML 页面。本质上，你可以把它当成所有更复杂业务应用的最小可复现框架。

5.2 关键链路：从用户输入到答案返回

为了让读者更清楚整个请求流程，我这里用一个极简后端来说明，避免被前端框架分散注意力。核心流程就五步：接收输入、判断意图、检索知识库或搜索、组装上下文、调用本地模型、返回结果。判断意图这一步我没用太复杂的逻辑，就是用几个关键词硬规则加模型自身的判断：如果查询里含“今天”“新闻”“最新”“2024”这类词，就走搜索；否则先走知识库，知识库召回相似度低于阈值时也能转搜索。

后端核心逻辑大概长这样：

from flask import Flask, request, jsonify from openai import OpenAI app = Flask(__name__) client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama") def build_answer(user_query, context_sources): messages = [ {"role": "system", "content": "你是家庭AI助手，只能基于提供的上下文回答问题，不要编造没有依据的内容。"}, {"role": "user", "content": f"资料如下：\n{context_sources}\n\n问题：{user_query}"} ] resp = client.chat.completions.create(model="qwen2.5:7b", messages=messages, temperature=0.2) return resp.choices[0].message.content @app.route("/api/ask", methods=["POST"]) def ask(): data = request.get_json() query = data.get("query", "") # 简化版：这里先做知识库检索，再拼搜索结果 kb_chunks = search_local_kb(query) web_chunks = search_web(query) combined = kb_chunks[0] if kb_chunks else web_chunks[0] return jsonify({"answer": build_answer(query, combined)}) if __name__ == "__main__": app.run(host="0.0.0.0", port=5000)

前端页面不复杂，一个输入框一个按钮一片显示区，点击后向/api/ask发 POST 请求，把返回的 answer 渲染到页面上。如果你想让结果更漂亮，可以用一个支持 Markdown 渲染的开源组件，但核心功能不需要任何复杂框架。这里再强调一次，整个系统所有调用都指向本机端口，没有任何一个请求发向云端模型服务。

5.3 这套全栈的实际效果与零成本账单

我把日常查询整理了大概三十条测试问题，包括“我上个月的产品会议记录整理一下”“2025年有什么值得关注的开源模型”“帮我查一下家里这款路由器的设置说明”这类混合知识库和搜索的场景。实测下来，直接知识库问答的成功率最高，模型有足够上下文时，回答基本有依据，不会胡编；搜索回答则非常依赖搜索引擎返回的摘要质量，摘要好，答案就好，摘要不对，模型也很容易被带偏。所以我不建议把搜索当成万能的，它更适合作为知识库不足时的补充。

零成本账单部分，我简单列一下：Ollama、Chroma、SearXNG、Flask 全部开源免费；模型权重文件是开源的，可以自由下载使用；运行这些服务没有订阅费。唯一需要支付的是家用电费和硬件折旧，而这笔钱即使不跑 AI 也会花掉。相比按量付费的云端模型，长期高频测试时省钱效应会越来越明显。

6. 常见问题与排查技巧：本地全栈最容易踩的坑

6.1 问题速查表

为了不让后来者在黑暗中摸索太久，我把实操中遇到的问题整理成了一个小表，每一条都是真实发生过的：

6.2 排查顺序与一条核心经验

如果你遇到问题，我建议按固定顺序来查：先看硬件资源被谁占用了，再确认服务是否在监听，然后手动用 curl 测试接口，最后才检查代码。比如先跑ollama ps看模型是否在运行，再跑curl http://localhost:11434/api/tags看 API 是否正常，不要在没确认模型运行状态时就直接怀疑代码逻辑。

我在这套全栈开发里最深刻的体会是，本地 AI 系统的瓶颈往往不在模型智商，而在上下文工程。模型只是一个推理器，它的上限由你喂给它的材料质量决定。知识库检索不准，它就胡说；搜索摘要太差，它就像读了一篇垃圾文章；提示词里放了十个网址，它连第一个都读不完。你把上下文整理清楚了，7B 模型也能在具体领域内表现得非常专业。

6.3 如何让多个本地服务长期稳定运行

这套系统搭建完成后，面临的另一类问题就是稳定性。Ollama 和 SearXNG 这类服务如果直接在终端里敲命令启动，一关终端它就停了。我现在的做法是：Ollama 用系统原生服务跑，SearXNG 用 Docker 的 restart 策略，Flask 后端用 supervisor 这一类守护进程工具托管。这样重启电脑后不需要手动启动一串进程，全家桶自动起来，省心很多。

日志排查也要养成习惯。每次改动配置后，不要只看界面是否正常，去翻服务日志，Ollama 的日志能告诉你显存分配了多少、用的是什么设备；SearXNG 的日志能告诉你哪个引擎返回了错误码。如果不懂日志，出了问题就只能靠猜，那这套系统维护起来会非常痛苦。

最后再分享一点使用心得

真要说这套零成本本地 AI 全栈给我带来了什么，倒不是省了多少钱，而是我对 AI 应用的掌控感完全不一样了。过去我调用公网模型接口，遇到问题只能去查服务商文档，代码写完了也说不清数据到底存在哪里；而现在，从 loading 模型那一刻到搜索服务返回 JSON，每一个环节都在自己眼皮底下，模型回答得不满意，我可以换一个模型文件再试，知识库回答得不准，我可以调切块大小和检索条数，这些都是云端方案给不了的灵活度。

如果你准备复刻这个项目，我的建议是不要一开始就追求把所有组件都部署好。先跑通模型层，然后加 API 封装，再单独搭一个知识库试几篇文档，等你觉得每一步都真正理解了，再动手加搜索和网页应用。把这个过程拆开做，每个环节你都能学到东西；一口气全上，最后大概率会陷入不知道问题出在哪一层的泥潭。这套方案后续你想扩展也很容易：加语音输入、挂载更多数据源、做成局域网共享服务，都是在现有基础上的延伸。技术这条路没有终点，但一个好的起点是把工具真正变成自己的。