企业官网建设流程全解析

1. 组合之前先把 ego_* 家族拆层看

很多人接触 ego-browser 之后，第一反应是挨个试一遍 ego_* 工具。试完之后就懵了：每个工具单看都挺简单，有的负责建档，有的负责抓取，有的负责检索，但真到了“我想把它用起来”的时候，反而不知道从哪里下手。原因很简单，这些工具不是平级的命令集合，它们串起来的是一条主题化浏览的工作流。

我自己的理解是，ego_* 家族本质上是把“浏览网页”这件事拆成了五个层次：

• 主题层：负责管理“我今天在看什么”。对应的是主题的创建、切换、重命名、归档这类基础操作。
• 采集层：负责把“看到的内容”变成“留下的数据”。对应的是页面快照、选区保存、笔记附加、来源记录。
• 检索层：负责从已经积累的素材里找东西，按关键词、按时间、按主题过滤都可以。
• 加工层：负责把素材重新组织。比如摘要、合并、去重、生成索引。
• 导出层：负责把主题库里的内容输出成可分享、可归档的格式，比如 Markdown、JSON、CSV。

层和层之间不是单向依赖，而是通过同一个主题存储库互相咬合。采集层写进去的东西，检索层可以查；加工层重新组织之后，导出层可以输出；主题层随时切换上下文，影响所有其他工具的行为。所以组合用 ego_*，本质上是在设计一条“从浏览到知识沉淀”的流水线，而不是在拼命令。

从这个角度去看官方文档也好，去看别人写的技巧帖也好，你会发现几乎所有有效的用法都在做同一件事：确认当前工作在哪个主题上下文里，然后把采集、检索、加工、导出这几个环节串成闭环。

这篇内容我会按照“接口约定—组合模式—常见坑—个人工作台”的顺序来讲。已经对 ego-browser 有基本操作经验的人可以直接跳到第三节看组合方案，纯新手建议从头读起。

2. 组合的底层逻辑：三个接口约定

2.1 约定一：永远显式声明主题上下文

ego_* 工具和普通命令行工具最大的区别在于：普通工具操作的是文件，ego_* 操作的是主题。主题是 ego-browser 里所有数据的容器，你可以把它理解成一个带标签的资料夹。每个 ego_* 调用都必须知道当前落在哪个主题里，否则它不知道该把数据写进哪个夹子，也不知道该从哪个夹子里读内容。

我见过太多人组合失败，不是因为命令写错，而是因为主题上下文断裂。比如先用 ego_topic create research/webrtc 建了一个主题，然后直接跑 ego_capture，发现抓下来的页面跑到了别的主题里。原因就是 capture 工具没有继承当前主题，需要重新声明。

所以我的第一个建议是：给 ego_* 工具统一加主题参数。具体哪种写法取决于你的版本，但通常都会支持类似 --topic 或者 -t 的全局参数。养成习惯之后，每条命令的可读性会提高很多，脚本也变得自解释：

ego_topic create research/webrtc ego_capture --topic research/webrtc --url "https://example.com/sdp" ego_find --topic research/webrtc --keyword "ICE"

如果你经常在同一主题下连续操作，也可以先把主题切换成默认上下文，再省去重复参数。但我的经验是：脚本里最好还是显式声明，因为一旦脚本被别人复用、或者你隔两周再来看，默认上下文的逻辑往往已经记不清了。显式写清楚主题，比依赖隐式状态要稳得多。

2.2 约定二：结构化输出是组合的命根子

组合的本质是“上一个命令的输出变成下一个命令的输入”。如果输出格式参差不齐，组合就无从谈起。ego_* 工具之间的数据传递，靠的是三类格式：

• JSON：适合机器处理，字段稳定，比如导出条目元数据、检索结果。
• Markdown：适合人阅读，适合沉淀成笔记，比如综述页、摘要卡片。
• TSV/CSV：适合批量处理和表格化分析。

这里有个很关键的实践原则：中间环节尽量用 JSON，最终输出才转 Markdown。比如我要批量清洗一批攒下来的页面，不可能手工一个个打开看，而是用检索工具拉到 JSON 列表，再写一个小脚本做过滤，最后才渲染成 Markdown 归档。如果你一开始就导出 Markdown，后面再做结构化处理反而麻烦。

实操中我习惯给 ego_export 配一个固定模板，把导出的主题库内容固定成统一的 JSON Schema：

{ "topic": "research/webrtc", "exported_at": "2025-01-10T20:00:00Z", "entries": [ { "id": "entry_001", "url": "https://example.com/sdp", "title": "SDP 协商机制与ICE候选", "captured_at": "2025-01-08T12:00:00Z", "notes": "重点看candidate优先级部分", "tags": ["sdp", "ice"] } ] }

这套结构跑通之后，你把同样格式的 export 文件再导回到另一个主题库做合并，工具不会出现字段对不上的问题。可以说，结构化输出的约定决定了你能把 ego_* 工具组合到多深的程度。

2.3 约定三：给每条记录一个稳定 ID

第三个约定很多人会忽略：组合操作里，你要能精准指代某一条记录。如果每次检索结果里条目 ID 都是临时生成的，那你就没法把“某条采集记录”作为参数传给加工层工具。

稳定 ID 的好处很直接：你可以把采集到的内容、附加的笔记、后续生成的摘要、甚至跨主题的链接关系，都挂到同一个 ID 下面。这样你的主题库就不是一摊散落的数据，而是一张可以追溯来源的知识网。实际操作里，我看到好几个人用标题或者 URL 做 ID，都不太可靠。标题会重复，URL 会失效，最稳妥的还是用工具生成的不变 ID。

2.4 组合层级的判断方法

把接口约定搞明白之后，再来看“怎么组合”就清晰多了。我一般把组合分成四个层级，不同层级对应不同强度和复杂度的使用场景：

不需要一上来就追求最高层级。能先把“同批顺序调用”打磨顺，就已经比大多数随手用的人强很多了。组合是逐步长出来的，不是设计出来的。

3. 六种有效组合模式

3.1 采集三件套：建主题 → 开页面 → 抓内容

最基础也最常用的组合，是围绕“一次浏览动作”展开的。整个流程就三步：

ego_topic ensure research/network-stack ego_open --topic research/network-stack "https://example.com/docs/tcp" ego_capture --topic research/network-stack --url "https://example.com/docs/tcp" --note "重点阅读重传部分"

这套组合解决了浏览和归档的割裂问题。以前我的流程是：读一篇长文，觉得有用，复制链接丢到备忘录，然后隔一阵子再整理。问题在于，等我真正要整理的时候，经常已经忘了当初为什么收藏这篇。现在我把“为什么收藏”这个信息，原地就在采集环节记录成 note，归档效率高了一倍。

ego_open 的作用也不只是打开 URL。它会带着当前主题上下文初始化页面状态，确保后续的 capture 能正确归属。我见过有人跳过 open 直接 capture，虽然也能抓到，但如果页面里有需要登录才能访问的内容，先 open 再 capture 往往更可靠，因为会话状态已经建立了。

另一个技巧：批量采集同一主题下的多个页面时，不要让 capture 一把抓太多。一次抓 3 到 5 个页面是舒服的节奏，抓完抽空把 notes 补一下，再抓下一批。批量太大会导致整理时根本想不起来每个页面当初为什么被选进来。

3.2 素材加工链：检索 → 过滤 → 摘要

第二个高频组合发生在积累了一段时间之后。主题库里有上百条记录，需要把它们变成一段可以理解、可以引用的内容。我的做法是：

ego_find --topic research/network-stack --keyword "congestion" --since 30d ego_filter --input results.json --by "tags contains tcp" ego_summarize --topic research/network-stack --scope selected --output digest.md --format markdown

这条链路的本质是：先把原始素材缩成一个候选集，再做一次精筛，最后让加工层生成摘要。组合的关键点在于，检索结果和过滤结果都必须保持同一套结构化格式，否则摘要工具读不到数据。

这里我想强调一个实际操作经验：摘要工具（或者任何 AI 生成类的加工工具）的输入端，最好只给它高信噪比的素材。如果不管什么内容都往主题库里塞，然后把一堆低质量页面丢给摘要工具，产出的综述也会很水。所以组合里宁可多跑一轮过滤，也不要让加工层吃太多噪声。

另外，这类加工链我通常放在浏览器外部执行，比如在命令行里直接调用。原因是我可以在正式执行前先看一遍过滤结果，确认没有误伤，再跑摘要。如果全在浏览器界面里点来点去，偶尔会跳过检查步骤，后面还要回头返工。

3.3 主题对照链：两个上下文并行推进

更进阶的用法是同时处理两个主题，并且让它们互相参照。典型场景是技术选型对比：你用主题 A 积累方案甲的资料，用主题 B 积累方案乙的资料，最后想要生成一张对比表。

ego_topic create research/compare-a ego_topic create research/compare-b ego_open --topic research/compare-a "https://example.com/tech/x" ego_capture --topic research/compare-a --url "https://example.com/tech/x" --note "X的吞吐量优势" ego_open --topic research/compare-b "https://example.com/tech/y" ego_capture --topic research/compare-b --url "https://example.com/tech/y" --note "Y的延迟表现"

单看每一步都不稀奇，但组合起来就有意思了。因为两个主题并行积累，你可以随时用交叉检索把 A、B 中的同维度信息拉出来比对，不用等全部收集完才开始思考。比如：

ego_find --topic research/compare-a --keyword "latency" ego_find --topic research/compare-b --keyword "latency"

然后手动把两次结果并排看，很快就能发现资料覆盖度的差异。如果 A 主题下 latency 相关记录有 10 条，B 主题只有 1 条，那说明 B 方向的资料收集还不充分，需要补采。这个“以对比结果反推采集方向”的技巧，比闷头攒数据有效得多。

等两边素材都够了，再出一份合并导出：

ego_export --topic research/compare-a --format markdown --output a.md ego_export --topic research/compare-b --format markdown --output b.md

对比表的核心内容其实在你的笔记里，两个 Markdown 文件只是呈现载体。真正帮助你做决策的，是持续观察两个主题各自的信息密度和冲突点。

3.4 知识库维护链：查重 → 合并 → 归档

主题库用久了，必然面临一个问题：重复内容越来越多。有的是同一篇文章被不同入口各采集了一遍，有的是两个高度相似但版本不同的页面。组合里的维护链就是专门治这个的：

ego_find --topic research/network-stack --duplicates ego_merge --topic research/network-stack --from entry_a --into entry_b ego_topic archive research/network-stack-old

这里最容易犯的错误是：看到重复条目就直接删。我建议保留合并而非直接删除的路线。原因是，两个不同时间采集的版本，笔记可能各不相同，某一版里记录的想法也许比正文还有价值。合并工具能把来源、笔记、标签汇总到一起，保留完整的历史脉络，比粗暴删掉一版要稳。

归档操作也值得多说一句。主题库不是只有“在用”和“废弃”两个状态。很长时间没动的主题，我会归档而不是删除。归档后它依然存在，只是默认不出现在检索结果里，避免干扰当前工作。等哪天要用的时候，再取消归档即可。

这条维护链不需要每天跑，一周一次或者两周一次就够。跑得太勤反而浪费时间，因为有些短期内看起来重复的内容，其实是在不同视角下刻意收集的，早点合并反而损失了信息。

3.5 定时批量链：用脚本把组合串起来

当你熟悉了上面几套组合之后，自然会想把它们固化成脚本。我自己会把采集、检索、摘要的固定流程写成一个可重复执行的脚本，每天定时跑。

#!/bin/bash TOPIC="research/network-stack" TODAY=$(date +%Y-%m-%d) ego_topic ensure "$TOPIC" ego_review --topic "$TOPIC" --since 1d --output "/tmp/ego_review_$TODAY.json" ego_filter --input "/tmp/ego_review_$TODAY.json" --by "notes != ''" --output "/tmp/ego_filtered_$TODAY.json" ego_export --input "/tmp/ego_filtered_$TODAY.json" --format markdown --output "~/logs/ego_$TODAY.md"

每天跑这么一遍，得到的是一份当天采集内容的干净归档。脚本的威力在于：你只需要把接口约定维护好（JSON 传递 + 主题显式声明），剩下的就是写好一次脚本，然后长期复用。

定时批量链也适合做周期性回顾。比如每个月跑一次全库总结：找出这个月新增的主题、增长最快的主题、以及长期没有更新的主题。这种站在元层面的审视，能帮你看清自己到底在浏览上投入了什么。

3.6 导航跳转链：从材料回到原文

这条链很容易被忽略，但实际用起来非常舒服。因为采集内容越来越多之后，你经常是在看自己的笔记，而不是在浏览网页。这时候需要快速从某条笔记跳回原始页面：

ego_find --topic research/network-stack --keyword "fast retransmit" ego_open --url "$(ego_get --field url --id entry_id)"

为什么要把这一步也视为“组合”？因为它完成了一次从知识库到原文的闭环。如果没有这条链，你看到一条记录后，还得手动复制 URL 贴到浏览器里，多一步操作就多一分懈怠。有了它，检索到任何条目都能一键回到现场，继续往下阅读相关联的上下文。

我建议在日常使用中刻意培养这个习惯：任何时候从主题库点开一条旧记录，如果发现原文已经变化、或者链接失效，就顺手用采集层补一条新版本。这样你的主题库始终跟源网页保持同步，不会变成一座内容停滞的孤岛。

4. 几个高频踩坑点

4.1 主题命名不统一

组合用得多之后，最让我头疼的问题反而不是命令，而是命名。一会儿建research/webrtc，一会儿又建webRTC，一会儿缩写成rtc。到后面想跨主题检索时，数据流三处汇总不上，逼着你要么重命名，要么手动迁移。

我的建议是：从一开始就定一套主题命名规范。比如顶层按领域分（research、project、personal），二级再按具体话题分，统一小写加连字符。听起来很基础，但能省掉后续大量整理时间。

4.2 中间格式随意输出

我在前面反复强调 JSON 作为中间层。实际操作里，有人习惯每一步都输出成 Markdown 再做下一步，结果就是过滤、合并、摘要工具都得重新解析 Markdown，非常脆弱。稍微复杂一点的组合，就绕不过格式兼容性问题。

判断自己是不是掉进这个坑，就看一个问题：你的脚本里有多少个地方在做字符串切割或者正则匹配？如果很多，大概率是中间格式选错了。

4.3 上下文被隐式覆盖

ego_* 工具如果支持全局主题设置（比如环境变量），就很容易发生隐式覆盖。你可能在某次调试时改了全局主题，然后忘了改回去，结果接下来所有命令都跑到了错误主题下面，攒了一堆错位数据。

怎么防？最有效的办法是脚本里逐个显式指定主题参数，而不是依赖全局状态。虽然写起来啰嗦，但脚本本身就是要时刻保持确定性。交互式使用偶尔依赖全局状态没问题，长期跑的任务绝对不行。

4.4 采集量大但利用率低

有一种情况很普遍：硬着头皮把整个网页全文抓进主题库，笔记不写、标签不打、后续也不整理。表面上积累了很多素材，实际上越积越乱，最后每次都只能用关键词硬捞。

解决办法不是在采集环节做更多事，而是给采集任务设一个“最小整理单位”：每条记录要么写一句笔记，要么打一个标签，否则宁可先不采集。这看起来降低了采集量，但换来的是每条素材都值得被再次调用。

4.5 脚本非幂等，重复执行产生脏数据

定时批量链写好了，但每次跑出来的结果不一样，甚至会导致重复数据累积，问题多半出在脚本没有做幂等控制。幂等的意思是：同一条记录，重复执行同一个流程，不会产生第二份副本。

在 ego_* 的组合里，幂等性主要靠稳定 ID 来保证。采集之前先检查这个 URL 是否已经存在于当前主题，如果存在就直接更新笔记，而不是重新插入一条。这个检查逻辑看起来简单，却能避免主题库在自动化流程里越跑越脏。

5. 一套可参考的最终工作台

讲了这么多组合模式，最后说下我现在实际用着的一套工作台。它不算复杂，但对我的日常浏览和生活管理帮助很大。你可以以此为蓝本，改成适合自己的版本。

每天早上的流程是一个轻量回顾。我会用 5 分钟跑一遍采集链路检查昨天新入库的内容，然后补写笔记。补笔记的时候顺手做一次过滤，把明显不需要长期保留的内容标记为临时，这能让主题库长期保持健康。

需要研究新领域时，我会启动的是“双主题对照”模式。先给每个候选方案建立独立主题，之后两周内所有相关浏览都显式落到对应主题里。等素材积累到一定程度，再走一次“检索 → 过滤 → 摘要”链路，生成一份阶段对比报告。这套打法帮我做过好几次技术选型，比传统收藏夹方式的信息密度高很多。

月底我会花一小时做更宏观的维护。把活跃度低的老主题归档，检查重复条目，把结构较乱的主题重新整理一次。这个习惯保证我从月初到月末，主题库一直是可检索、可依赖的状态。

如果你想抄作业，我建议不要一次引入全部模式。先只挑一个场景走通，比如“采集三件套”，用半个月建立起肌肉记忆。等它稳定了，再叠加“素材加工链”。组合不是目标，目标是你浏览后能留下什么可复用的东西。工具只是把这件事变简单了一点。