企业官网建设流程全解析

最近我把团队里那笔每月一百美元的商业AI套餐停掉了。说实话，决定之前犹豫了很久，毕竟过去半年大家已经习惯了拿它做问答、写摘要、解释代码，突然要断掉，最怕的是效率崩掉。后来我在技术社区看到有人在讨论dots体系——一套用开源工具把商业AI助手能力整个搬到本地的方案集合，覆盖日常对话、知识库、自动化流程三块，甚至连手机端和桌面端入口都给你准备好了。我花了两周时间把社区里讨论最多的三个实现全部跑了一遍，最终选了一套跑在自己办公室的旧电脑上，24小时常驻，数据全部留在本机。这篇就来说说我的选型对比、部署实录，以及那三个一键脚本到底怎么用。

1. 每月一百美元到底花在哪，平替凭什么敢说能打

1.1 商业套餐的钱袋子里都有什么

很多人以为商业AI助手就是一个聊天框，其实不是。你把付费服务拆开看，它至少由四个模块组成：对话交互界面、高性能模型推理、知识库托管、多端同步与团队权限。再加上背后的工具调用、插件生态和模板流程，才构成你每个月看到的完整体验。本地开源平替要做的，就是把这四层全部找到对应的替代品，并且用一套脚本把它们串起来。

我用一个表格把这笔账拆清楚：

看完这张表你就明白，所谓“平替”不是单纯把模型文件下下来，而是要把整条链路都补上。商业套餐的价值在于它把这些模块都集成好了，你花钱买的是省心；而开源方案的逻辑是，每个模块都有成熟工具，只是需要你自己把它们拼起来。dots体系在社区里被叫成“全套平替”，就是因为有人把拼装这件事做成了模板，拉下来就能用。

1.2 平替的真正价值，不止是省钱

省钱当然是最直观的，每月一百美元乘以十二个月就是一千多美元，这还不算按人头收费的团队套餐。但我在实际跑完以后，发现更值钱的其实是另外三点。

第一，数据不出本机。所有对话记录、上传的知识库文档、检索日志，全都在自己硬盘上。对很多小团队来说，这一点比省几百美元重要得多，特别是涉及内部技术资料和客户信息时，外传风险直接归零。第二，模型和界面都可以改。商业套餐给你什么模型你就用什么模型，本地方案里换个模型文件就是改一行配置的事，界面布局、提示词模板、工具调用逻辑全部能按自己习惯调整。第三，断网也能用。办公现场网络抖一下、出差到信号差的地方，本地服务照样跑，不受任何远端状态影响。

但也要说清楚门槛。平替不是白来的，你需要付出三样东西：一台长期开机的机器、一点维护精力、以及接受模型效果和顶级商业模型之间的差距。适合切换的人群是：常用场景固定、对数据敏感、愿意花一个周末折腾的人。不适合的是：追求最新最强模型、完全不想碰运维、以及重度依赖商业生态原生功能的人。我的看法是，先明确自己是哪类人再动手，别盲目跟风。

2. 三大实现横评：两周跑完所有方案后的真实结论

2.1 同是开源平替，路数完全不一样

社区里说“dots体系”的时候，其实涵盖了多个差异很大的项目。我挑了被讨论最多的三个实现，分别用方案A、方案B、方案C来代表，因为它们的定位从一开始就不同。

方案A是一个轻量对话套件。它的思路是让所有人最快速度跑起来，界面做得像聊天软件，模型加载、会话管理、历史记录都内置好，适合把日常问答入口替换掉。方案B走的是另一个方向，它本身不做界面，而是提供一套兼容商业API风格的接口。你原来写的桌面端工具、脚本、集成逻辑，只需要把请求地址改到本地，代码几乎不用动就能切换过来。方案C则是一体化工作台，对话、知识库、自动化流程、团队权限全部装在一个包里，适合小团队一步到位。

这三个实现表面都是AI助手，实际选型逻辑完全不同。我建议你在看横评结果前，先问自己三个问题：你是只想自己要个聊天界面，还是有一堆现成代码要改造，还是团队需要一套统一平台？答案不同，适合你的方案直接不同。

2.2 横评表：我从八个维度各跑了三天

为了做对比，我在同一台机器上把三个方案都部署了一遍，每个方案连续用了三天。机器配置是8核CPU、32GB内存、没有独立GPU，基本模拟了小团队办公室旧电脑的典型情况。部署耗时从拉取代码、下载模型到跑通第一轮对话计算，资源占用取的是日常使用24小时后的平均值。

实际跑下来，我的感受是方案A像是一辆好开的家用车，上手就能走；方案B更像一套乐高积木，本身不起眼，但它能和所有既有零件咬合；方案C是精装房，搬进去就能住，但户型改起来费劲。没有绝对的优劣，只有和你需求合不合。

2.3 我最意外的三个细节

第一，方案A看起来最轻量，但如果你后续想加知识库，改造量反而大。它的对话模块和知识检索模块是松耦合的，加装插件不算难，可用起来总觉得像是两块东西硬拼在一起，检索结果和对话上下文之间的衔接不如一体化方案顺滑。第二，方案B的接口兼容做得很好，但配置项实在太多。连接参数、模型映射、并发限制、超时策略散落在不同文件里，新手很容易卡在某一个参数上。我在第二天就踩了一次连接超时，排查半小时后发现只是超时阈值设小了。第三，方案C全家桶体验确实最完整，但升级要格外小心版本一致性。有一次我更新了前端组件，结果发现后端接口版本不匹配，登录页面都打不开，最后不得不回滚备份。所以方案C我建议跑通后尽量不要频繁升级，除非你已经做了完整备份。

如果让我给建议，我会这么说：个人单机使用先跑方案A，跑通对话再考虑加知识库；手里有存量代码的开发者直接上方案B，省掉改代码的麻烦；小团队想省事就直接选方案C，但控制住折腾的欲望。这个顺序能让你每一步都有回退空间。

3. 本地24小时驻场实战：从零部署到日常管理

3.1 硬件和系统准备

本地部署第一步不是敲命令，而是把硬件和系统环境想清楚。我的主力机是办公室一台淘汰下来的品牌机，配置不算高，但跑这些开源组件绰绰有余。下面是我整理的配置参考，你可以直接对照评估。

没有GPU完全不用慌。我这次部署的机器就没有独显，跑的是量化后的模型，单用户日常提问大约两三秒出结果，完全能接受。所谓量化，简单说就是把模型里的参数精度降低一点，换体积和内存占用的大幅下降，效果损失在可接受范围内。系统层面，建议直接装一个主流Linux发行版的64位版本，我不在这里写具体发行版名称，因为你用的是哪个发行版影响不大，只要带桌面环境或者纯命令行都行，后面全都走容器编排。

3.2 容器编排一起拉起来

我坚持用容器方式部署，原因有三个：隔离、可升级、好回滚。所有服务和依赖被打成一个独立运行单元，系统怎么折腾都不影响宿主机；升级时拉新镜像重启一下就行；出了问题把旧版本容器重新拉起，五分钟就能恢复。这在24小时常驻场景里非常重要。

部署目录我放在/opt/ai-stack下，所有配置和数据都集中在一个地方，方便备份和迁移。先准备一个环境变量文件，内容大概是这样的：

# .env # 镜像地址，建议用你自己构建或核对过哈希的可信镜像源 IMAGE_UI=your-registry.example.com/chat-ui:latest IMAGE_LLM=your-registry.example.com/llm-service:latest IMAGE_VDB=your-registry.example.com/vector-db:latest # 端口 UI_PORT=8080 LLM_PORT=8081 VDB_PORT=8082 # 数据目录 DATA_DIR=/opt/ai-stack/data MODEL_DIR=/opt/ai-stack/models

容器编排文件我做过精简，核心就是把三个服务串起来：

# docker-compose.yml version: "3.8" services: chat-ui: image: ${IMAGE_UI} ports: - "${UI_PORT}:8080" environment: - LLM_BASE_URL=http://llm:8081 - VDB_BASE_URL=http://vdb:8082 volumes: - ./data:/app/data depends_on: - llm llm: image: ${IMAGE_LLM} ports: - "${LLM_PORT}:8081" volumes: - ${MODEL_DIR}:/models environment: - MODEL_PATH=/models/chat.gguf - CONTEXT_LENGTH=8192 vdb: image: ${IMAGE_VDB} ports: - "${VDB_PORT}:8082" volumes: - ./data/vectors:/data/vectors

拉起服务的命令很简单，三行搞定：

cd /opt/ai-stack docker compose up -d docker compose ps

第一次启动会拉镜像，耐心等几分钟。看到三个服务状态都是运行中之后，打开浏览器访问http://本机IP:8080，能看到对话界面就算部署成功了。如果页面打不开，先检查系统防火墙有没有放行8080端口，这是最常见的坑，我后面会在问题排查里再讲。

3.3 模型接入与知识库初始化

对话界面起来只是第一步，真正决定体验的是模型和知识库。模型文件我建议用量化好的GGUF格式，这种格式把模型打包成了一个文件，下载后放入/opt/ai-stack/models目录就行，不需要自己装一堆依赖。量化等级里，Q8效果最接近原版但体积大，Q5是性能和体积比较均衡的日常选择，Q4更省内存但效果会肉眼看出来差一点。以7B参数量的模型为例，Q5文件大概4GB多，16GB内存的机器可以跑得很顺畅。我在没有GPU的机器上用Q5，日常对话体验已经足够写稿、改文案、做代码解释了。

模型接入后，下一步是把知识库跑起来。这部分很多人会忽略，但恰恰是平替体验拉开差距的地方。知识库的工作逻辑是把上传的文档切片、用嵌入模型转成向量、存进向量数据库；用户提问时再把问题转成向量，在库里做相似度检索，把最相关的片段拼进提示词交给大模型作答。

# config.yaml model: path: /models/chat.gguf context_length: 8192 threads: 8 embedding: model: /models/embedding.bin dimension: 768 vector_store: path: /opt/ai-stack/data/vectors top_k: 5

配置里context_length是上下文窗口长度，设成8192意味着模型能一次看到约五六千字的上下文，日常够用；top_k是每次检索返回几个相关片段，设成5就是取最相关的5段，太多反而会引入噪音。初始化知识库时要跑一遍嵌入任务，把准备上传的文档全部过一遍，这一步耗时取决于文档量，几百页的资料大约十几分钟。跑完以后在对话界面里上传一份PDF，问一个里面才有的细节，能答上来就说明链路通了。注意启动后先做一轮“预热提问”，随便问个问题让模型加载进内存，后面响应速度会明显变快。

3.4 远程访问与日常运行

部署在本机，自己用当然没问题，但要实现手机端和桌面端都能访问，就得解决网络问题。最稳妥的起步方案是局域网访问：只要手机和电脑连同一个路由器，直接访问http://主机IP:8080就能用。为了让地址不经常变，我给这台机器在路由器里设了固定内网IP，省得每天查地址。

如果你人在外面也想访问，我建议优先用端口映射，也就是在办公网络出口把某个公网端口映射到内网的8080端口。这个操作要小心，除非你有把握做好访问控制，否则不要直接把服务裸奔到公网。我的做法是开启强密码登录、关闭开放注册接口、限制访问来源IP，并且只开放必要的端口。日常管理上，给容器设置开机自启、把日志按天轮转、数据目录定期备份，这三点做到位，24小时常驻就不是负担。

4. 三端一键全自动脚本：部署、接入、备份全包

4.1 脚本体系总览

说完了部署，接下来是这篇的重头戏：三端一键脚本。我把它分成服务端、PC端、移动端三条线，外加备份和更新两个辅助脚本。整个目录结构是这样的：

/opt/ai-stack/ ├── docker-compose.yml ├── .env ├── config.yaml ├── models/ ├── data/ └── scripts/ ├── install_server.sh ├── pc_client_sync.sh ├── mobile_link.sh ├── backup_rotate.sh └── update_check.sh

脚本设计遵循一个原则：交互尽量少、参数尽量集中在环境变量里、每跑一步都要输出明确的成功或失败信息。这样哪怕三个月后不用了再捡起来，也能一眼看懂是干嘛的。下面我把最重要的三个脚本拆开讲。

4.2 服务端一键部署脚本

服务端脚本负责从零初始化整个环境，包括检查基础命令、创建目录、生成环境变量文件、拉取容器编排文件、启动服务和健康检查。代码如下：

#!/usr/bin/env bash set -euo pipefail BASE_DIR="/opt/ai-stack" DATA_DIR="${BASE_DIR}/data" MODEL_DIR="${BASE_DIR}/models" UI_PORT="${UI_PORT:-8080}" echo "[1/6] 检查基础依赖" for cmd in curl jq docker; do if ! command -v "$cmd" >/dev/null 2>&1; then echo "缺少命令 $cmd，请先安装" exit 1 fi done echo "[2/6] 创建目录结构" mkdir -p "${DATA_DIR}/vectors" "${MODEL_DIR}" "${BASE_DIR}/scripts" echo "[3/6] 准备环境变量" if [ ! -f "${BASE_DIR}/.env" ]; then cat > "${BASE_DIR}/.env" <<EOF IMAGE_UI=${IMAGE_UI:-example/chat-ui:latest} IMAGE_LLM=${IMAGE_LLM:-example/llm-service:latest} IMAGE_VDB=${IMAGE_VDB:-example/vector-db:latest} UI_PORT=${UI_PORT} DATA_DIR=${DATA_DIR} MODEL_DIR=${MODEL_DIR} EOF fi echo "[4/6] 写入容器编排文件" if [ ! -f "${BASE_DIR}/docker-compose.yml" ]; then cat > "${BASE_DIR}/docker-compose.yml" <<'YAML' version: "3.8" services: chat-ui: image: ${IMAGE_UI} ... YAML fi echo "[5/6] 启动服务" cd "${BASE_DIR}" docker compose up -d echo "[6/6] 健康检查" for i in $(seq 1 30); do if curl -sf "http://127.0.0.1:${UI_PORT}/api/health"; then echo "部署成功，访问 http://<本机IP>:${UI_PORT}" exit 0 fi sleep 5 done echo "健康检查超时，请查看容器日志" docker compose logs --tail=50 exit 1

脚本里最关键的是健康检查循环，最多等150秒，服务起来但还没完成初始化时不会误报失败，日志输出也能直接定位问题。另外我把镜像地址都放在环境变量里，不在脚本里写死，这样换机器部署时不用改脚本内容。执行方式很简单：

chmod +x /opt/ai-stack/scripts/install_server.sh /opt/ai-stack/scripts/install_server.sh

跑完看到“部署成功”四个字，就可以进下一步了。我建议第一次跑的时候人守在终端前，因为下载模型和镜像比较耗时，心理预期按10分钟起步算。

4.3 PC端接入脚本

PC端脚本解决的是“怎么让桌面电脑快速接入本地服务”。方案B走接口兼容路线，在桌面客户端里只需要改一个请求地址，但我做脚本的时候还希望连令牌都能自动配好，于是写了这样一个脚本：

#!/usr/bin/env bash set -euo pipefail # 从配置文件读取服务端地址和访问令牌 SERVER_URL="${SERVER_URL:-http://192.168.1.100:8080}" TOKEN_FILE="/opt/ai-stack/data/client_token.txt" CONFIG_DIR="${HOME}/.config/ai-stack" TOKEN="" if [ -f "${TOKEN_FILE}" ]; then TOKEN=$(cat "${TOKEN_FILE}") else echo "未找到令牌文件，请先在服务端生成客户端令牌" exit 1 fi mkdir -p "${CONFIG_DIR}" cat > "${CONFIG_DIR}/client.yaml" <<EOF server: ${SERVER_URL} token: ${TOKEN} timeout: 30 model: local EOF echo "已生成客户端配置：${CONFIG_DIR}/client.yaml" curl -sf "${SERVER_URL}/api/health" >/dev/null 2>&1 \ && echo "服务端连接正常" \ || echo "警告：服务端暂时无法连接，请检查网络"

令牌文件里的内容是一串随机字符，在服务端通过一条命令生成。PC端接入后，你原来用的那些客户端、脚本，只要支持自定义请求地址，都能直接指到本地服务上。我特别想强调一点，电脑端不要折腾原生应用安装包，很多时候使用终端工具反而更省事。

4.4 移动端一键接入

移动端听起来复杂，其实最简单。手机浏览器访问那个地址后，就可以用“添加到主屏幕”功能，把页面变成一个独立图标，使用体验和原生App非常接近，本质是PWA方式，不需要装额外软件。我的mobile_link.sh脚本做的事情，就是在服务端生成一个带配置参数的短链接，用二维码工具打印出来，手机扫一扫自动填入服务器地址和令牌。

#!/usr/bin/env bash set -euo pipefail SERVER_IP="$(hostname -I | awk '{print $1}')" UI_PORT="${UI_PORT:-8080}" TOKEN=$(cat /opt/ai-stack/data/client_token.txt) # 生成带参数链接 LINK="http://${SERVER_IP}:${UI_PORT}/m?token=${TOKEN}" echo "手机端访问链接：${LINK}" echo "请用任意二维码工具将以上链接生成二维码"

实际使用中，我会把这个链接复制到在线二维码生成页里，生成一张二维码图片，贴到办公室显示器旁边。手机扫一扫，浏览器打开，再添加到主屏幕，以后点图标就是本地AI助手。令牌要保管好，它等同于你访问服务的钥匙，发到群里被其他人拿到是个隐患。移动端不做原生App，是我尝试之后觉得最不折腾的方案，更新和配置都在服务端，手机端永远是零维护。

4.5 定时更新与备份

24小时常驻服务最怕的不是慢，而是升级出问题后找不到恢复点。所以我单独写了备份和更新脚本，并用系统定时任务管理它们。

定时任务配置：

0 4 * * * /opt/ai-stack/scripts/backup_rotate.sh 0 3 * * 1 /opt/ai-stack/scripts/update_check.sh

备份脚本的核心逻辑是：先停数据相关服务，压缩数据目录，按日期命名备份文件，只保留最近7个备份。更新脚本的逻辑则是拉取最新镜像清单，和当前运行版本对比，发现有新版本时只输出提示，不自动重启。为什么要提示而不是自动升级？因为我在方案C上吃过亏，版本不同步导致的兼容问题比想象中多。自动备份加手动确认升级，这个组合我用下来最安心。

5. 翻车现场：部署与使用中的高频问题

5.1 常见问题速查表

跑了两周，我前前后后遇到七八个问题，有些是配置疏忽，有些是版本兼容，还有纯粹是环境差异。整理成速查表，方便你对照排查：

这里面的共性规律是：大部分问题不是代码有问题，而是环境细节没对齐。路径、端口、权限、版本这四个词，几乎覆盖了所有翻车现场。你在排查时不要急着改动配置，先看日志，日志里通常会直接告诉你答案。

5.2 资源占用与性能调优

没有GPU的环境下，资源优化直接决定了体验。我第一次把上下文窗口设到16384，结果内存直接不够用，服务频繁重启。后来我把上下文调回8192，内存占用立刻降了三分之一，日常使用几乎感觉不到变笨。

几个实用调优点：

• 模型线程数根据物理核心数设置，8核机器设成8，不是越大越好。
• 上下文窗口按实际需求量设置，不要盲目拉满。
• 向量库的检索结果数量（top_k）默认5就够，设太大会让回答变得啰嗦。
• 模型文件放在SSD上，机械硬盘加载时间会明显拖慢首轮响应。
• 日志如果膨胀，可以用按天轮转的方式控制，避免把数据盘塞满。
• 有GPU的机器尽量把模型放到显存，CPU会释放出来处理其他任务。

还有一个容易被忽略的点：部署完成后一定要做一次预热，让模型先加载到内存里，否则真到用的时候第一句话要多等十几秒。

5.3 我踩过的坑和独家建议

最后说几条用真金白银换来的经验。第一条，默认密码和权限要在第一天就改完。某一次我图省事，部署完直接用了系统默认的管理员账号，结果没两天日志里出现一堆异常登录尝试，幸好服务只在局域网内，不然后果不堪设想。第二条，数据目录千万别默认放在系统盘根目录。我一开始把模型和向量库放在系统盘默认路径，后来升级系统时差点被格式化，亏得提前做了软链。第三条，升级前一定要先跑备份，升级后一定要做一次健康检查。这句话我重复很多次了，因为它是所有坑里性价比最高的一条习惯。第四条，移动端老老实实用浏览器主屏入口就够了，别花时间做原生App，一个是维护成本高，另一个是你的需求根本没到那一步。

我现在每天上班打开浏览器，点一下收藏夹里的本地地址，就能完成过去要依赖商业套餐的所有日常操作。模型可以随时换，知识库可以随时加，日志全在我手里，这种感觉确实比付费服务踏实。如果你也想从零跑一套，我的建议是别一开始就追求全家桶，先拿轻量方案跑通对话，再逐步加知识库和自动化，每一步都能回滚，永远不要把自己逼到没有退路。这大概就是开源平替最实在的价值：钱省下来了，掌控感提上去了，而且还多了一整条可以反复折腾的技术栈。