企业官网建设流程全解析

简介：页面辅助工具（Page Assist）是一款面向Chrome与Firefox浏览器的本地AI模型Web UI插件，通过集成Deepseek模型，让用户无需联网即可在侧边栏与网页中直接调用AI能力，适合注重隐私或需要离线使用大模型的开发者与爱好者。压缩包共131个文件，约11.97MB，包含45个js逻辑脚本、14个json配置、多个字体与样式文件，以及sidepanel.html、options.html等界面入口，目录结构清晰，便于二次配置。其中Chrome版本已实测通过Deepseek R1验证，Firefox插件尚未测试，但功能模块基本对应。资源附带内容脚本、后台逻辑及本地化资源，可帮助理解浏览器扩展与本地AI的集成方式，已有9764人学习下载，适合作为本地AI应用开发与插件定制的参考。

1. Page Assist 是什么：一个长在浏览器里的本地 DeepSeek 界面

第一次用 Page Assist 跑 deepseek 的时候，我的第一反应是：这不就是个侧边栏聊天框嘛。直到我在不打开任何 Docker 容器的情况下，用浏览器扩展直接连上本地 Ollama 里的 DeepSeek 模型，才反应过来它真正解决的问题是——本地 AI 模型的 Web UI 太重了。只要电脑能跑 LLM（推理），浏览器就是现成的壳子，不用再维护一个 Web 服务端。这篇文章就是讲清楚 Page Assist 到底是什么、怎么把它接到 DeepSeek 模型上、以及它和 Open WebUI 这类工具的根本差异，适合那些已经在用 Ollama 跑模型但嫌官方界面太朴素、或者不想为聊天界面再开一个 Python 服务的开发者。

2. 为什么选 Page Assist：它和 Open WebUI、Chatbox 不是一类东西

2.1 架构先想明白：这个 UI 根本没有"服务端"

很多人第一次看到 Page Assist，会下意识把它当成又一个"聊天网页"：打开一个 URL，输入 prompt，拿到回答。这是 Open WebUI 的做法——它要给本地推理后端套一层 HTTP API，宿主在一个 Python 服务里，有独立的端口和会话管理。而 Page Assist 把整条链路搬进了浏览器扩展：扩展页面本身是 UI，浏览器负责发请求、管理会话历史、处理上下文注入，后端可以是本机的 Ollama、LM Studio，也可以干脆用浏览器内置的 WebLLM 在本地跑小模型。

这个区别直接决定了你会不会选它。Open WebUI 是一个带完整生态的应用：你需要安装 Python、装依赖、配置环境变量、管理容器生命周期（如果用 Docker），启动之后才轮到模型干活。Page Assist 的设计逻辑就是"用最小代价换来一个够用的 Web 界面"：它不启动任何系统服务，不占端口，不用配反向代理，关掉浏览器就等于整个 AI 服务从内存里消失。对于"我在笔记本上跑着一个小蒸馏模型、就想要个顺手的聊天窗口"这个场景，它的开销趋近于零。

选型时可以按这个表对号入座：

我这里说的是"常见方案"里的对比，不是劝你放弃 Open WebUI。如果你要跑一个 32B 以上的量化模型、要管多用户、要审计日志，那 Web UI 后端反而是更稳的选择。但如果你只是一个人、一台机器、一个页面，Page Assist 的"零服务端"模型确实值得先试一下——它能帮你省掉一大半建环境的血泪经验里最常见的那一步：环境坏了重装。

2.2 安装和入口：它到底装在哪里、读写什么

Page Assist 的安装方式按浏览器的扩展分发渠道来，常见有两种：一是从 Chrome 网上应用店或 Edge 加载项商店直接安装；二是如果企业环境封闭，可以下载扩展包（crx 解压后的文件夹）再用"开发者模式"加载已解压的扩展。第二种方式本质上和装一个普通扩展没有区别，只是多一步选择文件夹的操作。装完以后，浏览器工具栏会出现它的图标，点开会有一个可拖动的侧边栏，也支持抽成一个独立窗口来用。

这里有一个大多数用户没注意到的权限点：Page Assist 会申请"读取网页内容"的权限。它需要这个权限才能实现网页上下文功能——也就是你在任何一个页面上选中几段文字，点一下按钮，就能把它喂给本地模型做翻译、总结、改写。这意味着它在运行时能看到你在当前网页里选中的内容，虽然只对当前激活标签页生效，不会后台收集所有页面内容，但如果你对隐私敏感，可以把这个权限在扩展详情页里关掉；代价就是只能手动粘贴文本进聊天框。

装好后最值得做的第一件事不是急着聊天，而是打开扩展的"设置/模型管理"页面，把 Provider 看懂。页面里会有类似 "Ollama"、"WebLLM"、"OpenAI 兼容接口" 这样的选项，这就是接下来要接 DeepSeek 模型的入口。很多人在这一步卡住，不是因为界面复杂，而是不知道 Ollama 和浏览器之间还隔着一道"跨域"的坎——这就是下一节要解决的问题。

3. 用 Ollama 接 DeepSeek：从装扩展到跑通聊天的完整链路

3.1 为什么默认连不上：扩展页面到 127.0.0.1 其实跨域了

把 Page Assist 的 Provider 切到 Ollama，地址填http://127.0.0.1:11434，然后点连通性测试，最常见的结果是失败。用 curl 直接打同一个地址，明明一切正常。这个"玄学"背后是一个确定的技术原因：浏览器扩展页面和内容脚本发起请求时，请求的 Origin 是chrome-extension://<扩展ID>这个专属源（源即 scheme + host + port）。而 Ollama 服务默认只接受来自本机 localhost 的源，对其他 Origin 一律返回 403。

这不是 Page Assist 的问题，而是 Ollama 出于安全考虑在较新版本里加上的跨源限制，白名单由环境变量OLLAMA_ORIGINS控制。原因是任何网页都能向你的本地端口发请求，如果把本地模型接口完全暴露给所有网页，等于任何带毒网页都能偷偷调你的显卡算力、消耗你的内存。所以 Ollama 默认允许的来源非常收敛。这里绕不开的解决办法就是把chrome-extension://源加进白名单。

3.2 最小可跑配置：改一个环境变量解决 90% 的连接失败

常见做法是设置两个环境变量：OLLAMA_HOST控制监听地址，OLLAMA_ORIGINS控制允许的跨域来源。对于本机单用户使用，OLLAMA_HOST保持127.0.0.1:11434即可，不需要改成0.0.0.0——那会把服务暴露给局域网，得不偿失。真正要动的是OLLAMA_ORIGINS。

Linux / macOS 下，我用的是临时导出加写入配置文件的组合：

# 临时生效，适合先验证链路 export OLLAMA_ORIGINS="chrome-extension://*" ollama serve # 持久化：写入用户级 systemd 配置（以 systemd 运行的常见方式） mkdir -p ~/.config/systemd/user cat >> ~/.config/systemd/user/ollama.service.d/override.conf << 'EOF' [Service] Environment="OLLAMA_ORIGINS=chrome-extension://*" EOF systemctl --user daemon-reload systemctl --user restart ollama

Windows 的情况稍有不同，在"环境变量"面板里新建一个用户变量，变量名OLLAMA_ORIGINS，变量值chrome-extension://*，然后重启 Ollama（任务管理器结束 ollama.exe 再重新运行，或在托盘区退出后重开）。设置完后来验证一下链路：

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

如果返回一段包含模型列表的 JSON，说明 Ollama 本身没问题；接下来才是被 Page Assist 调用。这里有一个容易忽略的点：OLLAMA_ORIGINS的值为chrome-extension://*时，*号匹配的是该 scheme 下的任意扩展 ID。为什么不用写死某一个 ID？因为每次 Chrome 更新或你重新加载扩展，扩展 ID 有可能变动，写死白名单等于埋雷，通配符在这里是省事且安全的做法——因为只有浏览器扩展这种进程才有chrome-extension://源，普通网站伪造不了。

参数说明：OLLAMA_HOST不建议动，保持127.0.0.1即可；OLLAMA_ORIGINS可以写多个来源用逗号分隔，比如你既要给 Page Assist 用，又要给局域网内的某个开发机调试，那就加上OLLAMA_ORIGINS="chrome-extension://*,http://192.168.1.100:3000"。每次改完环境变量，都必须完全重启 Ollama 进程才生效，很多"改完还报错"其实是因为旧进程还占着端口、新配置根本没加载。

3.3 在 Page Assist 里配置 Provider：地址、模型名和请求参数

Ollama 服务正常后，回到 Page Assist 的设置页。Provider 选 Ollama，API 地址填http://127.0.0.1:11434。这里注意括号里的细节：有些版本默认填的是http://localhost:11434，而localhost在部分系统上会先解析成 IPv6 的::1，如果 Ollama 只监听了 IPv4 就会连接失败。所以我建议一律写127.0.0.1，少一个变量就少一次排查。

模型列表会自动从 Ollama 拉取。DeepSeek 系列在 Ollama 上有多种命名（量化程度和蒸馏参数不同），常见的有deepseek-r1:7b、deepseek-r1:1.5b这类蒸馏量化命名，以及针对代码场景的变体。选择时按硬件显存判断：8GB 显存跑 7B 量化版还可以，纯 CPU 就老实选 1.5B，否则响应速度会让你怀疑服务是不是挂了。

请求参数里，最值得调的是num_ctx（上下文长度）。Ollama 默认的上下文长度有时候才 2048，也就是说你喂给模型的对话历史超过这个 token 数之后，模型会直接丢掉最早的部分，造成"聊着聊着它忘事儿了"。Page Assist 有的版本会在请求里把参数传给 Ollama，如果你没看到入口，可以直接在 Ollama 的模型配置文件里改：

ollama create deepseek-r1:7b -f Modelfile # Modelfile 里写： # FROM deepseek-r1:7b # PARAMETER num_ctx 8192 # PARAMETER temperature 0.6

这段命令的意思是：基于现有模型创建一个继承其权重的自定义配置副本。num_ctx 8192相当于约 6000 个中文字符的上下文，日常网页总结和长对话够用；temperature 0.6是创造性开关，代码生成和翻译建议设低一点（0.3~0.5），闲聊可以到 0.8。需要说明的是，num_ctx改大直接增加 KV cache 的内存占用，8GB 内存的机器不要无脑拉满 32768，否则模型加载时内存直接爆掉。

4. 避坑清单：连不上 Ollama、模型列表空白和对话中途断掉

4.1 坑一：curl 能通，扩展里却一直转圈

现象：在终端里用 curl 访问 Ollama 的/api/tags返回正常，但 Page Assist 里测试连接时一直转圈或返回 403。

原因：没有设置OLLAMA_ORIGINS，或者设置后 Ollama 进程没重启。浏览器发起的请求带了chrome-extension://源，而 Ollama 默认拒绝。

解决：按 3.2 节设置OLLAMA_ORIGINS=chrome-extension://*，然后确认 Ollama 进程真的重启了。有个混淆点：Windows 托盘区或者服务管理工具里看到的 Ollama 进程可能是开机自启的另一个实例，你手动启动的这个只是一个前台进程。最稳妥的验证方式是杀掉所有 ollama 相关进程，再重新启动，然后在 Page Assist 里重新跑一次连通性测试。

4.2 坑二：模型列表是空的，但 Ollama 里明明有模型

现象：在 Ollama 终端里ollama list能看到deepseek-r1:7b，Page Assist 的模型下拉框却是空的。

原因：很多情况下是 API 地址填成了http://localhost:11434，而 Page Assist 所在的运行环境解析 localhost 时走了 IPv6；另一种情况是扩展从缓存里拿了启动时的空白列表，没有重新拉取。

解决：把地址统一改成http://127.0.0.1:11434，然后关掉扩展页面重新打开。如果还不行，在浏览器开发者工具的网络面板里看/api/tags请求是否有报错；看到 403 就回到坑一，看到 200 但前端还是空的，就重启浏览器。为什么缓存会过期？因为 Ollama 的模型列表是动态的，扩展只会拉一次并缓存，不会实时探测。

4.3 坑三：对话中途突然断掉或超时

现象：聊得正投入，模型回答到一半，页面报错或者干脆空白。

原因：最常见的是num_ctx太小。长对话时 prompt 的 token 数超过了模型的上下文窗口，Ollama 不会自动截断而是直接报错。另一个容易被忽略的原因是 CPU 推理太慢，扩展默认的请求超时时间不够用，尤其用 7B 模型在无 GPU 环境跑长文本生成的时候。

解决：按 3.3 节的方式加大num_ctx，同时在 Page Assist 的请求参数里看有没有超时设置，有就调到 120 秒以上。如果你用的是同一台机器的核显或集成 GPU，注意观察显存占用是不是已经满了——显存溢出不报错，而是表现为生成速度骤降，这种翻车最隐蔽。可以先降到 1.5B 模型确认链路，再换回 7B 排查性能瓶颈。

4.4 坑四：网页上下文功能"选中总结"没反应

现象：在一个网页里选中一段文字，点 Page Assist 的"总结/翻译"按钮，聊天框迟迟没有动静。

原因：权限问题或者页面限制。如果扩展没有"读取网页内容"权限，它拿不到选中的文本；如果在浏览器的内部页面（如chrome://开头的页面或扩展商店页面），任何扩展脚本都无法注入，这是浏览器的安全机制。

解决：回到扩展详情页，确认"读取网站内容"权限是开启的；普通页面如果还不行，刷新一次页面让 content script 重新注入。我一般会先在example.com这种普通网站上测试，排除是内部页面的问题。这条经验提醒我：网页上下文功能好用，但它不是一个万能剪切板，遇到无权限页面时该复制粘贴还是复制粘贴。

4.5 坑五：WebLLM 模式下模型下载到一半就失败

现象：不用 Ollama，改用 Page Assist 内置的 WebLLM 跑模型，下载进度条卡在 80% 或者中途失败，重试又开始从头下。

原因：WebLLM 把模型文件缓存在浏览器存储里，是一个黑盒。断点续传逻辑在处理分片文件时有时候不够可靠，加上模型文件本身好几个 GB，任何一次网络抖动都可能中断。

解决：除了找个稳定的网络重试之外，更常用的做法是直接放弃 WebLLM，回到 Ollama 方案——Ollama 的下拉中断后续传逻辑成熟得多，而且不会把浏览器站点数据塞爆。这个坑给我的教训是：浏览器内跑模型这个功能适合做演示或临时用，真要长期用，还是让专业后端干专业事。

5. 进阶玩法：用 WebGPU 在浏览器里直接跑 DeepSeek 蒸馏模型

5.1 零后端原理：WebLLM 把 GPU 计算搬到了浏览器的 WebGPU API 上

Page Assist 的第二种模型来源是浏览器内模型（WebLLM），原理是把大模型推理所需的算子用 WASM 和 WebGPU 重写，数据预处理、token 采样、KV cache 全部在浏览器进程内完成，完全绕过 Ollama。模型权重以分片文件形式下载到浏览器的站点存储里，然后按需加载到显存/内存。它没有独立的服务进程，没有端口，也没有 Python 环境依赖——两个浏览器标签页，一个跑模型，一个聊天。

但要冷静看待这个模式的边界：能塞进浏览器跑的 DeepSeek 模型，通常只有蒸馏版的小参数模型（1.5B / 7B 的 4-bit 量化）。由于 WebGPU 的实现和驱动有关，同样一个模型在同一台机器上换个浏览器版本，速度可能差一倍以上。这个方案的定位是"应急 + 极简"——适合不方便安装 Ollama、或者临时在一台干净的机器上演示用。生产级体验还是 Ollama 更稳，不要指望 7B 模型在浏览器里能追上原生推理后端的性能。

用 WebGPU 跑模型，首要前提是浏览器支持并启用了 WebGPU。Chrome 较新的正式版已经默认开启，但如果你用的是旧版本或被组策略禁用的环境，就需要手动检查。

5.2 验证 WebGPU 是否可用：一个 JS 命令搞定

打开目标页面（任意 https 网页或扩展页面），按 F12 打开控制台，输入：

// 检查当前浏览器是否暴露 WebGPU API if (navigator.gpu) { // 请求适配器，打印 GPU 基本信息 const adapter = await navigator.gpu.requestAdapter(); console.log(adapter ? `WebGPU OK: ${adapter.info.vendor}` : 'No adapter'); } else { console.log('WebGPU not supported in this browser'); }

这段代码的思路分两层：navigator.gpu存在只代表浏览器实现了 API，真正能不能用还要看requestAdapter()能不能拿到一个适配器。如果适配器是null，说明当前设备的显卡驱动或者浏览器黑名单机制把 WebGPU 禁用了。最常见的场景是 Windows 的远程桌面会话里，很多虚拟显卡驱动不在 WebGPU 的支持列表内，脚本会打印 "No adapter"。

运行环境要求还有一个容易踩的点：WebGPU 必须先过安全检查，如果页面是在 HTTP（非 localhost）环境下打开，requestAdapter()同样会拒绝返回适配器。而 Page Assist 的扩展页面天然是chrome-extension://安全源，所以一般不会有这个问题；但如果你把它的窗口抽出来放进普通标签页调试，就要注意协议。参数说明：这里我没有写死任何设备型号，因为 WebGPU 的支持矩阵是驱动相关的黑匣子，你的机器能不能用，跑一下脚本比查文档快得多。

5.3 切到浏览器内模型：模型选择、缓存管理和期望值管理

在 Page Assist 的设置里把 Provider 切到"浏览器内模型 / WebLLM"，它会出现可用的模型列表。选择 DeepSeek 蒸馏版的时候注意看量化说明：Q4 甚至 Q3 量化通常是为了适配 8GB 以下显存，模型质量会有可见下降；Q8 以上跟原始权重差距小，但内存压力大。我一般按这个逻辑选：日常聊天选 Q4，代码或翻译类任务选 Q6/Q8 且保证显存足够。

参数上值得调的有两个：上下文长度和 temperature。WebLLM 的上下文长度会直接影响显存占用，建议从 4096 起步，跑长了再往上调。temperature 和 Ollama 里的含义一样，但这个环境里我习惯设低一些，因为浏览器内模型的采样稳定性本来就稍弱，0.4 左右比较保险。

模型文件下载到浏览器存储后，占用体积相当可观（多个 GB），清理方式是删除扩展的站点数据（在浏览器设置里清除该扩展的存储）——相当于后悔药，但吃完就得重新下载。缓存文件只能整体管理，WebLLM 目前没有提供按模型单独删除的粒度。

6. 最后一个习惯：把"选中文本一键喂给模型"变成肌肉记忆

真正提升 Page Assist 使用频率的，是它那个网页上下文功能。用顺手的方案是配置三套固定提示词，在设置里分别存好，用时选中文本一键触发：一套是"把下面内容压缩成三条要点"，适合读技术文档；一套是"把下面内容翻译成中文，术语保留英文并解释"，适合看英文 issue；还有一套是"指出下面这段代码里的问题并给修改建议"，适合逛代码片段。这三套模板能盖住日常 80% 的诉求，省去了反复输入相同指令的麻烦。

使用时选中文本、打开侧边栏点对应模板，模型收到的是"当前页面内容截取 + 你的指令"。这里有一个安全习惯要养成：不要选中登录后才能看到的隐私内容喂给模型，尤其是本地模型虽然不联网，但网页上下文本身可能会带上页面里其他不可见的文字（比如未渲染的隐藏段落）。有一次我给一个在线后台管理系统做页面文案总结，选中一段可见内容，模型却把隐藏在页面 JSON 里的另一段数据也一起处理了。从那以后，凡是涉及敏感数据的页面，我都关掉网页上下文权限，手动把文本复制进聊天框——多花十秒，少很多不必要的风险。

这套工作流的最终形态是：浏览器常年开着，侧边栏随手呼出，Ollama 在后台待命，DeepSeek 蒸馏模型负责翻译、总结、写代码草稿。不再为一次"临时总结"打开各种云笔记或第三方 AI 网页。Page Assist 给我的最大价值，不是又一个聊天框，而是把本地模型变成浏览器的原生能力。希望帮到你。

本文还有配套的精品资源，点击获取