1. 为什么要给知识工作单独做一套插件我做过一个内部项目名字就叫 knowledge-work-plugins。它不 fancy说穿了就是一组插件把平时散落在浏览器、文档、聊天记录和脑子里的信息统一收进一个可以检索、可以复用、可以输出的工作台。做之前我以为最大的困难是技术选型真正做完后才发现最难的是想清楚一个问题知识工作到底需要什么而不是工具能做什么。知识工作者和程序员的差别在于程序员的产出是代码知识的产出是判断、方案和内容。代码能通过测试驱动去验证而知识工作的验证周期往往很长可能一次项目复盘后才知道当初记录够不够。偏偏很多人的知识管理方式是收藏了一堆文章、截图、会议纪要到了真正要用的时候却翻不出来。原因很简单收藏是零成本的检索是高成本的而大多数工具只解决了前半段。knowledge-work-plugins 的出发点也很朴素把“采集、处理、检索、输出”整条链路打通让知识从一个静态的“囤积物”变成一个动态的“工作流”。它不是某一个笔记软件的替代品也不绑定特定平台而是以插件的形式嵌入现有环境在必要的地方补上缺失的环节。这篇文章不会讲太多概念更多是把我做这套插件时的设计思路、踩过的坑、以及实际使用中的配置流程分享出来。代码量不会很大但背后的取舍值得聊。1.1 知识工作的真实痛点我在不同团队里观察过知识工作者的日常工作流大多长这样早上收邮件聊天工具里蹦出来几条链接浏览器开着一堆标签页有的是一篇技术博客有的是一份竞品资料还有的是某个用户反馈截图。然后开始写方案写到一半想引用某篇文章里的一个观点结果忘了收藏在哪只能重新去搜索。好不容易找到又发现当时收藏时只存了链接现在已经失效了。这个场景不是个例。知识工作的痛点从来不是“缺工具”而是“工具各自为政”。笔记软件管文字浏览器管网页文档系统管正式文件聊天记录管碎片信息。每样东西都有归处但归处之间没有通道。结果就是信息被切成了碎片记忆被切成了标签知识被切成了收藏夹。还有一层隐性痛点就是记录时的“格式负担”。我见过不少人因为觉得笔记软件里的模板太复杂、双链要理解概念、标签要设计层级索性放弃记录。知识管理要是变成一件需要额外学习成本的事绝大多数人是坚持不下去的。所以插件的第一原则应该是进入成本足够低使用时不打断当前思路。1.2 插件应该解决的和不该解决的动手写插件之前我给自己定了几条边界这里直接说清楚能帮后来人省不少弯路。第一插件只解决“输入到输出之间的连接问题”不解决“存储载体的替换问题”。比如我把采集的网页正文统一转成 Markdown 文件放进某个本地目录而不是发明一个新的数据库格式。存储载体越通用数据越安全迁移越简单。第二插件不做大而全的编辑器。知识工作的核心动作是“记录、组织、检索、输出”不是排版不是做PPT也不是做项目管理。所以编辑器能力交给成熟工具我只需要提供快捷键和模板尽量做到“随手一按内容就进去了”。第三不强制改变用户原有的工作习惯。比如有人习惯用标签有人习惯用目录有人习惯用全文搜索。插件要做的是兼容这些模式而不是规定一种理想模式。兼容的意义在于知识工作本身是高度个人化的不适合用统一流程去约束。当然不该解决的也包括哪些比如实时协作、权限管理、审计日志这些是公司级系统的范畴不应该是个人插件的负担。边界划清楚之后开发量立刻小了很多真正需要花心思的反而是那些看起来不起眼但每天都要用的小功能。1.3 核心目标从记录到复用的闭环如果只用一个词描述这套插件的作用我会选“闭环”。知识管理最怕的是断层采集了不处理处理了不检索检索了不输出。每断一层前面做的动作就接近白费。闭环的第一步是采集把外部信息集中到一个收件箱目录不分类、不打标签纯粹先收下来。第二步是处理给每条内容补充上下文比如来源链接、捕获时间、相关项目、当时的想法。第三步是检索通过全文搜索、标签过滤、语义相似度把知识捞出来。第四步是输出从检索结果直接生成文档草稿、周报素材或会议纪要。这四步在 knowledge-work-plugins 里分别对应四个插件模块收件箱插件、元数据清理插件、检索增强插件、模板导出插件。模块之间通过文件系统和配置文件通信没有复杂的服务依赖。这样做的好处是任何一个模块坏了都不影响其他模块而且自己可以单独替换。我特别想强调“输出”这一步。很多知识管理方案只做到检索就停了好像找到了就万事大吉。但实际上检索到只是中间态最终的价值要体现在某个产出里。所以插件里专门做了一个“引用板”的功能检索到一条资料按一下快捷键它能以标准引用的形式插入当前文档并自动附带来源和日期。这个小功能看起来不起眼却是整个闭环里最提升幸福感的部分。2. 整体设计与模块划分这套插件在设计时参考了知识工作里常见的信息流模型输入、处理、检索、输出。整个架构也是按照这个模型拆的没有为了微服务而微服务也没有把功能堆到同一个脚本里。下面把每个模块的设计思路和核心接口讲清楚。2.1 采集层收件箱与自动清理采集层解决的第一件事是怎么用最小成本把内容搬进来。我做的第一个采集插件是浏览器扩展把当前页面的正文提取出来转成 Markdown存到本地收件箱目录。之所以选择浏览器扩展而不是直接把内容复制到剪贴板是因为网页正文提取过程中可以去掉导航、广告、侧边栏这些噪音保留标题、作者、发布时间这些关键元数据。采集层还有一个容易忽略的问题重复内容。同一个网页第一次读完收藏了过了两周再打开又会触发一次采集。所以收件箱插件在写入前会计算内容的哈希值如果已经存在同一条记录就只更新访问时间不新增文件。这样处理过后收件箱里的内容虽然多但不会出现明显的重复堆积。采集层的第三个设计是“暂存区”。有些内容不适合立刻处理比如一篇长文、一段视频稿、一份PDF报告。采集进来之后先放在inbox/pending目录等有空的时候统一处理。暂存区不是垃圾场它有一条定期提醒的规则超过 7 天未处理的内容会在状态栏给出提示避免收件箱越积越多。2.2 处理层元数据补充与标准化处理层的核心任务是把原始采集内容变成“可以被检索、被引用、被理解”的知识单元。标准化的第一步是文件名。我在插件里定义了一套规则YYYYMMDD_HHmm_来源_标题.md。文件名里带上时间和来源排序的时候天然就有一条时间线不需要额外维护索引。第二步是元数据头。每个 Markdown 文件的开头都会生成一段 YAML 格式的元数据包含标题、作者、来源链接、采集时间、标签、关联项目。这样写是为了后续检索时不用全文扫描只读取头部信息就能做列表展示。如果采集来源本身提供了 Meta 信息插件会尽量填完整如果没有就留空让用户在处理时补充。第三步是给内容做“净化”。网页转出来的 Markdown 往往有残留的代码块、重复段落、无意义的分隔符处理层会在写入时做一轮清理。清理规则我用的是白名单机制只保留段落、标题、列表、引用、图片、代码块这几类结构其他元素一律丢弃。白名单机制的好处是可控不会因为某次网页结构特殊而把正文误删。2.3 检索层全文、标签与语义线索检索层是我花时间最多的地方。因为采集和处理做得再好如果不好找整个系统还是等于零。检索层用了三层机制第一层是全文搜索。基于文件名和正文内容做关键词匹配速度快适合确定性的搜索场景比如我知道里面包含某个专有名词。这个机制不依赖任何外部服务离线环境下也能用。第二层是标签与属性过滤。通过元数据里的标签、来源、时间范围、项目标记做结构化筛选。比如我想找“2024年关于某客户的需求文档”只要过滤项目标签和时间范围结果很快就能出来。第三层是语义线索。为了避免“知道大概是什么但记不清关键词”的情况我给插件接了一个本地语义索引模块。它不需要云端接口只在本机把文本切块后生成向量再计算相似度。实测下来用“用户不喜欢复杂的配置流程”这种描述句也能检索到相关文档比纯粹依赖关键词的体验好很多。检索结果统一在搜索结果面板里展示点击某条结果会打开对应文件并且高亮匹配位置。这里的交互原则很简单减少跳转次数。从输入关键词到看到内容最多两次点击不能再多。2.4 输出层模板、引用与一键成稿输出层是很多知识管理方案忽视的部分但在我看来它是“从积累到价值”的临门一脚。我做得最顺手的是一个“快速成稿”插件用户选择一个文件夹输入主题插件自动扫描该目录下最近三个月内的笔记按照时间顺序和标签权重生成一份大纲再根据模板填充成文档草稿。这里的模板不是简单的字符串替换而是支持变量插值和条件区块。比如周报模板里可以写# 本周进展 {{#entries}} - {{date}} | {{project}} | {{summary}} {{/entries}} # 下周计划 {{#if plans}} {{plans}} {{else}} 待补充 {{/if}}模板处理器在渲染时会执行简单的逻辑判断把传入的数据对应填充进去。这样做的价值在于知识库里投入了时间和思考的笔记不会只躺在文件夹里睡觉而是能按需变成周报、月报、项目复盘、会议纪要甚至是文章初稿。输出层还做了一个“引用板”功能类似于临时收藏夹。用户在阅读笔记时按Alt1把当前文件加入引用板写完当前文档后按Alt2把所有引用板内容按统一格式一次性插入到文末。这个操作避开了“复制、粘贴、改格式”的机械劳动是我日常使用频率最高的功能。3. 核心能力的实现细节前面讲的是模块划分这一部分说说具体实现。我把每个模块里比较关键的技术点拆出来讲清楚为什么这么做以及做的时候要注意什么。3.1 文本提取与标准化网页正文提取是采集层的第一个技术难点。最初的版本我用正则表达式去抓article、main、content这些标签结果发现很多页面不按标准结构来导致提取结果经常缺头少尾。后来换了一种思路先用某个通用解析库把 HTML 转成 DOM再用文本密度算法来识别正文区域。简单说一下文本密度算法的直觉正文区域通常有较长的连续文本且段落分布均匀而导航、广告、版权信息这些区域要么文本很短要么夹杂超链接。计算每个候选区域的文字长度和链接密度取综合得分最高的区域作为正文再经过清理效果比固定规则好很多。还有一个容易出问题的地方是编码。现在大部分页面是 UTF-8但偶尔会遇到 GBK 编码的旧站点。插件在提取后会做编码探测如果发现中文乱码会自动用备选编码重新解码。这个细节很不起眼但能省掉很多“看起来像乱码实际是编码没识别”的烦恼。提取完成后的标准化统一输出为 Markdown。标题层级做降级处理原页面的 H1 变成#H2 变成##避免一篇文档里出现多个一级标题。图片地址如果是相对路径会拼上当前页面的域名防止图片丢失。3.2 语义索引与本地优先语义索引模块是这套插件里最“重”的一部分也是本地优先原则执行得最彻底的一部分。很多同类工具会把文本发送到云端做向量化虽然方便但我不太愿意让私人笔记过一道外部服务。所以我在实现时采用了本地嵌入模型输入是文本块输出是固定维度的向量整个过程不离开本机。具体流程是当处理层完成一篇笔记的标准化后插件会把正文切成若干文本块每块大约 512 个字符相邻块之间有适度重叠以保证边界处的语义不丢失。切完之后每个块生成一个向量连同原文标识一起存入本地向量数据库。检索时用户输入的查询文本也走同样的模型生成查询向量然后用余弦相似度排序返回最相近的若干个文本块。本地模型也有代价就是首次启动时加载较慢大约需要几秒。我的处理方式是在软件启动时做一次预加载等用户真正用到检索功能时模型已经在内存里了。另外笔记文件是持续增长的索引不可能每次全量重建所以插件监听文件目录新增或修改时只对增量部分做向量化这样能保持索引始终同步。3.3 模板引擎与快速插入模板引擎不算新鲜东西但我在设计时特意加了一个约束模板必须保持“所见即所得”。什么意思呢用户打开一个模板文件看到的应该是一份带占位符的 Markdown 文档而不是一段需要理解的程序代码。为了做到这一点模板语法尽量贴近自然语言。条件部分使用{{#if}}和{{/if}}循环部分使用{{#entries}}阅读起来和文档结构一致。渲染时模板引擎按行解析遇到控制标记就执行对应的逻辑遇到普通行就原样输出。快速插入功能也依赖模板。比如开会时随手记了几个要点按下快捷键后插件会自动把这些要点整理成“会议信息 决议 待办事项”三段式模板。整理的动作不涉及人工智能就是简单的正则匹配含“待办”“TODO”“下一步”的行直接归类到待办区含“决定”“确认”“结论”的行归类到决议区其余内容保留在信息区。这个方案简单但效果出乎意料地好因为会议纪要的核心本来就是这三类信息。3.4 快捷键与自动化联动知识工作插件如果只靠鼠标点来点去效率会大打折扣。快捷键设计上我给核心动作分配了全局快捷键保证在任意软件里都能触发。采集动作默认是AltShiftA临时引用是AltShiftQ打开收件箱是AltShiftI快速搜索是AltShiftF。快捷键的数量控制在五个以内超过五个人就记不住了。更复杂的功能不配快捷键而是通过命令面板输入名称搜索执行。命令面板的体验可以类比为“一个能记住所有操作入口的搜索框”输入关键词就能找到对应命令降低记忆成本。自动化联动的部分更实际。我做了两个触发规则第一个是每周五下午自动生成当周的笔记清单和未处理收件箱数第二个是当系统检测到某个项目目录里的文件数量超过一百个时自动提醒是否需要归档整理。这些都是轻量级脚本在后台跑不占资源但能让知识库长期保持在一个整洁的状态。4. 安装配置与常见坑再好的设计安装和配置体验翻车也会劝退人。这一部分把安装步骤、关键配置项和常见问题整理成一份偏实战的参考方便照着做。4.1 环境要求与安装顺序先说明环境要求。这套插件跑在主流桌面操作系统上需要本机装有某个可扩展的编辑器我开发时用的是通用编辑器体系以及运行时环境。安装顺序有讲究不要跳跃。第一步安装运行时环境确认版本符合插件要求。第二步安装编辑器本体并开启扩展模式。第三步通过扩展市场搜索 knowledge-work-plugins一键安装插件包。第四步安装外部依赖包括文本提取解析器、Markdown 处理工具和一个本地向量数据库。第五步重启编辑器让插件加载依赖。我在安装阶段踩过最大的坑就是依赖版本不一致。比如某个语义索引库需要特定版本的解释器但系统里装的是另一个版本插件加载时直接报错。后来我在插件启动脚本里加了前置校验检测到环境不对先给出提示而不是等运行到一半才崩溃。这个体验改进很直接能让使用者省掉大量排查时间。另外尽量使用统一版本。插件包会锁定主依赖但传递依赖偶尔会冲突。所以我在文档里强烈建议先建一个独立的虚拟目录所有依赖都装在这个目录里不和系统全局环境混在一起。目录隔离后升级插件或者做测试都不会影响日常使用的环境。4.2 关键配置项解析安装完成后第一次启动会生成一个配置文件里面有几项需要根据个人习惯调整我挑重要的说明。第一项是inbox_dir收件箱目录。默认指向用户目录下的Documents/Knowledge/inbox可以改成任意路径。要注意的是路径里尽量不要有空格因为某些命令行工具在解析带空格的路径时会产生歧义。我用的是全小写加下划线命名兼容性最好。第二项是tag_scheme标签体系。这里有两种风格扁平标签和层级标签。扁平标签就是前端、后端、项目X层级标签类似于工作/某项目/需求。插件支持配置分隔符默认是/。就个人经验来说标签层级不要超过三层否则维护成本会迅速上升。第三项是semantic_threshold语义检索的匹配阈值。默认值是 0.75表示只有相似度大于 0.75 的文本块才会出现在结果里。如果检索结果太少降低到 0.6如果相关性太差提高阈值。这个参数不好一次调对建议用一周的真实检索记录来逐步校准。第四项是auto_clean自动清理开关。打开后收件箱中超过设定天数的待处理文件会收到提醒。我建议不要设置太久7 到 14 天是合理范围超过 30 天大概率说明采集的内容已经过期了。4.3 数据存储、备份与迁移这套插件的数据存储设计从一开始就考虑了可迁移性。笔记文件是纯文本 Markdown存放目录可以整体拷贝到另一台电脑索引数据是本地向量数据库导出后也能重建。不要低估这一个决策的重要性大多数笔记工具把数据存在私有格式里真要换工具的时候才发现这些年积累的内容带不走。备份策略我采用三层。第一层是日常同步将知识库目录实时同步到一个私有网盘或本地移动硬盘。第二层是每日定时备份由插件生成带日期的压缩包保留最近七天。第三层是季度快照在项目节点或阶段复盘时手动打一次快照保留长期版本。迁移时有一件事容易遗漏就是外链。笔记里如果引用的是绝对路径换电脑后路径会失效。我的处理方式是尽量使用相对路径并且在采集时把网页链接保留在元数据里需要时一键打开原始网页。这样即使本地文件结构变了原始出处还找得到。4.4 常见问题速查表这一节把我在使用过程中碰到的高频问题整理成表格方便排查。现象可能原因处理办法浏览器扩展采集失败网页使用了严格的动态渲染静态提取拿不到正文先用浏览器阅读模式打开再触发采集检索结果为空语义模型尚未加载完成或阈值设置过高等待预加载结束检查阈值并适当降低到 0.6导入内容出现乱码页面编码识别失败源站点为旧编码手动指定编码再执行“重新提取”命令快捷键无响应全局快捷键被其他软件占用在快捷键设置界面查看冲突换一组组合键模板渲染后内容为空模板里的条件变量名与传入数据不一致检查{{#if}}对应的字段是否存在于数据源索引文件过大文本切分粒度过密向量数据膨胀增大切分块长度清理三个月以上的临时索引片段这六类问题覆盖了大多数日常故障。如果还有疑问先把日志级别调到debug复现一次操作然后查看插件日志。日志文件会记录每一步调用的接口和耗时基本能定位到是哪个环节出了问题。5. 实际场景中的操作流程配置和原理讲完来看在实际工作中怎么用。我按两个最常见的场景来说一个是个人知识库的从零搭建另一个是团队协作时的注意点。5.1 个人知识库从零搭建流程假设你是一个知识工作者想用这套插件整理自己的资料完整流程如下。第一步规划目录结构。目录不是越深越好我建议控制在三级以内。顶层分为inbox收件箱、daily日记与日志、projects项目资料、reference长期参考资料。顶层目录稳定后不要轻易改动否则很多元数据里的路径会失联。第二步配置采集入口。先安装浏览器扩展登录常用站点后测试采集效果。测试时选择三种不同类型的网页一篇长文、一个带较多代码的页面、一个内容很短的产品页。确认三种类型都能正确提取收件箱文件正常生成。第三步制定最小处理流程。每天傍晚花 15 分钟处理收件箱有价值的移动到projects或reference目录补全标签和关联项目没有价值的直接删除。处理流程要固定下来才能形成习惯。第四步建立搜索入口。把常用检索命令设置成全局快捷键日常写作时遇到不确定的内容随手搜索不再单独去浏览器找。语义检索会用一段时间收集相似内容前期的效果可能不如关键词精确但一周后你就会感受到它的价值。第五步生成输出模板。针对自己的工作内容准备三个模板周报、会议纪要、项目复盘。模板里写好引用板的插入位置这样每周五写周报时笔记素材能直接流入文档不用重新回忆。5.2 团队协作场景下的注意事项个人使用和团队使用是两回事尤其是知识库的共享与术语统一。如果你的团队也想用这套插件有几个前置工作要做。第一统一标签基线。团队里每个人都有自己的标签习惯A 喜欢用“需求”B 喜欢用“用户需求”检索时就容易出现漏查。建议先由一个人维护基础标签表包含项目名、岗位、常用文档类型这几个核心维度然后大家共用一份标签配置文件。这个文件放在项目仓库里插件每次同步时拉取最新的版本。第二明确团队知识库的边界。不是所有内容都适合进共享库比如个人思考、局部草稿、临时截图应该留在个人收件箱里。团队库只放有复用价值的正式内容比如调研报告、方案定稿、复盘记录。边界不清会导致共享库信息噪音过大检索时反而找不到重点。第三注意敏感信息。知识库插件本身是本地优先的如果配置了共享目录或云同步就要仔细审查内容中是否包含不可外传的字段。我的建议是在采集后增加一个“敏感内容检查”步骤插件会自动匹配常见的敏感词模式发现后高亮提醒由用户决定是否继续共享。5.3 插件化前后的效率变化我做了一个简单的对比测试用两周时间记录同一类任务在“纯手动整理”和“插件辅助整理”下的耗时差异。纯手动场景下采集一篇网页需要打开笔记、新建文档、复制标题和链接、粘贴正文、手动整理格式平均耗时 6 分钟左右。插件辅助场景下从浏览器点击采集到收件箱文件生成耗时约 10 秒后续处理再花 2 分钟补标签和位置。整体节省了约一半时间。检索方面差异更明显。手动模式下从几十个收藏夹里找一份旧方案平均耗时 8 分钟插件模式下用关键词或语义检索平均耗时 30 秒。最惊喜的不是耗时缩短而是那些“我以为自己没记过”的内容其实都在知识库里只是以前检索不出来。输出方面的对比也很直观。过去写周报要翻看聊天记录、邮件、笔记拼凑出本周做了什么事耗时 40 到 60 分钟。用上插件后每周五的周报生成流程变成打开周报模板插入引用板内容花 10 分钟调整措辞完成。这带来的不只是效率提升更是周末前少了一项抵触心理负担。6. 扩展与收敛插件做久了往往会陷入“什么功能都想加”的冲动。这一节聊两句哪些方向值得扩展哪些功能应该收敛。6.1 与常见工具的集成思路集成不应该以“替换”为目标而应该以“补齐”为目标。比如你已经有一套成熟的文档系统就不需要插件再造一套更多是打通文件导入导出、链接跳转、标签同步这几件事。我在插件里做了一层适配器通过配置文件声明外部工具的命令行入口实现“从插件发起操作在实际工具中落地”的效果。举几个实际集成的例子。邮件客户端里的重要内容可以一键转发到收件箱由插件的邮件解析模块转换成笔记。聊天工具的群组讨论记录可以定期导出为摘要再通过模板生成成会议纪要。项目管理工具里的任务状态变更可以触发插件记录形成项目时间线文档。集成时要特别注意回调循环。比如笔记更新触发了文档同步文档同步又触发笔记更新最后变成死循环。我的解决办法是在每个同步动作里加一个源标记遇到相同标记的事件直接跳过避免相互触发。6.2 哪些功能不应该加进插件有些功能看起来很美好但加进来以后会制造麻烦。我把它们列出来权当预警。第一是复杂数据库。插件一旦依赖数据库备份、迁移、权限管理的成本都会成倍上升。纯文本文件虽然在查询能力上弱一些但胜在简单可靠对个人知识工作来说够用。第二是图形化知识图谱。很多知识管理工具把双链和知识图谱当卖点实际用起来往往是视觉冲击大于实用价值。图谱在节点少的时候很直观节点多了就变成一团乱线。缺失的链接没有得到解决只是被可视化掩盖了。第三是过度的推荐系统。有些插件试图根据你正在写的内容推荐相关资料听起来智能实际很容易打断思路。我推荐的策略是把推荐结果放在侧边栏由用户点开查看关掉后不再反复出现这样既保留了机会又不打扰创作状态。收敛功能并不意味着不做扩展而是每一项功能都要回到最开始的问题它是否有助于“输入到输出之间的连接”如果答案模糊就先放着让时间去检验。6.3 后续迭代方向如果继续往下做我会优先补两个方向。一个是离线移动端采集现在出门在外想存一条线索只能先复制到某个待办应用里等回来再处理链路断了一截。另一个是团队分享模板版本控制目前的模板是各人维护各人的不够统一后续想做一个模板仓库让团队共享同一套模板同时保留个人覆盖能力。在技术层面我很想优化语义索引的增量更新速度。目前每新增一篇笔记向量化时间在数百毫秒到一秒之间感知不强但批量导入老笔记时还是会有明显的等待。底层方案可以考虑更轻量的向量量化用精度换速度。最后想把插件做成一个更开放的生态边界。让不同模块可以独立替换让用户能写自己的采集适配器、模板处理器、输出插件。知识工作这件事本身高度多样插件应该是一套可以生长的框架而不是一个锁定的方案。我个人在实际操作中最大的体会是插件不在于多而在于每一条都能把你推向下一个动作。收一条资料就暗示你去处理处理完就等着你去检索检索到了就顺手变成输出。这套 knowledge-work-plugins 也许不是最强大的但它在“从记录到复用”这条路上把每个环节都缩短到让人愿意去做的程度。如果你也在搭自己的知识工作流可以试着先从采集和检索这两个点入手别一上来就追求大而全。等你的知识库开始自己“长出”有用的东西你就会明白所谓的效率工具其实就是帮我们减少那些与思考本身无关的动作而已。