简介Page Assist是一款面向Chrome浏览器的本地化AI辅助插件适合需要在浏览器中快速调用大模型、管理对话与侧边栏操作的用户。压缩包内含完整可部署的插件源码与资源安装时开启开发者模式后拖拽即可加载。包体共95个文件、约6MB结构清晰核心包括manifest.json插件清单、background.js后台逻辑、content-scripts内容脚本、sidepanel.html与options.html两个界面以及多语言本地化目录此外包含大量ttf/woff/woff2字体和js/css等前端资源确保界面渲染与功能稳定。资源已吸引3026人学习下载。借助这份资源用户可以了解Chrome扩展的典型工程结构掌握侧边栏、选项页、内容脚本与后台脚本的协作方式同时可自行修改界面或扩展本地模型调用能力适合插件开发者与AI工具爱好者上手研究。1. 本地大模型和浏览器之间还缺一个趁手的控制台我最早接触 Page Assist 这个插件时第一反应是“又一个套壳聊天窗”直到某天要把一个 2 万字的网页资料丢给本地模型做摘要才发现传统 Web 界面要复制、粘贴、再清理格式来回折腾十分钟。而这个插件直接悬浮在浏览器侧边栏选中页面正文就能把内容喂给本地模型整个过程不需要上传到任何服务器。它本质上是把浏览器变成本地大模型的工作台适合三类人一是想在阅读网页时随时让模型总结、翻译、提问的内容工作者二是在本地跑着 Ollama 这类模型服务、却不想切窗口的开发者三是比较在意数据出本机的用户。这篇笔记会把它的工作原理、参数设置和我在实际使用中踩过的坑一次讲透。2. 安装与基础配置先理解它为什么能做“浏览器里的助手”2.1 插件的工作方式不是套壳聊天框而是一个页面注入程序Page Assist 看起来是个侧边栏实际上干的活是“注入脚本 代理请求”。它把自己的 UI 通过浏览器的扩展机制注入到当前标签页然后通过 JavaScript 直接请求本地模型服务端暴露的 HTTP 接口。这个设计和我们平时用的在线 AI 工具有本质区别在线工具是你把文本发给它们的服务器而 Page Assist 的聊天对话、摘要、翻译全都发生在你本机的回环地址上比如http://127.0.0.1:11434这样的端口。理解这一点非常重要因为后续所有配置、排坑都建立在它身上。你不需要把文章复制到任何输入框插件能直接读取当前页面的 HTML 结构抽取正文区域再用 prompt 模板拼成请求体发给本地模型。它其实就是一个“本地模型服务的浏览器前端”。这个架构带来的好处很明显数据不出本机断网也能用响应速度取决于你的显卡和模型大小。但它也有一个前提要求——你本机必须先跑着兼容 OpenAI API 格式的模型服务不然插件就是个空壳。绝大多数人在 Windows 或 macOS 上装的是 Ollama 这类服务端这也是 Page Assist 默认适配的对象。2.2 从商店安装到基本参数设置安装本身不复杂直接在 Chrome 应用商店搜索“Page Assist”就能找到装完会在浏览器右上角出现图标建议手动固定到工具栏不然每次都要点拼图图标才能展开。固定方式很简单右键浏览器右上角的拼图图标点图钉按钮。装完之后第一件事不是急着聊天而是检查连接地址。打开插件的设置面板找到类似“Ollama 服务器地址”的配置项默认值通常是http://127.0.0.1:11434。这里有一个细节如果你在另一台机器上跑模型服务或者用 Docker 部署在别的端口就要改成对应的 IP 和端口。{ base_url: http://127.0.0.1:11434, model: qwen2.5:7b, context_length: 4096, temperature: 0.7, stream: true }以上是一个常见的配置片段注意几个字段的含义base_url是模型服务的 API 地址配置成127.0.0.1表示只在本机回环不经过局域网和外网。model是默认要加载的模型名称名称必须和模型服务端列出的完全一致大小写和冒号后面的标签都不能错。context_length是上下文窗口长度单位是 token 数4096 适合 7B 左右的小模型如果你用的模型支持 32K 上下文可以调大。temperature控制回答随机性做摘要和翻译我一般设 0.3做头脑风暴设 0.8。stream开启流式输出这样答案一个字一个字蹦出来体验更接近在线工具。这些参数在插件界面里也能改不需要手动编辑 JSON 文件。但你要理解每个参数的意义因为后面排查“回答不完整”“输出重复”这些问题时大概率要从温度和上下文长度下手。2.3 页面权限和菜单入口的隐藏逻辑安装完成后如果发现右键菜单里没有 Page Assist 相关的选项不要急着重装先看权限设置。浏览器扩展的权限分为“读取页面内容”和“访问所有网站的数据”两类Page Assist 需要这两项才能做到“选中文字直接提问”。我一直建议把权限保持在“点击扩展图标时读取页面”这个粒度而不是“所有网站自动注入”。原因是自动注入模式会在每个标签页加载时都执行脚本既拖慢页面加载还会造成一些站点上的重复注入出现两个侧边栏叠在一起的情况。需要时再点图标启动对资源的占用最少也少很多怪毛病。到这里插件已经能用但还远谈不上顺手。真正拉开使用体验差距的是接下来要讲的网页摘要和选中问答的参数逻辑。3. 网页摘要与选中问答把“能跑”变成“好用”3.1 网页摘要入口、上下文长度与提示词模板的平衡网页摘要是 Page Assist 最打动我的功能。打开一个长篇文章点侧边栏里的“总结页面”按钮插件会自动抽取当前页面的正文内容拼接 prompt 后发给本地模型。但这个功能有两个隐藏问题一是正文抽取质量二是上下文长度够不够。先说正文抽取。Page Assist 的原理是解析页面的 DOM 结构找到类似article、main这样的正文标签。如果页面结构不规范或者文章是分页加载的抓取到的可能是一堆导航菜单。这时可以通过右键菜单里的“对选中文本进行摘要”绕过正文抽取自己动手圈选真正的核心内容。再说上下文长度。我给一个参照中文材料一个字符大约占 1 到 2 个 token7B 模型常见的 4K 上下文窗口只能容纳 2000 到 3000 个汉字。如果一篇文章有 8000 字硬塞进去会直接截断后半部分摘要结果自然丢信息。常见做法是分块摘要、再汇总。你可以把文章复制出来按标题拆成几段逐段让模型总结最后再合并。请阅读以下网页内容用不超过150字的中文概括其核心观点。 要求不要遗漏关键数字、不要添加原文没有的信息。 原文内容如下 {页面正文}这段提示词是我在插件自定义标签页里常用的模板。注意几点字数约束一定要写避免模型输出长篇大论要求“不要添加原文没有的信息”是对抗模型脑补的有效手段用花括号包裹变量是让插件识别出这是一个可替换的文本区域。参数上摘要任务我的固定配置是temperature 0.3context_length视模型而定。如果你的模型支持长上下文可以调到 8192 甚至更高但不要以为调高就一定更好上下文越长模型对开头部分的注意力就越分散这是我用长文本实测出来的现象。3.2 选中文本的上下文处理选区问答的机制选中一段文字点右键“向 Page Assist 提问”插件会把你的选区内容连同你的问题封装进请求里。这里有一个细节值得注意它发送的是“你选中的文字”而不是整个页面。这个设计非常实用比如你在读一段技术文档突然想让它解释某个函数的作用选中那一段就够了既省 token又让模型聚焦在相关上下文上。选区问答的 prompt 结构一般是这样{ messages: [ { role: system, content: 你是我的专业阅读助手。请基于用户提供的文本回答问题如果文本中没有答案请明确说‘原文未提及’。 }, { role: user, content: 以下是网页选中的内容\n「{选中文本}」\n\n我的问题是{问题} } ], temperature: 0.4 }这里面最关键的是 system 角色的那句“原文未提及”。很多人在用本地模型做问答时总觉得答案不靠谱其实根子在于没有约束模型的“事实边界”。模型天生倾向于编造内容为零的答案如果你不给它“不知道就直说”的指令它会非常自信地生成一段看似合理、实则完全虚构的说明。这个约束对本地模型尤其重要因为 7B 级别的模型能力有限编造的概率比大模型高得多。3.3 多轮记忆与上下文清空策略用了半天会发现侧边栏对话确实有上下文记忆上一轮说的事下一轮还能接上。但这里藏着一个性能坑记忆的长度占用的是同一个上下文窗口。当对话轮次堆积之前喂给模型的长文章摘要、代码片段全部挤在一起后面的回答会明显变慢质量也开始飘。我的习惯是每完成一个阅读任务就点一次清空按钮让上下文归零。如果确实需要连续讨论可以在插件设置里把“上下文自动裁剪”打开它会在上下文长度接近上限时自动丢弃最早的部分。这个策略牺牲了一点早期记忆但保住了实时响应速度在长会话场景下算是一个合理的妥协。4. 实战把 Page Assist 调成随手可用的本地阅读工作台4.1 场景一用侧边栏模式覆盖日常阅读流程在插件设置里开启“侧边栏模式”之后它会收起成浏览器右侧的一条窄栏不再遮挡页面主体。这个模式特别适合边看文章边提问。我配置了一套组合拳右手按住鼠标选中一段原文左手按快捷键唤起提问框直接输入问题回车出答案全程不离开当前页面。这套流程里有一个操作细节会影响体验默认的唤起快捷键需要到浏览器扩展的快捷键设置里自己绑定。你可以把它绑定为AltQ这种顺手组合避免和浏览器自带的书签或翻译快捷键冲突。在实际使用中我比较推荐让侧边栏常驻而不是每次用完就关。因为侧边栏关闭后会释放对话上下文下次打开就是一个全新的会话。如果你正在研究一个主题需要在多篇文章之间来回对照中途关掉侧边栏等于丢掉所有上下文这个坑我踩过好几回。4.2 场景二把模型输出直接复制回编辑器Page Assist 的回复区域支持一键复制、插入当前页面的功能。不要小看这个“插入到当前页面”的能力在写文档、整理资料时它比复制粘贴高效得多。具体实现是插件在你的光标位置插入模型答案而不是粘贴到侧边栏里。这意味着你可以在浏览器里开着在线文档或者本地静态页面的编辑模式让模型生成草稿然后一键落位。这个场景对 prompt 的要求是“结构化输出”。我习惯在自定义模板里加上一条“使用 Markdown 格式包括列表和子标题”让生成的答案直接成为文章的骨架。再配合分块提问把每个小标题下的内容逐个生成一篇文章的初稿就能在半小时内成型。4.3 场景三多模型对比与切换策略如果你本地装了多个模型比如一个中文能力较强的 7B 模型和一个代码能力较好的 7B 模型Page Assist 支持在侧边栏顶部的下拉框里直接切换。这个功能看似简单实际作用很大。我测试过同一段 JavaScript 代码在两种模型下的解释质量差异非常明显。但注意切换模型后当前会话的上下文会被清空因为不同模型的 tokenizer 不一样历史 token 无法直接复用。所以我的对比流程是先抓取一段有代表性的代码复制到侧边栏里然后分别用两个模型跑同一段请求最后对照两边的回答判断哪一个更符合需求。为了保持对比的公平性我会把温度都设成 0.2避免随机性干扰判断。5. 避坑与排查CORS、端口冲突与上下文丢失5.1 请求失败且报错 CORS现象侧边栏正常打开输入问题发送后提示类似“origin is not allowed”的错误控制台里能看到 CORS 字样。 原因这是浏览器安全策略在拦截跨域请求。插件页面运行在chrome-extension://协议下访问http://127.0.0.1:11434属于跨源访问。虽然 Page Assist 在扩展的 manifest 中声明了权限但本机模型服务默认没有放行这个来源。 解决在模型服务的环境变量里添加允许的来源。常见做法是设置OLLAMA_ORIGINShttp://127.0.0.1:*然后重启模型服务。如果你用的是 Docker 部署需要同时加上环境变量并重新创建容器。改完最好硬刷新一次插件页面。5.2 插件能打开但聊天窗口一直是空白现象侧边栏渲染正常但消息列表区域什么都不显示发送消息也无响应。 原因多数情况是模型服务没有启动或者启动后加载的模型名字和插件里填的对不上。另一种可能是模型服务端口被防火墙拦了尤其是 Windows 上首次运行模型服务时系统弹窗没点允许后面所有请求都会失败。 解决先在命令行执行一次调用确认服务本身可用格式参考curl http://127.0.0.1:11434/api/tags如果返回列表里有模型名称说明服务正常去插件设置里核对模型名。如果 curl 都不通检查服务进程是否还在端口有没有被其他程序占用。5.3 网页摘要抓取到的内容只有导航链接现象总结出来的结果是“首页、关于我们、联系我们”这类垃圾内容。 原因页面本身是动态渲染的内容在脚本执行后才出现在 DOM 里而插件在脚本执行前就完成了正文抽取。或者页面结构里没有标准的正文标签插件回退到了通用抽取逻辑。 解决先用快捷键唤起侧边栏后手动滚动页面到底部给脚本一些执行时间再触发摘要。对于动态页面更稳妥的方式是选中正文内容后右键提交绕过页面正文抽取逻辑。这个方案牺牲一点自动化但结果可靠得多。5.4 本地服务端口被占用导致模型拉取失败现象插件配置无误模型服务也显示在运行但发送请求后长时间无响应。 原因11434 端口被其他进程占用了或者模型服务启动的时候绑定失败进入了假死状态。 解决用系统命令查端口占用情况。Windows 上是netstat -ano | findstr 11434macOS 是lsof -i :11434查到 PID 后确认是不是模型服务的进程如果不是就结束掉在冲突进程然后重启模型服务。5.5 模型回答越来越慢直到提示超时现象会话使用时间越长每个字蹦出来的间隔越大最后直接转圈不动。 原因上下文窗口被长内容撑满每次请求都要把全部历史 token 交给模型重新计算一遍计算量随 token 数近似线性增长显存不足还会触发部分重载。 解决这是最常见的翻车现场。处理方式有两种任务一完成就清空会话这是最省心的。或者想保留话题就把大段内容手动摘掉只保留关键结论让模型继续讨论。热词“黑匣子”用在这里特别贴切上下文越长模型内部越难判断它是怎么得出这个结论的。6. 进阶自定义提示词模板与右键菜单验证到了这个阶段插件的基本功能已经不顺了剩下最值得花时间的是自定义提示词。我强烈建议建一个“阅读助手”模板要求模型无论接什么任务都必须先切分原文结构再作答具体模板如下直接配置在自定义提示词里每次提问都会自动带到你是我的阅读副手。请严格依据原文内容作答不要补充任何外部知识。 默认输出结构 1. 一句话结论不超过60字 2. 关键细节编号列表 3. 可能的争议点如果没有就不写模板设置好之后验证远比想象中重要。我一般会打开一篇比较旧的技术文档选中中间几段右键触发提问看看插件是不是真的沿着模板结构走。如果回答里多了“首先、其次、最后”这种口头禅说明模型没有被模板约束住这时候要检查模板有没有在“默认对话”模式下生效。常用验证方法打开一个纯文本页面选中一段原文然后问“这段的主要结论是什么”正常情况模型会严格按照模板输出三条结构第一行是一句话结论而不是一段自由发挥的叙述。如果验证不通过重新保存模板再试一遍必要时重启浏览器扩展。快捷键配置同样是容易被忽略的效率点。把“唤起侧边栏”绑定到顺手的位置把“粘贴当前选择”绑定到相邻键我习惯于在浏览器快捷键设置页里把这两件事配置成AltW和AltE。从那以后我每次读到文章里值得讨论的段落都强制自己走一遍“选中、唤出、提问、复制结论”的流程不顺手也变成了顺手。模型输出虽然偶有瑕疵但这条工作流确实帮我消化了大量长文。希望这篇拆解能让你少走我走过的弯路装好之后也顺手把你的插件的模型名和温度校准一遍——这两个参数是后续一切好用的前提。本文还有配套的精品资源点击获取