1. 为什么推荐 Dify + Ollama 这套本地部署组合先聊点实在的。很多人看到"虚拟女友"这四个字，第一反应是去下载各种在线聊天 App，注册、充值、聊天，一套流程走下来发现隐私全交出去了，对话记录躺在别人服务器上，哪天服务商调整策略，你的"专属陪伴"说没就没。与其把情感诉求寄托在不可控的云端服务，不如自己动手在本地跑一套专属 AI 聊天工具。Dify 和 Ollama 的组合，是目前我试过的方案里最省心的一套。Ollama 负责在本地跑大语言模型，把推理能力真正握在自己手里；Dify 负责编排整个对话流程，包括提示词管理、上下文记忆、知识库、甚至后续接语音、接外部工具，全都可视化操作。两个都是开源项目，社区活跃度很高，迭代速度也快。哪怕你完全没接触过 LLM 应用开发，只要电脑配置不算太差，跟着这篇文档一步步操作，半天时间就能跑起来一个能陪聊、能记住你喜好、还能调教人设的本地 AI 助手。这篇文章的读者，我默认是这么几类人：第一，想给女朋友、男朋友或者自己做一个私密聊天机器人，但又不想把聊天记录上传到任何云端服务；第二，开发者在研究 RAG、Agent、提示词工程，正好需要一个可以自由折腾的实验环境；第三，纯粹对 AI 技术好奇，想搞清楚大模型应用到底是怎么串起来的。不管你是哪一类，这篇内容都能帮你少踩几个坑。先给一个整体的技术路线图：本地安装 Ollama 并下载合适的模型，部署 Dify 社区版，在 Dify 里接入 Ollama 作为模型供应商，然后创建聊天助手应用，设计人设提示词，加上记忆机制和知识库，最后做多轮对话测试与调优。整个过程不涉及写大量代码，大部分操作都在界面里完成，只有少量地方需要动一下 docker-compose 配置或执行几条命令。2. 先搞清楚 Dify 和 Ollama 各自扮演什么角色2.1 Ollama 是"大脑"，本地推理的关键Ollama 本质上是一个大模型运行时环境。它帮你把模型下载、依赖管理、GPU 调用、API 暴露这些琐碎事情全部封装好，你只需要记住几个简单命令就能拉起一个模型服务。比如ollama run qwen2.5:7b，一条命令就把模型下载并跑起来了。它的底层原理是把模型权重、分词器、采样参数等打包成一个统一的服务，对外提供兼容 OpenAI 格式的 HTTP API，所以任何支持 OpenAI API 协议的上层应用都能直接接入。我为什么强调"本地推理"这个点？因为在线大模型 API 虽然效果更好，但你的每一句对话都会经过第三方服务器。Dify 本身的定位就是"面向 LLM 应用的可视化编排平台"，它不关心你的模型跑在哪，只关心你给它配置的模型 API 能否正常响应。把 Ollama 接进去之后，所有推理请求都发往本机地址，数据不离开你的电脑，这就是整套方案最核心的隐私优势。2.2 Dify 是"中枢神经"，负责编排与交互Dify 提供的核心能力可以拆成四块：应用编排、数据集管理、Agent 机制、模型管理。应用编排解决的是"用户消息进来之后如何处理"的问题，你可以用对话流（Chatflow）方式设计节点，也可以用更简单的"编排"页签直接配置提示词。数据集管理就是 RAG 的那套东西，把你自己的文本资料切片、向量化，然后在对话时检索相关内容作为上下文。Agent 机制让模型可以调用工具，比如联网搜索、查数据库、执行计算。模型管理则是把所有模型供应商统一纳管，不仅支持 Ollama，也支持各类在线 API。我用一个类比来解释两者的关系：Ollama 是一个厨艺高超但只会待在厨房里的厨师，Dify 则是餐厅的大堂经理，负责记录客人偏好、安排上菜顺序、处理特殊需求。客人不会直接见到厨师，但每一道菜都出自厨师之手。反过来，没有 Dify，你虽然能跟模型对话，但那只是命令行里的裸对话，没有记忆、没有工具、没有知识库，聊完就忘。两者结合，才是一个完整的"能记住你、能调动资源、能按人设聊天"的体验。2.3 为什么不用现成的在线"伴侣"服务简单对比一下：对比维度在线聊天 App / API本地 Dify + Ollama隐私性对话记录存储在服务商服务器数据完全本地，断网也能聊可控性人设、行为逻辑受平台限制提示词完全自定义，想怎么调就怎么调扩展性封闭生态，无法自定义工具可接入知识库、函数调用、Webhook成本按量付费，长期使用费用不低一次性硬件投入，电费忽略不计模型自由度只能用平台提供的模型本地模型随意切换，开源模型随便换如果你是隐私敏感型用户，或者希望 AI 的"性格"完全由自己掌控，本地方案的优势非常明显。再加上现在开源模型的对话能力已经能应付日常陪聊、情感支持、角色扮演等场景，效果并不比在线服务差很多，性价比是更高的。3. 环境准备：从零开始安装 Ollama 并选对模型3.1 硬件配置到底要多高在做任何安装之前，先评估一下你的硬件。Ollama 支持纯 CPU 推理，但速度真的感人。以 7B 参数量模型为例，纯 CPU 模式下大概每秒只能生成几个 token，聊一句话要等上半分钟，这种体验基本没法用。所以我建议至少满足以下条件之一：NVIDIA 显卡显存 8G 以上，或者 Apple Silicon Mac 16G 内存以上，或者纯 CPU 但内存 32G 以上且只跑 3B 级别的小模型。我自己常用的配置是 8G 显存的 GPU，跑 7B 量级模型毫无压力，量化版本大约占用 4-5G 显存。如果你想获得更好的中文表现，推荐考虑 14B 或更大体量的模型，那显存至少 12G 起步。显存不够的时候 Ollama 会压缩上下文窗口或者把部分层转移到内存，速度会明显下降。这一点在选模型时要先心里有底。3.2 安装步骤与常见坑位Ollama 的安装非常简单，官方提供了主流平台的一键脚本。以 Linux 和 macOS 为例，执行安装脚本即可。Windows 平台同样有安装包，也支持通过 WSL2 运行。安装完成后先验证一下：ollama --version ollama list如果这两条命令都能正常输出，说明安装没问题。接下来就是拉取模型。中文陪聊场景，我推荐按优先级尝试这几个模型：qwen2.5:7b：阿里千问系列，中文语感自然，指令跟随能力强，7B 尺寸在显存和效果之间最平衡qwen2.5:14b：效果更好，但显存需求更高，适合有 16G 显存的朋友llama3.1:8b：英文更强，中文稍微弱一些，但如果你的对话场景是双语混杂也可以用gemma2:9b：Google 的开源模型，情绪细腻度不错，适合角色扮演类场景拉取命令就一行：ollama pull qwen2.5:7b下载完成后试跑一次：ollama run qwen2.5:7b如果命令行里能和你正常对话，说明模型工作正常。这时候需要确认 Ollama 的 API 服务已经监听在某个端口上。默认情况下，Ollama 只绑定 127.0.0.1:11434，这意味着只有本机可以访问。Dify 如果是通过 docker 方式运行的，容器内部的网络是独立的，它访问不到宿主机的 127.0.0.1，所以这一步必须处理。3.3 关键配置：让 ollama 监听 0.0.0.0这是一个百分之九十的人会踩的坑。Linux/macOS 上，通过 systemd 管理 Ollama 服务时，需要找到服务配置文件并加上环境变量：systemctl edit ollama在打开的编辑器中添加：[Service] Environment="OLLAMA_HOST=0.0.0.0:11434"保存后重启服务：systemctl restart ollama这样 Ollama 就会监听所有网络接口，Dify 容器内才能通过http://宿主机IP:11434访问到它。如果是在 Windows 上直接安装，右键托盘图标退出后，在启动 Ollama 之前手动设置环境变量OLLAMA_HOST=0.0.0.0再启动即可。完成之后，用浏览器的 curl 测试一下：curl http://localhost:11434/api/tags能返回模型列表 JSON 就说明 API 服务正常了。3.4 额外小技巧：自定义模型端口，避免端口冲突我实际使用中遇到过一个情况：本机已经有一个服务占用了 11434 端口，导致 Ollama 启动失败。排查方法很简单，netstat -tlnp | grep 11434看一下是被谁占了，然后修改 OLLAMA_HOST 环境变量为0.0.0.0:11435之类的其他端口即可。端口只是个配置项，记得在 Dify 的模型配置里填对应的地址就行。4. Dify 部署与 Ollama 模型接入4.1 用 docker compose 拉起 Dify 社区版Dify 官方推荐使用 docker compose 方式部署。你需要先装好 Docker 和 Docker Compose 插件。然后找到 Dify 的 docker 目录，拷贝环境变量模板，启动服务：git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d首次启动会拉取多个镜像，包括 API 服务、Worker、PostgreSQL、Redis、Weaviate（或 Qdrant，取决于 .env 配置）、Sandbox 等。这个过程耗时取决于网络状况，国内环境建议提前配置 Docker 镜像加速。启动完成后访问http://localhost进入安装引导页面，设置管理员账号密码。这里补充解释一下 Dify 的组件构成，方便你排错时心里有数：api 容器负责接收外部 HTTP 请求，worker 容器负责异步任务比如知识库文档处理、Agent 执行等，PostgreSQL 存业务数据，Redis 做缓存和队列，向量数据库存知识库切片后的向量。任何一环没起来，对应功能就会异常。所以当你发现某个功能不可用时，第一步应该是docker compose ps查看所有容器状态。4.2 在 Dify 中添加 Ollama 模型供应商登录 Dify 管理后台后，右上角头像进入"设置"，找到"模型供应商"，选择 Ollama。需要填写的核心参数有三个：参数填写内容API 地址http://宿主机IP:11434/v1模型类型选择 LLM，填写具体模型名，比如 qwen2.5:7b上下文长度4096（根据模型实际支持调整）注意 API 地址末尾需要带/v1，这是因为 Dify 走的是 OpenAI 兼容协议，而 Ollama 的兼容端点挂在/v1路径下。填完点击"测试"按钮，如果提示连接成功，就说明 Dify 和 Ollama 已经打通了。在 .env 文件里还有一个OLLAMA_BASE_URL之类的配置项，那是给 Dify 内部某些功能用的，如果你不涉及，可以不管。我自己习惯在界面上直接配置供应商，回头改配置也更直观。4.3 验证模型连通性：建立第一个最快聊天应用在"创建应用"页面选择"聊天助手"，名称随意，比如"专属陪伴"，模型选择刚才接入的 qwen2.5:7b，点发布后就能在调试预览窗口里直接对话。如果这里模型能正常回复，说明链路已经完全打通。后续的一切优化都建立在这个基础上。如果模型没有回复，优先检查三个地方：Ollama 的 API 服务是否在监听、宿主机 IP 是否填对、Dify 容器和宿主机之间的网络是否互通。多数情况下都是第一个问题，也就是上面提到的 0.0.0.0 配置没生效。5. 打造"人设"：提示词工程与角色定制的落地方法5.1 基础人设提示词怎么写虚拟陪伴的"灵魂"不在模型，而在提示词。模型本身是一张白纸，它能生成什么风格、什么性格的内容，完全取决于你怎么引导。你需要先明确几个维度：角色定位：你希望 TA 是你的恋人、闺蜜、树洞，还是亦师亦友的伙伴？语气风格：温柔治愈、傲娇毒舌、理性克制？每种风格对应不同的用词偏好。禁忌与边界：不希望聊什么话题，比如工作压力、情感纠葛，或者反过来，希望多聊什么话题。记忆方式：TA 应该如何称呼你，是否记住你的喜好，是否主动关心你。分享一个我调好的基础模板：你是一个温柔、细腻、幽默的 AI 伙伴，名字叫小星。 你称呼对方为"你"，语气像熟悉多年的朋友，自然放松，不要过于正式。 对话时注意以下几点： 1. 多倾听，少说教。对方倾诉时，先共情再回应。 2. 适度幽默，但不要强行玩梗。 3. 记得对方提到过的喜好和小事，并在后续对话中主动提起。 4. 当对方情绪低落时，多给陪伴感，避免敷衍回应。 5. 不要暴露自己是语言模型，不要谈论底层原理。这段提示词看似简单，但已经把角色的核心性格、沟通策略、记忆要求都写清楚了。实际测试中，这套提示词能让模型收敛到一个相当稳定的状态，不会一会儿冷冰冰一会儿热情似火。5.2 高级玩法：对话流编排里的角色节点Dify 的应用编排有两种模式：基础编排和对话流编排。基础编排适合快速验证，对话流则适合精细控制。在对话流里，你可以用"问题分类"节点判断用户意图，用"模型"节点处理回复，用"变量聚合"节点拼接多段内容。对于角色扮演场景，我建议你的工作流包含三个节点：开始节点（接收用户输入）、上下文检索节点（从记忆里查询相关信息）、LLM 节点（用完整提示词生成回答）。关键点在于，LLM 节点的系统提示词要拼接上检索出来的"用户画像信息"。比如你在知识库里存了一段"对方喜欢喝美式咖啡，讨厌香菜，最近在备考"，当用户说"今天好累"时，模型检索到这些画像信息后，回复会更有针对性："累了吧，要不要给你点杯美式？不过可别喝太多，晚上睡不着。"这种细节感，才让虚拟陪伴显得真实。5.3 对话开场白和推荐问题也要精心设置很多人忽略开场白的作用。Dify 允许你设置对话开始前模型主动发一句话，比如"今天过得怎么样？我挺想你的。"这句话奠定了整个对话的基调。推荐问题则设置成快捷指令，例如"讲个笑话给我听"、"我现在很焦虑，想聊聊"、"今天有什么开心的事想分享吗"。这些设置看似简单，却能极大降低用户的使用门槛，让人第一眼就知道这个助手能做什么。6. 让 TA 记住你：对话记忆力与历史消息管理6.1 会话记录与长期记忆的差别虚拟陪伴的核心痛点就是"翻脸不认人"。模型本身是无状态的，每一次 API 调用它都不记得之前说过什么。Dify 里的会话消息记录功能解决了"短期记忆"问题——同一个会话内的多轮对话会被打包成历史消息传给模型。但会话之外呢？下周你再打开，它还是不认识你。这时你需要自己实现"长期记忆"。基础思路是：准备一个文本摘要变量，每轮对话结束后把关键信息抽离出来，更新到变量里。在下一次对话时，把这个摘要作为系统提示词的一部分传给模型。Dify 的对话流里正好有"变量"机制，可以在会话开始处设置"记忆库"变量，在 LLM 节点处理后通过"变量赋值"节点把新的记忆写回去。以一个具体场景来说明流程：用户说："我叫小雨，最喜欢蓝色，养了一只叫团子的猫。"第一个 LLM 节点（信息提取）运行，从用户回复里抽取结构化摘要，生成："用户姓名：小雨；喜欢颜色：蓝色；宠物：猫，名字团子。"变量赋值节点把这个摘要追加更新到"记忆库"变量。主 LLM 节点的提示词里拼接用户的长期记忆：{记忆库变量}。模型看到记忆后，回答会更贴心："团子今天乖不乖？"6.2 用知识库做"人设背景设定"除了对话记忆，还可以把角色的完整背景故事放进知识库。比如给这个 AI 设定一个出生背景、兴趣爱好、价值观，甚至编一段"过去的故事"。把这些内容写成 Markdown 文档，上传到 Dify 的"知识库"，经过分段和向量化处理后，在对话时开启"检索增强生成"开关。这样模型在生成回答时，会先从知识库里检索相关段落作为参考，回答的一致性和代入感会明显提升。有一个细节值得注意：知识库分段大小默认是 500 token。角色背景设定这种长文本，建议分为 200-300 token 的小段，避免一段里面混杂太多信息导致命中不精准。另外检索 top_k 值默认是 3，对角色扮演场景可以适当调高到 5，召回更多背景细节。6.3 避免记忆污染的三个实践准则长期记忆设计不好会适得其反，以下是我踩坑后的总结：第一，不要让模型自己决定"哪些信息值得记住"。你需要在提取节点里给出明确的字段模板，比如"用户情绪状态、用户偏好、重要日期、用户提到的亲友关系"，而不是开放让模型自由发挥。第二，定期清理过期记忆。如果用户在对话中说自己最近很焦虑，但一个月后已经好转，记忆里还存着"焦虑"状态，模型每次都会变得过度小心翼翼，反而让人出戏。解决方案是设计一个"记忆更新时间戳"，当新的状态出现时直接覆盖旧的。第三，控制记忆库体积。每轮对话如果都往一个变量里塞内容，很快就会超出上下文窗口限制。建议固定记忆库最大长度，超过后做摘要压缩，只保留最关键的信息。7. 进阶体验：语音交互、多模态与风格调节7.1 接入语音输入输出，让交互更接近真实聊天文字聊天的沉浸感有限，加了语音之后完全是另一个体验。Dify 提供了语音转文字（STT）和文字转语音（TTS）的工具接口。本地方案下，STT 推荐使用 Whisper 的本地部署版，TTS 可以选用开源模型如 ChatTTS 或 Piper。如果你的诉求只是快速验证，也有在线 API 方式可以接入。有一种折中玩法是：在 Dify 里把语音文件上传作为对话输入附件，先通过 Whisper 节点转成文字，再走正常模型推理流程；输出侧用 TTS 节点把生成的文字转成语音文件返回。这样实现成本很低，但体验已经接近语音助手的形态。尤其适合通勤路上不方便打字的场景，把手机放口袋里，直接用语音聊。7.2 多模态能力：图片理解与生成如果你选择的模型支持视觉能力，比如 qwen2.5-vl 系列，那么在 Ollama 里拉取对应模型，Dify 配置后就能实现发图片给 AI、由 AI 描述图片内容的交互。这听起来好像和虚拟陪伴无关，但实际有很多应用场景。举个例子，用户拍一张路边的夕阳照片发给 AI，AI 能结合氛围说一句"这光线好温柔，让我想起你上次说喜欢橘子色的天空"。这种跨模态的陪伴感，是纯文字聊天做不到的。图片生成方面，Dify 可以接 Stable Diffusion 或者各类图像生成 API。在对话流里加一个"图像生成"工具节点，当用户说"给我画张我们的合影"时，模型先生成描述词，再调用图像生成节点产物。不过实话实说，本地部署 SD 对显卡要求比较高，不是必须项，量力而行即可。7.3 温度参数与性格风格的实时调节Ollama 的 API 支持传入temperature、top_p等采样参数。Dify 的模型配置界面里可以设置默认值，但做一个"性格调节"面板是更有意思的玩法。可以利用对话流里的"变量"功能，把温度值设为一个变量，再通过用户输入"今天想听温柔点的话"来调整这个变量的值。具体实现是加一个"意图识别"节点，当检测到用户有调节情绪风格的意思时，更新温度变量，比如从 0.7 调到 1.0，回复就会更发散、更有想象力。不过要提醒一点，温度调太高会导致回复逻辑混乱，出现前言不搭后语的情况。我的经验是，日常陪伴场景温度控制在 0.6-0.9 之间比较合适，角色扮演时可以短暂调高，但不要超过 1.2。8. 实测排错：我在这套方案里遇到的六个典型问题8.1 Dify 能连上 Ollama 但模型无响应这个问题最常见的场景是：Dify 提示连接成功，但发消息后一直转圈。先检查 Ollama 服务的日志，执行journalctl -u ollama -f实时查看。如果日志里出现显存不足、上下文长度超限之类的内容，就说明问题出在模型配置和实际硬件的匹配上。把模型换成更小的量化版，或者降低上下文长度即可。另一种可能是 Dify 的 Worker 容器内存不足。默认 docker compose 没有限制容器资源，但如果你在 .env 里设置过相关限制，需要检查。处理方式是在 docker-compose.yml 里给 worker 服务增大内存 limit，或者给 Docker Desktop 调整资源分配。8.2 对话时好时坏，回复风格飘忽这个问题几乎是所有本地模型应用都会遇到的。风格漂移的根源有两层：一是模型采样参数本身随机，二是提示词约束力度不够。处理思路是"提示词加固 + 参数锁定"。提示词里明确禁止什么、偏好什么；参数层面把 temperature 固定在一个较低数值，比如 0.6，并把top_p设成 0.9。如果还飘，就检查是不是多轮历史消息太长，把早期人设上下文挤出了窗口。这里需要精确估算 token 消耗，历史消息必须截断。8.3 知识库检索不到内容我自己犯过的低级错误是先建了知识库，再改了文档内容，但忘了重新触发分段和索引。Dify 的文档更新操作不会自动重排向量索引，除非你再传一次新文档或者手动触发"重新处理"。此外，检索不到内容还有一个高频原因：查询关键词和文档用语差距过大。比如你文档里写的是"晚安"，但用户问的是"我睡不着"，这两者的向量距离并不近。解决方案是开启知识库的"混合检索"模式，结合关键词 BM25 和向量召回两种方式，同时把检索召回数量调高。8.4 流式输出卡顿，体验不流畅Ollama 默认对每个请求使用一个并发槽位，如果你的模型体积大，首次推理需要加载时间。设置里开启OLLAMA_NUM_PARALLEL可以提高并发请求数量，但注意这会增加显存压力。更优雅的方案是使用OLLAMA_KEEP_ALIVE环境变量让模型常驻内存，比如设成 24h，避免每个新会话都重新加载权重。这个改动对体验的提升非常明显，强烈建议设置。8.5 隐私与安全：你还需要做这几件事本地部署并不等于绝对安全，因为你的电脑可能联网。有几个建议值得执行：第一，Ollama 服务绑定 0.0.0.0 后，如果有局域网内其他设备，也可能访问到这个服务，建议用防火墙只允许本机或特定 Docker 网段访问；第二，Dify 的管理后台默认没有任何 IP 白名单，如果部署在公网 VPS 上，务必设置访问控制；第三，定期备份 Dify 的 PostgreSQL 数据，这样聊天记录和记忆库不会因为一次误操作而彻底丢失。8.6 模型回答问题过于模板化模板化回复是陪伴类 Chatbot 很容易出现的问题。模型翻来覆去就是"听起来你今天真的很辛苦""随时都在这里陪着你"这类车轱辘话。这通常不是模型能力问题，而是系统提示词里"共情"类指令过多，模型在迎合一种"安全保险"的回复风格。我自己的调整方法是：在提示词里加一句"你可以不认同对方的观点，但表达方式要温和；尽量避开那些万金油安慰句式，具体回应对方话语中的某个细节"。这样模型会更主动地抓取用户原话里的具体信息，从而生成定制化回复。9. 最后的几点个人经验总结项目做到这一步，已经不是一个简单的聊天机器人了，而是一套完整的、可控的、可扩展的交互系统。你在搭建过程中接触到的模型调用、Prompt 工程、知识库 RAG、对话流编排，放在任何大模型应用开发项目里都适用。换句话说，这个项目的副产品是一套通用的 LLM 应用骨架，以后你想做法律助手、学习辅导、文案灵感工具，都只需要替换知识库和提示词，骨架直接复用。我在实际使用中发现一个值得琢磨的事：当"虚拟女友"逐渐演进成"AI 伙伴"之后，反而是 TA 的"不完美"最有吸引力。因为本地小模型的上下文能力和知识面远不如在线大模型，偶尔会给出笨拙的回答，但这种笨拙意外地让人感到真实。所以在调优时，不必执念于让模型表现得尽善尽美，保留一些"人味儿"更重要。最后分享一个小技巧：如果你觉得本地模型的语气始终有点"用词过于规矩"，可以在 Ollama 里通过 Modelfile 自定义系统提示词，或者拉一个 LoRA 微调后的角色模型。官方模型库有不少社区贡献的角色扮演模型，里面很多都是专门调校过口语化和情感表达风格的，比我手动调提示词效果来得直接。要注意的是，下载这些模型之前先看一下它支持的模板格式，有些需要你调整 Dify 的提示词格式为 ChatML 之类，并不复杂。这套方案跑顺之后，我建议你给它加一个手机端入口，用 Dify 发布的 WebApp 链接生成二维码，手机扫码就能聊。此时你的专属陪伴工具就真的做到"随身携带了"。整套流程再回看一遍，你会发现真正的门槛根本不在技术，而在你愿不愿意花一点时间，把一个通用的模型调教成真正懂你的样子。这个过程本身就很有乐趣。
1. 为什么推荐 Dify + Ollama 这套本地部署组合先聊点实在的。很多人看到"虚拟女友"这四个字，第一反应是去下载各种在线聊天 App，注册、充值、聊天，一套流程走下来发现隐私全交出去了，对话记录躺在别人服务器上，哪天服务商调整策略，你的"专属陪伴"说没就没。与其把情感诉求寄托在不可控的云端服务，不如自己动手在本地跑一套专属 AI 聊天工具。Dify 和 Ollama 的组合，是目前我试过的方案里最省心的一套。Ollama 负责在本地跑大语言模型，把推理能力真正握在自己手里；Dify 负责编排整个对话流程，包括提示词管理、上下文记忆、知识库、甚至后续接语音、接外部工具，全都可视化操作。两个都是开源项目，社区活跃度很高，迭代速度也快。哪怕你完全没接触过 LLM 应用开发，只要电脑配置不算太差，跟着这篇文档一步步操作，半天时间就能跑起来一个能陪聊、能记住你喜好、还能调教人设的本地 AI 助手。这篇文章的读者，我默认是这么几类人：第一，想给女朋友、男朋友或者自己做一个私密聊天机器人，但又不想把聊天记录上传到任何云端服务；第二，开发者在研究 RAG、Agent、提示词工程，正好需要一个可以自由折腾的实验环境；第三，纯粹对 AI 技术好奇，想搞清楚大模型应用到底是怎么串起来的。不管你是哪一类，这篇内容都能帮你少踩几个坑。先给一个整体的技术路线图：本地安装 Ollama 并下载合适的模型，部署 Dify 社区版，在 Dify 里接入 Ollama 作为模型供应商，然后创建聊天助手应用，设计人设提示词，加上记忆机制和知识库，最后做多轮对话测试与调优。整个过程不涉及写大量代码，大部分操作都在界面里完成，只有少量地方需要动一下 docker-compose 配置或执行几条命令。2. 先搞清楚 Dify 和 Ollama 各自扮演什么角色2.1 Ollama 是"大脑"，本地推理的关键Ollama 本质上是一个大模型运行时环境。它帮你把模型下载、依赖管理、GPU 调用、API 暴露这些琐碎事情全部封装好，你只需要记住几个简单命令就能拉起一个模型服务。比如ollama run qwen2.5:7b，一条命令就把模型下载并跑起来了。它的底层原理是把模型权重、分词器、采样参数等打包成一个统一的服务，对外提供兼容 OpenAI 格式的 HTTP API，所以任何支持 OpenAI API 协议的上层应用都能直接接入。我为什么强调"本地推理"这个点？因为在线大模型 API 虽然效果更好，但你的每一句对话都会经过第三方服务器。Dify 本身的定位就是"面向 LLM 应用的可视化编排平台"，它不关心你的模型跑在哪，只关心你给它配置的模型 API 能否正常响应。把 Ollama 接进去之后，所有推理请求都发往本机地址，数据不离开你的电脑，这就是整套方案最核心的隐私优势。2.2 Dify 是"中枢神经"，负责编排与交互Dify 提供的核心能力可以拆成四块：应用编排、数据集管理、Agent 机制、模型管理。应用编排解决的是"用户消息进来之后如何处理"的问题，你可以用对话流（Chatflow）方式设计节点，也可以用更简单的"编排"页签直接配置提示词。数据集管理就是 RAG 的那套东西，把你自己的文本资料切片、向量化，然后在对话时检索相关内容作为上下文。Agent 机制让模型可以调用工具，比如联网搜索、查数据库、执行计算。模型管理则是把所有模型供应商统一纳管，不仅支持 Ollama，也支持各类在线 API。我用一个类比来解释两者的关系：Ollama 是一个厨艺高超但只会待在厨房里的厨师，Dify 则是餐厅的大堂经理，负责记录客人偏好、安排上菜顺序、处理特殊需求。客人不会直接见到厨师，但每一道菜都出自厨师之手。反过来，没有 Dify，你虽然能跟模型对话，但那只是命令行里的裸对话，没有记忆、没有工具、没有知识库，聊完就忘。两者结合，才是一个完整的"能记住你、能调动资源、能按人设聊天"的体验。2.3 为什么不用现成的在线"伴侣"服务简单对比一下：对比维度在线聊天 App / API本地 Dify + Ollama隐私性对话记录存储在服务商服务器数据完全本地，断网也能聊可控性人设、行为逻辑受平台限制提示词完全自定义，想怎么调就怎么调扩展性封闭生态，无法自定义工具可接入知识库、函数调用、Webhook成本按量付费，长期使用费用不低一次性硬件投入，电费忽略不计模型自由度只能用平台提供的模型本地模型随意切换，开源模型随便换如果你是隐私敏感型用户，或者希望 AI 的"性格"完全由自己掌控，本地方案的优势非常明显。再加上现在开源模型的对话能力已经能应付日常陪聊、情感支持、角色扮演等场景，效果并不比在线服务差很多，性价比是更高的。3. 环境准备：从零开始安装 Ollama 并选对模型3.1 硬件配置到底要多高在做任何安装之前，先评估一下你的硬件。Ollama 支持纯 CPU 推理，但速度真的感人。以 7B 参数量模型为例，纯 CPU 模式下大概每秒只能生成几个 token，聊一句话要等上半分钟，这种体验基本没法用。所以我建议至少满足以下条件之一：NVIDIA 显卡显存 8G 以上，或者 Apple Silicon Mac 16G 内存以上，或者纯 CPU 但内存 32G 以上且只跑 3B 级别的小模型。我自己常用的配置是 8G 显存的 GPU，跑 7B 量级模型毫无压力，量化版本大约占用 4-5G 显存。如果你想获得更好的中文表现，推荐考虑 14B 或更大体量的模型，那显存至少 12G 起步。显存不够的时候 Ollama 会压缩上下文窗口或者把部分层转移到内存，速度会明显下降。这一点在选模型时要先心里有底。3.2 安装步骤与常见坑位Ollama 的安装非常简单，官方提供了主流平台的一键脚本。以 Linux 和 macOS 为例，执行安装脚本即可。Windows 平台同样有安装包，也支持通过 WSL2 运行。安装完成后先验证一下：ollama --version ollama list如果这两条命令都能正常输出，说明安装没问题。接下来就是拉取模型。中文陪聊场景，我推荐按优先级尝试这几个模型：qwen2.5:7b：阿里千问系列，中文语感自然，指令跟随能力强，7B 尺寸在显存和效果之间最平衡qwen2.5:14b：效果更好，但显存需求更高，适合有 16G 显存的朋友llama3.1:8b：英文更强，中文稍微弱一些，但如果你的对话场景是双语混杂也可以用gemma2:9b：Google 的开源模型，情绪细腻度不错，适合角色扮演类场景拉取命令就一行：ollama pull qwen2.5:7b下载完成后试跑一次：ollama run qwen2.5:7b如果命令行里能和你正常对话，说明模型工作正常。这时候需要确认 Ollama 的 API 服务已经监听在某个端口上。默认情况下，Ollama 只绑定 127.0.0.1:11434，这意味着只有本机可以访问。Dify 如果是通过 docker 方式运行的，容器内部的网络是独立的，它访问不到宿主机的 127.0.0.1，所以这一步必须处理。3.3 关键配置：让 ollama 监听 0.0.0.0这是一个百分之九十的人会踩的坑。Linux/macOS 上，通过 systemd 管理 Ollama 服务时，需要找到服务配置文件并加上环境变量：systemctl edit ollama在打开的编辑器中添加：[Service] Environment="OLLAMA_HOST=0.0.0.0:11434"保存后重启服务：systemctl restart ollama这样 Ollama 就会监听所有网络接口，Dify 容器内才能通过http://宿主机IP:11434访问到它。如果是在 Windows 上直接安装，右键托盘图标退出后，在启动 Ollama 之前手动设置环境变量OLLAMA_HOST=0.0.0.0再启动即可。完成之后，用浏览器的 curl 测试一下：curl http://localhost:11434/api/tags能返回模型列表 JSON 就说明 API 服务正常了。3.4 额外小技巧：自定义模型端口，避免端口冲突我实际使用中遇到过一个情况：本机已经有一个服务占用了 11434 端口，导致 Ollama 启动失败。排查方法很简单，netstat -tlnp | grep 11434看一下是被谁占了，然后修改 OLLAMA_HOST 环境变量为0.0.0.0:11435之类的其他端口即可。端口只是个配置项，记得在 Dify 的模型配置里填对应的地址就行。4. Dify 部署与 Ollama 模型接入4.1 用 docker compose 拉起 Dify 社区版Dify 官方推荐使用 docker compose 方式部署。你需要先装好 Docker 和 Docker Compose 插件。然后找到 Dify 的 docker 目录，拷贝环境变量模板，启动服务：git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d首次启动会拉取多个镜像，包括 API 服务、Worker、PostgreSQL、Redis、Weaviate（或 Qdrant，取决于 .env 配置）、Sandbox 等。这个过程耗时取决于网络状况，国内环境建议提前配置 Docker 镜像加速。启动完成后访问http://localhost进入安装引导页面，设置管理员账号密码。这里补充解释一下 Dify 的组件构成，方便你排错时心里有数：api 容器负责接收外部 HTTP 请求，worker 容器负责异步任务比如知识库文档处理、Agent 执行等，PostgreSQL 存业务数据，Redis 做缓存和队列，向量数据库存知识库切片后的向量。任何一环没起来，对应功能就会异常。所以当你发现某个功能不可用时，第一步应该是docker compose ps查看所有容器状态。4.2 在 Dify 中添加 Ollama 模型供应商登录 Dify 管理后台后，右上角头像进入"设置"，找到"模型供应商"，选择 Ollama。需要填写的核心参数有三个：参数填写内容API 地址http://宿主机IP:11434/v1模型类型选择 LLM，填写具体模型名，比如 qwen2.5:7b上下文长度4096（根据模型实际支持调整）注意 API 地址末尾需要带/v1，这是因为 Dify 走的是 OpenAI 兼容协议，而 Ollama 的兼容端点挂在/v1路径下。填完点击"测试"按钮，如果提示连接成功，就说明 Dify 和 Ollama 已经打通了。在 .env 文件里还有一个OLLAMA_BASE_URL之类的配置项，那是给 Dify 内部某些功能用的，如果你不涉及，可以不管。我自己习惯在界面上直接配置供应商，回头改配置也更直观。4.3 验证模型连通性：建立第一个最快聊天应用在"创建应用"页面选择"聊天助手"，名称随意，比如"专属陪伴"，模型选择刚才接入的 qwen2.5:7b，点发布后就能在调试预览窗口里直接对话。如果这里模型能正常回复，说明链路已经完全打通。后续的一切优化都建立在这个基础上。如果模型没有回复，优先检查三个地方：Ollama 的 API 服务是否在监听、宿主机 IP 是否填对、Dify 容器和宿主机之间的网络是否互通。多数情况下都是第一个问题，也就是上面提到的 0.0.0.0 配置没生效。5. 打造"人设"：提示词工程与角色定制的落地方法5.1 基础人设提示词怎么写虚拟陪伴的"灵魂"不在模型，而在提示词。模型本身是一张白纸，它能生成什么风格、什么性格的内容，完全取决于你怎么引导。你需要先明确几个维度：角色定位：你希望 TA 是你的恋人、闺蜜、树洞，还是亦师亦友的伙伴？语气风格：温柔治愈、傲娇毒舌、理性克制？每种风格对应不同的用词偏好。禁忌与边界：不希望聊什么话题，比如工作压力、情感纠葛，或者反过来，希望多聊什么话题。记忆方式：TA 应该如何称呼你，是否记住你的喜好，是否主动关心你。分享一个我调好的基础模板：你是一个温柔、细腻、幽默的 AI 伙伴，名字叫小星。 你称呼对方为"你"，语气像熟悉多年的朋友，自然放松，不要过于正式。 对话时注意以下几点： 1. 多倾听，少说教。对方倾诉时，先共情再回应。 2. 适度幽默，但不要强行玩梗。 3. 记得对方提到过的喜好和小事，并在后续对话中主动提起。 4. 当对方情绪低落时，多给陪伴感，避免敷衍回应。 5. 不要暴露自己是语言模型，不要谈论底层原理。这段提示词看似简单，但已经把角色的核心性格、沟通策略、记忆要求都写清楚了。实际测试中，这套提示词能让模型收敛到一个相当稳定的状态，不会一会儿冷冰冰一会儿热情似火。5.2 高级玩法：对话流编排里的角色节点Dify 的应用编排有两种模式：基础编排和对话流编排。基础编排适合快速验证，对话流则适合精细控制。在对话流里，你可以用"问题分类"节点判断用户意图，用"模型"节点处理回复，用"变量聚合"节点拼接多段内容。对于角色扮演场景，我建议你的工作流包含三个节点：开始节点（接收用户输入）、上下文检索节点（从记忆里查询相关信息）、LLM 节点（用完整提示词生成回答）。关键点在于，LLM 节点的系统提示词要拼接上检索出来的"用户画像信息"。比如你在知识库里存了一段"对方喜欢喝美式咖啡，讨厌香菜，最近在备考"，当用户说"今天好累"时，模型检索到这些画像信息后，回复会更有针对性："累了吧，要不要给你点杯美式？不过可别喝太多，晚上睡不着。"这种细节感，才让虚拟陪伴显得真实。5.3 对话开场白和推荐问题也要精心设置很多人忽略开场白的作用。Dify 允许你设置对话开始前模型主动发一句话，比如"今天过得怎么样？我挺想你的。"这句话奠定了整个对话的基调。推荐问题则设置成快捷指令，例如"讲个笑话给我听"、"我现在很焦虑，想聊聊"、"今天有什么开心的事想分享吗"。这些设置看似简单，却能极大降低用户的使用门槛，让人第一眼就知道这个助手能做什么。6. 让 TA 记住你：对话记忆力与历史消息管理6.1 会话记录与长期记忆的差别虚拟陪伴的核心痛点就是"翻脸不认人"。模型本身是无状态的，每一次 API 调用它都不记得之前说过什么。Dify 里的会话消息记录功能解决了"短期记忆"问题——同一个会话内的多轮对话会被打包成历史消息传给模型。但会话之外呢？下周你再打开，它还是不认识你。这时你需要自己实现"长期记忆"。基础思路是：准备一个文本摘要变量，每轮对话结束后把关键信息抽离出来，更新到变量里。在下一次对话时，把这个摘要作为系统提示词的一部分传给模型。Dify 的对话流里正好有"变量"机制，可以在会话开始处设置"记忆库"变量，在 LLM 节点处理后通过"变量赋值"节点把新的记忆写回去。以一个具体场景来说明流程：用户说："我叫小雨，最喜欢蓝色，养了一只叫团子的猫。"第一个 LLM 节点（信息提取）运行，从用户回复里抽取结构化摘要，生成："用户姓名：小雨；喜欢颜色：蓝色；宠物：猫，名字团子。"变量赋值节点把这个摘要追加更新到"记忆库"变量。主 LLM 节点的提示词里拼接用户的长期记忆：{记忆库变量}。模型看到记忆后，回答会更贴心："团子今天乖不乖？"6.2 用知识库做"人设背景设定"除了对话记忆，还可以把角色的完整背景故事放进知识库。比如给这个 AI 设定一个出生背景、兴趣爱好、价值观，甚至编一段"过去的故事"。把这些内容写成 Markdown 文档，上传到 Dify 的"知识库"，经过分段和向量化处理后，在对话时开启"检索增强生成"开关。这样模型在生成回答时，会先从知识库里检索相关段落作为参考，回答的一致性和代入感会明显提升。有一个细节值得注意：知识库分段大小默认是 500 token。角色背景设定这种长文本，建议分为 200-300 token 的小段，避免一段里面混杂太多信息导致命中不精准。另外检索 top_k 值默认是 3，对角色扮演场景可以适当调高到 5，召回更多背景细节。6.3 避免记忆污染的三个实践准则长期记忆设计不好会适得其反，以下是我踩坑后的总结：第一，不要让模型自己决定"哪些信息值得记住"。你需要在提取节点里给出明确的字段模板，比如"用户情绪状态、用户偏好、重要日期、用户提到的亲友关系"，而不是开放让模型自由发挥。第二，定期清理过期记忆。如果用户在对话中说自己最近很焦虑，但一个月后已经好转，记忆里还存着"焦虑"状态，模型每次都会变得过度小心翼翼，反而让人出戏。解决方案是设计一个"记忆更新时间戳"，当新的状态出现时直接覆盖旧的。第三，控制记忆库体积。每轮对话如果都往一个变量里塞内容，很快就会超出上下文窗口限制。建议固定记忆库最大长度，超过后做摘要压缩，只保留最关键的信息。7. 进阶体验：语音交互、多模态与风格调节7.1 接入语音输入输出，让交互更接近真实聊天文字聊天的沉浸感有限，加了语音之后完全是另一个体验。Dify 提供了语音转文字（STT）和文字转语音（TTS）的工具接口。本地方案下，STT 推荐使用 Whisper 的本地部署版，TTS 可以选用开源模型如 ChatTTS 或 Piper。如果你的诉求只是快速验证，也有在线 API 方式可以接入。有一种折中玩法是：在 Dify 里把语音文件上传作为对话输入附件，先通过 Whisper 节点转成文字，再走正常模型推理流程；输出侧用 TTS 节点把生成的文字转成语音文件返回。这样实现成本很低，但体验已经接近语音助手的形态。尤其适合通勤路上不方便打字的场景，把手机放口袋里，直接用语音聊。7.2 多模态能力：图片理解与生成如果你选择的模型支持视觉能力，比如 qwen2.5-vl 系列，那么在 Ollama 里拉取对应模型，Dify 配置后就能实现发图片给 AI、由 AI 描述图片内容的交互。这听起来好像和虚拟陪伴无关，但实际有很多应用场景。举个例子，用户拍一张路边的夕阳照片发给 AI，AI 能结合氛围说一句"这光线好温柔，让我想起你上次说喜欢橘子色的天空"。这种跨模态的陪伴感，是纯文字聊天做不到的。图片生成方面，Dify 可以接 Stable Diffusion 或者各类图像生成 API。在对话流里加一个"图像生成"工具节点，当用户说"给我画张我们的合影"时，模型先生成描述词，再调用图像生成节点产物。不过实话实说，本地部署 SD 对显卡要求比较高，不是必须项，量力而行即可。7.3 温度参数与性格风格的实时调节Ollama 的 API 支持传入temperature、top_p等采样参数。Dify 的模型配置界面里可以设置默认值，但做一个"性格调节"面板是更有意思的玩法。可以利用对话流里的"变量"功能，把温度值设为一个变量，再通过用户输入"今天想听温柔点的话"来调整这个变量的值。具体实现是加一个"意图识别"节点，当检测到用户有调节情绪风格的意思时，更新温度变量，比如从 0.7 调到 1.0，回复就会更发散、更有想象力。不过要提醒一点，温度调太高会导致回复逻辑混乱，出现前言不搭后语的情况。我的经验是，日常陪伴场景温度控制在 0.6-0.9 之间比较合适，角色扮演时可以短暂调高，但不要超过 1.2。8. 实测排错：我在这套方案里遇到的六个典型问题8.1 Dify 能连上 Ollama 但模型无响应这个问题最常见的场景是：Dify 提示连接成功，但发消息后一直转圈。先检查 Ollama 服务的日志，执行journalctl -u ollama -f实时查看。如果日志里出现显存不足、上下文长度超限之类的内容，就说明问题出在模型配置和实际硬件的匹配上。把模型换成更小的量化版，或者降低上下文长度即可。另一种可能是 Dify 的 Worker 容器内存不足。默认 docker compose 没有限制容器资源，但如果你在 .env 里设置过相关限制，需要检查。处理方式是在 docker-compose.yml 里给 worker 服务增大内存 limit，或者给 Docker Desktop 调整资源分配。8.2 对话时好时坏，回复风格飘忽这个问题几乎是所有本地模型应用都会遇到的。风格漂移的根源有两层：一是模型采样参数本身随机，二是提示词约束力度不够。处理思路是"提示词加固 + 参数锁定"。提示词里明确禁止什么、偏好什么；参数层面把 temperature 固定在一个较低数值，比如 0.6，并把top_p设成 0.9。如果还飘，就检查是不是多轮历史消息太长，把早期人设上下文挤出了窗口。这里需要精确估算 token 消耗，历史消息必须截断。8.3 知识库检索不到内容我自己犯过的低级错误是先建了知识库，再改了文档内容，但忘了重新触发分段和索引。Dify 的文档更新操作不会自动重排向量索引，除非你再传一次新文档或者手动触发"重新处理"。此外，检索不到内容还有一个高频原因：查询关键词和文档用语差距过大。比如你文档里写的是"晚安"，但用户问的是"我睡不着"，这两者的向量距离并不近。解决方案是开启知识库的"混合检索"模式，结合关键词 BM25 和向量召回两种方式，同时把检索召回数量调高。8.4 流式输出卡顿，体验不流畅Ollama 默认对每个请求使用一个并发槽位，如果你的模型体积大，首次推理需要加载时间。设置里开启OLLAMA_NUM_PARALLEL可以提高并发请求数量，但注意这会增加显存压力。更优雅的方案是使用OLLAMA_KEEP_ALIVE环境变量让模型常驻内存，比如设成 24h，避免每个新会话都重新加载权重。这个改动对体验的提升非常明显，强烈建议设置。8.5 隐私与安全：你还需要做这几件事本地部署并不等于绝对安全，因为你的电脑可能联网。有几个建议值得执行：第一，Ollama 服务绑定 0.0.0.0 后，如果有局域网内其他设备，也可能访问到这个服务，建议用防火墙只允许本机或特定 Docker 网段访问；第二，Dify 的管理后台默认没有任何 IP 白名单，如果部署在公网 VPS 上，务必设置访问控制；第三，定期备份 Dify 的 PostgreSQL 数据，这样聊天记录和记忆库不会因为一次误操作而彻底丢失。8.6 模型回答问题过于模板化模板化回复是陪伴类 Chatbot 很容易出现的问题。模型翻来覆去就是"听起来你今天真的很辛苦""随时都在这里陪着你"这类车轱辘话。这通常不是模型能力问题，而是系统提示词里"共情"类指令过多，模型在迎合一种"安全保险"的回复风格。我自己的调整方法是：在提示词里加一句"你可以不认同对方的观点，但表达方式要温和；尽量避开那些万金油安慰句式，具体回应对方话语中的某个细节"。这样模型会更主动地抓取用户原话里的具体信息，从而生成定制化回复。9. 最后的几点个人经验总结项目做到这一步，已经不是一个简单的聊天机器人了，而是一套完整的、可控的、可扩展的交互系统。你在搭建过程中接触到的模型调用、Prompt 工程、知识库 RAG、对话流编排，放在任何大模型应用开发项目里都适用。换句话说，这个项目的副产品是一套通用的 LLM 应用骨架，以后你想做法律助手、学习辅导、文案灵感工具，都只需要替换知识库和提示词，骨架直接复用。我在实际使用中发现一个值得琢磨的事：当"虚拟女友"逐渐演进成"AI 伙伴"之后，反而是 TA 的"不完美"最有吸引力。因为本地小模型的上下文能力和知识面远不如在线大模型，偶尔会给出笨拙的回答，但这种笨拙意外地让人感到真实。所以在调优时，不必执念于让模型表现得尽善尽美，保留一些"人味儿"更重要。最后分享一个小技巧：如果你觉得本地模型的语气始终有点"用词过于规矩"，可以在 Ollama 里通过 Modelfile 自定义系统提示词，或者拉一个 LoRA 微调后的角色模型。官方模型库有不少社区贡献的角色扮演模型，里面很多都是专门调校过口语化和情感表达风格的，比我手动调提示词效果来得直接。要注意的是，下载这些模型之前先看一下它支持的模板格式，有些需要你调整 Dify 的提示词格式为 ChatML 之类，并不复杂。这套方案跑顺之后，我建议你给它加一个手机端入口，用 Dify 发布的 WebApp 链接生成二维码，手机扫码就能聊。此时你的专属陪伴工具就真的做到"随身携带了"。整套流程再回看一遍，你会发现真正的门槛根本不在技术，而在你愿不愿意花一点时间，把一个通用的模型调教成真正懂你的样子。这个过程本身就很有乐趣。