不用急着去找什么现成的 AI 聊天网页如果你已经跑起来了本地大模型比如通过 Ollama 或者 vLLM 部署好了服务下一步通常会纠结拿什么当入口裸 API 没法给非技术人员用默认的 Chat UI 又千篇一律。今天要聊的 Star Office UI就是那个能把你的 AI 拉进一间“像素办公室”的可视化前端。它既是一套完全开源的聊天界面也是一个带工作区氛围的桌面风格应用你部署好之后AI 就从一个黑乎乎的终端进程变成一个坐在像素工位里等你发消息的“同事”。这篇教程从零开始带你完成 Star Office UI 的部署、接入本地模型以及把服务安全地发布到公网访问。整个过程全部用 Docker 容器化适合有一台 Linux 服务器哪怕是 2 核 4G 的小机器、装过 Docker但对 UI 层不熟的读者。我不会只丢命令让你复制粘贴每一步都会把“为什么这么做”讲清楚方便你以后自己排查问题、按需改配置。1. Star Office UI 部署思路与方案选型1.1 为什么要给 AI 加一个“办公室”界面本地模型都跑起来了为什么还要加 UI很多人觉得终端里 curl 一下接口能返回结果就够了但真到了日常使用你会发现问题不少家里人点不开命令行同事看不懂 JSON自己每天复制粘贴 URL 也烦。而且大多数 Chat UI 只有一个聊天框历史会话、模型切换、Prompt 管理都混在一起用久了很乱。Star Office UI 的定位非常明确——它把聊天、联系人、工位、状态这些元素拼成了一个类似桌面操作系统的界面。你看左侧是同事列表实际上是不同的模型或不同角色的 Prompt中间是对话窗口底部是输入栏右上角还有状态指示灯。这个设计不只是好玩它解决了一个很实际的问题当你同时接入了多个后端模型比如 Qwen、DeepSeek、GLM你不需要记住哪个端口对应哪个模型直接像挑 IM 联系人一样点击切换就行。这套界面的底层逻辑是“模型即角色”。你在配置里定义好模型名称、API 地址、以及系统 Prompt 后Star Office UI 会把它显示成一个带名字的“同事”。每次对话它都按预设的角色跟你交流。这种模式非常适合做内部知识助手、客服预演、甚至角色扮演类的 AI 应用。1.2 部署形态为什么用 Docker 而不是裸进程Star Office UI 本质上是一个前后端分离的 Web 应用前端是像素风格的桌面界面后端负责和模型 API 通信、管理会话记录。它依赖 Node.js 运行时也依赖配置文件和环境变量。如果直接装在宿主机上一旦你升级系统、切换 Node 版本、跑多个 Python 虚拟环境很容易把依赖搅乱。用 Docker 的好处不只是隔离环境。它让“迁移”变得极其简单——你在一台机器上 docker run 起来改天换个服务器两条命令就能复制同样的环境。更重要的是Star Office UI 的官方镜像会把运行时依赖全部锁死免去了“在我机器上好好的到你这怎么报错”这种经典问题。我的建议是只要机器上装了 Docker一律用容器方式部署这一篇的所有操作也是基于 Docker 展开。如果你的服务器还没装 Docker先用下面命令装好Ubuntu/Debian 系其他发行版请参考官方文档curl -fsSL https://get.docker.com | sh systemctl enable --now docker docker --version提示如果你在墙内服务器上拉取 Docker Hub 镜像经常超时可以配置一个 registry mirror。这个大家应该都懂我就不展开讲具体镜像源了只提醒一句一定要用可靠稳定的源否则后续更新镜像时会很痛苦。1.3 整体架构三个容器各司其职整个部署链路大致是一条单向数据流浏览器访问 Star Office UI 的界面UI 把消息转发给后端模型推理服务模型把流式回复返回给 UI再实时渲染在对话框里。为了让这个链路跑通我们最少需要三个角色模型服务端比如 Ollama、vLLM、或任何一个兼容 OpenAI 格式的推理服务它们监听在本机某个端口。Star Office UI 服务端负责托管像素界面、维护会话状态、把请求转发给模型。反向代理层可选但推荐负责 HTTPS 终结、域名转发、公网流量接入。所以这一篇的实操部分会分两步走先把 UI 跟模型跑通内网可用再套一个公网访问方案外网可用。有一些人图省事直接把 Star Office UI 暴露到公网不加密、无鉴权这是非常危险的。本章后半部分会专门讲怎么安全地做公网映射。2. 核心机制与配置细节解析2.1 Star Office UI 的界面组成与交互逻辑第一次打开 Star Office UI你会看到一个像素风的桌面背景底部有任务栏左上角或侧边栏是“同事/联系人”列表。每一个联系人背后对应一个模型配置。点击联系人后中间弹出聊天窗口窗口里可以调整参数比如 Temperature、Top P、Max Tokens以及对每个会话单独调整 Prompt。这套 UI 有一个非常细的设计状态灯。模型后端在线时是绿色挂了是红色推理中会闪烁。这个状态是通过后端对模型 API 的健康检查接口通常是 /health 或 /v1/models轮询得到的。排查问题时第一眼看状态灯就能判断是 UI 的问题还是模型服务的问题相当省事。会话数据默认存放在容器内部的 SQLite 文件里。如果你不挂载 volume重启容器数据就丢了。所以部署时务必把一个宿主机目录映射到容器里的数据目录。这个细节很多人不注意等容器更新后才发现历史聊天记录全没了那时候想哭都来不及。2.2 它和主流 Chat UI 的差异社区里已经有很多成熟的 OpenAI 兼容前端比如 Open WebUI、Lobe Chat、NextChat。Star Office UI 和它们的最大区别是“工作区”心智。其他 UI 是给你一个工具这个 UI 是给你一个空间。它不是把所有东西堆在页面上而是把模型、会话、角色分散到桌面的各个“窗口”里。这种设计的取舍也很明显好看沉浸但信息密度偏低。如果你追求“一眼看到所有历史会话”或“快速批量管理 Prompt”它的效率不一定比传统 UI 高。所以选型时要想清楚定位。我个人推荐的使用场景是作为团队内部共享的 AI 入口或者做一个给非技术人员展示 AI 能力的 Demo 环境——因为像素办公桌面的视觉新鲜感会让人更愿意上手体验。如果你只想自己一个人用、追求极简高效那 Open WebUI 可能更合适。但如果你想让“AI 是一个工位上的同事”这个概念立起来Star Office UI 无疑是最贴题的选择。2.3 配置文件的组成与关键参数Star Office UI 的配置支持环境变量和单个 YAML/JSON 配置文件两种方式。生产环境我建议把敏感信息放环境变量把业务配置写进配置文件。这里列一下核心配置项配置项作用推荐做法MODEL_API_BASE模型服务的 API 地址内网用http://host.docker.internal:11434或容器网络别名MODEL_API_KEY模型服务密钥本地可随便写公网必须用强密钥MODEL_NAME默认模型标识要和模型服务里的实际标识一致OFFICE_THEME像素主题风格按喜好选择不影响功能DATA_DIR会话数据存储目录务必映射到宿主机 volumePORTUI 监听端口默认 8080可改成非常规端口这里有个常见的坑MODEL_API_BASE不要在容器里写localhost或127.0.0.1因为容器内的 localhost 指向容器自己不是宿主机。如果你是用docker run方式启动并且模型跑在宿主机上需要写host.docker.internal如果模型也跑在容器里最好把它们放到同一个 Docker 网络里用容器名互相访问。2.4 流式输出的衔接原理用 UI 聊过天的人都有感受字是一个一个蹦出来的这就是流式输出Streaming。Star Office UI 和模型之间的通信走的是 SSEServer-Sent Events协议。你发一句消息UI 服务端立刻转发给模型 API模型一边生成一边把 token 推回来UI 再通过 WebSocket 或 SSE 把内容实时渲染到对话框。这个链路里最容易出问题的是超时。如果模型推理速度很慢比如小显存跑大模型UI 服务端的 HTTP 客户端默认等 30 秒没响应就断开前端就会报错“连接中断”。遇到这个问题可以通过环境变量调大超时时间。后面排查章节我会给具体的配置示例。3. 完整实操从零部署到公网访问3.1 准备一个最小可用的模型后端以 Ollama 为例假设你已经有了一台装好 Docker 的 Linux 服务器内存不低于 4G硬盘剩 20G 以上。第一步不是装 Star Office UI而是确认模型后端通了。我这里以 Ollama 为例因为它对新手最友好一条命令就能拉起服务docker run -d --name ollama \ -v ollama_data:/root/.ollama \ -p 11434:11434 \ --restartalways \ ollama/ollama启动之后拉一个适合低配机器的模型比如 qwen2.5:3b大约 2G 左右docker exec -it ollama ollama pull qwen2.5:3b验证模型服务是否正常直接在宿主机执行curl http://localhost:11434/v1/models如果你能看到返回的模型列表 JSON说明 OpenAI 兼容接口已经通了。Ollama 默认监听 11434 端口凡是兼容 OpenAI 协议的地址都带/v1前缀这个后面配置 UI 时会用到。注意如果你用 vLLM、LM Studio 或 MiniMax 的本地推理服务只要它们提供 OpenAI 格式的/v1/chat/completions接口配置思路完全一致只是 API Base 地址不同。3.2 部署 Star Office UI 容器确认模型后端 OK 后开始部署 UI。我用docker run直接演示比较直观docker run -d \ --name star-office-ui \ -p 8080:8080 \ -e MODEL_API_BASEhttp://host.docker.internal:11434/v1 \ -e MODEL_API_KEYollama \ -e MODEL_NAMEqwen2.5:3b \ -v /opt/star-office-data:/app/data \ --restartalways \ your-star-office-ui-image:latest注意几点MODEL_API_BASE是指向模型服务的完整地址末尾必须带/v1。如果你模型跑在宿主机就用host.docker.internal如果你模型也在 Docker 里建议先创建一个 Docker 网络比如docker network create ai-net然后启动 UI 时加--network ai-net模型容器也连到同一个网络MODEL_API_BASEhttp://ollama:11434/v1。/opt/star-office-data是宿主机目录可以提前mkdir -p创建好。8080 是 UI 默认端口如果被占用就换一个宿主端口映射比如-p 8090:8080。启动后先在本机验证浏览器访问http://服务器IP:8080。看到像素桌面界面就算成功。3.3 界面上的首次调参进入界面以后第一步要确认“联系人”也就是模型角色是否显示在线。如果状态灯是绿色直接点开聊天窗口发一条消息测试。如果收到流式回复说明 UI 和模型链路通顺。如果联系人列表为空或者显示离线大概率是MODEL_API_BASE或MODEL_NAME配置不对。可以查看容器日志来定位docker logs -f star-office-ui日志里如果出现 404说明 API Base 的路径不对如果出现 401说明 API Key 对不上如果是连接超时检查网络和防火墙。查日志是排查这类问题最快的手段不要瞎猜。这里还建议把每个模型角色背后的 System Prompt 写清楚。比如给“客服助手”加一句“你是一名耐心、专业、简短回复的客服人员”给“代码审查员”加一句“你只负责指出代码问题和优化建议不解释基础语法”。这套 UI 的角色切换成本很低多配几个常用角色后面用起来会非常顺手。3.4 用反向代理做安全的公网访问内网跑通只是第一步。真正要“公网访问”至少要考虑两个问题第一你没有固定公网 IP或者不想在防火墙上开一堆端口第二AI 服务暴露到公网后不能裸奔必须加密传输、加上访问控制。我在这套部署中优先推荐的方案是用 Cloudflare Tunnel 做公网映射。它有几个好处不需要买服务器、不需要在路由器上开端口、自带 HTTPS 证书、可以在 Cloudflare Access 里设置邮箱白名单或 One-Time PIN 认证。如果你对国内访问速度和合规要求比较高也可以用 frp把流量转发到你自己的带公网 IP 的服务器上再用 Nginx 和 Let’s Encrypt 终结 TLS。方案ACloudflare Tunnel适合有域名、追求省事先安装 cloudflared。以 Linux 为例curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -o /usr/local/bin/cloudflared chmod x /usr/local/bin/cloudflared登录并创建 Tunnelcloudflared tunnel login cloudflared tunnel create star-office然后在~/.cloudflared/config.yml里写一条规则把公网域名指向本机的 8080 端口tunnel: star-office credentials-file: /root/.cloudflared/你的tunnel-id.json ingress: - hostname: ai.example.com service: http://localhost:8080 - service: http_status:404启动cloudflared tunnel route dns star-office ai.example.com cloudflared tunnel run star-office这样浏览器访问https://ai.example.com就能打开你的像素办公室。你可以在 Cloudflare Zero Trust 面板里创建一个 Access Group限定只有你和你团队的邮箱能登录多一层保护。方案Bfrp 自建反向代理适合已有公网服务器frp 的部署思路是内网机器跑 frpc连接到你公网服务器的 frps公网服务器把 443 或某个高位端口收到的流量转发回内网的 8080。frps 端配置示例[common] bind_port 7000 vhost_https_port 443frpc 端配置示例[common] server_addr your-public-server-ip server_port 7000 [star-office] type https custom_domains ai.example.com plugin https2http plugin_local_addr 127.0.0.1:8080公网服务器上用 Nginx 或 Caddy 终结 HTTPS 后代理到 frps 的转发端口或者直接配置证书到插件层。这个方案更适合国内服务器用户但对网络运维经验要求更高小白建议优先 Cloudflare Tunnel。3.5 数据持久化与备份公网访问配置好以后这台机器就真正“生产化”了数据安全必须重视。Star Office UI 的会话记录存放在数据目录里你需要做两件事一是确认目录已经映射到宿主机二是定期备份。可以把数据目录打包备份到对象存储或另一台机器tar -czf star-office-backup-$(date %F).tar.gz /opt/star-office-data也可以写一个简单的 systemd timer 定期执行备份。不要等到容器重建才发现数据没了那是最痛的教训。4. 常见问题与排查技巧实录4.1 容器能启动但页面打不开先确认端口是否监听ss -tlnp | grep 8080如果端口没有监听多半是容器启动失败看日志docker logs star-office-ui常见原因包括镜像名写错、环境变量里有非法字符、端口被占用。如果端口被占用改一下宿主端口映射就行不用排查半天。4.2 聊天窗口发消息后一直转圈没有回复这是最典型的联调问题。先看 UI 容器日志和模型服务日志。大概率是MODEL_API_BASE地址指向不通。用以下命令测试 UI 容器到模型服务的连通性docker exec star-office-ui curl http://host.docker.internal:11434/v1/models如果容器里没有 curl可以临时加装或者用 wget。如果连通性没问题再看模型本身是否在推理时崩溃比如显存不足。显存不足时 Ollama 会在日志里打印 CUDA error这时候要么换更小的模型要么把推理并发数降下来。4.3 联系人列表为空当你看到主界面没有任何“同事”时通常是前端还没有从后端拉到模型列表。Star Office UI 启动时会调一遍模型服务的/v1/models接口成功后把模型名称映射为联系人。如果这个请求因为超时或鉴权失败联系人列表就会空白。解决方法是检查启动时MODEL_NAME是否填写正确并且确认你填写的模型名称在/v1/models返回的列表里。如果模型服务刚从睡眠状态恢复第一次请求可能需要 10 秒以上UI 默认超时较短可以调大环境变量比如REQUEST_TIMEOUT120。4.4 流式回复断断续续或卡顿如果本地模型生成速度本身没问题但前端显示一顿一顿可能是 UI 服务端和模型之间的 HTTP 长连接被中断。排查方法打开浏览器开发者工具看 Network 面板里 SSE 请求是否有报错再看 UI 容器日志有没有 EOF 或 timeout 关键字的报错。解决办法一般有两个方向一是调大超时时间二是把 UI 和模型放在同一个 Docker 网络里避免经过宿主机端口转发带来的额外延迟。我实测下来同一个 Docker 网络比host.docker.internal回环更稳定推荐优先这么做。4.5 公网访问慢或连不上公网访问慢先分清是“到达 UI 服务器慢”还是“UI 服务器到模型服务慢”。如果https页面半天才加载出像素背景说明是隧道或反向代理的问题如果界面很快加载出来、但发消息后迟迟没有回复说明瓶颈在模型推理。Cloudflare Tunnel 在国内某些网络环境下速度不太稳定这时候可以切到 frp 自建方案。如果走 frp注意检查公网服务器的带宽上限和防火墙规则。另外如果直接用 IP 端口访问而不用域名部分运营商可能屏蔽高危端口建议统一走 80/443 加域名。4.6 容器重启后设置的 Role 和主题全丢了这基本可以确定是数据卷没有挂载好。检查启动命令里是否包含-v /opt/star-office-data:/app/data。如果挂载了但界面数据还是丢看容器内实际数据目录是不是/app/data——不同镜像版本可能目录结构不一样。可以用下面命令进入容器查看docker exec -it star-office-ui sh ls /app确认实际数据目录后再对应修改挂载路径。5. 深度优化把像素办公室变成多模型工作台UI 层跑通后很多人会想能不能同时接多个模型答案是可以而且这在 Star Office UI 里非常顺滑。它的底层设计支持配置多个模型端点每个端点在界面上就是一个独立联系人。你可以在配置里定义多个模型源比如联系人名称API 地址模型标识适用场景千问同学http://localhost:11434/v1qwen2.5:7b日常问答、文字创作代码评审官http://localhost:11434/v1qwen2.5-coder:3b代码审查、Python 脚本生成效率专家http://localhost:8080/v1minimax-h3 本地版长文档处理、结构化输出创意文案http://localhost:9000/v1glm-4-9b小红书文案、短标题优化配置好之后你只需要在联系人列表里来回切换就能在不同能力模型之间无缝对话。这种“一个工位一个专家”的模式比在单个聊天框里反复切换模型的体验好一截。建议把每个联系人的系统 Prompt 提前写好。比如代码评审官就可以设置你是一名严谨的代码评审专家。你只关注代码中的潜在问题错误处理、边界条件、性能瓶颈、安全隐患、可维护性。不要解释基础语法不要泛泛而谈。优先列问题然后给改进建议。这样每次切换到对应联系人AI 的“人格”就自动切换不用你在每轮对话里重复交代背景。6. 实操中的经验与体会这套部署方案我自己在多种环境下试过包括家用 NAS、云服务器、以及一台只有 8G 内存的迷你主机。总体感受是入口一定不要裸奔数据目录一定要挂载模型地址一定不要写 localhost。这三个“一定”踩过坑的人才知道多重要。最后再分享一个小技巧如果你打算长期跑这套服务建议在宿主机上把 docker 命令包一层 systemd service或者直接用 docker-compose.yml 管理。把环境变量、数据卷、网络配置全部写进 compose 文件以后升级只需要docker compose pull docker compose up -d五分钟完成一次迭代。比起手动敲一长串docker run出错概率小得多。顺带说一下Star Office UI 这个项目还支持自定义像素主题和桌面壁纸如果你的服务器上挂了多套模型服务可以在主题里给每套服务配不同颜色一眼就能看出当前在用哪个后端。这些小细节不一定影响功能但确实会让使用者觉得“这套东西是真的做了设计的”。AI 的能力边界在模型本身但是 AI 的体验边界在前端交互。一个让人愿意点开的像素办公室往往比一个功能全面但冷冰冰的聊天窗口更容易让团队里非技术成员接受 AI 工具。希望这篇教程能帮你把本地模型从“终端里的一条命令”变成“办公室里的一位同事”。