企业官网建设流程全解析

每个月扣款一百美元，结果真正高频使用的只有月初那几天——这种感受经历过的人就会懂。最近圈里讨论最多的是那套云端全家桶，界面里全是各种小圆点菜单，内行干脆叫它 dots 套餐。dots 不是某个具体模型的代号，而是那套覆盖对话、长文本分析、代码执行、文档解析、记忆管理和 API 接入的云端 AI 工具集的通称。如果你受够了这笔固定支出，又希望所有数据都稳稳放在自己的机器上，这篇内容就是写给你的。

我把整套服务老老实实迁回了本地，用三个开源实现把核心能力重新拼装起来，跑在一台吃灰的旧主机上，24 小时开机，手机、平板、电脑三个端都能用，每月新增成本基本就是一点电费。下面是完整记录：功能拆解、三大方案横评、私有化部署实战、三端一键脚本思路，以及我一路踩过的坑。不管你是单纯想省钱的技术爱好者，还是需要给团队做私有化方案的开发者，应该都能从中找到可以直接抄的部分。

1. 先算清这笔账：每月100美元到底买回些什么

1.1 把全家桶掰开看：六项能力，你实际用了多少

很多人订阅之后根本不知道自己到底在为什么付费。我把这套全家桶的核心功能拆成六个部分，逐个对本地开源生态的替代情况做了评估。

对话推理是最常用的能力，也是本地方案最容易覆盖的。如今开源模型在日常问答、代码生成、文案润色这些场景已经相当能打，对绝大多数用户来说体验差距没有想象中那么大。长文本分析与文档解析解决的是“丢一堆 PDF/Word 进去，让它提炼要点”的需求，本地部署时把模型接上文件解析组件，效果同样可用。代码执行属于低频功能，但本地方案里沙箱执行环境是现成的，把模型输出接到一个受限的 Python 环境即可。记忆与知识库则是最有价值的一块，本地用向量数据库就能把私有资料变成长期记忆，而且不用把内容上传到任何外部节点。API 接入与多端同步则完全可以通过本地网关加统一入口实现。

说得直白一点，这套云端全家桶就像一个包含健身房、私教、营养餐、洗衣房的会员卡，而你每天只去搭个跑步机。六项能力里你高频用到的可能就一两项，剩下的是为潜在可能性付费。

1.2 迁移的真实成本：硬件、时间与长期账单

先算钱。100 美元一个月，一年就是 1200 美元，按当前汇率折合约 8500 元人民币。这笔钱你付了一年，得到的是一堆云端对话记录和偶尔用到的高级功能。

本地方案的硬件成本是一次性的。我用的是一台吃灰的老款迷你主机，8 核 CPU、32G 内存、200G 硬盘，没独立显卡。如果你手头连这种机器都没有，去二手市场收一台同级别的机器也就几百块。首次部署需要预留一个下午，主要是熟悉环境、选模型、等模型下载。之后的运行成本就是电费，以这台机器的功耗来算，一天不到一度电，一年电费大约一两百块。

除了钱，还有一笔隐形收益——数据所有权。本地部署意味着所有对话记录、知识库内容都只存在于那台机器上，断电断网依然可以访问，不必担心服务波动或者政策调整让你突然失去历史数据。

2. 三大神级开源实现横评：谁才是那个“替身”

2.1 三套方案各守一道防线

平替不是只装一个模型那么简单，一个成熟全家桶的体验由三层能力构成：模型层、流程层、入口层。对应的三个开源实现，我分别称为“引擎芯”“编排台”“联控端”。

引擎芯负责把开源模型跑起来，对外提供一套与云端风格一致的 HTTP API，让上层应用不用关心模型来自哪里。编排台负责把模型、工具、记忆像乐高积木一样拼起来，支持多步流程、定时任务和外部服务联动。联控端负责统一入口，让手机、平板、电脑都能通过同一个地址访问整套餐服务。三者既可以独立使用，也可以串成一条完整的本地链路。

2.2 引擎芯：本地推理的底座

引擎芯是整套系统的地基。选它的核心标准是部署足够简单、模型管理方便、接口兼容性好。实测下来这类本地推理引擎的安装基本就是一条容器命令，装完以后你就能像调用云端服务一样调用本地模型。

模型选择上，我的经验是先小后大。先用 7B 参数级别的量化版模型把整套流程跑通，确认链路没有问题后再考虑升级到更大模型。在 8 核 CPU、32G 内存的机器上，量化版 7B 模型大概能跑到每秒 8 到 15 个字，日常对话够用；如果机器带独立显卡，速度能翻到至少三倍。硬件不够就选量化程度更高的版本，但要注意量化太狠会让回答质量明显下降，这个需要在速度和智商之间找平衡。

提示：模型下载体积普遍不小，预留足够磁盘空间。建议把模型目录单独挂载到一个独立分区，避免系统盘被撑爆。

2.3 编排台：把问答升级成自动干活

只有对话能力还不能叫全家桶，真正的效率提升来自自动化流程。编排台就是把“模型会用工具”这件事产品化的关键。

我在本地配了一个每天早上自动跑一遍的流程：抓取我指定的几个信息源→用模型生成内容摘要→按固定模板整理成简报→推送到内部群。整个流程是可视化配置的，不需要写多少代码。第一次配置花了我大概四十分钟，之后每天早上自动执行，再也没有手工整理的负担。

配置这类流程最容易踩的坑是模型地址写错，导致流程卡在调用阶段迟迟不响应。我的做法是先用命令行工具手动调一次模型接口，确认返回正常后再去编排台里填地址，避免把连通性问题和流程逻辑问题混在一起排查。

2.4 联控端：一个入口打通三台设备

联控端解决的是使用体验问题。实际部署之后，全家老小共用一台机器上的服务，总不能让每个人都在 SSH 终端里敲命令。联控端以 Web 应用形式运行，提供一个干净的聊天和文档管理界面，所有设备浏览器都能直接访问。

手机和平板上的使用体验，建议直接选择“添加到主屏幕”方式，这样它会以接近原生应用的全屏模式运行，不占额外空间，也不需要装商店应用。电脑端则可以把网页安装成独立窗口应用，快捷键和任务栏入口都很自然。关键一步是把这台服务器在局域网里固定住 IP，否则路由器重启后地址一变，所有入口全部失效。

安全底线我只说一次：这套本地服务不要直接暴露到公网。放在内网里大家通过局域网访问就足够了，非要远程访问的话，请用你所在网络环境已有的加密通道，而不是把端口裸奔出去。

2.5 横评表格与选型建议

选型建议一条条说。只想替代日常对话和文档分析，单独装引擎芯加一个简单的 Web 客户端就够用了。想把本地模型接入自己的工作流，做定时简报、自动整理文件这种，加装编排台。家里设备多、需要给手机和平板都配上顺手的入口，再补一个联控端。三个一起上，就是一套从模型到流程到入口的完整闭环。

3. 24小时私有化驻场实战：从一台旧电脑到全家桶

3.1 机器与系统准备

实战之前先把机器选好。如果你已经有旧电脑或者闲置迷你主机，直接拿来用；没有的话，按下面的配置参考去淘一台也不贵。

系统方面，Linux 是首选，Debian 或者 Ubuntu 这类主流发行版都可以；Windows 机器也能跑，但建议把底层服务放进 WSL2 里，环境干净也便于管理。所有服务统一用容器方式运行，好处很明显：环境隔离、卸载干净、备份和迁移都很直接。前期准备就是把容器运行时装好，然后确认一下防火墙没有拦截需要开放的内部端口。

3.2 四步部署全家桶

整个部署过程可以压缩成四步：拉起引擎芯、装载模型、部署编排台、联调验证。

第一步，拉起引擎芯。核心命令就是一个容器运行指令，我习惯把模型目录挂载到宿主机独立数据目录，方便后续备份和迁移。容器设置成开机自启，防止重启后服务丢。

docker run -d --name dots-brain \ --restart unless-stopped \ -p 11434:11434 \ -v ~/dots/models:/models \ local-brain:latest

第二步，装载模型。用引擎芯自带的模型管理命令下载并激活一个量化版模型。命名规则一般能看出参数规模和量化精度，比如“7b”代表 70 亿参数，“q4”代表 4bit 量化。首次下载体积可能有好几个 GB，需要耐心等。

local-brain pull qwen2.5-7b-q4

第三步，部署编排台。同样用容器方式拉起，数据目录与引擎芯共用同一个父目录，保证流程配置和模型文件可以统一备份。

docker run -d --name dots-flow \ --restart unless-stopped \ -p 8080:80 \ -v ~/dots/flow:/data \ local-flow:latest

第四步，联调验证。先用命令行直接请求一次本地模型的接口，确认返回结果正常，再打开编排台的配置界面，把模型地址填成http://127.0.0.1:11434。

curl http://127.0.0.1:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{"model":"qwen2.5-7b-q4","messages":[{"role":"user","content":"你好"}]}'

看到正常返回的那一刻，基础链路就算打通了。

3.3 三端接入：手机、平板、电脑统一入口

服务跑起来之后，先查一下主机在当前局域网里的 IP 地址，比如运行ip addr拿到一个类似192.168.x.x的地址。然后用同一局域网里的任意设备访问http://192.168.x.x:8080，就是联控端的入口。

电脑端可以把浏览器里的页面“安装为应用”，Chrome 和 Edge 都有这个选项，安装后就是一个独立窗口，跟原生桌面软件放在一起。手机端和平板端则在浏览器菜单里选择“添加到主屏幕”，之后打开的就是全屏的干净界面。

为了让这个入口长期稳定，去路由器后台给这台主机做 DHCP 静态绑定，把 IP 地址固定下来。这样一来，以后所有设备访问的地址永远不变，家人也不需要每次去问“地址是多少”。

3.4 让它24小时不睡觉：自启动、守护与日志

24 小时无人值守，最怕的是断电重启后服务没跟着起来。容器运行时的--restart unless-stopped已经解决一半问题，但更稳妥的做法是用系统守护进程包一层，确保容器服务异常退出也能被拉起来。

[Unit] Description=dots-family Requires=docker.service After=docker.service [Service] Restart=always RestartSec=10 ExecStart=/usr/bin/docker start %i [Install] WantedBy=multi-user.target

日志膨胀是长期驻场最容易忽略的问题。我给自己机器加了一个简单的清理计划：每周跑一次命令，删除七天前的日志文件。放在计划任务里自动执行，基本不用再管。

find ~/dots/logs -name "*.log" -mtime +7 -delete

4. 三端一键全自动脚本：核心设计与避坑指南

4.1 一键脚本要解决什么问题

前面四步操作如果全靠手敲，一遍还行，两遍就烦了。尤其要是在不同机器上重复部署，每台机器都要重来一轮环境检测、目录创建、容器启动，太浪费时间。一键脚本就是把这些重复动作固化成一次执行。

设计脚本时我给自己定了几条原则：一是幂等，脚本重复执行不能把已有环境搞坏；二是参数化，数据目录、端口、服务名都做成变量，换环境不用改代码；三是可观测，每一步执行都有明确输出，失败了能看到是卡在哪一步。

4.2 核心脚本片段与逐行讲解

下面是一个精简版本的部署脚本，核心思路是四步走：建目录、拉起引擎芯、拉起编排台、等待服务就绪并写入网关配置。

#!/usr/bin/env bash set -euo pipefail DATA_DIR="${DATA_DIR:-$HOME/dots}" BRAIN_PORT="${BRAIN_PORT:-11434}" FLOW_PORT="${FLOW_PORT:-8080}" mkdir -p "$DATA_DIR" echo "[1/4] 拉起引擎芯" docker run -d --name dots-brain --restart unless-stopped \ -p "$BRAIN_PORT:11434" \ -v "$DATA_DIR:/models" \ local-brain:latest || true echo "[2/4] 拉起编排台" docker run -d --name dots-flow --restart unless-stopped \ -p "$FLOW_PORT:80" \ -v "$DATA_DIR:/data" \ local-flow:latest || true echo "[3/4] 等待服务启动" for i in $(seq 1 30); do if curl -fsS "http://127.0.0.1:$FLOW_PORT" >/dev/null 2>&1; then echo "编排台已就绪" break fi sleep 2 done echo "[4/4] 写入网关配置" cat > "$DATA_DIR/gateway.toml" <<EOF [brain] url = "http://127.0.0.1:$BRAIN_PORT" EOF echo "完成。"

set -euo pipefail是很多工程师的标配，它让脚本在遇到未定义变量或命令失败时立刻停止，避免后续错误操作。每次docker run后面加的|| true是为了兼容重复执行，如果容器已经存在导致安装失败，脚本不会直接退出，继续走后续流程。等待服务就绪的循环是整套脚本最值得留住的逻辑，没有它，服务还没起来你就去写配置，很容易把错误配置写进去。

4.3 三端版本差异

实际部署环境不可能只有 Linux。三端差异主要集中在自启动机制和包管理命令上。

macOS 上跑这个脚本基本没问题，唯一的坑是数据目录路径习惯不一样，建议把DATA_DIR显式指到用户目录下。Windows 上最省心的做法不是直接双击脚本，而是先装好 WSL2，在 Linux 环境里执行同一个脚本，自启动交给 WSL 的系统服务处理，比处理 PowerShell 版本省心得多。

4.4 执行后的核验清单

脚本跑完不代表一切正常，我每次都会按下面这张表检查一遍，大概五分钟搞定。

5. 本地全家桶跑起来之后：常见问题与排障实录

5.1 问题速查表

5.2 我踩过的几个大坑

第一个坑是贪心模型。刚开始我图省事直接拉了一个 13B 参数的模型，结果发现内存直接吃满，整台机器卡到连鼠标都挪不动。后来换回 7B 量化版，流畅程度完全不同。给新手的建议永远是从小模型开始跑通链路，再视硬件情况逐步升级。

第二个坑是数据目录规划失误。早期我把所有数据扔在了一个临时目录里，后来系统崩溃重装，全部配置和模型镜像毁于一旦。所以数据目录一定要放在独立的持久化分区，并且定期做一次文件备份。备份的间隔我设为每周一次，实际操作起来成本很低，但关键时刻能救命。

第三个坑是端口冲突。有一次编排台怎么都起不来，排查了很久才发现是另一个服务占用了 8080 端口。现在我的做法是启动前先查一遍ss -lntp，看目标端口是否空闲，省去后续一大串问题。

第四个坑是安全意识不够。有一段时间我把服务映射到了公网，结果两天后日志里出现大量来自陌生地址的探测请求。从那以后我坚持所有服务只在内网透出，不再图省事直接开公网端口。既然要私有化，就把边界管住。

5.3 节约资源的三个小技巧

长期驻场最珍贵的资源是内存和磁盘，我总结了三招比较管用的。第一招是优先选择 4bit 量化模型，能在几乎不影响对话质量的前提下把显存和内存占用大幅降下来。第二招是限制并发请求数，在编排台里把默认并发调成 2 到 3，避免几个请求同时进来直接把内存打满。第三招是设置一个定时任务，每天凌晨低峰期重启一次容器，把累积的缓存和状态清干净，这个简单的动作能让服务在很长时间里保持稳定。

说在最后

真正把全家桶迁回本地之后，最明显的感受是每月那笔固定扣款没有了，但更重要的是一种“数据就在自己手里”的踏实感。当然本地方案也不是没有代价，它需要你愿意在初期花一个下午去安装调试，愿意在后续偶尔维护一下环境，但它换来的隐私和自主权是实打实的。

我个人在操作中的体会是：不要急着立刻停掉云端订阅。先把本地服务完整跑起来，让日常使用的核心功能都迁移过去，再并行使用一到两周，确认真的没有依赖断档，再考虑停用。这种平滑过渡的做法最稳妥。如果你手上也有一台闲置机器，不妨从这个周末开始，按正文里的四步把第一块引擎芯拉起来。先把地基打好，后面全家桶自然会长出来。