context-mode实战:把网页变成AI可读的上下文工作流

发布时间:2026/10/5 4:37:47
context-mode实战:把网页变成AI可读的上下文工作流 不知道你有没有经历过这种场景白天在浏览器里翻了几十篇文章收藏夹塞了一堆链接等晚上真正想用的时候要么网页打不开要么标题和内容对不上链接里的信息像沙子一样从手里漏走。我后来解决这个问题的核心思路就是 context-mode——让 AI 不靠一个“链接”去猜内容而是直接把当前网页的真实内容转成一份可以保存、可以反复对话的上下文。这东西不是某个平台专属功能而是一种工作流设计核心是把“浏览网页”这个动作升级成“积累上下文”这个动作。这篇文章写给所有需要大量处理网页信息的人做调研的、写方案的、整理资料库的、天天跟 AI 聊天的。我会把 context-mode 背后的原理、配置步骤、日常用法和踩过的坑一次性讲透确保你读完就能照着搭一套自己的上下文工作流。1. 从“给链接”到“给上下文”context-mode 解决的痛点1.1 链接不是上下文大多数人在用 AI 查资料时习惯直接把网址丢给对话框。这个动作看着省事实际上问题很多。网址本质上只是一个定位符它告诉你“信息在哪儿”但不包含信息本身。AI 拿到一个链接之后能不能读到内容取决于网站是否开放、是否需要登录、是否存在反爬机制、页面是不是动态渲染的。我试过好几次把一篇需要付费才能看全文的文章链接发给模型结果它只能根据标题和摘要瞎猜。更常见的情况是链接指向的页面已经改版或者下线AI 收到的是 404 页面里的错误信息它还会一本正经地告诉你“这篇文章认为……”实际它看的根本不是那篇文章。context-mode 要做的第一件事就是打破“给链接”的思维惯性。它不关心你贴了什么 URL而是先把网页正文抓下来、洗干净、压成一份纯文本再把这份文本作为可被模型直接消费的上下文。1.2 传统剪藏工具的短板我知道有人会说这不就是网页剪藏吗Evernote 的剪藏插件、印象笔记的网页保存、Notion 的 Web Clipper我都用过。它们确实能把你正在看的网页保存下来但保存下来的是一份静态快照是“存档”不是“上下文”。区别在哪里存档的意义是我以后翻出来自己看上下文的意义是它能被 AI 直接读取、检索、对话、再加工。传统剪藏工具擅长存储不擅长生成语境。你把一篇技术文章剪藏到笔记本里它不会自动提炼摘要不会按主题归类也不会在你提问的时候变成一份高质量的参考答案。还有一层麻烦很多剪藏工具把你保存的内容锁在自己的数据库里导出格式乱七八糟。想换个笔记软件迁移一次跟搬家一样累。context-mode 的定位不一样它输出的是一份干净、通用、可迁移的 Markdown 文件谁都能读谁都能处理。1.3 context-mode 的定位我把 context-mode 理解成一句话把“浏览动作”转化为“带元数据的 Markdown 文本”并让这份文本能被 AI 客户端直接读取和召回。它与收藏夹、剪藏工具的区别看这张表最直观维度普通收藏夹传统剪藏context-mode保存内容只有链接和标题页面快照清洗后的正文 元数据可检索性靠分类手工找靠全文搜索全文搜索 标签 摘要可对话性无无可发给 AI 做问答、总结、改写格式统一无不统一统一为 Markdown数据归属平台方平台方本地文件迁移成本高高低拿个移动硬盘就能拷走这个定位决定了它不是一个“保存按钮”而是一条管道网页进来正文留下元数据跟上AI 随时能用。接下来我们就拆开看这条管道内部是怎么工作的。2. 核心原理拆解网页是如何变成“上下文”的2.1 正文识别把噪音和杂质剔除网页原始内容是 HTML里面除了正文还有导航栏、侧边栏、推荐位、评论、广告脚本甚至弹窗提示。如果把这堆东西原封不动喂给 AI模型会在无关信息里迷失方向。context-mode 做的第一步就是识别真正的主内容区域。这个过程和阅读器模式背后的原理是一回事程序会分析 HTML 结构计算每个文本块的字数、位置、标签密度把那些像正文的段落挑出来把导航和广告块丢掉。分类讲究的是“文本块在页面里的占比”“标题层级是否连续”“段落长度是否达到阈值”。实际使用中我遇到过不少失败的例子单页应用SPA里的内容是 JavaScript 动态渲染的纯静态抓取拿到的是空壳有些网页用了懒加载图片和文章后半段要滚动才出现还有页面嵌了多层 iframe正文藏在子框架里。碰到这些情况很多扩展会退回到“整页可读性模式”或者让你手动框选正文区域。这也是我第一次用时觉得它“不够智能”的原因但它至少给了兜底方案。2.2 上下文打包从正文到带元数据的文件正文识别完成后context-mode 会把内容转成 Markdown。为什么要 Markdown因为它是纯文本、结构清晰、能被所有模型和编辑器直接处理。标题用#表示列表用-代码块用反引号包裹表格还能保留成 Markdown 表格。模型读 Markdown 比读一堆 HTML 标签要省非常多 token回答质量也会更高。一份合格的上下文文件不能只有正文还必须包含元数据。下面是我常用的一份格式--- title: context-mode 实践笔记 url: https://example.com/post captured_at: 2025-01-12T10:22:0008:00 tags: [AI, 工作流, 浏览器] summary: 把网页正文转成可对话上下文的思路与落地方法 --- # context-mode 实践笔记 正文内容从这里开始……你看到的关键字是title、url、captured_at、tags、summary。这几项一个都不能少。url保证你随时能回到原文核对captured_at告诉你信息是什么时候采集的summary是你给这份上下文写的一句话摘要后面做检索的时候这一行字能救你命。2.3 存储与检索本地优先是底线上下文的存储方式我强烈建议走本地文件优先的路线。原因很简单文件才是真正属于你的数据。存在某个平台里平台倒闭、收费策略变化、账号被封内容可能说没就没。我自己的上下文目录结构是这样的~/contexts/ 2025-01/ ai-workflow-notes.md context-mode-practice.md 2025-02/ browser-extension-review.md 2025-02_weekly-digest.md按月分目录文件名直接用文章标题简写。这样哪怕不用任何笔记软件我在终端里一条grep都能找到内容。文件一旦是纯文本以后不管换什么 AI 工具、什么笔记软件都能直接导入不会被绑死。2.4 对话接口上下文进入模型的方式有了干净的文件之后下一步是让模型消费它。最简单的办法是直接把 Markdown 内容粘贴到对话框稍微进阶一点的做法是把上下文目录挂载到支持本地知识库的 AI 客户端里再高级一点可以做成向量检索让模型只召回和问题相关的片段。Markdown 在这一层有几个天然优势也有需要注意的地方优势注意点纯文本token 开销低模型处理快表格复杂时容易丢失列对齐代码块可保留语言标记代码类内容清晰超长代码段会占大量 token标题层级清晰模型能理解文章结构嵌套列表层级过深时偶尔乱序是绝大多数工具的通用格式图片和附件需要额外处理一句话概括context-mode 不是某个黑科技魔法它的本质是把网页内容经过“清洗、打包、存盘”之后变成模型能直接读的一段干净文本。所有后续的智能问答都是建立在这份文本的质量之上。3. 实操配置从安装到跑通第一次上下文对话3.1 工具选型选什么样的扩展现在不少浏览器扩展都提供了类似的能力有的直接把核心模式命名为 context-mode。选的时候我建议看几个硬指标能不能右键直接抓取、能不能输出 Markdown、能不能自定义存储路径、元数据字段是否可配置、是否支持快捷键。我目前用的这类扩展有几个共同点提供侧边栏界面、在右键菜单里有“捕获为上下文”之类的选项、可以设置本地输出目录、支持把当前页面一键转成 Markdown 并追加元数据。选型时不要贪多先把“右键抓取 本地保存 Markdown 输出”这三条凑齐就已经够用了。这里有一个容易被忽略的点权限设置。安装的时候扩展一般会申请activeTab、storage、contextMenus这几项基础权限。老实说我不建议让它申请对所有网站的完全访问权限只在需要抓取的页面手动开启权限能少很多隐私风险。3.2 初次配置目录、文件名与快捷键第一次配置 context-mode我踩过最大的坑是文件名。默认情况下很多扩展会用网页标题当文件名但网页标题经常带各种奇怪的符号和超长后缀在文件系统里看着难受引用时也容易出错。我现在的配置逻辑是文件名统一用“日期-简短标题”的格式比如2025-02-06-context-mode实战.md。这样按文件名排序自动等于按时间排序检索效率高。存储目录先设置成~/contexts/当前月份/让扩展自动建子目录。快捷键一定要配。我给抓取动作配了CtrlShiftC手放在键盘上不用动鼠标看到一篇文章扫一眼觉得有用直接按下快捷键三秒钟进入“已捕获”状态。这个流畅度非常重要因为任何需要多点几步的操作都会慢慢被你放弃。3.3 日常操作流程五步走我每天处理信息的工作流已经固定成了五个步骤你可以直接抄浏览到有保留价值的页面按下抓取快捷键。扩展自动识别正文转成 Markdown补上标题、URL、时间、标签。文件落到本地目录我顺手补一句summary摘要。需要研究时把文件拖进 AI 客户端的对话框。基于上下文提问、总结、对比、改写用完后文件留在库里随时可复用。这套流程的精髓在第 5 步同样的网页以前你看完就划走了现在它变成了一份可复用资产。3.4 一个最小可运行示例假设我正在看一篇关于“本地优先软件”的文章按下快捷键后context-mode 生成了一份 Markdown 文件。之后我打开 AI 对话框粘贴下面这段提示词模板请基于以下上下文回答我的问题。 上下文内容 {{把捕获的 Markdown 内容完整粘贴到这里}} 我的问题这篇文章的核心观点是什么作者提供了哪些论据模型会严格按照上下文回答不会去编造文章之外的内容。注意这句“我的问题”要放在上下文之后否则模型可能把上下文当成对话主体回答方向就跑偏了。这看起来很简单但很多人第一次用上下文模式时都是把问题写在前面、文章内容丢在后面导致模型理解混乱。4. 进阶玩法用 context-mode 搭出个人知识系统4.1 资料搜集按主题归档而不是按时间归档很多人保存网页喜欢按时间堆堆到最后发现检索是个大问题。我的习惯是除了按月分目录之外文件名前缀会带上主题词比如AI-context-mode实践.md、效率-双链笔记.md、前端-浏览器扩展权限.md。这样在终端或者任何文件管理器里看到文件名就能猜出主题两个关键词一叠基本就能覆盖绝大多数手动检索场景。每周我会做一次小整理把同一主题下的上下文文件汇总合并重复观点淘汰内容过时的文件。这个动作不用太勤周末抽二十分钟做一轮就行。4.2 周报与复盘让模型在上下文库里提炼结论周报是我用 context-mode 收获最大的场景。以前写周报要回忆这周看过什么、做过什么、学到什么靠脑子硬憋。现在每周五下午我会把本周生成的 Markdown 文件全部拼起来丢给模型然后问它“这周我接触了哪些主题每个主题的关键结论是什么有哪些可以沉淀到下周计划里”拼文件在命令行里很简单cd ~/contexts/2025-W06 cat *.md weekly-context.md然后把weekly-context.md的内容发给 AI。模型的优势和劣势都很明显它能快速识别重复主题、归纳观点但它不知道哪些内容对你重要。所以在拿到它的总结之后我会再手工过一遍最终结果。context-mode 在这里不是代替你做判断是帮你把“回忆素材”变成了“可见文本”。4.3 长期记忆用固定目录建立可复用上下文库如果你的目标不是随手用而是想搭一个长期知识库那就得从一开始就为“机器可读”做设计。这个设计又回到 2.2 节那个summary字段。我一直强调每个上下文文件必须补一句话摘要。为什么因为上下文库大到几百个文件之后任何 AI 都不可能一次全读完你需要一个轻量级的入口来筛选。筛选的逻辑可以很简单先读所有文件的summary找出与当前问题相关的三五个再把这几份完整内容喂给模型。这个流程在操作上就是用grep -l搜索摘要关键字grep -rl context-mode ~/contexts/ --include*.md命中之后把对应文件内容作为上下文回答质量会明显高于“把整个目录都塞给模型”。上下文不是越多越好而是越精确越好。4.4 不同模型消费上下文的效果差异同一个 Markdown 文件不同模型读出来的“理解深度”确实不一样。表格对比一下我实测的大致感受模型类型长文本处理指令跟随总结能力适用场景长上下文模型强能一次读完整个文件强强能抓住主线长文分析、跨文件总结常规模型中超长会被截断中中依赖提示词质量单篇问答、要点提取本地模型视显存而定中中低重逻辑任务吃力隐私内容、离线场景这提醒我一个点context-mode 产出的高质量 Markdown在长上下文模型上发挥的价值最大。如果你的主要模型上下文窗口小那就更需要在保存时写好summary把文件拆小。4.5 轻量自动化给上下文库加一个索引文件多了以后纯靠目录和文件名找内容还是有瓶颈。我写过一个不到 30 行的 Python 脚本扫描整个上下文目录读取每份文件的元数据把标题、URL、时间、标签、摘要插进一个 SQLite 数据库。这样搜索时不用grep可以直接用 SQL 按标签过滤。这个方向如果你有兴趣可以先用最简单的方式做写一个 Python 脚本遍历~/contexts下的.md文件解析两行title和tags打印成一个表格。用不着上什么复杂框架能解决你“找不到昨天看的那篇文章”的问题就算成功了。5. 实测中的坑与细节建议5.1 正文抓取失败的几种情况context-mode 不是万能的。我遇到最多的问题是正文识别不准尤其是这几类网站单页应用内容由 JavaScript 动态生成静态抓取拿到的只有空包壳。解决办法是改用整页可读性模式或者等页面完全加载后再触发抓取。懒加载页面文章后半段在滚动时才加载直接抓取可能只抓到开头。对策是关闭懒加载插件或者手动下拉到页面底部让所有内容加载完再抓。登录墙和付费墙扩展拿到的是你当前登录状态下的内容。公网 404 的页面通常抓不到正文它会给你一个错误提示。遇到以上情况我通常的兜底做法是复制网页正文的核心段落手动粘贴到一个新建的 Markdown 文件里再手动补元数据。过程重一点但内容保住了。5.2 上下文会过时要有时间意识网页是活的东西。技术文档会改版新闻会更新你三个月前保存的上下文可能已经和现实脱节。所以元数据里的captured_at和url很重要它提醒你这份信息的“采集时间”。我现在的习惯是重要主题的上下文文件每三个月重新抓取一遍把新版内容同步进来。不要指望一份文件管终身上下文也要有“保鲜期”。5.3 上下文污染一次别喂太多无关内容这是新手最容易踩的坑。有朋友问我为什么我把收集的所有资料都发给模型它还是回答得很空原因很可能是输入太多无关内容模型被噪音干扰了判断。正确做法是“先筛后问”。通过summary筛选出最相关的两三份文件再让模型基于这几份内容回答问题。如果拿到的回答确实发散立刻回退一步把上下文的限定范围收紧比如明确说“只依据我提供的上下文其他不要推测”。5.4 表格和代码是格式损坏高发区网页里的复杂表格在转 Markdown 时经常对不齐行列关系丢失。代码块相对好一点但某些高亮颜色代码和行号会混进文本里。遇到这类情况我的建议是表格不用强求还原手动改成要点列表即可代码文件最好直接下载原文件存到项目里不要只靠 Markdown 存代码。上下文文件里保留原始 URL 还是有价值的格式坏了可以点开链接回到原文比对。5.5 隐私边界要拎清context-mode 抓取的页面如果包含你的个人信息那就不能随手丢给外部 AI。登录后的个人后台、工作邮件、公司内网文档这些都属于隐私敏感内容。我的原则很简单私人数据不进公共模型如果一定要用就部署本地模型处理。这个边界不能依赖工具的默认设置必须在日常使用中形成习惯。上下文库建得越大“安全默认值”越重要。宁可少存一份内容不要存一份给自己惹麻烦的内容。context-mode 这套工作流我用下来最大的感受是它改变的不是工具而是习惯以前“收藏一下”就完事现在“当场变成上下文”才算真正吸收。而且这个流程的投入产出比很划算每次多花两三秒后面能省下几十分钟的找资料时间。最后再分享一个小技巧给每个上下文文件的summary字段留一行字别嫌麻烦后来你做任何检索、汇总、复盘最先读到的一定是这一行它比正文还常用。