企业官网建设流程全解析

知识工作者的日常，说白了就是和一堆信息搏斗：收到一篇长文、一份会议记录、一段群聊讨论、几张截图，处理完还要转成结论和文档，最后再复盘。过程中真正耗时间的往往不是“写”，而是“找”“等”“切”——在浏览器、编辑器、笔记工具之间来回切换，信息明明都在，到你真需要的那一刻却什么都抓不住。这也是我最终整理出一套名为 knowledge-work-plugins 的插件工作流的原因。它不是某一个插件，而是一组围绕“收集—整理—输出—复盘”四个环节设计的小插件集合，底层共用同一个文本工作区，上层通过配置彼此联动。这篇文章不打算做大而全的工具盘点，而是把从零搭到最终稳定运行的完整过程、选型理由、踩坑链路和最终配置模板一并写出来，适合那些每天大量处理资料、做技术调研、写方案文档、做知识梳理的朋友参考。

1. 知识工作者的手工作坊时代：为什么需要一套插件工作流

1.1 来回切换的碎片化是效率最大的敌人

知识工作者和程序员有一个明显差别：程序员的产出物是代码，代码天然有目录、模块、版本管理这些强结构；而知识工作者的产出物是文档、报告、方案、会议记录，这些东西大多是一堆半成品拼出来的。半成品散落在哪里？剪贴板、收藏夹、邮件附件、聊天记录、网盘、相册截图，甚至还有几张写满手写笔记的纸。

我观察过自己一天的工作动线，发现大量时间花在了“切换”上。从这个窗口跳到那个窗口，从手机复制到电脑，再从某篇网页里翻半天找一句话。这些动作不需要思考，但每做一次，大脑都要重新加载一遍“刚才看到哪了”的上下文。这种重新加载的损耗，心理学里叫任务切换成本，实际体验就是：一上午好像看了很多东西，下午动笔时脑子里却空空如也。

一开始我尝试用一个“大而全”的笔记工具把所有东西都装进去，结果发现这种方案更累。工具越大，规则越多，你必须先理解工具设计者的心智模型，才能在里面干活。而大多数知识工作者的真实需求其实很小：把东西存下来，将来能找到，写东西时能引用。为了这样一个基本需求去迁就一套复杂体系，成本不值。

这让我意识到，问题不在于“没有好的工具”，而在于我的工作方式本身就是手工作坊式的：每一步都要人为决策，每次切换都要人为找回状态。想要改变，不是换一个更重的工具，而是把工作流拆成固定环节，让每个环节做它最该做的事。

1.2 插件工作流的目标：把“处理资料”变成“流水线”

我想要的方案，是像流水线一样处理信息：原料进来，经过几个固定工位，变成合格品出去。这个方案不需要多聪明，只需要每个工位职责清晰，上下衔接稳定就好。这也就是 knowledge-work-plugins 的起点——它不是某个大软件，而是一系列小型插件组合，底层依赖同一个文本工作区，插件之间通过约定好的文件格式来传递数据。

做个类比可能更清楚：手工厨房里，一顿饭从洗菜、切菜到炒菜，每一步厨师都要亲自判断“下一步干什么”；而流水线把步骤固定下来，洗菜的不思考切菜，切菜的不操心跳锅。区别不是每一步更快了，而是动作之间的决策损耗被砍掉了。

plugin 工作流要消灭的，正是那些“不用思考但必须做”的动作。比如一条新素材进来，过去我需要想：这放哪？叫什么名字？要不要加个标签？现在这些动作全部由插件自动完成：统一命名、统一放收件箱目录、统一补上来源和时间戳。我只需要做那个最需要人脑判断的动作，比如“这段内容到底值不值得留”。

当然，流水线不等于死板。我的原则是：凡是“看一眼就知道怎么做”的动作交给插件，凡是“需要理解内容才能做”的判断留给人。这样既保证效率，又不至于被笨自动化绑架。

2. 选型之前先想清楚：插件的四个能力象限与管理边界

2.1 能力象限：收集、整理、输出、复盘

在开始安装任何插件之前，我先做了一件很笨但很有用的事：把自己的工作场景按信息流转画成四个阶段，然后为每个阶段定义一个输入和输出。这个框架后来成了所有插件选型的依据，也成了出问题时的定位地图。

这四象限不是凭空想出来的，而是我把自己混乱的笔记目录翻出来，按“这条笔记究竟在哪个环节产生”归类后提炼出来的。你会发现很多笔记工具里长期以来堆积的那几百条“待整理”内容，几乎全部属于第一象限的收集环节——东西进了门，却从没被消化。

有了象限图以后，选插件的逻辑就清楚了：每个插件必须属于某一个象限，不能横跨多个象限什么都做。因为一旦一个插件什么都做，你就搞不清楚数据到底被它变成了什么样，出了问题也找不到责任人。边界清晰，是插件组合能长期维护的前提。

2.2 边界原则：能少装就少装，装一个就必须明确它干什么

我最初搭建这套插件组合时，一度装到二十多个插件：这是链接预览增强、那是目录树增强、还有格式美化、同步增强。装得越多，功能越丰富，但随之而来的是配置项爆炸、右键菜单爆炸、命令面板爆炸。最难受的是插件之间会互相踩脚，两三个插件同时监听同一个文件事件，行为冲突时你根本不知道是谁干的。

后来我动手砍掉一大半，核心插件只留四五个，辅助插件控制在个位数。砍掉之后效率反而上升了。道理很简单：插件之间最好的协作关系是尽量减少协作。每多一个插件，就多一组事件监听、多一组快捷键映射、多一重配置交叉影响。少装一个插件，比优化一个插件配置更有价值。

砍插件的判断标准有两条。第一，这个功能是不是每周至少用三次？低于这个频率，就用一个模板或者一段脚本来替代。第二，这个功能是不是已经有更基础的承载方式？比如目录骨架、命名规范这种东西，用约定就能解决，不需要插件。绝大多数“增强体验”类插件，砍掉后你其实不会感觉缺了什么，只会感觉整个世界安静了。

2.3 依赖关系：底层设施与上层插件的先后顺序

选型时还有很多人容易忽略的一环：插件之间是有依赖关系的，安装顺序、启用顺序、初始化时序都会影响稳定性。我把这套插件组合分成了三层。

最底层是编辑器本身，它提供文件系统监听、命令面板、快捷键体系、终端集成这些基础设施。这一层决定了整个工作流的“地基”，所以我会优先花时间把它的基础配置打磨好，比如缩进规则、编码格式、自动保存策略。

中间层是文本解析与格式化能力，负责统一处理 Markdown 文本和元信息配置。这一层非常关键，因为上层的收集、整理、输出插件，大多要依赖它解析文件头部信息、识别标题层级、处理链接关系。如果这一层的规则不稳定，上层插件的行为就会像搭在浮沙上一样。

最上层才是具体业务插件，比如剪贴板采集、双链索引、导出模板。在安装顺序上，我的经验是先配置底层，再安装中间层，最后启用上层插件。很多奇怪的“插件坏了一半”的问题，根本不是插件本身的 bug，而是中间解析层的版本和上层插件不匹配，或者底层还没准备好某个文件目录，上层插件就已经开始扫描了。

3. 核心插件逐个拆解：功能定位与关键配置

3.1 收集类：捕获零散输入的入口

首个要解决的是收集问题。我日常工作里零散输入的来源大致有几种：网页链接、图片截图、聊天里的文字片段、以及脑子突然冒出来的想法。过去这些内容分布在不同的收容场所：浏览器收藏夹、相册、聊天记录、备忘录。现在我要求它们全部进入同一个“收件箱”目录。

为了实现这一点，我配置了一个代号为 collector 的采集插件。它的逻辑非常简单：检测到剪贴板里出现新的文本或图片时，自动弹出一个快速确认框，让我选择来源类型（网页、会议、灵感、资料），然后按固定规则生成文件名，写入收件箱目录。文件名规则如下：

2024-12-20_竞品公告_官网.md 2024-12-20_会议纪要_晨会.md

这个命名格式里依次包含日期、内容主题、来源标识。用日期开头是因为按时间排序时，最近的素材永远在最上面；带来源标识是因为将来复盘时，可以很容易看出来自哪种渠道的信息最多。

文本框我还会自动补一段 YAML 头信息，记录原始链接、捕获时间和来源类型。图片类输入的处理稍微复杂一些：截图会先做一次文字识别，把识别出的文本存在正文里，原图作为附件放在同名资源目录下。这样做的原因很朴素——文字可搜索、可复制、可引用，而一张截图里的信息是“死”的。识别不出也无所谓，原图还在，只是将来检索会困难一些。

3.2 整理类：把纯文本变成可检索结构

收集只管把东西收进来，真正让知识有价值的是整理环节。我用的代号为 organizer 的整理插件，承担两件核心事：补全标签与双链关系、定期生成索引文件。

每次我打开一个新素材文件开始阅读时，organizer 会在文件底部生成一个“后续动作”区域，里面预置三个选项：转存到项目、打标签、关联旧笔记。这个设计的初衷是倒逼自己不要“读完就放回去”。一篇文章读完如果什么都不做，它就永远是一则收件箱里的废品；但只要我花了十秒钟给它打三个标签，它未来被检索到的概率就指数上升。

标签规范我定得很死：必须使用预先约定好的标签字典，而不是临时起意造新词。比如技术调研类的标签只用“技术调研”“竞品分析”“方案评审”这几个，不允许出现“技术研究”“竞品对比”这种近义词。标签字典能保证检索的准确性——否则半年后你会发现，自己造的几十个标签里有一半语义重叠，检索系统形同虚设。

双链关联则解决“知识孤岛”问题。整理插件会扫描当前文件正文里的关键词，和已有的知识节点标题做匹配，给出可点击的双链候选。这功能并不神秘，本质就是反向索引：每次新增或修改文件后，把所有已经建立的双链关系更新一次，生成一个“谁引用了谁”的图谱。

另外，organizer 每天会更新收件箱根目录下的索引文件，把我一周内新增和修改过的素材按标签分组汇总。这个索引文件其实就是一个很普通的 Markdown 文件，好处是直接可读、可被其它工具引用，不依赖任何私有数据库。

3.3 输出类：从笔记到成稿的“最后一公里”

收集和整理做得再好，最终还是要落到一篇篇完整的输出物上。输出环节的痛点往往不是“没素材”，而是”素材明明是拼好的，写的时候还是要从头开始把结构搭一遍“。

我配置代号为 publisher 的输出插件，它做的事情是：把整理过的知识节点按模板组装成初稿。模板分三层：一是文档结构模板，比如一篇方案包括背景、现状、目标、方案、风险评估、实施计划；二是段落复用模板，比如常规的开场说明、结论页格式；三是导出前检查。

publisher 最有用的一点是”引用自动抽取“。每当我写的内容里引用了一则素材，它会把素材头部的原始链接、来源说明自动抽出来，放到文末的参考资料区。想在动笔阶段就保证引用格式规范，基本只有自动化这条路能走。人工整理引用总是会漏，特别是在改稿好几轮之后。

导出前检查更像一个质量门禁：检查标题层级是否连续、有没有超过规定长度的段落、有没有残缺链接、有没有未填写的 TODO 标记。这些检查都是非常机械的规则，但机械规则恰恰是插件最擅长，也是人最容易懈怠的。据说很多格式错误如果不拦下来，后面到交付环节再改就至少要花三倍时间。

3.4 复盘类：让插件反过来提醒你

很多人做到“输出”就结束了，但其实还有一个隐形成本极高的环节：复盘。如果不定期回头看，你根本不知道自己的时间都流向了哪里，也不知道哪些素材其实永远都不会再用到。我配置的最后一个核心插件代号为 reviewer，它做三件事：统计、提醒、清理。

统计很好理解：它会统计过去一周新建了多少素材、修改了多少文件、哪些标签使用频率最高。我每周看一次这个统计，就能清晰地发现，本周有三天时间全在收集竞品信息，而真正花在“形成结论”上的输出动作几乎没有。比起自觉，这种拿数据说话的方式更不容易骗自己。

提醒功能则是把长期不用的素材暴露出来。比如某条素材已经在收件箱里躺了三十天而从未被任何文章引用，reviewer 会给它标记一个“待清理”状态。这类素材要么立刻消费它，要么归档到“冷冻区”，不占据日常检索的流量。

清理功能是自动删除孤儿的必要安全阀：那些既没有标签、没有双链、也没有被任何索引文件引用，且创建超过九十天的素材，reviewer 会先列出清单，等我确认后再丢进回收站。自动清理听起来很危险，但这是防止整个知识库膨胀失效的最后防线。

4. 串联成一条工作流：从零散输入到结构化输出的完整过程

4.1 一次典型任务的全链路演示

说再多抽象概念，不如完整跑一遍流程。就拿“整理一份竞品调研报告”这个最常见的场景举例。

第一步是收集。我收到一条竞品发布的公告链接，复制到剪贴板。collector 立刻识别出这是网页链接，弹框问我是“网页”还是“灵感”，我选择网页。抢在“读取链接正文”这一步，插件自动抓取文章主体内容，存成带原始链接的素材文件：2024-12-20_竞品公告_官网.md，全部动作不到五秒，我不需要先想好它该存在哪个文件夹。

第二步是整理。我打开刚生成的素材文件，把文章读完一遍。遇到关键数据，比如价格调整、新功能上线时间，我直接在原文上加了这样的标记：[待引用]和几个标签。organizer 在文件保存后自动更新双链索引，如果我发现之前写过一篇与之相关的笔记，会在文件底部快捷建立一条反向链接。到这里，这条素材已经从“死的资料”变成了“可被检索的结构化节点”。

第三步是输出。我新建一个“竞品调研_十二月”索引文件，把本周积累的几条竞品素材链接汇总进去，按功能点排布。publisher 根据我选定的方案模板生成初稿：背景段落、竞品现状、对比表格、初步建议。初稿里每个结论后面都带着引用链接，因为引用是素材头部自动带的。

第四步是复盘。报告输出后并不是结束。reviewer 在本周末的统计里显示，本周新建素材里“竞品信息”类占比过高，而“方案结论”类产出偏低。我在这条统计的提醒下，把下周的安排向“输出结论”倾斜，而不是继续无边际地收集竞品信息。整个闭环到这里才算真正跑完。

4.2 模板与快捷键是串联工作的“胶水”

插件之间要顺畅接力，光靠插件本身还不够，还需要两样胶水：模板和快捷键。模板负责统一每个环节的产出格式，快捷键负责降低发起动作的门槛。

我给自己定下的核心快捷键映射如下：

• Ctrl+Shift+N：新建一条素材，直接打开发布器模板（用于灵感速记）
• Ctrl+Shift+O：随机打开一条收件箱里的旧素材（用于清理积压）
• Ctrl+Shift+L：在选中文本上方插入标签补全菜单
• Ctrl+Shift+P：调用输出插件，把当前文件按模板渲染成成稿草稿
• Ctrl+Shift+R：运行复盘统计脚本

这些快捷键未必适合所有人，但关键是：每一个高频动作都要有肌肉记忆级别的入口。如果一个操作你需要去菜单里找，那这个工作流大概率只是你收藏夹里的摆设，一个月后用两次就闲置了。

模板方面，我维护了一套“素材头部”模板，所有插件都强制读取这段头部。模板字段包括 id、date、source、type、tags、status。id 是全局唯一标识；source 记录原始来源；type 区分“全文、摘录、灵感、会议纪要”等类型；tags 使用标签字典；status 标记“待整理、已整理、已引用、需清理”。这套头部的好处是，任何插件只要识别这个结构，就能稳定对接上下游。

4.3 各环节的交接点：数据格式要做收敛

插件多了以后，最容易翻车的就是环节之间的数据格式不统一。我见过一个很典型的场景：收集阶段存进去的文件是纯文本，整理阶段解析的时候却按 Markdown 语法去扫描标题，结果所有一级标题全没被识别，双链索引整个失效。问题根源不在插件，而在于交接点没有约定好格式。

所以 design 原则里有一条非常重要——所有环节交接的数据格式必须收敛到同一种：Markdown 正文加 YAML 头部。我不允许某个插件私自定义一种只在它内部使用的数据结构。任何一个人用文本编辑器打开我的素材文件，都能看懂内容；任何一个小脚本读这个文件，都知道去头部解析元信息。

格式收敛之后，插件之间的协作变得出奇简单。collector 写入的是 YAML 头部加正文；organizer 只读头部和正文里的标签标记；publisher 只认头部里的引用字段与正文段落结构；reviewer 也只需要扫描头部状态变化。各环节不共享任何数据库、不依赖任何内存状态，唯一的真相就是文件系统里的那些文本文件。

这带来的额外好处是可迁移性极强。哪怕有一天我彻底不用这些插件了，留在地上的仍然是一堆结构清晰的 Markdown 文件，随便找个文本工具就能继续用。知识资产永远不会被绑定在某个工具的私有格式里。

5. 实测中绕不开的三类问题与完整排查链路

搭这套插件工作流的过程中，我踩过的坑不算少。这里挑三类最具代表性的问题，把完整排查链路写出来，希望你能少走弯路。

5.1 症状一：两个插件同时处理同名文件导致写入互相覆盖

有一次我在编辑一份长方案时，发现一个诡异现象：每次保存文件，过几秒再看，文件内容里有一部分被回退成了旧版本，有时候保存目录里还会冒出名称相近的.tmp文件。

一开始我以为是编辑器本身的自动保存设置有问题，于是先关闭了自动保存功能，但问题依旧。这时我意识到不是编辑器的事，而是某个插件在保存后对文件做了二次处理。排查链路是这样的：

1. 打开编辑器的任务管理面板，观察保存一瞬间有哪些插件在后台活动。
2. 逐个禁用可疑插件，每禁用一次就做一次“修改加保存”的操作，观察问题是否复现。
3. 最后定位到两个插件都在监听“文件保存后”事件：collector 发现当前文件属于收件箱目录，会自动把它移动到更精确的分类目录；而 organizer 还需要读取原路径下的文件内容做索引更新。两边一前一后执行，collector 已经把文件挪走了，organizer 还按旧路径去读，读出来的自然是被覆盖前的旧缓存内容。

解决方式是把文件处理顺序改成“收集入箱”优先，而“分类移动”延迟到文件关闭时再做。同时，给两个插件增加共享的事件队列，保证同一时刻只有一个插件对同一文件进行写操作。这类问题在插件组合里非常典型，单看任何一个插件的行为都正常，放在一起就互相拉扯。

5.2 症状二：配置同步后部分插件静默失效

因为我在多台设备上办公，配置文件需要定期同步。某一次同步之后，设备 A 上一切正常，设备 B 上却出现了“收集插件还在，但整理插件完全不工作了”的怪状。

这类问题最讨厌的地方在于没有报错弹窗，插件像睡着了一样。我的排查步骤：

1. 打开插件初始化日志，发现整理插件启动时报了“路径不存在”警告。
2. 检查配置文件，发现里面的收件箱路径仍然指向设备 A 的磁盘路径，设备 B 上这个路径位置完全不同。
3. 修正路径后，整理插件的行为还是不完整——此时我意识到可能还有一层缓存索引没刷新。整理插件内部保留了一个“已扫描文件列表”的缓存文件，同步过来的缓存内容里全是设备 A 的文件列表，设备 B 上的新文件不会被收录。
4. 删除缓存目录，重新构建索引，问题彻底解决。

这件事给我的教训是：任何插件组合的配置文件同步之后，都必须跑一次健康检查。后来我把这个动作脚本化：同步完成后自动核验关键目录是否存在、插件版本是否一致、缓存是否为当前机器生成，然后输出一份状态报告。把这种容易遗忘的检查变成自动化流程以后，跨设备切换就稳多了。

5.3 症状三：启动速度从 1 秒变成 6 秒，怎么定位

随着收件箱里的素材越来越多，工作区启动速度肉眼可见地变慢。最明显的一次，打开编辑器要等六秒才变成可操作状态，这个等待体验几乎让人想放弃整套插件方案。

定位这类性能问题，我的做法是二分排查法。先打开启动日志，看每个插件的初始化耗时，通常你会看到某个插件的耗时高出其他插件一个数量级。如果日志不够详细，就手动把插件启用列表砍掉一半，测一次启动速度；如果变快了，问题一定在被禁用的那一半里；如果还慢，再砍另一半。这样最多两轮就能把嫌疑插件揪出来。

我遇到的具体问题是整理插件在启动时做了一次“全量目录扫描”：把所有历史素材都读了一遍，用来刷新索引。素材越多，扫描越久。这个问题最后通过三招解决：第一，把扫描范围从“全目录”缩小到“近三十天新增和修改的文件”；第二，大文件目录加入忽略清单；第三，全量扫描从启动时改为手动触发，一周跑一次足够。优化之后启动速度回到两秒以内，而索引刷新该有的效果一点没少。

这类问题的本质是，插件作者默认你的数据量是有限的，而真实工作半年后，素材量可能比作者预想的大一个数量级。遇到性能退化时，不要第一反应是换机器，先考虑是不是启动时干了不必要的重活。

6. 一套可以直接抄作业的配置文件模板（最终版）

6.1 总体目录结构与核心配置

经历多轮删改之后，我最终稳定下来的目录结构长这样：

. ├── config │ ├── core.settings.json │ ├── hotkeys.json │ └── plugins │ ├── collector.entry.json │ ├── organizer.rule.json │ ├── publisher.tpl.json │ └── reviewer.policy.json ├── inbox ├── projects ├── archive └── scripts └── healthcheck.sh

inbox是收集阶段的落盘位置，所有新素材先到这里；projects存放正在推进的实际项目文档，每个项目一个子目录；archive是冷冻区，存放已经完成或长期不会用到的内容。这套三桶结构简单粗暴，但足够覆盖绝大多数知识工作场景。

核心配置文件里我最看重的是插件执行的次序配置。下面以整理插件的规则文件为例：

{ "pluginsOrder": [ "collector", "organizer", "publisher", "reviewer" ], "organizer": { "scanIntervalMinutes": 60, "scanDirs": ["inbox", "projects"], "ignoreDirs": [".git", "node_modules", ".cache"], "cachePath": ".cache/organizer-index.json", "tagDictionaryPath": "config/tag.dict.txt", "expireDays": 30, "fullScan": "manual" } }

scanIntervalMinutes表示增量扫描周期，设置 60 分钟足够；fullScan设置为manual表示全量索引需要手动触发，避免启动时拖慢整个工作区。这条配置是我从性能问题里学到的宝贵经验。

再看 hotkeys.json 的片段：

{ "commands": [ { "key": "ctrl+shift+n", "command": "knowledgeWork.newEntry" }, { "key": "ctrl+shift+o", "command": "knowledgeWork.openRandomInbox" }, { "key": "ctrl+shift+l", "command": "knowledgeWork.addTag" }, { "key": "ctrl+shift+p", "command": "knowledgeWork.publishDocument" }, { "key": "ctrl+shift+r", "command": "knowledgeWork.runReview" } ] }

我个人的习惯是把常用核心动作的快捷键都集中在一份配置文件里，而不是散落在各个插件各自的配置项里。这样万一快捷键冲突，只需要检查一个文件就可以。长期维护这类配置，你会发现“集中优于分散”是一条重要规律。

6.2 我的经验参数与“如果重新做一遍”的取舍

有不少参数是我试错试出来的，这里直接给推荐值，并简单说明理由。

• 文件名日期格式采用YYYY-MM-DD而非YYYYMMDD，因为带连字符的格式在按文件名字典排序时和实际时间顺序一致，也更易读。
• 收件箱目录的“待清理”期限设为三十天，短于三十天容易误杀还在消化中的素材，长于九十天则会导致积压感太强。
• 全量索引频率建议一周一次，放在周末复盘时手动执行。如果数据量超过五千条，增量扫描的周期也可以从 60 分钟降到 180 分钟，减少无谓的磁盘扫描。
• 标签数量控制在 200 个以内，超出后就合并同类项。标签不是收藏夹，它的目的是让你能稳定检索，而不是记录你所有好奇心的边界。

如果重新做一遍，我会特别注意一点：最早不要一上来就追求自动化比例，先手动跑两个星期。先手动执行每个环节，感受哪些动作重复了三五遍以上，再决定哪个动作要交给插件。很多读者拿到我的配置文件后兴冲冲装上，结果发现自己平时的输入习惯跟我差异很大，插件组合自然用不起来。方案本身没有错，错在没有先建立自己的基线流程。

7. 最后再聊几点个人体会

回头看这套 knowledge-work-plugins，我觉得它帮到我的不是“换了更好用的工具”，而是逼着我把整个知识处理流程从“藏在脑子里、随缘执行”变成了“写在明处、有节奏推进”。搭这套东西之前，我收藏了无数好东西，但真正用上的没多少；搭好之后，每条素材从进收件箱到被引用、再到归档或清理，都有明确去处，知识库不再是一口越积越深的死井。

我个人体会最深的一条经验是：每个插件都值得做一次“启用两周后有没有实际改变行为”的拷问。如果两周下来，你发现某个插件只是让你感觉设备更强大了，但它从未真正改变你任何一个工作步骤，就把它关掉。真正有用的插件会让你改变操作习惯，而不仅仅是在界面上多一个图标。

另外一个建议是留着那个健康检查脚本。高效工作流是很容易“悄悄坏掉”的，某天你会发现某个环节已经停止工作两周了，而你一直靠手动补救。把健康检查固化成一个命令，每次同步配置或更新插件之后跑一遍，能省下很多查问题的时间。

如果你正在搭自己的知识工作插件组合，可以从“收集—整理—输出—复盘”这个框架着手。先不用管我具体用了哪些插件，先从自己的实际工作流里划出这四个环节，再为每个环节找最顺手的一个工具。测试的时候尽量用一份真实任务去跑，不要拿“新建文档打个字”这种玩具测试来衡量效果。跑通一轮完整的真实任务之后，你自然会知道哪些环节最痛、哪个插件最该优先打磨。工具永远是配角，真正的主角是你那个形成闭环的工作习惯。