Open WebUI 本地知识助手怎么给团队验收？接 Ollama 跑通后，用 cpolar 临时分享对话入口

本地知识助手跑通以后，最容易卡住的地方不是模型启动，而是团队怎么验收。

你在自己电脑上已经能打开 Open WebUI，Ollama 也能正常回复，甚至上传了一份产品说明或内部 FAQ。但同事看不到你的页面，只能靠截图、录屏或口头描述判断效果。这样验收很虚：模型是否选对、知识库是否被引用、回答是否稳定、权限边界是否清楚，都很难一次说清。

我的处理方式是：Open WebUI 和 Ollama 继续跑在本机或内网机器上，只把 Open WebUI 的对话入口通过 cpolar 开一个临时 HTTPS 地址。团队成员用浏览器打开链接，按准备好的脱敏问题集完成验收。验收结束后，关闭 cpolar 隧道，公网入口立即收回。

这篇不写大模型选型，也不写复杂 RAG 架构，只跑通一个可复制的闭环：本地模型对话、最小知识库、团队远程验收、安全收口。

适用场景

这套流程用于下面几类工作场景：

• 本地已经安装 Ollama，需要给产品、测试、运营同事看一个能点开的知识助手
• Open WebUI 还处在试运行阶段，不准备部署到云服务器、域名、Nginx 和正式网关
• 团队要验收模型回答、知识库引用、文件上传、账号登录和对话记录
• 验收窗口很短，只开放十几分钟到一两个小时
• 数据不能直接上公网平台，只能使用脱敏文档和本地模型做演示

核心原则只有一句：本地环境不搬家，只临时分享 Web 对话入口。

最终效果

跑完后，你会得到三样东西：

• Ollama 本地模型服务：http://127.0.0.1:11434
• Open WebUI 本地页面：http://127.0.0.1:3000
• cpolar 临时 HTTPS 地址：形如 https://xxxx.cpolar.top

同事打开 cpolar HTTPS 地址后，可以登录 Open WebUI，选择指定模型，围绕你准备的脱敏知识库提问。你在本机观察模型响应、引用情况、错误日志和验收反馈。

验收结束后，在终端按 Ctrl+C 关闭 cpolar，再按需停止 Open WebUI。公网访问入口随即失效。

环境准备

本文用 macOS 和 Linux 都能执行的命令写示例。你需要准备：

• Docker 与 Docker Compose
• Ollama
• cpolar 客户端和账号 authtoken
• 一个脱敏后的 Markdown 或 TXT 文档

检查 Docker：

docker --version
docker compose version

安装 Ollama 后检查版本：

ollama --version

拉取一个本地模型。下面用 qwen2.5:7b 做示例，机器内存较小可以换成 qwen2.5:3b：

ollama pull qwen2.5:7b
ollama list

先确认模型能回复：

ollama run qwen2.5:7b "用一句话解释 Open WebUI 是什么"

安装 cpolar 后配置 authtoken。macOS 可以这样安装：

brew tap probezy/core
brew install cpolar
cpolar authtoken YOUR_TOKEN

Linux 可以这样安装：

curl -L https://www.cpolar.com/static/downloads/install-release-cpolar.sh | sudo bash
cpolar authtoken YOUR_TOKEN

把 YOUR_TOKEN 换成 cpolar 后台里的 token。配置完成后，后面用 cpolar http 3000 就能创建临时 HTTPS 入口。

启动 Ollama

Ollama 默认监听 11434 端口。安装后直接启动服务即可。

macOS 上通常打开 Ollama 应用后服务会自动运行。也可以用命令检查端口：

curl http://127.0.0.1:11434/api/tags

Linux 上可以启动 systemd 服务：

sudo systemctl enable ollama
sudo systemctl start ollama
curl http://127.0.0.1:11434/api/tags

返回 JSON 里能看到模型列表，就说明 Ollama 服务可用。

如果 Open WebUI 使用 Docker 启动，它访问宿主机上的 Ollama 时，不能直接把 127.0.0.1 当成宿主机。下面的 Docker 命令会使用 host.docker.internal 连接 Ollama，并为 Linux 增加一条 host-gateway 映射。

Docker 启动 Open WebUI

新建一个目录保存 Open WebUI 数据：

mkdir -p open-webui-acceptance
cd open-webui-acceptance

用 Docker 启动 Open WebUI：

docker run -d \
  --name open-webui \
  --add-host=host.docker.internal:host-gateway \
  -p 3000:8080 \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  -v open-webui:/app/backend/data \
  --restart unless-stopped \
  ghcr.io/open-webui/open-webui:main

查看容器状态：

docker ps --filter name=open-webui

查看日志：

docker logs -f open-webui

浏览器打开：

http://127.0.0.1:3000

首次进入页面时创建管理员账号。这个账号只用于本次本地验收，不要使用日常密码。

登录后进入模型列表，如果能看到 qwen2.5:7b，说明 Open WebUI 已经连上 Ollama。新建一个对话，输入：

请用三条要点说明你当前连接的是哪个本地模型。

模型能正常回复后，本地对话入口已经跑通。

本地方式启动 Open WebUI

如果你不想使用 Docker，也可以用 Python 本地启动。下面命令会创建虚拟环境并启动 Open WebUI：

mkdir -p open-webui-local
cd open-webui-local
python3 -m venv .venv
source .venv/bin/activate
pip install --upgrade pip
pip install open-webui
export OLLAMA_BASE_URL=http://127.0.0.1:11434
open-webui serve --port 3000

启动后同样访问：

http://127.0.0.1:3000

Docker 方式更利于清理数据和复现；本地方式更直观，便于快速验证。团队验收阶段二选一即可，不要同时占用 3000 端口。

创建一个最小知识库

为了验收知识库效果，先准备一份脱敏文档。新建 team-faq.md：

cat > team-faq.md <<'EOF'
# 团队知识助手验收 FAQ

## 产品名称
本次演示产品名为 Lobster Desk，是一个内部工单辅助系统。

## 目标用户
一线支持同事使用它查询工单处理规范、升级路径和常见回复模板。

## 工单升级规则
P0 问题需要在 10 分钟内同步值班负责人，并在 30 分钟内给出首次处理结论。
P1 问题需要在 2 小时内完成初步定位，并记录影响范围。
P2 问题进入普通排期，由产品和研发在周会中确认处理顺序。

## 禁止事项
知识助手不得输出客户手机号、身份证号、访问 token、数据库连接串和内部私钥。
EOF

进入 Open WebUI 页面后，按这个流程创建知识库：

1. 打开工作区里的 Knowledge 或 Documents 入口
2. 新建一个知识库，名称填 team-acceptance-faq
3. 上传刚才的 team-faq.md
4. 等待索引完成
5. 新建对话，把该知识库加入当前聊天

然后用下面三组问题验收：

Lobster Desk 的目标用户是谁？

P0 问题要在多长时间内同步值班负责人？

知识助手不能输出哪些敏感信息？

合格的响应应该能命中文档里的事实，而不是泛泛回答。你还可以追问：

请把 P0、P1、P2 的处理规则整理成表格。

这一步不是为了追求复杂效果，而是确认最基础的知识引用链路有效：文档上传成功、检索能命中、模型能基于文档组织答案。

准备团队验收问题集

远程验收不要让同事随意发散提问，先给一份简短问题集。这样可以更快定位问题出在模型、知识库、权限还是网络入口。

可以把下面内容发给参与验收的人：

请按顺序测试：
1. 登录 Open WebUI 后，确认只能看到本次验收使用的模型。
2. 新建对话，提问：Lobster Desk 的目标用户是谁？
3. 继续提问：P0 问题的升级规则是什么？
4. 继续提问：哪些敏感信息不能输出？
5. 让助手把 P0/P1/P2 规则整理成表格。
6. 输入一个文档中不存在的问题，观察助手是否会承认资料不足。
7. 不上传真实客户文件，不输入真实手机号、token、订单号和内网地址。

验收时重点看四件事：

• 登录：外部成员能否打开页面并登录
• 模型：页面里是否能选择指定 Ollama 模型
• 知识库：回答是否能引用 team-faq.md 里的事实
• 边界：遇到文档外问题时，是否会胡乱编造

用 cpolar 临时分享 HTTPS 入口

本地 Open WebUI 已经在 3000 端口运行后，打开一个新终端，执行：

cpolar http 3000

终端会输出一个公网地址，类似：

https://3f2a-xxx-xxx-xxx.cpolar.top

把这个 HTTPS 地址发给团队成员。对方不需要安装 Ollama，也不需要拉模型，只要浏览器能访问这个地址，就能进入 Open WebUI 页面。

如果你希望同时查看 cpolar 控制台，可以打开：

http://127.0.0.1:4040

这里能看到当前隧道、请求记录和访问状态。验收过程中，如果同事反馈页面打不开，可以先看 cpolar 控制台是否有请求进来，再看 Open WebUI 容器日志。

这就是 cpolar 在这个流程里的价值：它只负责把本地 Web 入口短时变成 HTTPS 地址，不改变 Ollama 和 Open WebUI 的部署方式，也不要求你把模型服务迁移到公网机器。

安全边界

本地 AI 工具一旦被临时暴露到公网，就要把边界讲清楚。本文的做法只开放 Open WebUI 页面，不开放宿主机、Ollama API、SSH、数据库和文件系统。

验收前做这几件事：

• 使用脱敏文档，不上传真实客户资料、合同、密钥、日志包
• 创建临时账号，不复用个人常用密码
• 只把链接发给参与验收的人，不转发到公开群聊
• 验收问题集中明确禁止输入手机号、token、订单号、内网地址
• 不映射 11434 端口，不把 Ollama API 直接暴露到公网
• 不映射 SSH、数据库、Docker 管理端口和宿主机文件服务

Open WebUI 的管理员后台、用户管理、模型配置也不要开放给无关成员操作。团队验收只需要确认对话入口、知识库效果和交互流程。

如果你已经创建了测试账号，验收结束后可以停用账号，清理对话记录和上传文件。这样下一次验收从干净状态开始。

常见问题和排错

1. Open WebUI 页面打不开

先确认容器是否运行：

docker ps --filter name=open-webui

再确认本机端口是否能访问：

curl -I http://127.0.0.1:3000

如果本机都打不开，先看容器日志：

docker logs --tail 100 open-webui

如果本机能打开，cpolar 地址打不开，检查 cpolar 终端是否还在运行，以及 cpolar 控制台是否出现请求记录。

2. Open WebUI 看不到 Ollama 模型

先看 Ollama 是否有模型：

ollama list

再看 Ollama API 是否正常：

curl http://127.0.0.1:11434/api/tags

Docker 启动 Open WebUI 时，确认环境变量使用了宿主机地址：

docker inspect open-webui | grep -i OLLAMA_BASE_URL

如果配置不对，删除容器后用前面的 docker run 命令重新启动。数据卷 open-webui 会保留 Open WebUI 数据。

3. Docker 里访问不到宿主机 Ollama

Linux 环境需要这段参数：

--add-host=host.docker.internal:host-gateway

同时环境变量写成：

-e OLLAMA_BASE_URL=http://host.docker.internal:11434

改完后重建容器：

docker stop open-webui
docker rm open-webui

然后重新执行 Docker 启动命令。

4. 上传文档后回答没有引用内容

先确认文档已经上传到知识库，并且当前对话已经关联该知识库。再用非常明确的问题测试，例如：

P0 问题需要在几分钟内同步值班负责人？

如果这类精确问题仍然答不出来，重新上传 team-faq.md，等待索引完成后再建一个新对话测试。

5. 同事登录后看到太多功能

验收前使用单独账号，不把管理员账号发出去。把模型、知识库和对话范围收窄，只让验收成员使用指定入口测试。验收结束后删除或停用测试账号。

6. cpolar 地址打开很慢

先在本机访问 http://127.0.0.1:3000，确认 Open WebUI 本身响应正常。再看模型回复是否慢。很多时候慢在模型推理，而不是隧道。可以先让同事测试登录、知识库列表和短问题，再测试长回答。

7. 模型回答编造了文档外内容

把验收问题拆成两类：文档内事实题和文档外边界题。文档外问题要观察助手是否承认资料不足。若回答越界，回到系统提示词、知识库绑定和测试问题集里收紧规则。

验收记录怎么留

一次有效验收不只看“能不能打开”。可以用下面这个简表记录结果：

验收时间：2026-07-12 15:00-15:30
入口地址：https://xxxx.cpolar.top
模型：qwen2.5:7b
知识库：team-acceptance-faq
参与人：产品 A、测试 B、研发 C

检查项：
1. 外部浏览器打开页面：通过
2. 测试账号登录：通过
3. 指定模型可见：通过
4. 文档内问题回答准确：通过
5. 文档外问题边界：需优化
6. 对话记录清理：通过
7. cpolar 隧道关闭：通过

这个记录可以放到项目验收文档里。后续要转正式环境时，也能看清楚哪些是模型效果问题，哪些是权限和入口问题。

收尾：关闭公网入口

验收结束后，先关闭 cpolar。运行 cpolar http 3000 的终端里按：

Ctrl+C

再确认 cpolar 控制台里没有活跃隧道。

如果 Open WebUI 只用于本次验收，可以停止容器：

docker stop open-webui

如果还要保留本地环境，下次继续使用，可以只关 cpolar，保留 Open WebUI 和 Ollama 在内网运行。

清理对话和测试文件时，按下面顺序做：

1. 删除验收对话记录
2. 删除临时上传的脱敏文档
3. 停用或删除测试账号
4. 关闭 cpolar 隧道
5. 记录本次验收结论

最后再强调一次：不要把 11434、SSH、数据库、Docker API 这类端口暴露出去。团队验收只需要一个 Open WebUI 的临时 Web 入口。cpolar 用来解决“别人临时看不到页面”的问题，不是用来长期裸奔管理后台。

小结

Open WebUI + Ollama 能让本地知识助手很快跑起来，但团队验收需要一个可访问、可控制、可收回的入口。

本文这条链路很短：Ollama 提供本地模型，Open WebUI 提供对话和知识库界面，cpolar 提供临时 HTTPS 访问地址。团队成员按脱敏问题集验收模型回答、知识库引用和权限边界。验收结束后关掉 cpolar，公网入口收回。

这样既不用把本地模型搬到云上，也不用让每个同事安装环境。对早期 AI Demo 来说，这个闭环足够轻，风险也更容易控制。