企业官网建设流程全解析

前阵子群里有个折腾了三天本地部署的哥们，突然冒出来一句话：“我是不是在养一只不会长大的电子宠物？本地模型放单机上，是不是压根没有学习能力了？”这问题问得挺实在，但确实把一堆概念搅在了一块。先说结论：本地模型当然可以“学习”，只是这个“学习”和我们以为的，以及在线产品给的那种“越用越懂你”，完全是两码事。这篇我就把这个问题彻底拆开，讲清楚单机部署下模型到底有哪些学习路径、哪些做不到，再给一套我自己实测能跑通的增强方案。它适合两种人：一种是想把本地模型当私人助理、知识库问答工具，但总感觉“它记不住东西”的人；另一种是纠结要不要折腾本地部署，怕折腾半天搭起来的是个死水潭的人。

先说清楚，这里的“单机”指的是本地独立运行、不依赖云端的部署方式，不是单机游戏那种玩法。你本地跑一个 Ollama、跑一个 llama.cpp，加载 DeepSeek-R1 7B 或者 Qwen 系列，这叫单机。理解这个前提，下面的内容才聊得下去。

1. “本地模型不学习”的直觉，其实只对了一半

1.1 你看到的现象没错，但归因错了

“本地模型不学习”这个说法，现象层面是成立的：你问它昨天聊过的事，它不记得；你喂给它的文档，它看完就忘；它的知识截止日期永远停在你下载模型文件的那一刻。

但这些现象不是说“单机导致没有学习能力”。就算你用云端 API，模型本身也是“失忆”的——API 背后那个大模型，不会因为你昨天问过它什么，今天权重就变一点。真正让在线产品看起来“越用越懂你”的，是产品层替它做了记忆存储和检索回填：你的聊天记录被存进数据库，下次对话时系统把相关历史自动拼进上下文，塞给模型。模型自己什么都没学会，是产品学会了帮你翻聊天记录。

这个归因一旦纠正，思路就打开了：本地模型天生不带“产品层”，你把它下载下来，它就是一个纯粹的推理引擎。学习能力不是它没有，而是没人帮它搭。

1.2 训练和推理：模型“上学”和“上班”是两回事

我特别喜欢用一个类比：模型权重文件就像一个刚毕业的实习生。预训练是大学基础教育，海量语料读下来，学会了语言、常识、逻辑；指令微调是岗前培训，教它“用户问你要怎么答”；RLHF 是入职后的行为规范，告诉它什么话能说什么不能说。这一整套流程，叫训练。训练结束，模型权重冻结，生成一个 GGUF、safetensors 之类的文件，你下载下来，部署到电脑上，开始推理。

推理就是上班干活，但权重已经冻结了。你和它聊十天，它不会因为这十天对话自动更新一个参数。这是设计如此，不是缺陷——如果每次对话都反向传播改权重，模型会灾难性遗忘，聊几轮就变成一个什么都不会的傻子。

所以，训练门类的问题，和单机、联网没关系。你调 OpenAI 的 API，模型权重同样冻结。区别只在于：云端厂商在模型之外额外维护了记忆、推荐、历史这些系统，然后把结果包装成“一个聪明的 AI”。本地部署，这些系统就得你自己动手。

1.3 在线产品给你的“聪明”错觉从哪来

你打开 ChatGPT，一个月前问过“我喜欢极简风格的装修”，今天再问它推荐什么沙发，它可能真的会提“你之前说喜欢极简风”。你觉得模型记住了你，存进数据库。Claude 的 Projects、ChatGPT 的 Custom Instructions，本质都一样：产品层把你的人设、偏好、过往对话抽取出来，在下一次请求时作为额外上下文注入。

想明白这层，单机的路就清晰了：本地模型的“学习能力”，90% 要靠你在应用层补。模型本身只做一件事——把你给它的上下文理解透、回答好。那接下来的问题就变成：上下文里能塞什么，塞进去之后它能“学会”什么。这正是下一章要拆解的四种学习形态。

2. 单机模型的四种“学习”形态，先对号入座

2.1 参数微调：唯一真正改变模型本体的学习

第一种是动真格的：参数微调，也就是 LoRA、QLoRA 这类方案。通过给模型喂一批特定格式的数据集，对权重做低秩更新，产出一个新的适配层——不改变原始底座，但推理时叠加这个适配层，模型在某个领域的表现会发生真实改变。

这是唯一一种“模型本体进化”的学习方式。个人电脑上跑得动的通常是 QLoRA，4bit 量化加载，配合 Unsloth 或 LLaMA-Factory 这类工具，一张 RTX 3060 12G 显存就能微调 7B 模型，速度慢一点，但确实能跑。

不过我的态度是：不到万不得已，别一上来就微调。成本不只是硬件。你得准备几百上千条高质量数据集，得清洗、标注、做指令模板，训练完还得评估会不会过拟合、会不会把原来的通用能力给“冲”掉。微调适合的场景非常具体：让模型模仿某种固定写作风格，或者让它精通某个垂直领域的专业话术。如果只是想让它知道某些文档知识，用后面的 RAG 方案性价比高得多。

2.2 上下文记忆：会话里的“临时脑”

第二种是上下文记忆。模型在单次会话里，你说过的话它都“看得见”，这叫上下文窗口。7B 模型现在普遍支持 8K、32K 甚至 128K 上下文，窗口内它能记住你前面聊的所有内容，并且基于这些内容作答。这是模型默认自带的学习能力——会话级学习。

但窗口是有限的，聊长了就会把最早的内容“挤”出去。解决思路是记忆压缩和摘要：聊一段时间，让模型把前面的关键信息浓缩成几百字摘要，作为新的“长期记忆”塞回上下文。再进一步，把摘要持久化到本地文件，下次新会话时重新加载，就实现了跨会话记忆。

本质上，这不算模型会学习了，而是你的应用层替它维护了一本“笔记”。模型每次重新读笔记，表现得像“记得你”。

2.3 知识库检索（RAG）：把参考书放在模型旁边

第三种是 RAG，全称 Retrieval-Augmented Generation，检索增强生成。这是目前单机场景下我个人最推荐的学习方案。原理一句话：让模型带着参考书答题。

具体过程是：把文档切块，用 embedding 模型转成向量，存进本地向量库；用户提问时，把问题也转成向量，在库里做相似度搜索，找出最相关的 3-5 个片段；把这些片段作为“参考资料”拼进用户的提示词，最后交给大模型生成答案。

这套方案妙在：模型权重完全不用变，公司新来了 100 份技术文档，你不用重新训练，只要把文档切片、向量化、入库，模型立刻就“学会”了新知识。而且模型会引用你提供的片段来回答，不太容易胡编，答案来源可追溯。对个人用户来说，这是“本地模型有没有学习能力”的最优解：有，而且是你亲手教它的。

2.4 工具调用（Function Calling）：会查就是会学

第四种更隐蔽：Function Calling，工具调用。模型本身不知道实时天气、不知道数据库里的订单数据、不能替你执行代码，但你可以定义一组函数，告诉模型“当你需要这些信息时，输出一个特定格式的调用请求”。应用层收到请求后，去调外部 API、查本地数据库、跑一段脚本，把真实结果返回给模型，模型基于真实结果继续作答。

这算学习吗？我的看法是，这是一种能力边界的学习：模型不需要把知识装在脑子里，它学会了“遇到什么问题该去哪个工具查”。就像一名员工不需要背下公司所有客户数据，但他知道该打开哪个系统去查。这是单机模型扩展能力非常有效的方式。

四种形态说完，你会发现一个核心真相：本地模型真正缺的不是“学习能力”，而是一个愿意替它搭建学习通路的操盘手——也就是你自己。下一章直接给实操路线。

3. 实操路线：给单机模型搭一套“会学习”的脚手架

3.1 先想清楚你要哪种“学习”

动手之前，先做一个选择题。我整理了一张表，直接按需求对号入座：

我的经验是：单机场景 90% 的需求，用“RAG + 记忆层 + 工具调用”组合就够，微调属于进阶玩法，别一上来就碰。

3.2 基座模型怎么选：R1 还是 Qwen？

选模型直接决定后面体验。我实测了 DeepSeek-R1 系列和 Qwen2.5/Qwen3 系列，感受差异很大：

DeepSeek-R1:7b 的强项是推理，你给它一道逻辑题、一个复杂分析任务，它会先输出一大段思考过程，再给出结论。这个能力在单机 7B 级别的模型里相当难得。但它有两个短板：第一，思考过程会拖慢响应速度，简单问题它也习惯性“反思半天”；第二，工具调用的格式控制不理想，官方本身对 Function Calling 的支持就不如 Qwen 系列来得顺。

Qwen2.5:7b 则是“全能型选手”，日常问答、文本改写、结构化输出、Function Calling 都能担起来，配合工具调用时格外稳定。如果你要玩 RAG + 工具调用的组合拳，我建议基座用 Qwen；如果核心诉求就是让模型帮你做深度分析、论文阅读、复杂逻辑推理，那 R1 更香。

第三方的“本地模型热词”里，还有不少人直接把这两个模型都拉下来，按任务切换。这也是好办法，反正 Ollama 支持多模型共存，哪个任务用哪个。

3.3 从零跑起来：Ollama 部署和那些配置细节

Ollama 是我现在首选的单机部署工具，跨平台、命令行简单、自带 OpenAI 兼容 API。安装没什么说的，官网下载对应系统的安装包即可。重点说配置细节。

先把模型拉下来：

ollama pull deepseek-r1:7b ollama pull qwen2.5:7b

注意模型名一定要带标签，很多人配置报错就是因为写成了deepseek-r1，实际标签是deepseek-r1:7b。拉完直接跑：

ollama run deepseek-r1:7b

这就进交互界面了。但日常使用更推荐走它提供的 HTTP 接口：默认端口 11434，同时暴露了 OpenAI 兼容的/v1/chat/completions端点。这意味着你在任何支持 OpenAI 格式的客户端工具里，只要填上：

Base URL: http://localhost:11434/v1 API Key: ollama（随便填） Model: deepseek-r1:7b

就能把本地模型接进去。Trae、CodeGeeX、Continue 这类工具基本都是这么配置的。Mac 上我实测 M2 16G 内存跑 7B 模型，每秒生成 20-30 个 token，日常问答完全流畅；8G 内存会明显吃紧，建议换 3B/4B 的小模型。

Linux 服务器部署时有个坑：默认只监听 127.0.0.1，局域网内其他机器访问不了。要开放远程访问，设置环境变量：

OLLAMA_HOST=0.0.0.0:11434 ollama serve

Windows 上装完 Ollama 后会在系统托盘常驻，如果改了端口或遇到连接失败，先检查托盘服务是不是活着，再检查防火墙有没有放行 11434。

3.4 加一层轻量 RAG：让模型学会“翻资料”

现在进入正题，怎么让单机模型真正学会你的私有知识。我给一个最简可跑的方案：Ollama + Qwen3-Embedding 嵌入模型 + Chroma 向量库。

首先把 Embedding 模型拉下来：

ollama pull qwen3-embedding:0.6b

这个 0.6B 的嵌入模型对中文语义理解足够用，1024 维向量，本地跑起来毫无压力。接着写一个 Python 脚本，完成“文档入库 + 提问检索”：

import ollama import chromadb # 初始化向量库 chroma_client = chromadb.Client() collection = chroma_client.get_or_create_collection("local_docs") # 1. 文档切片，每个切片就是一个知识点 chunks = [ "智能门锁项目V2.3需求：支持人脸+指纹+临时密码。", "临时密码由管理员在APP生成，有效期默认5分钟，可设置1-30分钟。", "人脸识别在暗光环境下失败率需低于2%。" ] # 2. 逐条生成向量并入库 for i, chunk in enumerate(chunks): res = ollama.embed(model="qwen3-embedding:0.6b", input=chunk) vector = res["embeddings"][0] collection.add( ids=[str(i)], embeddings=[vector], documents=[chunk] )

查询阶段，把问题向量化，去库里找最相似的片段，再交给大模型：

question = "临时密码默认有效期是多少？" q_res = ollama.embed(model="qwen3-embedding:0.6b", input=question) q_vector = q_res["embeddings"][0] results = collection.query(query_embeddings=[q_vector], n_results=2) context = "\n".join(results["documents"][0]) prompt = f"""基于以下参考资料回答问题，如果资料中没有，直接说不知道。 参考资料： {context} 问题：{question} """ completion = ollama.chat( model="deepseek-r1:7b", messages=[{"role": "user", "content": prompt}] ) print(completion["message"]["content"])

这里有个细节要注意：ollama.embed是新版 Python 库的接口，如果你用的是老版本或者命令行调 curl，参数会不太一样。建议安装后先print(res.keys())确认返回值里是embeddings还是embedding，再取对应字段。

嵌入模型对切块策略很敏感。我踩过的经验是：按语义段落切，每块 300-500 字比较稳，太短语义碎片化，太长检索噪声大；相邻块之间可以保留 50-100 字重叠，避免关键句刚好被切断。中文文档尤其注意不要在句子中间硬切，按下句号、问号、换行来切最自然。

3.5 让模型跨会话“记住你”：轻量记忆层

RAG 解决的是“知识记忆”，记忆层解决的是“用户记忆”。想让你搭的单机助手下次开新会话还记得你的偏好、项目背景，这类信息不适合进向量库，更适合一个简单的 JSON 记忆文件。

思路是这样：每次对话结束后，用一个小模型把对话中用户透露的关键信息抽出来，写入memory.json；新会话开始时，把整个 JSON 文件当系统提示词注入模型：

from pathlib import Path import json mem_file = Path("memory.json") memory = json.loads(mem_file.read_text()) if mem_file.exists() else {} # 抽取对话中的用户信息 conversation_log = "用户：我下个月要验收一个智能门锁项目。\n助手：明白了。" extract_prompt = f"""从对话中抽取用户的长期有效信息（偏好、项目、身份、目标）， 只输出JSON，不要解释。对话如下： {conversation_log} """ res = ollama.chat( model="qwen2.5:7b", messages=[{"role": "user", "content": extract_prompt}], format="json" ) new_mem = json.loads(res["message"]["content"]) memory.update(new_mem) mem_file.write_text(json.dumps(memory, ensure_ascii=False, indent=2))

实测下来，用format="json"约束输出格式确实有效，但 7B 小模型偶尔还是会返回无效 JSON，所以解析处一定要包try/except，失败就丢掉这次抽取，不影响主流程。

新会话开始时，把memory.json的内容拼进系统提示词：

system_prompt = "你是我的私人助手。关于用户的长期信息如下：\n" + json.dumps(memory, ensure_ascii=False)

这个方案就是 OpenAI 那些产品“记忆功能”的穷人版，但逻辑是一样的：模型本身不会记，是应用层替它记，用完再注入。

4. 实测记录：投喂知识前后的对比

4.1 测试环境

我实测这套方案用的是一台 M2 MacBook Air 16G 内存，Ollama 里同时装了deepseek-r1:7b和qwen3-embedding:0.6b。测试文档是我手头一份模拟的项目需求说明，包含三块内容：门锁的解锁方式、临时密码规则、人脸识别的性能指标。先测未接 RAG 的效果，再测接上后的效果。

4.2 不接 RAG：问私有文档内容的翻车实录

不接任何检索，直接问模型：“临时密码的有效期默认是多久？”

模型给出的回答是：“根据常见产品设计，临时密码有效期通常设置为 24 小时，但具体需要参考实际产品文档。”

这个答案看起来“像那么回事”，其实是编的。资料里明明写着默认 5 分钟，模型没看过资料，只能基于训练数据里的通用印象瞎猜。这是大模型最坑的地方：它不知道就是不知道，但会一本正经地编。不做 RAG 的知识问答，本质上是在赌模型猜得准不准，纯碰运气。

我又问了一个更偏内部细节的问题：“暗光环境下人脸识别失败率要求是多少？”模型甚至直接开始解释人脸识别技术原理，完全跑偏。

4.3 接上 RAG：同一个问题的回答变化

接上前面那套 RAG 流程后，同样的问题结果完全不一样：

问“临时密码的有效期默认是多久？”模型回答：“根据文档，临时密码有效期默认为 5 分钟，管理员可在 APP 中设置 1-30 分钟。”而且回答后面还能带上一句“以上内容来自你提供的人脸识别相关资料”，不装懂、不编造，回答有出处。

问“暗光环境下失败率要求”时，检索到的片段准确命中了那句“人脸识别在暗光环境下失败率需低于 2%”，模型直接引用。整个体验从“一个爱胡说八道的陌生人”变成了“一个翻着你的笔记回答问题的助手”。

这就是 RAG 的价值：你不需要让模型“记住”你的文档，你只需要在它回答时把文档放到它面前。单机模型的学习能力，本质上是系统层的检索能力，不是模型记忆能力。

4.4 跨会话“记住你”的效果

在加了 JSON 记忆层之后，我做了个简单的跨会话测试：第一次会话里说“我的项目代号叫麒麟”，第二次开新会话直接问“你记得我的项目代号吗？”

没有记忆层时，模型一头雾水：“我们没有聊过这个，请问你的项目代号是什么？”有记忆层时，系统提示词里注入了上次抽取的信息，模型直接回答“你的项目代号是麒麟”。

这个效果非常实用。做成私人助理后，你今天告诉它“我喜欢极简风格的设计方案”，明天它就真的能在你问设计建议时引用这个偏好。虽然技术原理非常朴素，但对终端体验的提升是几何级的。

5. 边界与翻车点：哪些“学习”单机真做不到

5.1 权重不会自动更新，离线训练同样要你主动做

必须说清楚一个边界：单机模型永远不可能像人一样，用着用着自己就变强。模型权重一旦部署，就冻结了。你搭了 RAG、加了记忆层，它回答得再好，也只是“外部系统替它记住了内容”，模型本身的参数一个没动。

要让模型本体变聪明，只有微调一条路，而微调必须你主动准备数据、跑训练、出适配层、重新加载。这个过程不是“用”出来的，是“炼”出来的。所以如果一个人说“我本地模型用了一个月，怎么感觉它逻辑水平没有提升”，这是正常的，它当然不会自动提升。想提升，认认真真去做 LoRA。

我的建议是：日常使用优先完善 RAG 和工具调用，这俩能解决 80% 的“模型不懂我”问题；微调之类的投入，等积累了大量高质量数据、明确知道模型哪里不够用时再上。

5.2 R1 系列工具调用的坑：想玩 Function Calling 建议换模型

这是我在实测中踩得最深的坑。一开始想用 DeepSeek-R1:7b 做工具调用，定义了一个“查询天气”的函数，结果模型要么输出一大段思考内容然后给的调用参数格式不对，要么直接说“我无法获取实时天气”。调了很久，把提示词写得再清楚也没用。

后来查资料才发现：R1 系列的设计重心在推理链，输出格式本身就不适合严格的工具调用协议。这不是配置问题，是模型特性问题。换回qwen2.5:7b之后，工具调用一次通过，函数名、参数、JSON 格式都规规矩矩。

所以选基座模型的原则是：偏推理分析选 R1，偏工具调度和数据提炼选 Qwen。硬让一个推理模型去做“执行调度”的活，体验会非常拧巴。

5.3 工具链配置报错：CodeGeeX、WorkBuddy、Trae 的共性问题

热词里出现不少“vscode codegeex配置本地模型连接错误”“workbuddy保存本地模型配置失败”这类问题，我统一说下排查方向。这些工具接本地模型时，本质上都是填一个 OpenAI 兼容端点，所以 80% 的报错原因高度一致：

第一，Ollama 服务没起来，或者端口被占用。先用浏览器访问http://localhost:11434，能看到Ollama is running就说明服务正常。

第二，模型名写错。填deepseek-r1不行，必须是 Ollama 列表里的完整标签，用ollama list查一下自己到底有哪些模型。

第三，跨域和监听地址问题。某些工具从浏览器发起请求，Ollama 默认的 CORS 配置会拦。临时解决方法是启动时设置：

OLLAMA_ORIGINS=* ollama serve

这种只建议本地调试用，别在生产环境放开。

先照着这三步排查，大概率能解决一大半“连接错误”“配置失败”。实在不行就开一个终端，用最简单的 curl 命令测 API，把问题定位在“模型服务”还是“客户端配置”哪一端：

curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"deepseek-r1:7b","messages":[{"role":"user","content":"你好"}],"stream":false}'

能返回完整 JSON 就说明模型服务没问题，问题出在客户端填参方式上。

5.4 硬件选型的现实衡量

最后说下硬件。很多人问“我到底要什么配置才能本地跑模型”，我直接说实测结论：

7B 模型量化到 Q4_K_M 大约是 4.7GB 权重文件，加上推理时的 KV Cache 和运行时开销，16GB 内存/显存的机器跑起来比较从容。Mac 的统一内存架构有天然优势，M 系列芯片 16G 内存跑 7B 模型流畅度优于同价位的 CPU 笔记本。Windows 加显卡的话，NVIDIA 显卡优先，12G 显存能愉快跑 7B，也能勉强试 13B 量化；32B 级别的模型强烈建议 24G 以上显存。

纯 CPU 跑 7B 可以启动，但生成速度会让人崩溃，一分钟蹦几个字。如果你只有一台普通办公电脑，建议先从qwen2.5:3b或deepseek-r1:1.5b这样的模型开始，先把流程跑通，再考虑升级硬件。

这些边界和坑，我都是实际撞过墙之后才总结出来的。把期望值放对位置，单机模型能带给你的惊喜远大于失望。

最后再分享一个小技巧：本地模型和云端 API 可以混用。我在同一个工具里配置了 Ollama 本地端点和云端 API 两个后端，日常问答、RAG 检索走本地，复杂的长文写作和代码生成走云端。这样既保住了数据的私密性，又能在需要强能力时随时调用更大更聪明的模型。单机不是一座孤岛，它该是你 AI 工具链里的一个稳定支点。