企业官网建设流程全解析

不知道你有没有经历过这种场景：白天在浏览器里翻了几十篇文章，收藏夹塞了一堆链接，等晚上真正想用的时候，要么网页打不开，要么标题和内容对不上，链接里的信息像沙子一样从手里漏走。我后来解决这个问题的核心思路，就是 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 客户端直接读取和召回。

它与收藏夹、剪藏工具的区别，看这张表最直观：

这个定位决定了它不是一个“保存按钮”，而是一条管道：网页进来，正文留下，元数据跟上，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:00+08: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 在这一层有几个天然优势，也有需要注意的地方：

一句话概括：context-mode 不是某个黑科技魔法，它的本质是，把网页内容经过“清洗、打包、存盘”之后，变成模型能直接读的一段干净文本。所有后续的智能问答，都是建立在这份文本的质量之上。

3. 实操配置：从安装到跑通第一次上下文对话

3.1 工具选型：选什么样的扩展

现在不少浏览器扩展都提供了类似的能力，有的直接把核心模式命名为 context-mode。选的时候，我建议看几个硬指标：能不能右键直接抓取、能不能输出 Markdown、能不能自定义存储路径、元数据字段是否可配置、是否支持快捷键。

我目前用的这类扩展有几个共同点：提供侧边栏界面、在右键菜单里有“捕获为上下文”之类的选项、可以设置本地输出目录、支持把当前页面一键转成 Markdown 并追加元数据。选型时不要贪多，先把“右键抓取 + 本地保存 + Markdown 输出”这三条凑齐，就已经够用了。

这里有一个容易被忽略的点：权限设置。安装的时候，扩展一般会申请activeTab、storage、contextMenus这几项基础权限。老实说，我不建议让它申请对所有网站的完全访问权限，只在需要抓取的页面手动开启权限，能少很多隐私风险。

3.2 初次配置：目录、文件名与快捷键

第一次配置 context-mode，我踩过最大的坑是文件名。默认情况下，很多扩展会用网页标题当文件名，但网页标题经常带各种奇怪的符号和超长后缀，在文件系统里看着难受，引用时也容易出错。

我现在的配置逻辑是：文件名统一用“日期-简短标题”的格式，比如2025-02-06-context-mode实战.md。这样按文件名排序，自动等于按时间排序，检索效率高。存储目录先设置成~/contexts/<当前月份>/，让扩展自动建子目录。

快捷键一定要配。我给抓取动作配了Ctrl+Shift+C，手放在键盘上不用动鼠标，看到一篇文章，扫一眼觉得有用，直接按下快捷键，三秒钟进入“已捕获”状态。这个流畅度非常重要，因为任何需要多点几步的操作，都会慢慢被你放弃。

3.3 日常操作流程：五步走

我每天处理信息的工作流已经固定成了五个步骤，你可以直接抄：

1. 浏览到有保留价值的页面，按下抓取快捷键。
2. 扩展自动识别正文，转成 Markdown，补上标题、URL、时间、标签。
3. 文件落到本地目录，我顺手补一句summary摘要。
4. 需要研究时，把文件拖进 AI 客户端的对话框。
5. 基于上下文提问、总结、对比、改写，用完后文件留在库里，随时可复用。

这套流程的精髓在第 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字段留一行字，别嫌麻烦，后来你做任何检索、汇总、复盘，最先读到的一定是这一行，它比正文还常用。