简介Page Assist 是面向 ollama 本地模型生态的 Chrome 插件资源包适合想在浏览器中快速调用本地 AI、自建侧边栏 Web 界面的开发者与进阶用户。资源共 95 个文件、压缩后 6MB以 ttf/woff/woff2 字体、json 配置、js 脚本和 html 页面为主体另含 css、png、wasm 等辅助资源文件类型覆盖前端渲染、脚本逻辑、界面样式与字体图标等多个方面既包含界面呈现所需静态文件也包含后台逻辑与多语言本地化内容。已有 896 人学习下载可用于学习 Chrome 插件工程结构或二次开发。文件中侧边栏页面、设置页、后台脚本与扩展清单配置清晰可循配合内容脚本、分块代码、多语言目录能帮助理解侧边栏交互、设置项配置、后台事件监听与国际化实现OCR 相关 wasm 与语言数据文件还展示了本地识别能力的集成方式整体适合作为本地 AI 浏览器工具链的参考实现或改造起点。1. 本地模型装好了浏览器里却用不上Page Assist 补上最后一块拼图搞过本地大模型的人都有这个经历ollama 拉了一个不错的模型终端里 curl 一把能跑通但真正想在日常用起来就卡住了——复制网页内容、切到终端、贴进 curl、再等输出。Page Assist 就是冲着这个痛点来的它是跑在 Chrome 里的侧边栏插件直接连本机 ollama 的 API把聊天窗口、网页选中提问、本地文件对话都收进浏览器。适合两类人本地模型已经跑通、想把模型用进日常阅读和写作的人以及正在调研本地模型能不能替代在线 API、想先低成本验证的人。这条路径不用写一行前端代码装好插件、点两下设置就能把模型搬进浏览器。2. 把环境铺好ollama 与 Page Assist 的安装和首次连接2.1 先确认 ollama 服务真的在跑两条命令验证 API 可用很多插件连不上的问题其实在 ollama 那边就已经断了。安装完 ollama 后默认监听127.0.0.1:11434。先验证两件事服务有没有起来、模型有没有拉好。ollama list curl http://localhost:11434/api/tagsollama list能看到本机已下载的模型列表curl请求/api/tags返回一个 JSON 对象里面的models数组包含模型名称、大小、修改时间。如果 curl 报connection refused说明 ollama 服务没起来先查任务管理器或系统服务里的 ollama 进程。在 Windows 上 ollama 安装后默认开机自启托盘区有小羊驼图标在 Linux 上用systemctl status ollama看服务状态。我一般会先跑 curl 再打开插件因为插件界面上的报错不如 curl 直白——connection refused一看就知道是服务端问题不是插件配置问题。确认 API 可用后再确认模型已经存在。插件本身不负责下载模型模型列表为空的话先在终端用ollama pull拉一个模型回来。这一步卡住后面所有功能都无从谈起。注意插件的模型列表完全依赖/api/tags的返回。你在终端里感觉模型应该能用和插件里看到模型名是两回事后者才是插件工作的前提。2.2 安装 Page Assist商店安装与手动加载两种路径Page Assist 以 Chrome 扩展的形式分发正常安装路径是从 Chrome 应用商店搜索 Page Assist 直接添加。装完之后地址栏右侧会出现一个图标。这里有个细节很多用户装了之后找不到入口因为扩展的弹出窗口和侧边栏是两套 UI——图标点击默认弹出小窗口真正的侧边栏在设置里打开或者右键图标选择在侧边栏中打开。如果你所在环境访问不了商店可以用手动加载的方式步骤是先拿到扩展的打包文件通常是 zip解压到一个固定目录然后在 Chrome 地址栏输入chrome://extensions打开右上角的开发者模式点击加载已解压的扩展程序选择包含manifest.json的那个目录。手动加载的扩展在 Chrome 重启后会保留但不会自动更新以后要升级得重新下载覆盖。手动加载的扩展目录不能删一删扩展就失效。我第一次手动加载时把解压后的源文件随手删了结果 Chrome 里的扩展直接报Manifest 文件缺失。这不是什么玄学扩展会直接引用解压目录里的文件所以建议把扩展文件放在一个固定目录里和下载目录分开。2.3 首次连接地址怎么填、模型怎么出现在列表里装好后进入扩展的设置页核心配置项是 Ollama 服务的地址。默认值通常是http://localhost:11434ollama 和 Chrome 在同一台机器时不用改。如果你把 ollama 跑在另一台机器上这里要填那台机器的局域网地址比如http://192.168.1.100:11434并且 ollama 那边要设置监听地址为0.0.0.0否则外部请求会被拒绝。常见做法是给 ollama 配环境变量来控制监听行为环境变量作用示例OLLAMA_HOST控制监听地址和端口0.0.0.0:11434表示所有网卡可访问OLLAMA_MODELS指定模型存放目录D:\ollama\models或/data/ollamaOLLAMA_ORIGINS控制跨域来源白名单*表示放行所有来源内网调试常用OLLAMA_KEEP_ALIVE模型在内存中的驻留时间5m、1h、-1表示常驻设置完环境变量后必须重启 ollama 进程才生效只关掉窗口没用。连接成功后插件会自动拉取模型列表下拉框里能看到模型名。看到模型名剩下的对话、选中提问、文件上传就全是建立在这条链路上的功能了。3. 把 Page Assist 的功能逐个拆开五个高频场景的使用路径3.1 侧边栏对话默认就是最小可用的聊天窗口装好之后不用额外配置点开侧边栏就能用。这就是 Page Assist 和终端 curl 流最大的区别对话记录会保留模型输出是流式的一边生成一边显示而且支持多轮上下文。侧边栏布局左边是模型选择下拉框中间是对话区底部是输入框和常见的在线聊天界面没有太大区别。侧边栏的对话会沿用当前页面的 URL 作为对话标题方便你回头看某次对话是在哪个网页上发起的。对话记录存在浏览器本地不会上传到任何服务器——这一点对本地模型用户很重要数据不出本机。本地模型的核心价值就在这里如果你需要把对话同步到多台设备那不在 Page Assist 的能力范围内它本身不提供云同步。第一次用的时候建议先开一个空白页再测避免浏览器里其它扩展的快捷键冲突。我遇到过某翻译扩展和 Page Assist 抢快捷键的情况表现为侧边栏弹出后立刻被另一个扩展的弹窗盖住。这不算 bug但排查起来很让人头疼先关掉其它扩展再测是最快的定位方式。3.2 选中网页文本提问把任意页面变成模型输入这是 Page Assist 最有辨识度的功能。在任意网页上选中一段文字右键菜单里会出现 Ask Page Assist 之类的选项点击后选中的文本作为上下文传入模型你可以在侧边栏里针对这段文字继续追问。实现原理并不复杂扩展通过浏览器的右键菜单 API 拿到选中文本再拼到当前对话的上下文中。这里要理解一个关键点它传输的是网页的纯文本内容不是网页截图也不是 DOM 结构。对于有大量脚本渲染的页面选中区域是文字就能用但表格、图表这类视觉信息会丢失。我做技术调研时常用的方式是选中某篇文档的核心段落直接问用三句话概括这一段然后再针对术语追问。模型拿到的虽然是纯文本但对话历史里已经包含了这段文字追问不需要重新选中。一个实际限制跨标签页的上下文不会自动合并。你在 A 标签页选中文本提问切到 B 标签页侧边栏里的对话历史还在但新输入的内容默认和 A 标签页的上下文无关。如果想让它关联需要把当前页面的文本重新喂进去。这是扩展的机制设计不是故障。3.3 本地文件对话不开知识库也能做简单的 RAGPage Assist 支持上传本地文件到对话中常见格式包括 PDF、Word、Markdown、TXT 等。上传后扩展会解析文本内容作为上下文的一部分传给模型。这个功能对不想搭完整知识库、就想问几个文档问题的场景非常实用不用额外起服务也没有向量化那套流程。实现逻辑上扩展是把文件内容全文塞进上下文而不是做真正的向量检索。这意味着文件越大占用的上下文窗口越多超过模型上下文限制时超出部分会被截断或直接报错。我一般用这个功能处理说明书、接口文档这类单文件场景超过 50 页的文档会先自己拆成章节再分多次问。文件类型文本解析情况注意事项PDF纯文本可提取扫描版不行扫描 PDF 没有文本层解析出来是空Word正文可提取页眉页脚可能混入长文档容易带出无关内容Markdown / TXT完整提取代码块内容会原样保留注意长度上传后注意看上下文用量提示。如果设置里打开了 token 显示输入框上方能看到当前已用 token 数。当这个数字接近模型上限时回答质量会明显下降——模型会忘掉对话开头的内容表现为回答前后矛盾。这时候应该新开一个对话再传一次文件。3.4 多模型切换与对比同一个对话里换模型看差异侧边栏顶部的模型选择框在对话过程中随时可以切换。切换后当前对话的历史上下文会原样传给新模型相当于同一个问题让多个模型回答。这个功能很适合做模型选型同样一段代码让两个模型各写一遍实现对比风格和正确率。我常用的对比方法是先在侧边栏里输入一个精确的问题拿到第一个模型的回答后不新开对话直接切换模型再问一遍重新回答上面这个问题。注意第二遍问的时候对话历史里已经包含了第一个模型的回答所以新模型看到的是问题模型 A 的回答这会影响它的输出——它可能会倾向于修正或赞同前者。想公平对比应该把两个模型的回答放在两个独立的对话里测。另一个容易忽视的点切换模型不改上下文窗口大小。如果你从一个 7B 模型切到轻量模型原来能容纳的上下文可能超出后者的限制回答会从中间开始丢信息。切模型之前最好清理一下对话历史或者把问题缩小到轻量模型能覆盖的范围。3.5 网页搜索增强给模型装上联网能力可选Page Assist 提供了将搜索结果注入对话的可选功能。设计思路是先通过搜索引擎拿到搜索结果摘要再把摘要作为上下文交给模型让模型基于搜索结果回答。这个功能默认关闭需要在设置里启用并选择搜索服务。这个功能和让模型自己联网不同它实际是把搜索 API 的返回结果拼进 prompt。优点是模型不会胡编链接因为链接有来源缺点是搜索结果质量取决于上游搜索服务的返回而且很多免费搜索接口有限流。我自己的实践是优先用于知识截止期之后的新信息查询比如某个工具的最新版本号日常问答保持纯本地模式避免响应变慢。需要强调的是联网搜索会把你的查询关键词发送到搜索服务——如果查询涉及内部敏感信息这个功能就不应该开。本地模型的价值恰恰在于数据不出本机开启联网搜索等于主动放弃了这一点。我的建议是把它当按需开关而不是常开配置。4. 参数和提示词管理把模型从能用调到好用4.1 温度、上下文长度、top_p 到底在管什么Page Assist 给每个模型提供独立参数配置核心三个Temperature、Top-P、Context Length。很多人全用默认值但默认值不一定适合你的任务——尤其是上下文长度默认值往往等于模型训练时的窗口大小实际使用时很容易触顶。Temperature 控制输出随机性范围通常是 0 到 1默认 0.8。温度越高回答越发散适合头脑风暴、写文案温度越低越确定适合代码生成、格式严格的 JSON 输出。做代码相关任务时我会调到 0.2 到 0.4写文案时维持 0.7 以上。Top-P核采样是另一套随机性控制它从累计概率角度裁掉低概率词默认 0.9。实际调参里调低 Top-P 比调低温度更稳——温度降到太低会让回答机械、重复而 Top-P 降到 0.8 左右通常是严谨但不呆板的甜点区间。Context Length 是最容易被忽略的参数。它决定模型能看到多少历史对话和输入文本。设小了长文档对话会截断设大了推理变慢且显存占用上升。Ollama 对每个模型有一个默认值但 Page Assist 可以针对每个模型单独调大比如给处理长文档的模型设 8192 或 16384。调参有个基本原则先看任务类型再动参数。任务类型推荐温度推荐 Top-P上下文建议代码生成0.2~0.30.7~0.8按项目文件量调越短越快技术问答0.4~0.60.8~0.94K 起步文案写作0.7~0.90.98K 可以覆盖长文翻译0.3~0.50.8按文档长度建议分段这组数值不是标准答案但比全默认值靠谱。我会先按这张表设一个起点跑三次任务看输出风格再微调而不是每次从头试。4.2 System Prompt 与对话预设让模型固定角色Page Assist 支持在设置里配置默认的 System Prompt以及保存多个会话预设。System Prompt 是模型回答任何问题之前都会先读到的一段指令作用相当于给模型定身份、定输出格式。它比在对话里反复叮嘱要稳定得多——每次新对话都会自动带上。我常用的 System Prompt 写法是带输出格式约束的比如你是一名严谨的技术文档写作者。回答时先给出结论再给理由和示例。代码块必须标注语言。不要使用首先…其次…这类没有信息量的套话。如果不确定明确说不确定而不是猜测。这种写法让模型在每轮回答都遵循同样的格式。副作用是它会为每一轮回答消耗额外的 token因为 System Prompt 始终在上下文里。所以 System Prompt 不要写太长50 到 150 字足够表达约束。写成长篇大论反而挤占任务内容的空间。对话预设就是把一组参数和 System Prompt 捆绑保存。比如建一个代码审查预设Temperature0.2、Top-P0.8、System Prompt 写扮演资深代码审查者重点找空指针、并发和边界问题。切预设比每次改参数快得多特别是你有几个固定工作流的时候。4.3 多模型参数差异化配置前面提过参数是按模型独立保存的这里展开讲一下场景。你的机器上大概率同时装了大小不同的模型一个日常问答模型一个轻量模型可能还有一个大参数模型但只在特定任务时用。它们的性格完全不同参数不能一套走天下。对轻量模型我把 Temperature 调高一些0.7~0.8因为小模型本身输出偏保守温度高点能减少机械感。对大参数模型我反而把温度调低0.3~0.5因为大模型能力下限高低温度能保证稳定输出。上下文长度也要分开日常模型给 8K 够用处理长文档的模型给 16K但要确认显存够——上下文越长KV cache 占用显存越多。这里有个容易踩的坑Page Assist 里改参数只对新请求生效。已经产生的对话历史不会因为你调了参数就重算你需要在新的对话里才能看到参数变化的效果。如果改了参数但回答风格没变先确认是不是还在同一个对话里测试。玄学调参大多发生在这种场景——你改了很多但测的是同一段历史自然看不出区别。5. Page Assist 使用排障五个高频坑与排查路径5.1 连接被拒绝ollama 服务和浏览器不在同一个网络视角现象打开侧边栏后选择模型输入任何内容回车回复一直显示连接失败或者转圈后报错。原因Page Assist 通过 HTTP 请求http://localhost:11434这个 localhost 是浏览器所在机器的 localhost。如果你的 ollama 跑在虚拟机、WSL2、Docker 或另一台机器上localhost 指向的根本不是 ollama 所在的地方。另一个常见原因是 ollama 服务本身没启动。解决先在浏览器所在机器上跑第 2.1 节的 curl 命令。curl 能通再看插件设置页的地址是不是默认值改成 ollama 实际监听的地址。如果 ollama 在 Docker 容器里需要把端口映射到宿主机-p 11434:11434。WSL2 内部的 ollama 通常能被 Windows 的 localhost 自动转发但偶尔会出现转发失效这时直接用 WSL2 的 IP 地址最省事。5.2 服务端 CORS 拦截curl 通、浏览器插件不通现象命令行 curl 一切正常但插件里一直报跨域错误控制台显示类似 blocked by CORS policy 的信息。原因ollama 服务端默认允许的来源有限。浏览器扩展的页面运行在chrome-extension://协议下这个来源不在 ollama 的默认允许列表里浏览器就拦截了响应。这是服务端配置问题不是 Page Assist 自身的选择。解决设置环境变量OLLAMA_ORIGINS*然后重启 ollama。Windows 上在系统属性-环境变量里加Linux 上在 systemd 服务配置或 shell profile 里加。设置后确认 ollama 重新读取了环境变量看进程启动时间是不是最新的。注意OLLAMA_ORIGINS*表示允许所有来源内网环境下没问题如果 ollama 服务暴露在公网不建议这样设应该有方向地限制来源。5.3 回答被截断一半输出停在中间且没有报错现象模型回答到一半突然停住刷新后重问有时能回答完整有时还是截断。原因上下文长度num_ctx不够。对话历史、System Prompt、用户输入加起来的 token 数超过了模型配置的上下文窗口ollama 在生成时达到上限就强行停止了。这不是网络问题也不是模型偷懒而是容量触顶。解决在该模型的配置里把 Context Length 调大从 4096 调到 8192 或更高。同时注意显存上下文翻倍KV cache 显存占用也会上升。如果调大后显存不够就只能缩短对话历史、减少上传文件大小或者换一个上下文效率更高的模型。也可以在 Ollama 层面设置默认num_ctx但插件里的设置优先级更高我一般优先在插件里调。5.4 模型列表为空下拉框里什么都没有现象连接看似正常但模型选择下拉框是空的无法发起对话。原因页面的模型列表来自GET /api/tags。列表为空只有两种情况一是 ollama 里真的没有下载任何模型二是模型文件位于自定义路径而当前 ollama 服务启动时读的是默认路径。解决终端里跑ollama list看有没有输出。没有输出就先拉一个模型。有输出但插件里为空检查OLLAMA_MODELS环境变量是否指向了模型实际存放的位置。比如把模型目录改到其他盘符后服务启动时没有带这个环境变量就会到默认目录找人找不到就返回空列表。5.5 GPU 占用率偏低模型响应不稳定时而快时而慢现象同一个模型第一次回答很快隔一段时间后再回答明显变慢甚至要等好几秒才出第一个 token。原因ollama 的 keep_alive 机制。模型在一段时间没有被调用后会被从内存中卸载下次调用需要重新加载到显存这段时间里响应自然慢。这不算故障但会让用户觉得插件是不是卡了。解决在 Ollama 配置或 API 请求里设置更长的keep_alive比如3600s或-1常驻内存。Page Assist 的模型设置里通常能看到 keep_alive 选项拉到最长即可。代价是显存一直被占用不能跑其它大显存应用。我只有在一整天高频使用特定模型时才常驻平时保持默认避免用完一次就占着显存的尴尬。6. 进阶玩法把 Page Assist 从聊天框变成本地工作流入口6.1 接上本地知识库服务补上文件对话的容量上限第 3.3 节里的文件对话在文件量大了以后会不好用因为全文塞进上下文很快触顶。进阶做法是给 Page Assist 配一个本地知识库服务通过自定义 API 的方式接入。这样对话时的上下文来源变成检索后的相关片段而不是全文。实现上你需要一个本地 HTTP 服务暴露一个接口接收 query、返回相关文档片段然后把 Page Assist 的请求转发到这个接口。多数人的实际做法是在 Ollama 前面加一层代理服务代理把请求先送到知识库检索再把检索结果拼进 prompt 发给 ollama。Page Assist 在 Ollama 地址里填这个代理地址即可。这一层不在插件内部实现需要你自己写或找现成的本地网关工具。6.2 用指令模板固化高频操作第 4.2 节提到的预设进阶用法是把整个任务模板做成一条固定指令。我自己的固定指令模板之一是我接下来会粘贴一段日志。你的任务是 1. 识别日志级别DEBUG/INFO/WARN/ERROR 2. 找出最早出现的 ERROR 及其上下文 3. 给出最可能的三个原因按概率排序 4. 只输出结论不要输出过程这个模板配合一个低温度预设让我在处理日志时不用每次重新解释任务。Page Assist 支持把这类长文本保存为快捷指令在输入框里敲一个关键词就能带出整段模板比复制粘贴快很多。这是把模型调教成对口工具的关键一步——不是每次现写指令而是把常做的任务固化成模板。6.3 验证参数是否生效看响应首 token 时间最后给一个验证习惯调完任何参数后不要只看回答内容对不对还要看背后的性能指标。浏览器开发者工具的 Network 面板里能看到每个流式请求的分块时间首块返回时间如果是几百毫秒以内说明模型已经在显存里如果是几秒说明在重新加载。这个数字能帮你判断 keep_alive、num_ctx 调整是否真的生效。我踩过的一个实际教训曾经把 num_ctx 从 4096 调到 16384回答质量没提升反而首 token 时间从 0.3 秒变成 2 秒。后来意识到是显存不够KV cache 把 GPU 显存挤满了模型在做内存交换。那时候我才理解上下文越大越好是错的得看显存余量。此后我调参的顺序固定了先看显存占用再决定上下文长度调整完后用 Network 面板确认首 token 时间没有恶化才算一次成功的调参。这套插件 本地模型 浏览器上下文的组合是目前把本地模型推进日常使用路径里门槛最低、反馈最快的一条。希望这篇笔记能帮到你。本文还有配套的精品资源点击获取