简介：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 个 token，7B 模型常见的 4K 上下文窗口只能容纳 2000 到 3000 个汉字。如果一篇文章有 8000 字，硬塞进去会直接截断后半部分，摘要结果自然丢信息。常见做法是分块摘要、再汇总。你可以把文章复制出来，按标题拆成几段，逐段让模型总结，最后再合并。
请阅读以下网页内容，用不超过150字的中文概括其核心观点。 要求：不要遗漏关键数字、不要添加原文没有的信息。 原文内容如下： {页面正文}这段提示词是我在插件自定义标签页里常用的模板。注意几点：字数约束一定要写，避免模型输出长篇大论；要求“不要添加原文没有的信息”，是对抗模型脑补的有效手段；用花括号包裹变量，是让插件识别出这是一个可替换的文本区域。
参数上，摘要任务我的固定配置是temperature = 0.3，context_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 场景一：用侧边栏模式覆盖日常阅读流程
在插件设置里开启“侧边栏模式”之后，它会收起成浏览器右侧的一条窄栏，不再遮挡页面主体。这个模式特别适合边看文章边提问。我配置了一套组合拳：右手按住鼠标选中一段原文，左手按快捷键唤起提问框，直接输入问题，回车出答案，全程不离开当前页面。
这套流程里有一个操作细节会影响体验：默认的唤起快捷键需要到浏览器扩展的快捷键设置里自己绑定。你可以把它绑定为Alt+Q这种顺手组合，避免和浏览器自带的书签或翻译快捷键冲突。
在实际使用中，我比较推荐让侧边栏常驻，而不是每次用完就关。因为侧边栏关闭后会释放对话上下文，下次打开就是一个全新的会话。如果你正在研究一个主题，需要在多篇文章之间来回对照，中途关掉侧边栏等于丢掉所有上下文，这个坑我踩过好几回。
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_ORIGINS=http://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 11434，macOS 是lsof -i :11434，查到 PID 后确认是不是模型服务的进程，如果不是就结束掉在冲突进程，然后重启模型服务。
5.5 模型回答越来越慢，直到提示超时
现象：会话使用时间越长，每个字蹦出来的间隔越大，最后直接转圈不动。 原因：上下文窗口被长内容撑满，每次请求都要把全部历史 token 交给模型重新计算一遍，计算量随 token 数近似线性增长，显存不足还会触发部分重载。 解决：这是最常见的翻车现场。处理方式有两种，任务一完成就清空会话，这是最省心的。或者想保留话题，就把大段内容手动摘掉，只保留关键结论让模型继续讨论。热词“黑匣子”用在这里特别贴切，上下文越长，模型内部越难判断它是怎么得出这个结论的。
6. 进阶：自定义提示词模板与右键菜单验证
到了这个阶段，插件的基本功能已经不顺了，剩下最值得花时间的是自定义提示词。我强烈建议建一个“阅读助手”模板，要求模型无论接什么任务，都必须先切分原文结构再作答，具体模板如下，直接配置在自定义提示词里，每次提问都会自动带到：
你是我的阅读副手。请严格依据原文内容作答，不要补充任何外部知识。 默认输出结构： 1. 一句话结论（不超过60字） 2. 关键细节编号列表 3. 可能的争议点（如果没有就不写）模板设置好之后，验证远比想象中重要。我一般会打开一篇比较旧的技术文档，选中中间几段，右键触发提问，看看插件是不是真的沿着模板结构走。如果回答里多了“首先、其次、最后”这种口头禅，说明模型没有被模板约束住，这时候要检查模板有没有在“默认对话”模式下生效。
常用验证方法：打开一个纯文本页面，选中一段原文然后问“这段的主要结论是什么”，正常情况模型会严格按照模板输出三条结构，第一行是一句话结论，而不是一段自由发挥的叙述。如果验证不通过，重新保存模板再试一遍，必要时重启浏览器扩展。
快捷键配置同样是容易被忽略的效率点。把“唤起侧边栏”绑定到顺手的位置，把“粘贴当前选择”绑定到相邻键，我习惯于在浏览器快捷键设置页里把这两件事配置成Alt+W和Alt+E。从那以后，我每次读到文章里值得讨论的段落，都强制自己走一遍“选中、唤出、提问、复制结论”的流程，不顺手也变成了顺手。模型输出虽然偶有瑕疵，但这条工作流确实帮我消化了大量长文。希望这篇拆解能让你少走我走过的弯路，装好之后也顺手把你的插件的模型名和温度校准一遍——这两个参数是后续一切好用的前提。
本文还有配套的精品资源，点击获取
