企业官网建设流程全解析

最近两个多月，我身边陆续有朋友发现一个尴尬事：家里的 AI 会员越买越多。你自己包了一个写作助手，媳妇买了一个绘图会员，孩子上网课又开了一个 AI 学习助手，每个月加起来百来块，真到用的时候还总碰上次数限制。直到我在 GitHub 上翻到腾讯开源的 3.6K 星标全家共享平台，才意识到这个问题的解法其实很简单：与其每个人单独付费，不如用一个开源平台，把全家人的 AI 用量统一管起来。这篇文章我就把这段时间的部署、接入、踩坑全过程聊透，想省这笔钱的朋友可以直接照着抄。

1. 全家各自开会员的时代，该结束了

1.1 我家的 AI 付费账单

先说我自己的真实情况。家里四个人，真正高频用 AI 的是我和我媳妇，孩子偶尔用一下 AI 查作文素材和英语对话，老人基本不用，但偶尔会让我帮他们问个菜谱或者药品说明。

在没有统一方案之前，我家一度同时开着三份 AI 相关订阅：我自己的一个通用助手会员、媳妇的绘图工具会员、孩子学习平板里的 AI 辅导功能。每个月加起来一百多，问题在于这些订阅大多是按账号绑定的，换设备登录麻烦，遇到聊天次数上限就只能等第二天重置。更让人觉得浪费的是，很多功能其实互相重叠，同一个问题在三个工具里问，答案质量还参差不齐。

后来我认真算了一笔账：如果直接按 API 调用量付费，以我和媳妇的日常使用强度——每人每天大概 20 到 30 次对话——一个月总消耗量并不大。真正花钱的地方其实是各家会员的"月费门槛"，而不是实际使用的量级。也就是说，用会员模式养全家，本质上是在为大量用不上的额度买单。

1.2 这个 3.6K 星标项目想解决的事

腾讯开源的这个全家共享平台，GitHub 上已经有 3.6K star。它解决的核心问题就是：把各家大模型的 API 统一接到一个私有平台上，管理员分配账号，每个家庭成员领自己的"子 key"，各用各的模型，但费用统一从管理员的主账户走。

这么做的好处非常明显。第一，只需要一个模型服务商的 API key 就能覆盖全家需求，不用每个人单独开会员。第二，不同人可以配置不同的模型，比如孩子默认用教育向的本地小模型，大人用能力更强的在线大模型。第三，每个人有多少额度、每天能用多少次，管理员在后台看得明明白白，不会出现月底账单爆炸的情况。

从我实际使用的感受来说，这个项目最适合三类人：一是家里有两三个以上 AI 高频使用者的家庭，二是小型创业团队想统一管理 AI 调用成本，三是学校社团、实验室之类需要多人共享大模型资源的组织。如果你只是自己一个人用，那确实没必要折腾，直接买会员或者用官方 API 就行。

2. 拆解"AI 家庭共享网关"：它到底做了什么

2.1 一个不算复杂但很关键的核心流程

很多人第一次听到"全家共享 AI 平台"时，以为它是个聊天软件，装上就能用。实际上它是一个位于"模型厂商"和"聊天客户端"之间的网关服务。你可以把它理解成家里装了一个净水器：自来水厂的水（各家大模型 API）通过净水器（共享平台）分流到各个水龙头（家庭成员的不同 App），每个水龙头的出水量（token 用量）都能被单独计量。

我自己的理解是，这个项目本质上做了一层 OpenAI 兼容 API 的代理和转译。它对上对接各家模型服务商，对下提供一个标准接口，任何支持 OpenAI 协议的前端——网页聊天、手机 App、浏览器插件——都可以直接连上来。这样一来，全家人不需要使用同一个聊天工具，你用你的客户端，我用我的，后端都走同一个平台，费用和权限也能统一管理。

2.2 统一密钥、模型路由、配额计量三大能力

项目最核心的三个能力，我觉得可以这样概括。

统一密钥管理：管理员在平台里配置一个或多个模型服务商的真实 API key，这些 key 不会直接暴露给家庭成员。每个成员拥有一个独立的子 key，形如sk-member-xxx。平台记录每个子 key 的调用次数、token 消耗、对应到哪个模型服务商。即便某个成员的 key 泄露了，管理员也能一键禁用，不影响其他人。

模型路由：平台允许管理员定义多个模型通道，每个通道指向一个具体模型。举例来说，我配置了四条通道：混元、通义、DeepSeek 和本地 Ollama 的 qwen2.5。给家庭成员分配时，可以指定默认模型，也可以让他们自己选。这个设计的灵活之处在于，模型升级或者厂商调整价格时，管理员只要改通道配置，不需要让每个家庭成员改客户端设置。

配额计量：每个人可以设置每月 token 上限、每分钟最大请求数、单次对话最大 token 数。孩子用的账号我可以限制在每月 100 万 token 以内，超过就自动熔断，等到下个月自动恢复。这点对控制成本非常关键，毕竟如果不做限制，一个想象力旺盛的小孩可能半下午就把一周的额度聊完。

从技术选型上看，这个项目用 Go 写的核心网关，部署产物就是一个二进制文件，资源占用很低。我在一台 2 核 2G 的旧迷你主机上跑，内存占用基本控制在 200MB 以内，负载基本可以忽略不计。它还把 SQLite 作为默认数据库，省去了单独维护数据库的麻烦，对小规模家庭场景非常友好。

3. 部署实战：用 Docker Compose 把平台跑起来

3.1 部署前的环境准备

这个项目官方推荐用 Docker Compose 部署，我觉得这也是普通人最省心的方式。准备的东西不多：一台能长期开机的电脑或者 NAS，装有 Docker 和 Docker Compose 插件；一个用来跑网关的端口，默认是 8080；另外就是各家模型服务商的 API key。

如果你是零基础，我的建议是先别碰 NAS，找一台闲置笔记本，装个 Ubuntu Server，再装 Docker，跟着下面的步骤走一遍。等跑通了，再考虑迁移到 NAS 上长期运行。我当时图省事直接部署在群晖 NAS 上，后来发现如果对 Linux 不太熟，排障会很痛苦，还是建议先在普通电脑上验证一次。

安装 Docker 的部分就不展开了，官方脚本一把梭。装完之后确认一下版本：

docker --version docker compose version

如果都正常，就可以开始部署。

3.2 编写 docker-compose.yml 与启动

项目仓库里有一个示例的 docker-compose.yml，我按自己的需求做了精简。下面这个版本可以作为起点：

version: '3.8' services: ai-gateway: image: ghcr.io/example-org/tx-ai-family-gateway:latest container_name: ai-family-gateway restart: unless-stopped ports: - "8080:8080" environment: - APP_PORT=8080 - DATABASE_URL=sqlite:///data/gateway.db - ADMIN_INITIAL_PASSWORD=change-me-please - JWT_SECRET=please-set-a-long-random-string volumes: - ./data:/data - ./config:/config

这里有几个值得注意的点。restart: unless-stopped保证机器重启后网关自动拉起来，不然家里的老人孩子找不到人恢复服务。JWT_SECRET千万别用默认值，它用来签名登录态的，如果太简单，局域网里的其他人可能直接伪造管理员身份。./data目录是 SQLite 数据库所在位置，备份整个目录就等于备份了全家的配置和用量记录。

启动之前，最好先手动拉一下镜像确认网络访问正常：

docker pull ghcr.io/example-org/tx-ai-family-gateway:latest

然后启服务：

docker compose up -d docker compose logs -f

看到日志里出现类似listening on 0.0.0.0:8080的输出，就说明网关起来了。在当前机器的浏览器里访问http://localhost:8080，会进入初始化管理员账号的页面。

3.3 初始化管理员与家庭成员

第一次打开页面，系统会让你设置管理员账号密码。这里的密码建议用密码管理器生成一个长密码，因为管理员能看全家的用量记录和子 key，安全性不能马虎。

进入管理后台之后，界面比我预期的简单很多，主要就是"模型通道""成员管理""用量记录"三个模块。添加一个人的步骤非常直观：

1. 在成员管理里点击"新增成员"，填上名字，比如"小明"。
2. 系统生成一个独立的子 key，复制下来发给对方。
3. 为这个成员选择可用的模型通道，设置月度 token 上限和限速参数。
4. 保存，完事。

我实际测试的时候，添加上一个成员到对方能用上，整个流程不到两分钟。这也是这个项目让我觉得最舒服的地方，管理成本低，日常根本不用盯着。

4. 把各家大模型都接进来

4.1 添加 OpenAI 兼容的在线模型

这个平台对模型服务商的兼容性做得不错，只要是 OpenAI 兼容的接口，都能通过"模型通道"配置接进来。下面是我在用的几个模型通道配置，用的都是国内可以直接调用的服务，价格也相对透明。

配置时只需要填通道名称、Base URL、模型名和对应的 API key。需要注意，不同服务商的 Base URL 格式有差异，有些是/v1结尾，有些是/compatible-mode/v1，填错了平台会在测试连接时直接报 404，按照实际文档填就行。

我最初只配了一家模型，后来发现不同场景用不同模型体验差距挺大。比如孩子查作文素材，DeepSeek 的回答条理清晰，长度也合适；我自己写代码时更习惯用混元或者通义，对代码格式和注释的处理更顺手。所以我在模型通道里配了四个不同服务商，然后给每个成员设置了各自的默认模型。

4.2 接入本机 Ollama

如果你不想所有请求都走在线 API，也可以把本地模型接到同一个平台里。这个方案最大的好处是隐私性好、没有按 token 计费的压力，缺点是模型能力不如在线大模型，需要一台配置还行的机器。

我家里有一台以前淘汰下来的 3060 显卡主机，装了 Ollama 之后跑qwen2.5:7b和llama3.1:8b都够用。Ollama 本身也提供 OpenAI 兼容接口，所以接入方式和在线模型一样，只是在通道配置里把 Base URL 指向那台机器的地址：

Base URL: http://192.168.1.100:11434/v1 Model: qwen2.5:7b

唯一要注意的是，如果 Ollama 跑在不同的机器上，那台机器的 Ollama 服务需要监听局域网地址，默认只绑定 127.0.0.1 时，其他机器是访问不到的。修改方式是在 Ollama 的 systemd service 里加上OLLAMA_HOST=0.0.0.0环境变量，然后重启服务。

我把本地的 qwen2.5 分配给了家里老人用的账号，他们问的无非是天气预报、菜谱、药品说明这类问题，不需要多深的推理能力，本地模型完全够用，还能避免每次查询都消耗在线额度。这台机器平时放在书房，功耗大概一两百瓦，但相比给老人单独买一个 AI 会员，这点电费反而更划算。

4.3 给不同成员分配默认模型与额度

这一步是整个平台的灵魂。管理员可以在成员配置里，为每个人指定默认模型通道、可切换的模型列表、单日调用上限和月度 token 上限。

我目前的分配方案供参考：

• 我自己的账号：默认 DeepSeek，可切换混元和通义，月度 token 上限 1000 万。
• 媳妇的账号：默认通义，可切换混元和 DeepSeek，月度 token 上限 800 万。
• 孩子的账号：默认本地 Ollama qwen2.5，可切换 DeepSeek，月度 token 上限 300 万，晚上十点后自动停止响应。
• 老人的账号：默认本地 Ollama qwen2.5，无切换权限，月度 token 上限 200 万。

这个方案跑了一周之后，我看了下后台的用量统计，全家的模型调用量加起来还不到 500 万 token，折算成在线 API 的费用，大概就十几块。对比之前三份会员一个月一百多的开销，成本直接降了一个量级。

5. 全家人实际怎么用

5.1 网页入口：不折腾的直接聊天

项目自带一个内置的简洁聊天页面，非常朴素，就是左侧成员列表、中间对话区域、底部输入框。家里长辈或者完全不想折腾技术的人，直接用浏览器打开网关地址、登录自己的账号，就能开始聊天。

我给老人把入口做成了浏览器收藏夹里的一个书签，名字叫"问问题"。他们打开后看到的就是一个类似聊天软件的页面，没有复杂度，也不需要配置任何东西。这个内置页面虽然长相朴素，但响应速度很快，聊天记录也会自动保存，换手机、换电脑都能看到历史记录。

5.2 手机和电脑客户端接入

如果你不想用内置的网页，而是想用自己喜欢的聊天客户端，也没问题。项目的对外接口完全兼容 OpenAI API，所以我试着接了好几个常用的第三方前端，都能直接识别。

以我在手机上的配置为例，用的是一款开源的聊天客户端，只需要填写三个参数：

API 地址: http://你的服务器IP:8080/v1 API Key: sk-member-xiaoming-xxxx 模型: deepseek-chat 或 default

配置好之后，App 里的体验和直接用官方 API 没有任何区别。媳妇用的电脑端接的是沉浸式翻译插件，把翻译服务的自定义接口指向网关，之后在浏览器里选中英文，直接就能用家庭共享的 AI 通道翻译，每个月省下单独买翻译服务的钱。

一个很实用的技巧是：客户端的模型名可以直接填default。这样网关会自动把请求路由到成员配置里设置的"默认模型通道"，切换模型时只需要管理员在后台改配置，客户端不用动。

5.3 一周实测：速度、费用与体验

我把家里的网络接入正式切换到这个平台之后，跑了一周做了一次完整复盘。

响应速度方面，走腾讯混元和通义的请求体感上和直连官方接口没有差距，部分地区可能比直连还稳定一些，因为网关会做连接复用。本地 Ollama 的响应速度受限于显卡性能，7B 模型的生成速度大概在每秒 20 到 30 token，日常问答完全够用，但让它写长文章就会觉得有点慢。

费用方面，我查了后台的月度统计，全家人一共消耗了大约 460 万 token，其中在线模型占大头，本地模型消耗了大约 100 万 token。折算下来，在线 API 的实际花费是十几块人民币。放在以前，这点钱连一个会员月费都不够。

体验上的一个意外收获是，聊天记录统一了。以前每个人的对话散落在不同的 App 里，现在全家的对话记录都集中在这个平台的数据目录里，备份只需要打包一个文件夹。家里人偶尔会让我帮忙翻一下之前某次问过的内容，我在后台一搜就能找到。

6. 配额、隐私与防滥用：家庭共享的生命线

6.1 防止有人把额度刷光

多人共用一个平台的麻烦在于，一旦有人不小心写了个无限循环脚本，或者一个好奇心爆棚的小孩反复追问同一个问题直到上下文爆炸，当天的额度可能几分钟就烧完了。

我经历过一次比较深刻的"事故"。有一天孩子放学回家，拿着一个编程课的项目问我能不能让 AI 帮他把代码跑起来，我随口说了一句"你可以用默认模型试试"，结果他在客户端里粘贴了一份几千行的代码，连续提问了二十多次，再加上我把上下文长度设置得比较大，单日额度很快就触顶了。

从那以后我吸取了教训，给成员设置配额时，几个参数一定要配合使用：单次请求最大 token 数、每分钟请求数、日累计 token 上限。这三个参数缺一不可，否则总有一个口子会被钻空子。具体到孩子的账号，我现在的配置是单次最大输出 1024 token，每分钟最多 10 次请求，日累计不超过 30 万 token。

6.2 聊天记录和隐私边界

多人共享平台最敏感的其实是隐私。每个人的聊天记录里都可能涉及工作、健康、财务等敏感信息，管理员虽然能看到全家的用量统计，但不应该能直接翻看每个成员的对话内容。

我特意确认了这个项目的权限设计。默认情况下，成员账号只能看到自己的聊天记录，管理员后台也只会展示请求次数、token 用量、调用时间等元数据，对话内容做了隔离。当然，如果你在部署时把用户隔离功能关了，那就另当别论。我的建议是保持默认，哪怕家里人之间互相信任，也应该保持这个边界，这是长期稳定使用的前提。

另外一个细节是，平台支持关闭聊天内容日志，只保留用量统计。如果你对隐私要求非常高，可以在配置里把日志级别调低，这样即使有人拿到数据库文件，也只能看到请求记录，看不到具体对话内容。但代价是你自己也没法在后端搜索聊天历史了，这个取舍需要根据自己的情况来定。

7. 部署与运行中的坑，我替你踩过了

7.1 升级后登录态失效

有一次看到项目发布了新版本，我心血来潮执行了docker compose pull && docker compose up -d。升级倒是很顺利，但全家人第二天都被迫重新登录了一遍。

排查下来发现原因是我第一次部署时没设置JWT_SECRET，升级过程重建了容器，服务内部随机生成的签名密钥变了，所有旧登录态同时失效。解决方式很简单，在 docker-compose.yml 里固定一个JWT_SECRET环境变量，之后升级就不会再出现这个问题。顺带说一句，如果你刚开始部署，一定要从一开始就设置这个变量，别像我一样等全家人找你排查时才想起来。

7.2 模型 API key 过期，全家"断网"

还有一次，某个在线模型服务商因为账户余额不足，API key 被停用了。这个服务商刚好是我设置的默认通道，结果全家人的请求全部失败。后台日志里全是 401 鉴权错误，而各成员客户端显示的都是各种看不懂的报错。

这个问题的排查路径其实很有规律。我先在管理后台用"测试连接"功能检查通道状态，发现测试也失败，再去看具体的错误码，是 401 而不是网络超时，基本可以确定是 key 或者余额问题。登录服务商后台一看，果然余额清零了。充完值、更新通道配置，全家恢复。

经过这次之后，我把模型通道做成了至少两路互为备份。比如默认通道是 DeepSeek，同时给每个成员开放了混元作为备选。如果主通道的 key 出问题，成员在客户端里切换到备选通道就能继续用，不用等我远程处理。

7.3 模型响应超时的排查链路

家里的网络或者模型服务商出问题时，最常见的一个现象是：请求发出去，转圈很久，然后报超时。很多人在这一步会误以为网关挂了，甚至想重启容器，但多数情况并不需要。

我总结了一套简单的排查链路：

# 第一步，看服务本身是否活着 curl -I http://localhost:8080/health # 第二步，看日志里有没有最近的错误 docker compose logs --tail=100 # 第三步，直接用 curl 模拟一次客户端请求 curl http://localhost:8080/v1/chat/completions \ -H "Authorization: Bearer sk-member-xxx" \ -H "Content-Type: application/json" \ -d '{"model":"default","messages":[{"role":"user","content":"你好"}]}'

如果第三步能正常返回，说明网关和成员 key 都没问题，问题大概率出在模型服务商那边；如果超时，再把model改成具体模型名试一次，确认是不是默认模型通道的问题。这套流程走下来，80% 的问题都能自己定位，不用到处问人。

7.4 一些省心的运维小习惯

最后分享几个我运行这段时间积累的小习惯。数据目录的备份一定要做自动化，我直接用群晖的定时任务每天晚上把/data目录打包上传到另一块硬盘，恢复流程也验证过，解压替换目录重启容器就能回来。另外每季度更新一次 docker-compose.yml 里的镜像版本，顺带看看项目仓库的 release 说明。

还有一个小细节，家里的路由器如果支持 DHCP 固定分配，建议给跑网关的机器绑定固定内网 IP。不然有一天机器重启之后 IP 变了，全家人的客户端都会连不上，到时候你不在家就很难远程处理。绑定固定 IP 之后，所有客户端的 API 地址就再也不用动了。

平台运行一个月下来，最大的感受是省心。不用惦记哪个会员到期了，不用纠结同一句话在哪个 App 问更划算，家里人各用各的客户端，所有开销和用量都在一块后台面板里。如果你家里也有两个人以上长期在给 AI 助手单独付费，不妨找个周末把这个平台部署起来，按本文的配置走一遍，大概率不会再想回到各买各会员的日子。