尧图网站建设 
我最早跑本地模型的时候面对的就是一个黑乎乎的终端窗口。ollama run qwen2.5敲进去剩下的时间就是盯着光标闪烁一行一行跟模型对话。能用但非常折磨人——想翻历史记录要往上划半天复制回答里的代码还得手动选中换个模型又得重新敲一次启动命令。后来我开始在浏览器里挂 Page Assist这个图形化界面工具本质上只是一个插件却硬生生给我补上了一个完整的 webUI 体验侧边栏唤起、会话保存、网页联动、本地知识库全都齐了。这篇文章就把我实际的配置过程和踩坑记录整理出来给还在跟终端较劲的朋友一个参考。1. 为什么我需要一个图形化界面从命令行到浏览器侧边栏1.1 命令行时代能用但太累本地大模型起步阶段很多人跟我一样是先从终端入门的。ollama serve跑起来ollama run开启对话感觉上很“极客”实际用起来全是细节上的痛苦。终端窗口里模型回答一长上下文就开始滚动你想回看之前某段关键结论得不断往上翻模型输出代码片段的时候复制整块代码需要鼠标精确框选稍不注意就带着$符号或者系统提示一起复制走。还有更现实的场景——你正在写文档想顺便问模型一个问题就得把注意力从编辑器挪到终端切窗口、找焦点思路全断了。这些痛点本质上不是模型的问题而是缺少一层图形化界面工具。模型只是推理引擎它不负责展示历史、管理会话、渲染 Markdown、读取网页。这些东西都需要一个前端壳子来做。市面上的 webUI 方案很多有的重、有的轻但真正适合个人日常高频使用的我最顺手的就是 Page Assist。Page Assist 的使用场景很明确你在浏览器里干活本地模型跑在后台它作为浏览器插件常驻在侧边栏按一下快捷键就能唤出来问问题。它解决的不只是“跟模型聊天”这一个需求而是把 AI 辅助能力无缝塞进你原本的浏览工作流里不需要额外开一个页面不需要切换窗口网页本身就成了对话的上下文来源。适合谁来用一句话凡是装了 Ollama、LM Studio 这类本地推理工具又觉得纯命令行交互憋屈的人都值得试试。尤其是经常需要一边查资料一边读网页、一边写文章的人Page Assist 的“当前网页摘要、翻译、问答”功能会让你觉得之前用终端纯聊天简直是暴殄天物。1.2 Page Assist 的定位浏览器里的“第二层皮肤”很多人第一次听说 Page Assist会以为它又是一个独立 Web 服务要去部署、要开端口、要维护。实际上它就是一个浏览器扩展Chrome、Edge、Firefox 都能装。装着之后它基本不占端口、不跑后台服务只是在浏览器里渲染出一个侧边栏界面然后通过 HTTP 请求去连接你本机的模型服务。这层“第二层皮肤”的设计其实非常聪明。传统 webUI比如 Open WebUI是独立跑一个本地 Web 服务你需要开着一个页面来使用本质上还是“离开浏览器内容去另一个页面聊天”。Page Assist 反过来它寄生在浏览器里把聊天界面做成侧边栏跟当前标签页并行显示。你左边是正在阅读的技术文档右边是跟模型的对话窗口那种体验是独立页面给不了的。而且因为它是浏览器扩展天然就拥有访问当前页面 DOM 的能力。做网页内容总结、让模型读当前页面再回答专业问题这些都是普通 webUI 需要绕很多弯才能实现的功能对 Page Assist 来说反而成了核心优势。我后面第 3 章会详细展开这几个功能的实际用法和限制这里先记住一个结论Page Assist 不是一个“小号的 Open WebUI”它是完全不同的产品形态和交互逻辑。1.3 横向对比Page Assist vs Open WebUI vs 其他方案既然聊到图形化界面我就把自己实际用过的几类方案放在一起对比一下。Open WebUI 名气最大功能也确实全多用户管理、知识库、绘图插件都有。但它的架构是独立的 Docker/本地服务需要常驻进程启动速度、内存占用都不是零成本的。我一开始也跑过 Open WebUI后来发现我绝大多数场景只是一个人在本机用杀鸡用牛刀而且它的页面交互还是传统的“打开一个站点”跟浏览器本身的联动很弱。其他还有各种基于 Gradio 或 Streamlit 的封装界面用来演示还可以长时间个人使用总觉得差点意思。Page Assist 的定位正好卡在最舒服的位置足够轻、驻留浏览器、跟网页上下文打通。它不追求功能无限大但核心体验非常聚焦安装到能用的时间成本大概就是几分钟。我用一个简单的表格来对比方便你按自己的需求判断对比维度Page AssistOpen WebUI纯终端安装复杂度低浏览器扩展一键装中高需部署服务或 Docker低本身自带界面形态浏览器侧边栏独立 Web 站点无界面网页联动强可直接读取当前页面弱需要手动复制或走工具链无会话管理浏览器本地保存数据库管理功能全面终端滚动记录多用户/权限仅本机个人使用支持团队化使用不支持资源占用很低仅扩展常驻高服务常驻极低适合场景个人日常阅读AI辅助团队共享、重度功能需求临时测试模型指令我个人现在的习惯是轻量问答和网页总结用 Page Assist需要整理知识库、多人共享的时候才考虑把 Open WebUI 拉起来。两条路线互补不冲突。2. 安装与连接把 Page Assist 接到你的本地模型2.1 安装浏览器扩展安装这一步没什么技术含量但有几个小细节值得说一下。以我主力用的 Chrome 为例直接去 Chrome 网上应用店搜索 Page Assist找到后点击“添加至 Chrome”即可。Edge 用户去 Edge 加载项商店搜索同名扩展Firefox 用户则去 Firefox Add-ons 站。名字虽然都是 Page Assist但插件生态各平台独立维护版本号略有差异优先选你主力浏览器对应商店的版本。装完之后默认图标会出现在扩展栏里。我建议你手动把它固定到工具栏不然每次使用都要点拼图图标再找它多一步操作就多一分放弃使用的可能。固定之后单击图标默认是打开一个独立的标签页版界面注意这个不是侧边栏它是一次性会话窗口。真正好用的是侧边栏模式需要在扩展的选项页里设置启动方式或者直接用默认快捷键唤起。这一步容易犯的错误是重复安装。有些人一边在 Chrome 装了一边又去 Edge 装然后疑惑为什么两边聊天记录不通。要记住Page Assist 的聊天数据、模型配置、上传的知识库文件都是存储在具体某个浏览器的本地存储IndexedDB 和 localStorage里的不同浏览器之间不共享甚至同浏览器的普通模式和无痕模式都不共享。所以选定一个浏览器长期用它别频繁迁移。2.2 配置后端Ollama、LM Studio、OpenAI 兼容 API装好扩展之后最关键的一步是告诉 Page Assist“你的模型跑在哪”。打开扩展的选项页右键图标 → 选项或从侧边栏设置入口进你会看到页面顶部选语言下面有一块叫“Chat Provider”或者“Provider”的设置区域支持 Ollama、LM Studio、Open WebUI、OpenAI 兼容接口、Gemini 等。默认通常选的是 Ollama。选 Ollama 时只要本机 11434 端口开着 Ollama 服务Page Assist 默认地址http://localhost:11434就能自动探测到模型列表。保存之后你会在模型下拉框里看到所有已经ollama pull过的模型。这里有个判断依据如果模型列表是空的先确认你是不是真的在后台开了 Ollama——它没有系统托盘常驻很多人装完就忘了启动以为装好了就能用实际上 90% 的连接失败都是这个原因。LM Studio 的配置逻辑类似但要先去 LM Studio 软件里把 Local Server 打开拿到端口地址后填进 Page Assist。OpenAI 兼容 API 这块要提醒一下如果你配置的是远程服务地址你的文本内容会离开本机隐私敏感信息谨慎发送。如果只是本地起了一个 OpenAI 兼容网关比如通过一些代理工具转发到本地模型那填http://localhost:端口即可。整个配置过程大概就是选 Provider、填地址、保存、刷新模型列表四步。如果你的环境一切正常从安装到能聊天不会超过五分钟。如果超过了五分钟大概率是掉进了 2.3 这个坑里。2.3 最容易踩的坑CORS 与端口配置我第一次配置 Page Assist 连接 Ollama模型列表死活拉不出来。打开调试一看控制台报了一堆 CORS 错误。这个问题的本质是浏览器扩展虽然可以请求跨域资源但 Ollama 服务端默认不会放行来自浏览器的跨源请求。你在 Postman 里直接请求 Ollama 接口没问题因为那不是浏览器环境但 Page Assist 是从浏览器扩展发起的请求源Origin跟 Ollama 期望的不一致请求就被服务端安全策略拦下了。解法也简单给 Ollama 设置环境变量OLLAMA_ORIGINS把它允许的来源指定为浏览器扩展。官方文档给的做法是设置成*课程代表允许所有来源。单机个人使用*图省事没问题如果你在意安全可以精确到你的扩展 ID不过那个 ID 序列比较长我实际还是用*居多因为反正 Ollama 默认只监听本地地址外部机器访问不进来。具体操作按系统区分# macOS / Linux临时生效重开终端失效 OLLAMA_ORIGINS* ollama serve # Windows PowerShell临时生效 $env:OLLAMA_ORIGINS* ollama serve # Windows 持久设置 setx OLLAMA_ORIGINS *Windows 用过setx之后要重启终端或重启 Ollama 才会生效这个坑我也踩过。改完环境变量重启 Ollama再回 Page Assist 点刷新模型列表就出来了。LM Studio 的用户通常没这个烦恼因为它的本地服务端默认就开了比较宽松的 CORS 策略所以很多人在 Ollama 上折腾半天的问题换 LM Studio 就不存在了。但如果你用的 Ollama 恰好是装在远程 Linux 服务器上而不是本机那就还得考虑端口和防火墙的问题这就是另一个话题了我后面在问题排查表里简单提两句。3. 核心功能拆解侧边栏聊天、网页上下文与 RAG3.1 侧边栏聊天与多模型切换Page Assist 最核心的交互就是侧边栏聊天。默认情况下按一次快捷键我习惯设置的AltA右侧就会弹出侧边栏里面有完整的对话输入框和会话列表。输入文字、按回车发送模型响应流式输出在气泡里。这个过程跟 Perplexity 那种 AI 浏览器产品很像但它背后连接的是你自己的本地模型数据不出本机。侧边栏聊天跟独立页面聊天最大的区别在于“随时召唤”。我在写文章、查文档、看博客的时候遇到不理解的概念直接快捷键唤起侧边栏问一句得到答案后继续手头的工作。这个“不打断心流”的价值非常高。一开始我也觉得多按一个快捷键挺麻烦习惯了之后回不到终端窗口聊天了。多模型切换也设计得很顺手。侧边栏顶部有个模型下拉框列出了你在 Ollama 里拉取的全部模型。我在本机同时放了 qwen2.5 和 llama3.1问日常问题时用 qwen2.5中文更好涉及代码逻辑时切换到 codellama 一类的专用模型。切换模型不会清空当前会话上下文这一点体验很好同一个问题可以拿两个模型分别回答做对比。聊完想清空上下文点新建会话就可以了。3.2 与当前网页直接交互总结、翻译、内容纠错这才是 Page Assist 的灵魂功能。普通 webUI 你开个新页面跟模型聊天模型根本不知道你正在看什么网页最多就是你把网页内容复制粘贴发给它。Page Assist 因为有浏览器扩展权限可以直接读取当前激活标签页的正文内容然后配合系统提示词让模型做各种处理。实际使用的入口在侧边栏的聊天输入框上方有一个“操作当前页面”之类的按钮或选项菜单。我常用的几个动作网页摘要让模型把当前正在看的这一篇长文提炼成三到五个要点适合快速了解一篇技术文档的核心结论。翻译英文博客一键翻译成中文翻译结果直接显示在侧边栏保留代码块和列表结构。这个比浏览器自带的整页翻译要智能因为模型理解了上下文不是逐句生硬直译。基于当前页面的问答这是我最喜欢的功能。读完一篇项目文档后直接问“根据这个页面这个项目的初始化命令是什么”模型会从页面内容里找答案而不是凭空编。它背后的原理不算复杂Page Assist 从当前页面提取正文文本拼进系统提示词跟你的问题一起发给本地模型。这个过程要求模型支持比较长的上下文窗口因为页面文本动辄几千上万 tokens。我用的 qwen2.5 默认上下文拉到 32K处理大部分长文够用。如果你跑的是老一些的模型上下文只有 4K 或者 8K摘要长网页的时候会截断效果会差很多。这里要注意权限问题。读取网页内容需要扩展获得当前站点的访问权限有些站点的页面结构是大量脚本动态渲染的Page Assist 抓到的可能只有框架代码抓不到正文。遇到这种情况我一般退回手动复制正文或改用站点的阅读模式。另外有些隐私敏感页面比如网银、邮箱本身就不该让 AI 读取Page Assist 也提供了一个开关可以在指定站点禁用读取功能我强烈建议保持开启谨慎使用。3.3 本地知识库与文档对话内置 RAG除了网页Page Assist 还内置了一个轻量 RAG 能力可以让模型基于你上传的文档回答问题。它的实现很有意思直接在浏览器本地用 Transformers.js 做文本向量化向量存放在 IndexedDB 里不依赖外部向量数据库。也就是说你的文档无论内容多敏感始终留在本机浏览器存储里发给模型的时候也只是把相关片段作为上下文送进去不会上传到任何远程服务。实际使用方法也不复杂。在侧边栏的某个菜单里进入知识库或文档列表上传 PDF、TXT、Markdown 文件系统会做切分和向量化。上传完成后你在对话时只要把“使用知识库”之类的开关打开有的版本是 文件名附加上下文模型就会先做相似度检索把命中的文档片段放进上下文再回答。我拿它做过一次具体实践把一套内部 API 接口文档传进去然后问“登录接口的请求参数是什么”它能从文档对应章节里提取出来回答得比直接问裸模型准确得多。因为裸模型没看过你的专有文档你再怎么引导它也只能瞎猜而 RAG 相当于先帮模型“查资料”再回答幻觉大幅减少。这个功能也有局限。一是浏览器向量化的速度不快几十页 PDF 要处理一小会大文件动辄卡顿二是 IndexedDB 的存储空间有限不适合放整个知识库的三百份文档三是检索效果依赖切分策略和 embedding 质量文件格式太乱时命中率会明显下降。所以我的态度是Page Assist 的 RAG 适合几百页以内的个人资料集日常查阅够用真正的企业级知识库还是交给更重的专业方案。4. 进阶玩法与效率配置4.1 会话管理与工作流保存很多人用 webUI 都遇到过同一个困惑聊完一个话题关掉界面下次再开还要不要从零开始Page Assist 的会话管理其实做得很完善只是藏得有点深。侧边栏顶部有一个会话列表入口点开之后能看到历史会话每一条都按时间排序。你随时可以点回某一条继续追问或者修改之前的对话语境。这比终端的滚动记录要规整得多也解决了“webUI 里怎么保存工作流”的痛点——不需要手动导出它默认自动保存在浏览器本地。我自己养成的一个习惯每次切入一个新主题之前新建一个会话并给它起个名字比如“RAG 方案调研”“oauth2 实现细节”。这样后续回看的时候通过标题就能快速定位当时讨论的背景不用靠时间和内容猜测。虽然 Page Assist 不会主动提醒命名但多敲几个字的成本换来的是日后检索的高效值。清理策略上我也有个经验别让历史会话攒太多。因为会话内容全部存在浏览器 IndexedDB 里攒久了数据体积变大打开侧边栏时会有可感知的卡顿。每周清掉一批不用的旧会话或者定期删掉刷屏的日志类对话跟清回收站一个道理。4.2 Markdown、公式渲染与代码块体验聊天界面的渲染质量直接决定你愿不愿意长期用它。Page Assist 的消息流是基于 Markdown 渲染的模型输出的标题、列表、引用、加粗、表格都会正确呈现。代码块尤其值得夸一句它有独立的高亮配色、行号和右上角复制按钮不需要手动框选。这一点在终端里是奢望在弱一点的 webUI 里也未必做得好。数学公式方面Page Assist 支持 LaTeX 形式的公式渲染。如果你的模型回答里包含$f(x)x^2$或$$\int_0^1$$这种片段界面里会把它渲染成规范的数学表达式而不是给你一双括号和反斜杠的原始文本。这个能力对技术文档党非常关键因为很多模型默认输出数学公式就是 LaTeX 源码没有渲染的话根本没法看。我在问“解释一下贝叶斯公式的推导”的时候输出效果跟看教科书排版一样清晰。有一点使用经验供参考如果你发现公式不渲染先检查模型本身是不是以纯 Markdown 格式输出。有的模型会被系统提示词影响输出变成缩进文本块或 json 包装的怪异结构这时候需要在模型配置或系统提示词里强调“用 Markdown 格式输出”。渲染工具再强也扛不住上游坏了格式。4.3 自定义 Prompt 模板与模型参数Page Assist 不是只能做默认的“用户问、模型答”。在设置里你可以自定义 Prompt 模板也就是内置一批常用指令点一下就把预设文本填进输入框。我配置了几个用得最多的模板“解释代码”自动在问题前加上“请逐行解释这段代码的逻辑指出潜在问题”。“写周报”预设结构化模板让模型按“本周完成/遇到的问题/下周计划”三段输出。“翻译润色”指定目标语言和语气风格。这样每次不用重复敲提示词效率提升很明显。模板本质是帮你把 prompt engineering 的经验沉淀下来同一套提示词在工作流里反复使用输出的稳定性也更高。模型参数方面Page Assist 暴露了 temperature、top_p、max tokens 等核心参数设置。我用本地的 qwen2.5 时习惯把 temperature 调到 0.7代码解释类问题再调低到 0.3减少发散和胡编。max tokens 建议根据你常用模型的实际上下文设一个合理值别一味拉大太大反而容易造成响应变慢、侧边栏渲染卡顿。具体情况没有绝对标准但原则是编程和事实问答用低温度创意写作可以用稍高温度。5. 常见问题与避坑实录5.1 连接失败排查速查表我把实际使用中遇到最多的问题汇总成了一张排查表方便你直接对照。现象可能原因处理办法模型列表为空Ollama 没启动或端口不对确认ollama list能输出模型名检查 11434 端口请求报 CORS 错误Ollama 未设置 OLLAMA_ORIGINS设置OLLAMA_ORIGINS*后重启服务发送消息后一直转圈模型上下文过长或推理中调小 max tokens或换个更快的模型网页摘要抓不到内容网页是动态渲染或站点限制抓取换阅读模式或手动复制正文侧边栏打开很慢历史会话/知识库数据过大清理历史会话和上传文件连接 LM Studio 失败没开启 Local Server在 LM Studio 里启动 Server确认端口重装扩展后配置没了浏览器扩展数据被清除导出配置或确认是同一浏览器配置文件第一条里有个小技巧ollama list命令能列出所有已拉取的模型如果命令本身都报错说明服务根本没起如果命令正常但 Page Assist 里空那大概率是地址填错了或 CORS 问题。这个判断路径很直接。5.2 网页抓取失败的权限与站点限制网页抓取这个功能看起来很美好但在真实网络环境下经常翻车。原因主要有两个层面。第一是权限层面。浏览器扩展读取页面内容需要 host permissions不同版本的 Page Assist 对这一块的默认配置不完全一样。有时候你第一次安装时没细看权限弹窗直接点了取消后面用起来就会遇到“能打开侧边栏但抓不到内容”的怪现象。解决方法是去扩展管理页检查权限把“读取此站点数据”之类的权限授予到你常用的网站域名。不用在一个域下反复弹窗时才授权主动去扩展设置里统一授予更省心。第二是站点设计层面。大量现代网站的内容是动态 JavaScript 渲染出来的Page Assist 抓取时拿到的可能只是初始 HTML 骨架正文全是空白。还有一些站点明确通过出海策略或 robots 限制阻止自动抓取这种情况你无论怎么调整扩展配置都没用。我的经验是提前判断一篇页面如果能在浏览器里“阅读模式”显示成功Page Assist 通常也能抓到如果阅读模式本身就是残缺的那也别指望扩展能凭空提取。真正重要的长文我干脆下载 PDF 丢进本地知识库处理绕开网页抓取这层不确定性。5.3 隐私边界、资源占用与使用建议浏览器扩展的隐私问题很多人会忽视。Page Assist 帮你在浏览器和本地模型之间搭了一座桥当你跟本地 Ollama 对话时数据确实不出本机但如果你在配置里填了远程 OpenAI 兼容 API那么每次对话的文本都会经过远程服务器。这意味着你不该在这个入口发送任何账号密码、身份证号、未公开的代码等敏感信息。模型服务商虽然声称对话用于改进服务但多一分克制总没有坏处。资源占用方面Page Assist 本身极轻常驻内存大概几十 MB几乎可以忽略。大头在模型服务自己。一个 7B 模型跑起来Ollama 会吃几个 GB 内存这跟界面工具无关是本地推理的物理成本。侧边栏界面偶尔在长回复流式输出时会有一点卡顿尤其是在浏览器开了大量标签页的场景下这个受浏览器本身性能影响更大不全是 Page Assist 的锅。使用建议上我最想强调的一点不要把 Page Assist 当成万能工具。它擅长“阅读对话”场景但不适合做大文件批量处理也不适合跑复杂代码解释器或 agent 工作流。认清工具边界才能在正确场景里发挥最大价值。对我来说它就是那个“在浏览器里随时能喊一声的本地 AI 助手”这个定位一直很清晰。6. 一个让体验翻倍的小技巧最后分享一个我自己用得很爽的配置。在 Page Assist 的快捷键设置里选择全局快捷键而不是仅在浏览器窗口内生效。这样一来哪怕你当前焦点在某个全屏的编辑器里按下AltA也能直接唤起浏览器侧边栏。实际操作中我会先让浏览器在后台开着编辑代码或者写作时突然想起某个问题一个组合键侧边栏就弹出来了整个交互最接近原生桌面应用的体验。另外侧边栏宽度是可以拖拽调整的。别一股脑拉满太宽了喧宾夺主太窄了代码块会折行。我习惯调到约占屏幕宽度的三分之一刚好左边正文内容还能舒适阅读右边模型回复也排得开。这两个细节调好之后我才真正觉得 Page Assist 融入了我每天的工作流而不是一个“偶尔打开试一下”的玩具。 Page Assist：给本地大模型补上浏览器侧边栏图形界面
我最早跑本地模型的时候面对的就是一个黑乎乎的终端窗口。ollama run qwen2.5敲进去剩下的时间就是盯着光标闪烁一行一行跟模型对话。能用但非常折磨人——想翻历史记录要往上划半天复制回答里的代码还得手动选中换个模型又得重新敲一次启动命令。后来我开始在浏览器里挂 Page Assist这个图形化界面工具本质上只是一个插件却硬生生给我补上了一个完整的 webUI 体验侧边栏唤起、会话保存、网页联动、本地知识库全都齐了。这篇文章就把我实际的配置过程和踩坑记录整理出来给还在跟终端较劲的朋友一个参考。1. 为什么我需要一个图形化界面从命令行到浏览器侧边栏1.1 命令行时代能用但太累本地大模型起步阶段很多人跟我一样是先从终端入门的。ollama serve跑起来ollama run开启对话感觉上很“极客”实际用起来全是细节上的痛苦。终端窗口里模型回答一长上下文就开始滚动你想回看之前某段关键结论得不断往上翻模型输出代码片段的时候复制整块代码需要鼠标精确框选稍不注意就带着$符号或者系统提示一起复制走。还有更现实的场景——你正在写文档想顺便问模型一个问题就得把注意力从编辑器挪到终端切窗口、找焦点思路全断了。这些痛点本质上不是模型的问题而是缺少一层图形化界面工具。模型只是推理引擎它不负责展示历史、管理会话、渲染 Markdown、读取网页。这些东西都需要一个前端壳子来做。市面上的 webUI 方案很多有的重、有的轻但真正适合个人日常高频使用的我最顺手的就是 Page Assist。Page Assist 的使用场景很明确你在浏览器里干活本地模型跑在后台它作为浏览器插件常驻在侧边栏按一下快捷键就能唤出来问问题。它解决的不只是“跟模型聊天”这一个需求而是把 AI 辅助能力无缝塞进你原本的浏览工作流里不需要额外开一个页面不需要切换窗口网页本身就成了对话的上下文来源。适合谁来用一句话凡是装了 Ollama、LM Studio 这类本地推理工具又觉得纯命令行交互憋屈的人都值得试试。尤其是经常需要一边查资料一边读网页、一边写文章的人Page Assist 的“当前网页摘要、翻译、问答”功能会让你觉得之前用终端纯聊天简直是暴殄天物。1.2 Page Assist 的定位浏览器里的“第二层皮肤”很多人第一次听说 Page Assist会以为它又是一个独立 Web 服务要去部署、要开端口、要维护。实际上它就是一个浏览器扩展Chrome、Edge、Firefox 都能装。装着之后它基本不占端口、不跑后台服务只是在浏览器里渲染出一个侧边栏界面然后通过 HTTP 请求去连接你本机的模型服务。这层“第二层皮肤”的设计其实非常聪明。传统 webUI比如 Open WebUI是独立跑一个本地 Web 服务你需要开着一个页面来使用本质上还是“离开浏览器内容去另一个页面聊天”。Page Assist 反过来它寄生在浏览器里把聊天界面做成侧边栏跟当前标签页并行显示。你左边是正在阅读的技术文档右边是跟模型的对话窗口那种体验是独立页面给不了的。而且因为它是浏览器扩展天然就拥有访问当前页面 DOM 的能力。做网页内容总结、让模型读当前页面再回答专业问题这些都是普通 webUI 需要绕很多弯才能实现的功能对 Page Assist 来说反而成了核心优势。我后面第 3 章会详细展开这几个功能的实际用法和限制这里先记住一个结论Page Assist 不是一个“小号的 Open WebUI”它是完全不同的产品形态和交互逻辑。1.3 横向对比Page Assist vs Open WebUI vs 其他方案既然聊到图形化界面我就把自己实际用过的几类方案放在一起对比一下。Open WebUI 名气最大功能也确实全多用户管理、知识库、绘图插件都有。但它的架构是独立的 Docker/本地服务需要常驻进程启动速度、内存占用都不是零成本的。我一开始也跑过 Open WebUI后来发现我绝大多数场景只是一个人在本机用杀鸡用牛刀而且它的页面交互还是传统的“打开一个站点”跟浏览器本身的联动很弱。其他还有各种基于 Gradio 或 Streamlit 的封装界面用来演示还可以长时间个人使用总觉得差点意思。Page Assist 的定位正好卡在最舒服的位置足够轻、驻留浏览器、跟网页上下文打通。它不追求功能无限大但核心体验非常聚焦安装到能用的时间成本大概就是几分钟。我用一个简单的表格来对比方便你按自己的需求判断对比维度Page AssistOpen WebUI纯终端安装复杂度低浏览器扩展一键装中高需部署服务或 Docker低本身自带界面形态浏览器侧边栏独立 Web 站点无界面网页联动强可直接读取当前页面弱需要手动复制或走工具链无会话管理浏览器本地保存数据库管理功能全面终端滚动记录多用户/权限仅本机个人使用支持团队化使用不支持资源占用很低仅扩展常驻高服务常驻极低适合场景个人日常阅读AI辅助团队共享、重度功能需求临时测试模型指令我个人现在的习惯是轻量问答和网页总结用 Page Assist需要整理知识库、多人共享的时候才考虑把 Open WebUI 拉起来。两条路线互补不冲突。2. 安装与连接把 Page Assist 接到你的本地模型2.1 安装浏览器扩展安装这一步没什么技术含量但有几个小细节值得说一下。以我主力用的 Chrome 为例直接去 Chrome 网上应用店搜索 Page Assist找到后点击“添加至 Chrome”即可。Edge 用户去 Edge 加载项商店搜索同名扩展Firefox 用户则去 Firefox Add-ons 站。名字虽然都是 Page Assist但插件生态各平台独立维护版本号略有差异优先选你主力浏览器对应商店的版本。装完之后默认图标会出现在扩展栏里。我建议你手动把它固定到工具栏不然每次使用都要点拼图图标再找它多一步操作就多一分放弃使用的可能。固定之后单击图标默认是打开一个独立的标签页版界面注意这个不是侧边栏它是一次性会话窗口。真正好用的是侧边栏模式需要在扩展的选项页里设置启动方式或者直接用默认快捷键唤起。这一步容易犯的错误是重复安装。有些人一边在 Chrome 装了一边又去 Edge 装然后疑惑为什么两边聊天记录不通。要记住Page Assist 的聊天数据、模型配置、上传的知识库文件都是存储在具体某个浏览器的本地存储IndexedDB 和 localStorage里的不同浏览器之间不共享甚至同浏览器的普通模式和无痕模式都不共享。所以选定一个浏览器长期用它别频繁迁移。2.2 配置后端Ollama、LM Studio、OpenAI 兼容 API装好扩展之后最关键的一步是告诉 Page Assist“你的模型跑在哪”。打开扩展的选项页右键图标 → 选项或从侧边栏设置入口进你会看到页面顶部选语言下面有一块叫“Chat Provider”或者“Provider”的设置区域支持 Ollama、LM Studio、Open WebUI、OpenAI 兼容接口、Gemini 等。默认通常选的是 Ollama。选 Ollama 时只要本机 11434 端口开着 Ollama 服务Page Assist 默认地址http://localhost:11434就能自动探测到模型列表。保存之后你会在模型下拉框里看到所有已经ollama pull过的模型。这里有个判断依据如果模型列表是空的先确认你是不是真的在后台开了 Ollama——它没有系统托盘常驻很多人装完就忘了启动以为装好了就能用实际上 90% 的连接失败都是这个原因。LM Studio 的配置逻辑类似但要先去 LM Studio 软件里把 Local Server 打开拿到端口地址后填进 Page Assist。OpenAI 兼容 API 这块要提醒一下如果你配置的是远程服务地址你的文本内容会离开本机隐私敏感信息谨慎发送。如果只是本地起了一个 OpenAI 兼容网关比如通过一些代理工具转发到本地模型那填http://localhost:端口即可。整个配置过程大概就是选 Provider、填地址、保存、刷新模型列表四步。如果你的环境一切正常从安装到能聊天不会超过五分钟。如果超过了五分钟大概率是掉进了 2.3 这个坑里。2.3 最容易踩的坑CORS 与端口配置我第一次配置 Page Assist 连接 Ollama模型列表死活拉不出来。打开调试一看控制台报了一堆 CORS 错误。这个问题的本质是浏览器扩展虽然可以请求跨域资源但 Ollama 服务端默认不会放行来自浏览器的跨源请求。你在 Postman 里直接请求 Ollama 接口没问题因为那不是浏览器环境但 Page Assist 是从浏览器扩展发起的请求源Origin跟 Ollama 期望的不一致请求就被服务端安全策略拦下了。解法也简单给 Ollama 设置环境变量OLLAMA_ORIGINS把它允许的来源指定为浏览器扩展。官方文档给的做法是设置成*课程代表允许所有来源。单机个人使用*图省事没问题如果你在意安全可以精确到你的扩展 ID不过那个 ID 序列比较长我实际还是用*居多因为反正 Ollama 默认只监听本地地址外部机器访问不进来。具体操作按系统区分# macOS / Linux临时生效重开终端失效 OLLAMA_ORIGINS* ollama serve # Windows PowerShell临时生效 $env:OLLAMA_ORIGINS* ollama serve # Windows 持久设置 setx OLLAMA_ORIGINS *Windows 用过setx之后要重启终端或重启 Ollama 才会生效这个坑我也踩过。改完环境变量重启 Ollama再回 Page Assist 点刷新模型列表就出来了。LM Studio 的用户通常没这个烦恼因为它的本地服务端默认就开了比较宽松的 CORS 策略所以很多人在 Ollama 上折腾半天的问题换 LM Studio 就不存在了。但如果你用的 Ollama 恰好是装在远程 Linux 服务器上而不是本机那就还得考虑端口和防火墙的问题这就是另一个话题了我后面在问题排查表里简单提两句。3. 核心功能拆解侧边栏聊天、网页上下文与 RAG3.1 侧边栏聊天与多模型切换Page Assist 最核心的交互就是侧边栏聊天。默认情况下按一次快捷键我习惯设置的AltA右侧就会弹出侧边栏里面有完整的对话输入框和会话列表。输入文字、按回车发送模型响应流式输出在气泡里。这个过程跟 Perplexity 那种 AI 浏览器产品很像但它背后连接的是你自己的本地模型数据不出本机。侧边栏聊天跟独立页面聊天最大的区别在于“随时召唤”。我在写文章、查文档、看博客的时候遇到不理解的概念直接快捷键唤起侧边栏问一句得到答案后继续手头的工作。这个“不打断心流”的价值非常高。一开始我也觉得多按一个快捷键挺麻烦习惯了之后回不到终端窗口聊天了。多模型切换也设计得很顺手。侧边栏顶部有个模型下拉框列出了你在 Ollama 里拉取的全部模型。我在本机同时放了 qwen2.5 和 llama3.1问日常问题时用 qwen2.5中文更好涉及代码逻辑时切换到 codellama 一类的专用模型。切换模型不会清空当前会话上下文这一点体验很好同一个问题可以拿两个模型分别回答做对比。聊完想清空上下文点新建会话就可以了。3.2 与当前网页直接交互总结、翻译、内容纠错这才是 Page Assist 的灵魂功能。普通 webUI 你开个新页面跟模型聊天模型根本不知道你正在看什么网页最多就是你把网页内容复制粘贴发给它。Page Assist 因为有浏览器扩展权限可以直接读取当前激活标签页的正文内容然后配合系统提示词让模型做各种处理。实际使用的入口在侧边栏的聊天输入框上方有一个“操作当前页面”之类的按钮或选项菜单。我常用的几个动作网页摘要让模型把当前正在看的这一篇长文提炼成三到五个要点适合快速了解一篇技术文档的核心结论。翻译英文博客一键翻译成中文翻译结果直接显示在侧边栏保留代码块和列表结构。这个比浏览器自带的整页翻译要智能因为模型理解了上下文不是逐句生硬直译。基于当前页面的问答这是我最喜欢的功能。读完一篇项目文档后直接问“根据这个页面这个项目的初始化命令是什么”模型会从页面内容里找答案而不是凭空编。它背后的原理不算复杂Page Assist 从当前页面提取正文文本拼进系统提示词跟你的问题一起发给本地模型。这个过程要求模型支持比较长的上下文窗口因为页面文本动辄几千上万 tokens。我用的 qwen2.5 默认上下文拉到 32K处理大部分长文够用。如果你跑的是老一些的模型上下文只有 4K 或者 8K摘要长网页的时候会截断效果会差很多。这里要注意权限问题。读取网页内容需要扩展获得当前站点的访问权限有些站点的页面结构是大量脚本动态渲染的Page Assist 抓到的可能只有框架代码抓不到正文。遇到这种情况我一般退回手动复制正文或改用站点的阅读模式。另外有些隐私敏感页面比如网银、邮箱本身就不该让 AI 读取Page Assist 也提供了一个开关可以在指定站点禁用读取功能我强烈建议保持开启谨慎使用。3.3 本地知识库与文档对话内置 RAG除了网页Page Assist 还内置了一个轻量 RAG 能力可以让模型基于你上传的文档回答问题。它的实现很有意思直接在浏览器本地用 Transformers.js 做文本向量化向量存放在 IndexedDB 里不依赖外部向量数据库。也就是说你的文档无论内容多敏感始终留在本机浏览器存储里发给模型的时候也只是把相关片段作为上下文送进去不会上传到任何远程服务。实际使用方法也不复杂。在侧边栏的某个菜单里进入知识库或文档列表上传 PDF、TXT、Markdown 文件系统会做切分和向量化。上传完成后你在对话时只要把“使用知识库”之类的开关打开有的版本是 文件名附加上下文模型就会先做相似度检索把命中的文档片段放进上下文再回答。我拿它做过一次具体实践把一套内部 API 接口文档传进去然后问“登录接口的请求参数是什么”它能从文档对应章节里提取出来回答得比直接问裸模型准确得多。因为裸模型没看过你的专有文档你再怎么引导它也只能瞎猜而 RAG 相当于先帮模型“查资料”再回答幻觉大幅减少。这个功能也有局限。一是浏览器向量化的速度不快几十页 PDF 要处理一小会大文件动辄卡顿二是 IndexedDB 的存储空间有限不适合放整个知识库的三百份文档三是检索效果依赖切分策略和 embedding 质量文件格式太乱时命中率会明显下降。所以我的态度是Page Assist 的 RAG 适合几百页以内的个人资料集日常查阅够用真正的企业级知识库还是交给更重的专业方案。4. 进阶玩法与效率配置4.1 会话管理与工作流保存很多人用 webUI 都遇到过同一个困惑聊完一个话题关掉界面下次再开还要不要从零开始Page Assist 的会话管理其实做得很完善只是藏得有点深。侧边栏顶部有一个会话列表入口点开之后能看到历史会话每一条都按时间排序。你随时可以点回某一条继续追问或者修改之前的对话语境。这比终端的滚动记录要规整得多也解决了“webUI 里怎么保存工作流”的痛点——不需要手动导出它默认自动保存在浏览器本地。我自己养成的一个习惯每次切入一个新主题之前新建一个会话并给它起个名字比如“RAG 方案调研”“oauth2 实现细节”。这样后续回看的时候通过标题就能快速定位当时讨论的背景不用靠时间和内容猜测。虽然 Page Assist 不会主动提醒命名但多敲几个字的成本换来的是日后检索的高效值。清理策略上我也有个经验别让历史会话攒太多。因为会话内容全部存在浏览器 IndexedDB 里攒久了数据体积变大打开侧边栏时会有可感知的卡顿。每周清掉一批不用的旧会话或者定期删掉刷屏的日志类对话跟清回收站一个道理。4.2 Markdown、公式渲染与代码块体验聊天界面的渲染质量直接决定你愿不愿意长期用它。Page Assist 的消息流是基于 Markdown 渲染的模型输出的标题、列表、引用、加粗、表格都会正确呈现。代码块尤其值得夸一句它有独立的高亮配色、行号和右上角复制按钮不需要手动框选。这一点在终端里是奢望在弱一点的 webUI 里也未必做得好。数学公式方面Page Assist 支持 LaTeX 形式的公式渲染。如果你的模型回答里包含$f(x)x^2$或$$\int_0^1$$这种片段界面里会把它渲染成规范的数学表达式而不是给你一双括号和反斜杠的原始文本。这个能力对技术文档党非常关键因为很多模型默认输出数学公式就是 LaTeX 源码没有渲染的话根本没法看。我在问“解释一下贝叶斯公式的推导”的时候输出效果跟看教科书排版一样清晰。有一点使用经验供参考如果你发现公式不渲染先检查模型本身是不是以纯 Markdown 格式输出。有的模型会被系统提示词影响输出变成缩进文本块或 json 包装的怪异结构这时候需要在模型配置或系统提示词里强调“用 Markdown 格式输出”。渲染工具再强也扛不住上游坏了格式。4.3 自定义 Prompt 模板与模型参数Page Assist 不是只能做默认的“用户问、模型答”。在设置里你可以自定义 Prompt 模板也就是内置一批常用指令点一下就把预设文本填进输入框。我配置了几个用得最多的模板“解释代码”自动在问题前加上“请逐行解释这段代码的逻辑指出潜在问题”。“写周报”预设结构化模板让模型按“本周完成/遇到的问题/下周计划”三段输出。“翻译润色”指定目标语言和语气风格。这样每次不用重复敲提示词效率提升很明显。模板本质是帮你把 prompt engineering 的经验沉淀下来同一套提示词在工作流里反复使用输出的稳定性也更高。模型参数方面Page Assist 暴露了 temperature、top_p、max tokens 等核心参数设置。我用本地的 qwen2.5 时习惯把 temperature 调到 0.7代码解释类问题再调低到 0.3减少发散和胡编。max tokens 建议根据你常用模型的实际上下文设一个合理值别一味拉大太大反而容易造成响应变慢、侧边栏渲染卡顿。具体情况没有绝对标准但原则是编程和事实问答用低温度创意写作可以用稍高温度。5. 常见问题与避坑实录5.1 连接失败排查速查表我把实际使用中遇到最多的问题汇总成了一张排查表方便你直接对照。现象可能原因处理办法模型列表为空Ollama 没启动或端口不对确认ollama list能输出模型名检查 11434 端口请求报 CORS 错误Ollama 未设置 OLLAMA_ORIGINS设置OLLAMA_ORIGINS*后重启服务发送消息后一直转圈模型上下文过长或推理中调小 max tokens或换个更快的模型网页摘要抓不到内容网页是动态渲染或站点限制抓取换阅读模式或手动复制正文侧边栏打开很慢历史会话/知识库数据过大清理历史会话和上传文件连接 LM Studio 失败没开启 Local Server在 LM Studio 里启动 Server确认端口重装扩展后配置没了浏览器扩展数据被清除导出配置或确认是同一浏览器配置文件第一条里有个小技巧ollama list命令能列出所有已拉取的模型如果命令本身都报错说明服务根本没起如果命令正常但 Page Assist 里空那大概率是地址填错了或 CORS 问题。这个判断路径很直接。5.2 网页抓取失败的权限与站点限制网页抓取这个功能看起来很美好但在真实网络环境下经常翻车。原因主要有两个层面。第一是权限层面。浏览器扩展读取页面内容需要 host permissions不同版本的 Page Assist 对这一块的默认配置不完全一样。有时候你第一次安装时没细看权限弹窗直接点了取消后面用起来就会遇到“能打开侧边栏但抓不到内容”的怪现象。解决方法是去扩展管理页检查权限把“读取此站点数据”之类的权限授予到你常用的网站域名。不用在一个域下反复弹窗时才授权主动去扩展设置里统一授予更省心。第二是站点设计层面。大量现代网站的内容是动态 JavaScript 渲染出来的Page Assist 抓取时拿到的可能只是初始 HTML 骨架正文全是空白。还有一些站点明确通过出海策略或 robots 限制阻止自动抓取这种情况你无论怎么调整扩展配置都没用。我的经验是提前判断一篇页面如果能在浏览器里“阅读模式”显示成功Page Assist 通常也能抓到如果阅读模式本身就是残缺的那也别指望扩展能凭空提取。真正重要的长文我干脆下载 PDF 丢进本地知识库处理绕开网页抓取这层不确定性。5.3 隐私边界、资源占用与使用建议浏览器扩展的隐私问题很多人会忽视。Page Assist 帮你在浏览器和本地模型之间搭了一座桥当你跟本地 Ollama 对话时数据确实不出本机但如果你在配置里填了远程 OpenAI 兼容 API那么每次对话的文本都会经过远程服务器。这意味着你不该在这个入口发送任何账号密码、身份证号、未公开的代码等敏感信息。模型服务商虽然声称对话用于改进服务但多一分克制总没有坏处。资源占用方面Page Assist 本身极轻常驻内存大概几十 MB几乎可以忽略。大头在模型服务自己。一个 7B 模型跑起来Ollama 会吃几个 GB 内存这跟界面工具无关是本地推理的物理成本。侧边栏界面偶尔在长回复流式输出时会有一点卡顿尤其是在浏览器开了大量标签页的场景下这个受浏览器本身性能影响更大不全是 Page Assist 的锅。使用建议上我最想强调的一点不要把 Page Assist 当成万能工具。它擅长“阅读对话”场景但不适合做大文件批量处理也不适合跑复杂代码解释器或 agent 工作流。认清工具边界才能在正确场景里发挥最大价值。对我来说它就是那个“在浏览器里随时能喊一声的本地 AI 助手”这个定位一直很清晰。6. 一个让体验翻倍的小技巧最后分享一个我自己用得很爽的配置。在 Page Assist 的快捷键设置里选择全局快捷键而不是仅在浏览器窗口内生效。这样一来哪怕你当前焦点在某个全屏的编辑器里按下AltA也能直接唤起浏览器侧边栏。实际操作中我会先让浏览器在后台开着编辑代码或者写作时突然想起某个问题一个组合键侧边栏就弹出来了整个交互最接近原生桌面应用的体验。另外侧边栏宽度是可以拖拽调整的。别一股脑拉满太宽了喧宾夺主太窄了代码块会折行。我习惯调到约占屏幕宽度的三分之一刚好左边正文内容还能舒适阅读右边模型回复也排得开。这两个细节调好之后我才真正觉得 Page Assist 融入了我每天的工作流而不是一个“偶尔打开试一下”的玩具。