企业官网建设流程全解析

搞知识工作的人，大多都有个共同毛病：信息来得太快，自己记得太慢。看到一篇好文章，先收藏；读到一句有用的话，复制到备忘录；遇到一段关键代码，截个图扔进文件夹。结果攒了大半年，收藏夹成了黑洞，备忘录里全是断头句子，截图文件夹更是从来不会打开第二次。

我一直在维护一个叫knowledge-work-plugins的自用插件合集，目的不是造一个"大而全"的效率工具，而是把知识工作里最常出现的几个断点——信息收集、内容检索、摘要打标、自动归档——用一组轻量插件串起来。整套体系跑下来，最直观的变化不是"存得更多了"，而是"存完之后真的会回头再看"。这篇文章就把这套插件的设计思路、核心实现和踩坑过程完整拆开讲一遍。如果你是搞研究、做分析、写技术文档的人，或者只是日常被信息淹得喘不过气的普通打工人，里面这套"收集-索引-摘要-联动"的框架都可以直接抄走。

1. 收集环节：为什么"看到就存"比"看完再存"更能留住信息

1.1 最原始的"复制-粘贴-整理"为什么低效

我过去收集信息的方式非常原始：看到有用的段落，鼠标选中，复制，切到笔记软件，新建文档，粘贴，起标题，找分类放进去。这套流程看起来很严谨，实际上每执行一次都要消耗大概二三十秒的"上下文切换成本"。更致命的是，这种操作会打断你正在进行的深度思考——本来在读一篇论证严密的文章，突然为了记录一段话切走注意力，回来时思路已经断了。

后来我试着"看完再存"，但人类对信息的判断力远没有自己想象中可靠。一篇三千字的文章，读完后你可能觉得"整体很有启发"，但具体哪段话值得存、哪个数据点以后要引用，当时的记忆已经开始模糊。到最后往往整篇保存，或者干脆不存。两个极端都让知识管理变成摆设。

1.2 MarkKeeper 的字段设计：来源、时间、标签与上下文

所以我在 knowledge-work-plugins 里做的第一件事，是给浏览器装一个叫MarkKeeper的收集插件。它的核心思路是：把你从"复制-粘贴-整理"这个三步操作里解放出来，只保留最关键的"选中-锚定-确认"三个动作。

选中一段文字后，按快捷键，MarkKeeper 会立即弹出一个小窗，里面自动带上了几项信息：原文的 URL、页面标题、采集时间和一个可编辑的临时标签。你只需要按一下回车，这一段文本就会带着这些"元信息"一起落到本地的一个 Markdown 收件箱文件里。整个过程三秒以内，不用切换窗口，不用思考分类。

这里值得多说一句字段设计。很多人做笔记只存正文，这是个大坑。一条信息如果没有来源、没有时间、没有上下文，存储三天之后就会变成无源之水。MarkKeeper 强制带上 URL 和标题，看起来只是多记两个字段，实际上给后续的"溯源"和"去重"留了命根子。我在字段里还留了一个"上下文"选项，默认截取选中文字前后各 200 个字符，目的是避免以后看到一条孤零零的句子时不知道它原本在论证什么。

{ "id": "20250207-001", "type": "text-selection", "title": "关于长期记忆与工作记忆的研究综述", "url": "https://example.com/papers/working-memory", "captured_at": "2025-02-07T09:30:00+08:00", "tags": ["认知科学", "待整理"], "context": "...前文提到工作记忆容量有限...正文内容...后文进一步指出...", "content": "工作记忆的容量约为 4±1 个组块，且受到任务复杂度的显著影响。" }

这份 JSON 最后会被追加进收件箱 Markdown 文件的对应用例区块里。为什么不用数据库？因为在收集阶段，数据库的强约束反而是负担。Markdown 文件人人可读、可 diff、可手动修改，出了问题随时能救回来。数据从收集到最终归档的路径上，越早期越应该保持"松耦合"。

2. 检索环节：编辑器里的本地全文索引方案

2.1 为什么索引要放在本地而不是云端

收集到足够多的内容后，第二个问题马上浮现：存下来的东西怎么找回来？我试过直接在收件箱文件里用编辑器的全局搜索，收集量到五百条以后，搜索速度开始变得不能忍。你也肯定体会过那种感觉：明明记得存过一句话，但怎么搜关键词都搜不出来——多半是当初存的片段和现在想的关键词根本不同字。

这个阶段的正确解法是做一次本地全文索引。做这个选择之前我纠结过要不要上云，后来想明白了：知识工作者最私密的东西就是自己的阅读轨迹和笔记碎片，这些数据放云端等于把自己的思考过程交给别人保管。而且笔记检索这种场景，单机 SQLite 的全文索引速度已经绰绰有余，完全没有跨设备实时同步的刚性需求。我最终的方案是在本地维护一个 SQLite 数据库，里面只存索引不存原始文件，原始内容仍然保留在 Markdown 里，两边用文件路径和时间戳关联。

2.2 FTS5 字段映射与查询逻辑

索引库的逻辑不复杂，核心就一张表。我用的是 SQLite 自带的 FTS5 全文索引引擎，它支持中文分词的方案比较灵活，我这里没有上额外的分词器，而是采用"整条文本按字符索引 + 优化查询写法"的方式。对一千条以内的笔记规模来说，这套方案完全跑得动。

CREATE TABLE IF NOT EXISTS note_index ( id TEXT PRIMARY KEY, file_path TEXT NOT NULL, captured_at TEXT NOT NULL, title TEXT, tags TEXT, content TEXT, context TEXT, source_url TEXT ); CREATE VIRTUAL TABLE IF NOT EXISTS note_fts USING fts5( title, tags, content, context, content='note_index', content_rowid='rowid', tokenize='unicode61' );

这张虚拟表让你可以用 SQL 的 match 语法做全文检索。我实际更常用的是一个带权重的查询：标题命中权重最高，正文命中其次，上下文命中权重最低，然后按时间和权重综合排序。这样搜出来的结果才不是乱七八糟按时间倒序排列的，而是"最相关"排在最前面。

SELECT id, title, snippet(note_fts, 1, '[', ']', '...', 12) AS preview, bm25(note_fts, 1.5, 1.2, 1.0, 0.8) AS score FROM note_fts WHERE note_fts MATCH ? AND id IN (SELECT id FROM note_index) ORDER BY score ASC LIMIT 20;

这段逻辑最后被封进了编辑器里的一个插件，起名叫DocPilot。它的交互很简单：在编辑器中按下专属快捷键，弹出一个命令面板，输入关键词，展示预览和来源链接，回车后可以一键跳回原始 Markdown 文件的对应行。不需要单独开一个搜索窗口，也不用离开当前正在写的文档，它始终待在你手边。

2.3 索引同步：增量和全量之间的权衡

索引和 Markdown 文件之间的同步，我经历了三个版本的迭代。第一版是全量扫描，每次打开编辑器都重新读所有文件，内容少的时候无所谓，内容上千条以后每次都要等十几秒，彻底不能接受。第二版做了增量监听，用文件系统监听事件，只有收件箱文件变化时才去解析新追加的对应用例并插入索引库。

增量方案跑得很顺，但有一个隐蔽的坑：文件监听在某些网络磁盘和同步盘上会失效。如果你把收件箱放在网盘同步目录里，偶尔会碰到文件变了但监听事件没触发的情况，索引就悄悄落后于实际内容了。所以我在插件里保留了一个手动"重建索引"的命令，也在启动时做一次"快速校验"：对比收件箱文件最后的修改时间和索引库里的最大时间戳，不一致就自动补齐。这个兜底逻辑看起来简单，却是整套检索稳定性的关键所在。

3. AI 环节：摘要、打标与自动归档的工程化写法

3.1 摘要模型调用：不是越智能越好，而是要扛得住批量

收集和检索的路通了之后，我又很自然地产生了第三个需求：把那些长段落快速"压缩"成一句话摘要，再自动揣摩出几个标签，这样以后浏览索引的时候能更快地做判断，哪些要精读、哪些只需要看摘要就够了。

我接入了一个对话式 AI 服务的接口，写了个独立的小服务叫TLDR-Sync。技术上不复杂，就是拿到 MarkKeeper 新写入的条目，调用模型生成摘要和标签，回写进索引库。但工程上细节不少，随便拎一个出来都够写一篇避坑实录。

首先是成本控制。刚开始我把每条新信息都立刻发给模型处理，一百条信息一百次请求，一个下午代币就烧掉不少。后来改成了批量触发的策略：每积累十条信息，或者每十五分钟统一处理一次，用一条 prompt 一次喂进去，让模型批量输出。长文本用截断策略控制输入长度——超过三百字的段落只取前后各一百五十字，宁可稍微丢一些细节，也要保证 API 成本和延迟都在可控范围内。

import json import time import requests def process_batch(items: list[dict]) -> list[dict]: prompt = "请为以下信息逐条生成一句话摘要和2-4个中文标签。\n" prompt += "严格按JSON数组返回，不要输出额外内容。\n" for item in items: prompt += f"\n[{item['id']}] {item['title']}\n{item['content']}\n" resp = requests.post( "https://api.example-ai-service.com/v1/chat/completions", headers={"Authorization": "Bearer YOUR_KEY"}, json={ "model": "compact-summary-model", "messages": [{"role": "user", "content": prompt}], "temperature": 0.2, }, timeout=60, ) result = resp.json()["choices"][0]["message"]["content"] parsed = json.loads(result) return parsed

这里有个很容易翻车的细节：模型输出的 JSON 格式偶尔会不合法，尤其在摘要内容里出现换行或引号时。我的处理方式是先做一次正则兜底，把明显多余的前缀摘出来；如果还是解析失败，就把这一批退回队列，下次单独放开 temperature 重新跑。千万不要因为一次解析失败就丢掉原始数据——原始数据才是资产，摘要只是衍生品。

3.2 打标规则：先规则后模型，控制幻觉

自动打标签这件事，我一开始完全交给模型，效果其实一般。模型的标签有很强的"幻觉倾向"，特别容易给出一堆看着漂亮但根本没有检索价值的词，比如"知识""学习""方法"。这种词当标签等于没打，搜出来一百条全都带着。后来我改成"规则优先、模型兜底"的两段式方案：先用正则规则基于关键词词库打标，词库来自我之前手动整理过的所有历史标签；如果一条信息没被任何词库命中，才交给模型去猜。

这样改之后，标签的准确率提升非常明显。规则标签是确定性的，同一篇文章今天打和明天打结果完全一致；模型标签则保留一定的扩展能力，用于覆盖那些新概念、新词汇。我还给标签做了一个频度统计，每周跑一次，把连续多周没有新命中的"僵尸标签"自动降级到"候选标签"，避免词库越滚越大。

这套"AI 赋能知识工作"的姿势，我的最大体会是：AI 在流程里只负责"锦上添花"的部分——摘要和冷门标签——而所有决定信息安全和检索可靠性的部分，比如存储、索引、规则标签，都必须用确定性的传统代码来实现。把太多环节交给模型，最后模型抽一次风，你的知识库就跟着乱一次。

4. 联动环节：让各插件通过同一份索引文件协作，而不是互相乱调

4.1 一条信息的完整生命周期

到这儿我已经有了三个独立组件：浏览器端收集插件 MarkKeeper、编辑器内检索插件 DocPilot、AI 摘要服务 TLDR-Sync。很快我意识到，如果不把它们的协作关系理顺，就会陷入"工具越来越多，流程越来越乱"的困境。实际设计时我给每条信息定义了一个完整的生命周期：

第一步，MarkKeeper 在浏览器里捕获一段文字，写入收件箱 Markdown，同时向索引库插入一条状态为"待处理"的记录。第二步，TLDR-Sync 通过轮询收件箱，发现新的待处理条目，生成摘要、补充标签，更新索引库的状态为"已归档"。第三步，DocPilot 在编辑器里被唤起时，查的就是这份已经归档完毕的索引，因此用户永远看到的是完整字段，中间状态不会暴露出去。

这个流程最大的好处是：每一步都在上一个步骤的产物上工作，而不是直接去调对方的内部接口。MarkKeeper 完全不知道 TLDR-Sync 的存在，它只负责写文件和一条索引记录。TLDR-Sync 也只认收件箱文件，不去碰浏览器的任何内部状态。各自的失败和降级都不会波及其他组件。

4.2 事件模型还是轮询模型，这是一个工程决策

这里有个值得展开讲的工程决策：组件之间到底该用"事件推送"还是"轮询拉取"。我最初设计的是一件基于文件监听的事件驱动方案，MarkKeeper 写文件后，立即触发回调让 TLDR-Sync 处理。听着很优雅，实际跑起来难维护。原因在于文件监听事件本身不可靠，比如编辑器自动保存、网盘同步产生的瞬时文件写入，会让监听器同时触发多次；而且进程崩溃重启后，事件丢失，后续处理就断了。

后来我改成客户端的"启动时检查 + 定时轮询"模型。TLDR-Sync 每隔十五分钟扫一次索引库，找到所有"待处理"的条目，批量交给模型摘要，处理完更新状态。事件驱动改轮询，听起来像是技术倒退，但稳定性成倍提升。甚至是凌晨笔记本休眠之后，第二天早上醒来打开它，定时任务会立刻补跑一次，把昨晚没处理的条目全部消化掉。

{ "inbox_file": "~/notes/inbox.md", "index_db": "~/notes/.index.db", "poll_interval_minutes": 15, "batch_size": 10, "ai": { "enabled": true, "endpoint": "https://api.example-ai-service.com/v1/chat/completions", "model": "compact-summary-model", "temperature": 0.2, "max_input_chars": 300, "daily_quota": 200 }, "rules": { "tag_priority": "rule-based-first", "fallback_to_model": true, "zombie_tag_weeks": 4 } }

注意配置里的daily_quota，这是我自己加的一层保险。AI 工具有时候会磨洋工，批量处理的请求可能因为网络抖动连续失败，如果没有每日配额，它会无限重试，白白消耗代币。设置配额之后，超出部分自动跳过，留到第二天再处理，损失最多少量标签，但绝不会从根上破坏整条流水线。

5. 配置管理：插件合集的同步、锁版与重建索引

5.1 中央配置文件的层级设计

组件多起来之后，你会发现一个特别现实的问题：配置项散落在各个插件自己那三五行的设置文件里。改一个 AI 的温度参数要去翻浏览器插件的设置页，改轮询时间又要去编辑器的配置文件里翻半天。为了让 knowledge-work-plugins 真正好维护，我把所有配置收拢到一个config.json里，三个组件启动时都只读这一份配置。

配置层级的设计原则是：全局共享项放顶层，组件私有的放各自命名空间下。比如inbox_file是三个组件都要用的，放顶层；ai.temperature只有 TLDR-Sync 用，放ai子对象里；rules.zombie_tag_weeks属于打标规则，单独归到rules。这样的好处是，你一眼就能看出哪些改动会牵一发动全身，哪些改动只影响局部。我在注释里把每条配置的默认值来源和改动后果都写清楚了，防止过两个月自己都忘了某个参数是干嘛的。

5.2 版本锁与升级避坑实录

插件合集涉及到第三方库和模型接口的依赖，最怕的是"昨天还正常，今天突然不工作"。我遇到的真实案例是：某次给 AI 摘要模块升级底层 SDK 之后，模型的 prompt 格式变了，老的chat/completions接口直接把temperature=0.2给禁用了，返回了校验错误。这个错误理论上应该在集成测试里被拦住，但因为我升级后没有立刻跑批量任务，直到第二天轮询执行时报错才发现。

从此我养成了一个习惯：给整个项目加了一份"版本锁"文件，把关键的依赖版本、模型名称、API 版本全部记录下来，并且每次升级只允许一个小版本号的跳跃。升级之后的第一件事不是看仪表盘，而是手动跑一遍最小样本——拿三条真实的历史笔记走一遍收集、摘要、归档的全流程，确认没问题时再放开给批量任务使用。

# 手动触发一次完整链路自检 python tl dr-sync.py --self-check --sample 3

5.3 索引重建的三种触发条件

最后说说索引库的维护。全文索引和源文件之间本质上是"缓存关系"，缓存就免不了失效。我总结出三种必须触发重建索引的场景，写成了三个入口。

第一种是文件结构变更。如果你把收件箱从一个目录迁移到另一个目录，索引里的file_path字段全部作废，必须重建。第二种是索引库自身损坏。SQLite 在异常断电后偶尔会出现database disk image is malformed错误，这时候只能用备份恢复。第三种是规则升级。比如我调整了标签权重字段，旧索引的结构和新代码对不上，也需要重建。

重建索引的命令我做成了一键式的交互命令：它会把当前索引导出为一个 JSON 备份，然后从零开始扫描所有 Markdown 文件重新建表。在内容量不超过一万条的情况下，重建时间通常在十秒以内，完全是可以接受的运维成本。

结尾：一点关于"工具使用哲学"的体会

整套 knowledge-work-plugins 从第一版到现在，已经跑了小半年。回顾下来，最让我意外的不是某个插件本身有多好用，而是插件与插件之间的"弱连接"设计带来的稳定性红利——因为每个组件都只依赖同一份索引文件和同一份中央配置，任何一个组件单独崩溃都不会拖垮整套体系。

如果你也想搭一套自己的知识工作插件，我的建议是不要一上来就堆功能。先把你目前最痛的那个环节——通常都是收集——用一个最简单的方式打通，跑两周，再决定要不要加 AI 和联动。我在第一个版本里就是只做了浏览器选段收集和本地 Markdown 收件箱这两个功能，那时候检索靠的还是编辑器自带的搜索，虽然粗糙，但已经比"收藏了从来不看"强出很多。流程跑通了，后面的一切都是增量优化；流程没跑通，工具越多负担越重。这个顺序，比任何插件本身都重要。