Matrix 首页推荐
Matrix 是少数派的写作社区,我们主张分享真实的产品体验,有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章,展示来自用户的最真实的体验和观点。
文章代表作者个人观点,少数派仅对标题和排版略作修改。
或许是这几年笔记圈的讨论风向,或许纯粹只因过了那个阶段,这几年我对于知识管理相关讨论逐渐倦怠。常青笔记、PARA、卡片笔记、双链、MOC……知识管理圈不断创造着新的概念,但我愈发觉得,真正有效的方案是从更高的层面,独立思考自身需求,创建稳定可靠的个人工作流。
本文试图在构建可持续的个人工作流方面提供一些有用的思考材料。让我们先从一组经常出现的概念开始:
在工具使用的讨论中,我们经常能看到「重器轻用」与「all-in-one」两种观点的交锋。然而,我的感觉是这种讨论没有抓住重点。
首先,二者的概念定义不甚清晰。
「重器轻用」概念的首创来自张玉新老师(善用佳软)的一场直播:「不关注某个笔记工具哪方面不足,而是只关注吸引他的那一面,只用那一点。」后被王树义老师等人反复引用。
但是,重器究竟指的是什么样的软件?上手难度高,还是价格昂贵?两个评判标准都非常个人。
再看「all-in-one」,one 又是什么?是指一个软件,还是一个软件加上它的扩展插件,还是一个软件加上它的扩展插件再加上与之交互的其他软件?
以个人的场景为例,如果输入源是多媒体,包括播客、课程、电影、剧集、其他视频等,不管是在线还是本地,我都喜欢在 Emacs Org-mode 的插件 org-media-note 中进行。它让我可以从 Emacs 中快速调用 mpv 播放器打开在线或本地的媒体资源,然后在 Emacs 中就能快速插入当前媒体的时间戳链接、截图、视频文本,控制视频的播放进度、倍速、音量,设置插入时间戳链接后自动暂停、自动截图,甚至可以插入媒体的全部字幕方便纵览等。如果想回到原来的语境,点击时间戳链接就可以一键直达对应位置。避免了做视频笔记时,要在笔记工具和视频播放器之间来回跳转。
在这里,笔记编辑和视频播放的功能分别由 Org-mode 和 mpv 实现,对于 Emacs 的使用连 20% 的功能都不到,这似乎满足重器轻用的定义。但是我的交互又都在 Emacs 中进行,Org-mode 是 Emacs 的笔记管理插件,org-media-note 又是 Org-mode 的一个多媒体笔记管理插件,它直接通过系统命令行调用 mpv 的功能,似乎也可以说是 all-in-one。
无法清晰定义的问题很难进行有效的讨论。让我们返回二者提出的语境,看下它们究竟想解决什么问题。
首先,没有单一的工具能完全满足所有用户的需求,这是必须接受的现实,也是「重器轻用」的立足点。但随着工具数量的增加,使用的摩擦也会增加:边看视频或边阅读,边做笔记时在播放器和笔记软件之间的切换,如果在笔记库之外,还有不同的软件单独管理文献(如 Zotero)、书籍(如 Calibre)、播客(如 gpodder、audiobookshelf)、影视(如 tinymediamanager)、当下的思维路径(如 TheBrain、Heptabase 等可视化工具)、未来的记忆状态(例如 Anki),摩擦力更会翻倍增加。
诚然,产品不应一味追求更小的摩擦力,而是设计与认知相符的摩擦力。由于必要难度(Desirable difficulty)的存在,我们也不应回避笔记过程中必要的良性摩擦(Eufriction),但是类似这里所提到的工具之间的摩擦(Friction),无疑是长期维护工作流的阻力,自然是越小越好,这是「all-in-one」想解决的问题。
正是不被满足的需求和多个工具之间的摩擦,拉动我们在所谓的「重器轻用」和「all-in-one」之间来回摇摆。
观念的名称会潜移默化地影响人的认识。关于这点,我甚至觉得脱离了语境、仅从字面来理解这两个概念是有害的:
那么,我们真正需要的是什么呢?
真正的需求是什么? 构建笔记管理系统、项目管理系统、目标管理系统、文件管理系统,如此种种,皆非目标,而是通向最终目标的道路。我们的目标一定是某种形式的输出。如同我在 把阅读作为方法:从选书到笔记的经验分享 中所言,输出应该作最广义的理解:
而高效输出的核心是一个稳定可靠并减少阻力的的工作流。我们的认知和身份角色都会随着时间变化,流程和需求也可能随之变化,因此我们希望这个工作流能超越工具,不断适应新的变化:要么是在已有的工具之上扩展,要么是能够以可接受的成本迁徙到新工具,同时保持整个系统的稳定。当我们拥有这样的工作流并持续实践,自己会变得更好,目标也会持续推进。
根据加尔定律(Gall's Law),一个运转正常的复杂系统,总是从一个运转正常的简单系统演化而来。但是我们也知道,用「过早的优化是万恶之源」来回避一切初始的架构设计是不负责任的做法。「过早的优化是万恶之源」是对 Donald Knuth 原话简略且不准确的翻译,原始说法为:
We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
准确来说,Knuth 是说 97% 的优化为时过早,并不重要,应当避免,但是剩下的 3% 的优化依然是关键且必要的。在软件工程中,系统性能和伸缩性主要依靠好的架构设计,而不是局部优化。初期对整体稳定性、扩展性多加考量,使其适应某段时间的需求变化,避免后期难以兼顾,但是也不能在早期就陷入不必要的细节,以免裹足不前,做好行动与决策的平衡,是架构师的职责所在。也值得每个希望构建个人工作流的朋友学习借鉴。
现在的问题是,如何构建一个既能当下可用、又能未来不断迭代的最简工作流(MVP)?如何平衡当下的探索成本和未来的踩坑代价?
工具先用起来,事情先做起来,在实践中发现系统的缺陷,澄清需求,慢慢改进,这是比较理想的状态。但是如果能在一开始,用最短的时间快速试错,了解工具是否适合自己,而不要在用了一段时间才发现踩了大坑,而且是无法通过局部优化解决、只能改弦易辙推翻重来的大坑,岂不更加理想?毕竟在公司做项目时,把方案调研的时间考虑在排期之内,也是为了尽量避免这种情况的发生。
为了能够平衡好行动与决策,控制好初期的调研成本,我们需要知道哪些是 3% 的关键优化,哪些是 97% 的无效干扰。
「重器轻用」与「all-in-one」的讨论对此没有帮助。根据泰斯勒定律(Tesler's Law),每个系统都有固有的不可简化的复杂性。到达临界值后就不能再简化,而是是一个恒量。唯一的问题是,谁必须去处理它。
「重器轻用」与「all-in-one」的区别主要在于复杂度是在多个软件之间的粘合剂上(重器轻用),还是单一软件的使用技巧和方法上(all-in-one)。我觉得更有效的思考框架是下者:
为此我们需要抛开观点之争,了解一些关于软件的常识。阅读《Web 表单设计》时看到它在扩展资料中推荐了一本书,专门介绍帮助文本应该如何设计,让我感到「道」的讨论固然高大上,但其产生的价值取决于读者能否思考并与其他材料相联系;与之相比,更为扎实的「学」和略显琐碎的「术」提供了更加具体的材料和经验。
我希望这个系列能多少在这方面有所贡献,就像数据库的「增删改查」,质量管理的「人机料法环」,提供一些工具的思考框架:
让我们先从认清自己和工具开始,因为只有认清这两者,才能定义适合自己的工具流。
认清自己可以说是构建个人工作流的核心。这里我们来聊聊与构建个人工作流紧密相关的三点:
这点看似简单,其实陷阱重重。首先是如何区分真实需求和虚假需求。
这种混淆常见于笔记管理领域。如前文所述,笔记管理是通向最终目标的道路,但是不同人的目标输出差别迥异:学生为了通过考试,研究者为了发表论文,职场人士为了推进工作进展。不同的目标对于笔记管理的需求也大有不同:学生强调记忆系统和概念结构,研究者需要文献引用和观点交互,职场人士关注思考决策和项目行动。
当然,他们之间可以学习借鉴,但是关注点的差异导致完全照搬未必合适。最高效的笔记法是契合个人认知的方法论,系统能生效的重要原因是能够服务于个人的习惯和旨趣。
例如,由于关于笔记管理的很多文章大多是学生和科研者写的,以及该领域的宣传推广繁多,职场人士照搬可能就会水土不服:不少人的工作中更多是与项目和人打交道,如何构建方案、辅助决策、跟进进展、复盘项目才是重点;另外在工作中,记不很清楚又能怎样,只要知道有这样一个东西,适合的情景是什么,在需要的时候可以把它找出来就行。
除了这种需求不匹配的情况,还有一种情况是:虽然需求匹配,但是并非当下迫切所需,推迟到未来实现更适合。大部分文章分享展示的都是作者经过长期磨合所形成的完整系统,但对于读者的当下,或许只用其中的几个功能,完成现在要做的就够了。不用把刀磨得吹毛断发再去砍柴。磨得能用了就先去完成一部分工作,工作实践中再去总结可以如何针对性的磨刀。照搬其他人的系统可能是一种效率低下的过早优化。《暗时间》中说「我发现每每需要寻找对一个算法的解释的时候,翻开这些书,总是直接就看到关于算法逻辑的描述,却看不到整个算法的诞生过程背后的思想。」遗憾的是,类似的情况同样发生在个人效率的讨论。读者需要从结果逆向拆解,理解这个系统背后的需求和逻辑,再与自己的需求对照,选择性地应用,而非直接照搬。
其次,是要挖掘自己的隐性需求。很多时候人们说的需求,并不是在说希望解决什么问题、达成什么目标,而是自己理解中的可以满足需求的具体方案。但是方案并不是需求。受限于认识等因素,这个方案也许投入产出比很低,也许未必真能达成预期目标。因此,每当遇到「我想要 XXX」的时候,再多问自己一步「我想解决什么问题」「这个问题的场景根源是什么」「我可以在现有的条件下,以一些工具的自由组合解决这个问题么」。跟身边朋友的讨论有助于把这个过程显示化,个人要想提升这方面的能力,需要有意识地反思、拆解需求,并从使用的工具中总结经验。
需要承认的是,每个人当下驾驭软件的能力不同,未来愿意为此付出的时间与精力也不同。关键是选择与自身情况匹配的工具。
如果以住房比喻工具,在选择光谱的一端是精装房,另一端是毛坯房。精装房已经事先规划哪里是卧室、哪里是书房,每个房间有多大,橱柜炉灶一应俱全,拎包即可入住。
这就像很多笔记软件自身包含了一套方法论,例如 Roam Research 和 Heptabase。对于新手来说,直接跟着它的方法来可以快速上手。某种意义上,备忘录也是一种方法论为「不要让笔记数量超过你的管理能力」的笔记软件。
住久了精装房,经常发现有些地方不符合自己生活习惯,但是房屋布局又不能大动。类似的,随着使用形成了自己的方法论,或者有了新的需求后,这些有着自己方法论的笔记软件也可能会遇到怎么调整都不契合的情况。
而毛坯房可以从头设计布局、硬装、软装等等,使其完全贴合自己的需求。但是这需要自身对想要达成的目标有着清晰的思路,还需要有一些关于室内设计、住房装修的基础知识,同时要做好要为此劳心费力一段时光的心理预期。
这就像那些处于更底层逻辑的笔记软件,它们没有告诉你要怎么记录笔记,只是定义了笔记的格式,以及一些操作笔记的基本方法:快速新增、编辑浏览、导航跳转、搜索查询等等。这方面的代表是 Obsidian。Emacs Org-mode 与其说是毛坯房,不如说是砖头。越靠近底层逻辑,工具的上限越高,可以与自己的工作流磨合得更加如臂使指,也意味着入门门槛更高,需要付出更多的时间与精力来学习和磨合。
在精装房与毛坯房中间,还有着提供了更大的自由度的 OPEN PLAN 格局:这种设计在室内空间中避免隔墙的使用,用户可以先挑选一个模版,随着需求的变化,在不同阶段可以自行进行调整布局。
这就像在用 Emacs 的时候,可以选择一个流行的配置方案,例如 Spacemacs 或者 doom-emacs,它们用砖头帮你预先组装好了很多组件,避免从头盖房子。随着使用有了自己的需求之后,再选择自己加盖新组件,或者替换掉一部分已有组件。当然,为了与已有的组件协调一致,除了底层的逻辑,还需要额外了解这些配置方案的组装逻辑。
需要注意的是,软件的逻辑复杂和使用简单并不矛盾。你可以很容易地用 Excel 来维护自己的收支情况,但是玩转需要了解各种函数和 VBA;用 Emacs Org-mode 记录笔记跟记录 Markdown 文档的难度差距不大,但是要把笔记管理好,除了需要设计适合自己的组织方式,最好还能了解一些 elisp。究其原因,是这些软件把复杂的逻辑包裹在一个直观的 UI 之下。
最后,就像租房的经验和痛点可以转化为未来装修的宝贵财富,我觉得新手一开始选择自带方法论的工具可能更合适。太过自由的工具反而会让人无从下手,大多数人需要的是明确且适当的束缚,超出能力范畴的自由只会让人无所适从。而且一开始,我们需要的是一个能快速上手干活的工具,而不是费力去配置工具。如果这个工具已经足够满足输出的需求,这很好,从工具属性来说,完全不需要花费时间去折腾其他的。
但是如果用着用着发现了痛点,现有方案怎么都无法解决,或许便是合适的时机去探索第二个方案:考虑一个在方法论上不设限、功能更自由的工具。一来,你可以在第一个方案上继续工作,不至于打乱输出节奏;二来,哪些功能非常重要,哪些功能可以妥协,现在有了更清晰的认识。在没有清晰想法的时候,一个自由强大的工具会让你迷失,但是如果有了明确的目标,你会发现它提供了充足的潜能来契合自身需求。使用自带方法论工具的经验的过程,也是观察、借鉴应用反映的工作流和方法论的机会。经验是最好的老师。
我用 Emacs Org-mode 管理笔记十多年,它虽不完美、但足够好地契合我的工作流,并且不断适应我的需求变化,我认为它将一直会是我的工作流核心。但我依然很少向其他人推荐使用它(不过,我会推荐其他人了解它,我觉得 Emacs Org-mode 的很多设计剥离了各种花里胡哨,更接近笔记的本质),因为我认为它不适合作为个人上手的第一个知识管理方案,它更适合作为第二个进阶方案。Emacs Org-mode 同样是我的第二个方案,我也是在长文书写、代码学习、项目管理、文献引用、概念链接等方面发现它有难以匹敌的优势之后,逐渐把它作为主力。
为了稳定的可持续的使用,选择符合自己经济预算的工具也是关键,特别在订阅制越发流行的当今。
这点需要结合多方面来考虑:
如何寻找合适的工具,我派已有不少好文谈及,在此不予赘述,推荐阅读:
这里简单谈谈,初步确定工具之后的评价问题。
就像《如何阅读一本书》所说,不同类型的书要用不同的阅读方法。工作流中的工具有不同的类型,承担不同的功能,也有不同的选择标准和使用方法。同样的,也像所有类型的书籍阅读都依赖于基础阅读,软件的评价也存在通用标准。这里主要聊一下通用的「如何评价一个软件的付费合理性」和「如何判断一个软件未来发展态势」,至于软件工具的分类以及选择标准留待下篇。
现在软件的付费授权方式多种多样,无法简单的划分为免费或付费,买断制或订阅制。我们需要先了解有哪些常见的付费方式,才能讨论付费方式是否合理。根据个人选择优先级从高到低来排序:
自由软件 Free software:尊重用户和社区自由的软件,赋予用户运行、复制、分发、学习、修改并改进软件的自由。由于开源是自由软件的先决条件,所以大部分自由软件都是免费的。虽然从成本上来看,自由软件和免费但不自由的软件一样都不收费。但是我觉得因为它更关注用户的自由权益(liberty),而非免费(free)的价格,故此单独列出。
免费但是不自由的软件:可以从应用商店等渠道免费下载,但是没有开源,无法学习、改进的软件。
免费+内购:常规功能免费,高级功能需要付费买断。常见于小型软件。
完全买断制:所有功能付费买断。常见于小型软件。
「无限使用,有限升级」的混合模式:
我自己判断付费机制是否合理有一个简单的标准,以 Freemium 为界,再加上是否有云服务的维度:
在不提供云服务的应用中有两个特例可以接受订阅制:
上面讨论的付费机制是否合理还可以有一个较为客观的标准,至于具体的付费价格是否合理就比较主观了。除了结合上文所谈的「认清自己愿意付出的金钱」来看之外,还可以对比功能近似的软件价格进行判断。需要注意的是,开发团队小、主要面向海外市场等因素导致的工具价格高昂可以理解,但并不意味着用户需要去接受这种额外的高价。
除了软件功能性之外,我会特别关注软件未来发展的态势,正因如此,虽然我也会有买断之后因为平台迁移等原因弃用的工具(例如 PDF Expert),总体而言没有踩过大坑:
在选择软件时,对于以下几点的评估是我没踩大坑的重要保证:
专业不只是软件工程方面的专业性,更是产品设计方面的专业性,而且后者相对更容易判断。产品专业性可以从工具功能、官方博客、团队构成等多方面来判断,例如:
那什么叫有自己的精神的笔记软件呢?通过体验产品、阅读创始人自己写的文章和其他人对创始人的访谈,我认为:
即便工具的一些专业功能用不上,专业性本身也是对工具未来发展的保证。
如果工具的发展方向与个人的需求不一致,再好的软件也只能遗憾告别了。了解软件的发展方向一是从 Changelog 看过去的功能实现,二是从 Roadmap 看未来的规划方向。一个清晰的 Roadmap 本身就是工具方向明确的表现,Obsidian Roadmap 是我看到的佼佼者,非常明了。
此外,笔记软件因为往往自带方法论,需要额外考虑是否与自己的使用场景相符。可以逛逛官方论坛,当年正是因为看到魏拾俊在百度贴吧对用户的回复,让我觉得这是一个有想法、有情怀的理工男,为知的发展方向也与当时我的需求一致,所以在与印象笔记等其他工具的对比之下选择了为知。可以看看创始人的访谈,正是因为看过少楠的采访,我知道指望 flomo 增加白板功能是不现实的,他的产品哲学是做减法。
说到产品哲学,由于工具的调性改变很难,因此当你认同一个工具的价值观,那同样认同工具的未来方向的概率会更高。推荐阅读 The values of Emacs, the Neovim revolution, and the VSCode gorilla,虽然介绍的是文本编辑器,但是文中总结的易用性、稳定性、键盘中心、文本中心等价值观对于很多工具的选择都有启发。
一个工具在 Roadmap 里许诺的未必真能实现,因此我会考虑团队是否真诚。一个真诚的团队无疑会提升信任度:
如果一个工具是自由软件,由社区维护,对于未来的可持续性我没有太多焦虑。从 Anki 的 FSRS 新记忆算法到 Calibre 的全文搜索功能,社区维护的自由软件不断推出令人惊喜的功能。社区的规模和质量值得考量,但是至少自由软件保证了你也可以去学习、修改并改进软件。在 AI 工具逐渐普及的当下,学习、修改并改进软件的成本会进一步降低。拿 Emacs 的使用来说,虽然拆解大的需求尚有不足,但是用 AI 写一个新的 elisp 函数满足个性化的小需求,还是很高效的。
如果一个工具由商业团队维护,那么我会考虑公司能存活多久:
一个好的社区可以帮助用户解决不同层面的问题,不只是软件本身的功能配置,还包括使用软件的案例方法,这点对于知识管理类工具很有帮助。
社区的氛围也很重要。早期 Roam cult 那种狂热粉圈的社区氛围是劝退我的因素之一,而 Emacs 吸引我的原因之一也是它理性开放的社区氛围。
当有人说「没有 lisp 这个信仰,就别用 emacs 了!」时,Emacs 社区中会有人站出来反驳:
用不用一个编辑器是一个简单问题,哪怕是单纯觉得它好用都可以——而不用升华到所谓的「信仰」高度。这里面问题太多了。另外,就
没有 lisp 这个信仰 就别用 emacs 了!
这个论调来说,它纯粹是绑架。
比如我就不信仰 lisp。我喜欢 lisp,但我从未敢说自己「信仰」lisp。而且哪怕我不喜欢 lisp,我也会用 emacs,因为我认为它满足了我的需求,它足够好用。
那么现在有人说「不信仰 lisp,就别用 emacs 了」,凭什么?有什么权利限制一个人不能用 emacs?面对这种问题,我不能反抗吗?
一个良好的社区应该有人反对这种风气,这样大家才能集思广益、一起成长。
我们是社区,不是邪教。
在知识管理领域和文本编辑器领域,经常会有人把工具作为信仰,所以我倍加珍惜这股清流。
认识篇至此告一段落。很遗憾,本文依旧不太落地,因为尚有很多观点没有展开:
但我希望,如果你正在构建个人工作流的道路上,本文能帮助你放下一些执念,驱散一些迷茫。
让我们期待下篇的再会。
> 关注 少数派公众号,解锁全新阅读体验 📰
> 实用、好用的 正版软件,少数派为你呈现 🚀
© 本文著作权归作者所有,并授权少数派独家使用,未经少数派许可,不得转载使用。