企业官网建设流程全解析

简介：Page Assist 是一款面向 Ollama 本地 AI 模型的 Chrome 浏览器插件，适合需要在浏览器侧边栏中快速与本地大模型对话、查询和整理信息的用户。无论是日常问答、内容摘要生成，还是本地知识库交互，都可以在侧边栏内完成。这份源码包共 95 个文件，压缩包约 6MB；文件类型以 ttf、woff、woff2 字体资源为主，同时包含 JSON 配置、JavaScript 脚本、HTML 页面、PNG 图标以及 WASM/OCR 相关模块，结构清晰，便于直接安装、修改或学习。插件通过 sidepanel 侧边栏、options 设置页、background 后台脚本和 manifest 配置协同工作，还引入了 KaTeX 数学公式渲染字体与离线 OCR 引擎，可支持公式显示和图片文字识别；_locales 多语言目录覆盖中、英、日、德等常用语言，assets 与 content-scripts 则提供了静态资源和网页内容交互能力，适合作为完整扩展开发范本。目前已有 896 人浏览/学习，适合 Chrome 插件开发者、Ollama 用户及对本地 AI 应用感兴趣的爱好者参考。

1. Page Assist 是什么：把 Ollama 本地模型变成浏览器的随身助手

Page Assist 是一个专门给 Ollama 配套的 chrome 插件，装上之后不用切窗口，在浏览器侧边栏就能和本地大模型对话、读取当前页面、选中文字直接提问。过去我用 Ollama 只会在终端敲命令，查资料要把网页内容复制粘贴到终端再回车，来回切窗口很割裂，输出排版在终端里也没法看。装了这个插件，整个体验才对得上"本地 AI 助手"这几个字：页面内容不出本机，所有推理在本地跑，不经过任何云端 API。

它对三类人最实在：一是数据隐私敏感的用户，网页内容不想交给第三方服务；二是后端开发和运维，日常要调试 Ollama、对比多个本地模型效果，需要一个顺手的图形界面；三是刚开始玩本地大模型的新手，不想为装一个 WebUI 去折腾 Docker 和 Node 服务，一个 chrome 插件就是最低成本的接入方式。后面每个章节都围绕一个目标：装好、连上、用好、坑少踩。

2. 部署前的准备：Ollama 环境、模型拉取与硬件基线

2.1 先把 Ollama 跑起来：服务验证是第一道关

Page Assist 本身不加载模型、不负责推理。它的本质是一个 API 客户端，把你在侧边栏输入的文本整理成请求，发给 Ollama 服务端，再把流式返回渲染到界面上。所以整个链路的第一环永远是：Ollama 服务必须正常监听。很多人插件装完显示连接失败，第一反应是插件坏了，实际上 80% 是服务端没起来。

装好官方安装包后，服务默认监听 11434 端口。验证服务状态我先用两条命令：

ollama list curl http://localhost:11434/api/tags

第一条列出本地已拉取的模型，第二条直接请求 API 的模型列表接口。如果 curl 返回的 JSON 里有 models 字段，说明服务是活的。我一般在这里先做隔离：先用这两条命令确认服务端正常，再去碰插件，这样能省掉一大半排查时间。

接着拉一个最小模型验证推理链路：

ollama pull qwen2.5:3b ollama run qwen2.5:3b "用一句话介绍你自己"

pull 是把模型权重从仓库下载到本机，run 是启动一个交互式会话。qwen2.5:3b 这个 tag 对应 30 亿参数的量化版本，磁盘占用大概 2GB 上下，内存压力小，是验证链路性价比最高的选择。如果 run 之后半天没输出，先考虑是不是首次加载的冷启动，再怀疑驱动和内存。模型拉取完成后，Ollama 会在收到请求时才把权重加载进内存，首次等待十几秒很正常。

2.2 模型选型：看内存总量，别只看参数规模

本地模型的选型有一个玄学：参数规模只是参考，量化版本和硬件内存共同决定能不能跑出可用的速度。"拉得下来"和"用得动"是两码事，新手最容易一上来拉 70B 模型，结果每秒蹦两个字，最后把插件卸载了怪工具不行，其实问题出在选型。

我的建议基线是这样：

选型时还有两个容易忽略的点。第一是语言倾向，中文场景优先 qwen 系列，llama 在中文口语和成语理解上明显弱一截；第二是模型默认上下文长度，有些模型的默认上下文只有 2048，处理网页全文会非常吃力，需要配合参数调大。这些在后续章节会展开讲。

2.3 量化版本与显存：为什么 16GB 是分水岭

Ollama 的模型 tag 里带 3b、7b、8b 是参数量，但实际内存占用要按量化精度算。常见做法是看 q4 量化版本，8B 模型在 q4 精度下权重大约 4.5GB，加上激活值和上下文缓存，总占用在 6-8GB 之间。这就是为什么 16GB 内存机器能流畅跑 7B/8B 模型，而 8GB 机器会明显卡顿，甚至触发系统换页。

看实际占用用这个命令：

ollama ps

输出会列出当前加载的模型、占了多少内存或显存、以及推理速度。我在调优阶段隔几分钟就跑一次。如果你发现某个模型加载后一直驻留内存、导致浏览器和其他应用变卡，可以在 Ollama 的模型配置里调低 keep_alive 时间，让模型闲置后自动卸载。这个参数后面避坑章还会提到。

2.4 GPU 加速与驱动：没有独显的预期管理

Ollama 默认优先用 GPU 推理，没有独显就退回 CPU。同一台机器上，7B 模型在独显上能跑到每秒三四十个 token，纯 CPU 往往只有个位数。这个差距直接决定侧边栏的回答速度，也决定你日常到底愿不愿意用它。

怎么确认模型到底跑在 GPU 还是 CPU？开调试日志：

OLLAMA_DEBUG=1 ollama serve

然后正常发一条请求，日志里会明确写 loaded 了多少层到 GPU、VRAM 用了多少。如果看到 VRAM 为 0，就是纯 CPU 推理。我经常遇到的情况是：机器明明有显卡，但驱动版本太旧或者没有装 CUDA 运行库，Ollama 检查不到 GPU，静默退回 CPU。这种问题在日志里一眼就能看出来，别在插件设置里瞎调参数。

3. 安装 Page Assist 插件：三条路径、跨域配置与连接验证

3.1 最省事的路：应用商店安装与信息核查

服务端备好之后，进入浏览器侧。安装首选是 Chrome 网上应用店，打开后搜 "Page Assist"，一般会看到一个标题类似 "Page Assist - Sidebar for Ollama" 的条目。这里有个核查习惯要养成：装之前看两个信息，一是最近更新时间，二是使用者数量。插件类工具维护频率很重要，长时间不更新可能和最新版 Ollama 的 API 不兼容。

装上之后，在浏览器工具栏找到 Page Assist 图标，右键固定到工具栏更顺手。点击后侧边栏从右侧滑出，第一次打开会进设置引导页。此时不要急着聊天，先确认设置里的 Ollama URL 是不是http://localhost:11434，如果服务跑在远程机器上，要换成对应的 IP 和端口。

这里有一个容易被忽略的细节：商店版的自动更新由浏览器管理，但推送有延迟。当你发现 Ollama 升级之后插件行为变怪异，先去商店手动检查更新，这个是一个常见翻车点，后面排查章会再带一句。

3.2 源码构建：适合排查与实验的开发版路径

如果你要用到商店版还没上线的功能，或者想把插件当黑匣子拆开看它的请求逻辑，就走源码构建。我在开发机上一般这么操作：

git clone 官方仓库地址（GitHub 上搜 page-assist 即可找到） cd page-assist npm install npm run build

这段命令的逻辑：clone 把源码拉到本地，npm install 根据 package.json 装齐依赖，npm run build 把前端源码打包成浏览器能识别的扩展目录结构。构建产物默认在 dist 目录。然后打开浏览器的扩展管理页chrome://extensions，开启右上角"开发者模式"，点"加载已解压的扩展程序"，选中 dist 目录就装上了。

有几个版本相关的坑提前说清楚。Node 版本低于 16，npm install 经常报依赖冲突，我一般直接用 Node 18 或 20 LTS。构建过程中如果报某个包找不到，优先删掉 node_modules 和 package-lock.json 重装一遍，而不是手动去装包。另外，源码版和商店版同时装会导致配置互相覆盖，实验时只保留一个。我自己的习惯是：日常用商店版，要排查才临时切到源码版。

3.3 连接配置：OLLAMA_ORIGINS 与跨域放行

插件装完、服务也在跑，但侧边栏仍然连不上，十有八九是跨域问题。浏览器对跨域请求的管控非常严格，插件页面的 origin 和 Ollama 服务的 origin 不一致时，即便都在 localhost，浏览器也会拦截响应。Ollama 默认只放行少数可信来源，需要显式配置允许插件来源访问。

Linux/macOS 下这样配置：

export OLLAMA_ORIGINS="chrome-extension://*" ollama serve

Windows 下在系统环境变量里新建 OLLAMA_ORIGINS，值填chrome-extension://*，然后重启 Ollama 服务。这里有个执行细节：Ollama 在 Windows 上有系统托盘图标，改完环境变量要把托盘里的进程完全退出再重新启动，只改不重启完全不生效。

通配符*开发时用省事。但如果你把 Ollama 暴露到了内网，我建议收紧成具体的扩展 ID，写法是chrome-extension://<你的扩展ID>。扩展 ID 在chrome://extensions页面当前插件的卡片上能看到，是一串 32 位字符串。改完之后回到插件设置面板点"测试连接"，能列出模型列表就说明链路通了。

3.4 远程 Ollama 服务器：OLLAMA_HOST 与内网场景

如果你和我一样，把 Ollama 跑在一台内网的大内存机器上，Page Assist 装在自己的办公机上，那就要处理监听地址的问题。Ollama 默认只监听 127.0.0.1，远程访问需要改监听地址：

export OLLAMA_HOST="0.0.0.0:11434" ollama serve

改完之后，插件设置里的 Ollama URL 填局域网 IP，比如http://192.168.1.100:11434。这一步有两个附加风险要处理：一是系统防火墙要放行 11434 端口，二是跨域的 OLLAMA_ORIGINS 值要包含办公机的来源，或者干脆配置成需要的具体来源。远程方案能让你在轻薄本上享受大显卡的推理速度，但代价是网络排查多了一层，出问题时先分别验证：办公机能 ping 通服务器、服务器本机能 curl 通 API、插件设置里的 URL 没有拼错。

4. 从能用到好用：页面上下文、多模型切换与推理参数调优

4.1 页面上下文传递机制：整页、选中与截断

Page Assist 区别于普通聊天框的核心能力是页面感知。它能读当前标签页的内容，作为上下文带给本地模型。这个能力背后的逻辑不复杂：插件通过浏览器扩展 API 拿到页面 DOM，剔除 script、style、隐藏元素后提取正文纯文本，拼进提示词一起发给 Ollama。本质上你发的请求长这样：

curl http://localhost:11434/api/chat -d '{ "model": "qwen2.5:7b", "messages": [ {"role": "system", "content": "你是页面摘要助手，输出精炼结论"}, {"role": "user", "content": "请总结以下页面内容：<这里是提取出的页面正文>"} ], "stream": true }'

这个请求体基本就是插件在后台做的事情。system 消息约束模型的回答风格，user 消息携带页面正文，stream 开启流式输出让侧边栏逐字渲染。

业务上要分清两种用法：整页上下文适合对长文章做摘要，但提示词非常长，吃上下文窗口；选中文本上下文只有一段，模型回答更精准，不容易被无关内容干扰。我日常用最多的是选中模式：打开文章、选中关键段落、让模型解释或改写。整页模式只在需要全文综述时才开。

上下文长度是这里最大的隐形坑。默认 contextLimit 不高，长网页的正文经常超出窗口，超出部分被静默丢弃，表现就是模型答非所问，或者只基于前半段回答。处理长文时先调大上下文：

ollama run qwen2.5:7b --num-ctx 8192

这个参数临时指定本次会话的上下文长度。注意 num_ctx 提高后内存占用明显上升，8B 模型从 4096 拉到 8192，内存可能多消耗 2-3GB。所以不是越大越好，要在页面实际长度和硬件承受力之间找平衡。

4.2 多模型路由与快捷指令：把常用操作模板化

插件支持同时配置多个模型，按场景切换，不用每次改 Ollama 默认模型。常见做法是在设置里维护一个模型列表：

{ "models": { "默认问答": "qwen2.5:7b", "长文摘要": "llama3.1:8b", "代码助手": "qwen2.5:14b" } }

这样拆的好处是：普通问答用 7B 保证响应速度，长文摘要切到上下文能力更强的模型，代码审查用参数更大的 14B 提升推理质量。切换就在侧边栏顶部的模型下拉框里完成，一次点击的事。

快捷指令是另一个被低估的功能。它本质是预置的提示词模板，相当于 system prompt。我存了几条常用的："把这段内容改写成周报口吻"、"给这段代码找 bug 并给出修改建议"、"总结这篇文章的三个核心结论"。存好之后配合选中文本，一键触发，不用每次手打提示词。

存模板有个心得：指令里最好写清楚输出格式。比如摘要类指令结尾加一句"分三条输出，每条不超过 50 字"，模型会稳定输出结构化结果。这个习惯对本地小模型尤其重要，因为它们的指令遵循能力弱于大模型，输出约束写得越明确，返工越少。

4.3 推理参数调优：temperature、num_ctx 与 num_gpu

如果觉得模型回答质量忽好忽坏，除了提示词问题，多半是推理参数没调。Ollama 支持通过 Modelfile 固化模型参数，比每次命令行传参更规范：

FROM qwen2.5:7b PARAMETER num_ctx 8192 PARAMETER num_gpu 999 PARAMETER temperature 0.3 PARAMETER top_p 0.9

几个参数逐个说。num_ctx 是上下文窗口长度，按页面场景调。num_gpu 表示卸载到 GPU 的层数，写 999 意思是尽量全量卸载；没有独显时这个参数被静默忽略，退回 CPU 不报错，这也是一个常见误区——以为写了就有 GPU 加速，实际要看日志确认。temperature 控制随机性，摘要、改写类任务用 0.3 左右输出稳定，创意文案可以调到 0.8 以上。top_p 是核采样阈值，配合 temperature 用，0.9 是相对保守的默认值。

4.4 效果验证：固定测试问题与一致性检查

调参之后怎么验证效果？看两个指标：生成速度和输出质量。速度用ollama ps看 token 生成速率，输出质量靠多跑几次对比。我的习惯是每个关键参数改完，固定同一个测试问题连跑三遍。如果三遍输出差异很大，说明 temperature 偏高，或者模型能力撑不起这个任务，优先降 temperature，而不是换更大的模型。

这个验证习惯还有一个附加价值：能暴露上下文截断问题。同一个问题，短文本下三遍回答一致，换成长网页就串台，那基本可以断定是上下文被截断而不是模型问题。把测试样本固定下来，等于给本地模型环境做了一套最轻量的回归测试。

5. 避坑排查：连接失败、上下文错乱与五个常见翻车点

5.1 现象：插件一直转圈，控制台报 CORS 错误

原因：Ollama 没有配置 OLLAMA_ORIGINS，浏览器拦截了跨域响应。请求其实发出去了，但响应被安全策略挡在门外，插件拿不到数据只能一直转圈。

解决：在系统环境变量里新增 OLLAMA_ORIGINS，填chrome-extension://*，然后完全退出托盘里的 Ollama 进程再重新启动。只改环境变量不重启不生效，这一点最容易踩。改完回插件设置点"测试连接"，能列出模型就说明跨域通了。

5.2 现象：能连上，但每次第一轮回答要等很久，后续又正常

原因：模型冷启动。Ollama 在接到请求时才把权重加载进内存，首次请求要等十几秒甚至几十秒，加载完成后模型驻留内存，后续请求就快了。如果长时间不用，模型又会被按 keep_alive 策略卸载，再次触发冷启动。

解决：使用频率固定的话，在 Modelfile 里把 keep_alive 调长：

PARAMETER keep_alive 1800m

或者干脆接受这个等待，把它当成本地模型固有体验。不要误判成插件问题去重装扩展，浪费的时间比等待本身还多。

5.3 现象：选中网页文字提问，模型答非所问或引用无关内容

原因：页面正文提取不干净，脚本动态生成的内容、隐藏标签、导航文本混进上下文；或者整页模式和选中模式叠加，内容超出模型窗口后被静默截断。

解决：先把模式收敛到一种，只开选中文本，不要同时开整页。如果必须整页，按 4.1 的方法调大 num_ctx，并确认 contextLimit 大于页面正文实际字数。查看页面字数有个小技巧：在浏览器开发者工具的 Console 里执行document.body.innerText.length，几秒就能得到正文长度，用这个数去对照上下文窗口设置，能快速判断是不是截断导致的串台。

5.4 现象：插件更新后，自定义模型列表和快捷指令全部消失

原因：插件更新过程中本地存储被重置，或者同时装了商店版和源码版，两个实例共享的 storage 互相覆盖，后加载的实例把先写的配置冲掉了。

解决：养成导出备份的习惯。Page Assist 设置页有配置导出功能，把模型列表和快捷指令导出成 JSON 存到本地，更新完成后重新导入。如果同时装有商店版和源码版，只保留一个。这是我踩过的血泪坑，开发版每 build 一次就可能丢一次配置，没有备份就只能重新配。

5.5 现象：笔记本休眠唤醒后插件连不上 Ollama，重开浏览器也没用

原因：系统休眠时 Ollama 服务进程被挂起，网络 socket 失效，唤醒后进程没有自动恢复监听。这是本地服务类工具在笔记本上的通病，台式机开了休眠也一样。

解决：开启 Ollama 的开机自启；更稳的做法是写探活脚本，定时检测 11434 端口，不通就自动拉起ollama serve。Windows 用任务计划程序，Linux 用 systemd 定时器，都能实现。脚本本身很简单，核心就是 nc 或者 curl 探活加 restart 动作，别在这个问题上反复手动重启。

查这些问题时有个顺序方法论：先ollama list确认服务端有模型，再插件里测试连接，然后开长网页实测上下文，最后ollama ps看资源。按这个顺序走，九成问题能定位到具体环节，不会出现"以为插件坏了，其实是 Ollama 没启动"的误判。

6. 进阶玩法：把 Page Assist 用成真正的本地知识工具

到这一步，插件已经稳定运行，但它还只是个"聊天框"。我把它从聊天工具变成工作流入口，主要用了两招。

第一招是封装场景化指令。回看我存过的模板：翻译并解释术语、代码审查、周报改写、全文观点提取。每条模板的提示词里都刻意写了输出约束，比如"先给结论再给论据，结论不超过两句"。配合选中文本，日常工作中 80% 的重复提问被压缩成了一键操作。这个收益在长文档场景最明显：以前读一篇技术文档要自己划重点，现在选中章节丢给模型，让它按固定格式输出要点和疑问点，我再对着要点精读原文。

第二招是和内网模型服务器配合。本地笔记本跑 7B 模型始终有硬件上限，团队有 24GB 以上的 GPU 机器时，我一般把 Ollama 跑在那台机器上，Page Assist 的 Ollama URL 指向内网地址。浏览器不占本地资源，推理走内网大显卡，速度比本地 CPU 快一个数量级。跨机器明文传输的暴露面要自己评估，更稳妥的做法是给 Ollama 服务套一层反向代理再加鉴权，代理层顺手把超时和请求体大小限制也一起管了。

关于验证，我每次改配置或换模型都会强制走一遍固定四步：ollama list查服务端模型，插件设置里点测试连接，开一个长网页实测上下文传递，ollama ps看资源占用。四步走完，几乎不会把问题留到下一次会话。这个习惯是我头一周踩坑踩出来的，当时连续两天以为是插件坏了，最后发现是休眠后服务没起来，从那以后我每次换机器、重装环境都会强制把四步验证走一遍，再没有在这个插件上浪费过排查时间。如果你刚入手本地模型工具链，把这套流程记下来，能少走很多弯路。希望帮到你。

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