关于数字阅读流程的分析和分享，现有的讨论已经很充分了。不过，这些讨论主要关注阅读和处理两个阶段，而对收集阶段则着墨不多。这本身固然没错：一方面，收集阶段一个不可回避的话题是内容源，而这是一个很个人化的选择，并无对错和规律可言；另一方面，更多人在数字阅读中遇到的主要困难，在于如何有效消化已显过剩的内容，而过多的收集只会进一步加剧这一问题。
但在对数字阅读的实践中，我逐渐发现收集的意义并不亚于阅读和处理。下列情形相信各位都不陌生：你原本只是想浏览 RSS 中的新文章或 Twitter 上的新推文列表，但点进某个链接后，却发现其中的另一个链接也十分有趣，于是再次点击跳转。在反复的跳转中，你最终忘记了最初的目的只是读完一个列表，却花费了数倍于原本需要的时间。又或者，你在浏览中遇到一则希望进一步处理的内容，却因时间或场合的限制无法细看：它未必是长文，可能是视频、漫画或交互式网页，因此直接发送到传统的稍后读服务并不合适；只凭标题和匆匆一瞥，你也不能判断它是否值得仔细消化，因此存入笔记类 app 也无意义。这就造成了一种阅之无暇、存之无处、弃之可惜的尴尬局面。
之所以会出现上述困境，归根结底是因为网络本身是非线性的，这也是 HTML 的本质特征；但从提高效率、节约时间的角度出发，我们却希望自己的阅读尽可能是线性的，减少因不断跳转和思考如何处理信息带来的不必要干扰。
那么，如何将非线性的信息获取变成线性的呢？很简单，我们只需要引入一个列表：在收集阶段，遇到感兴趣的链接时，不去直接阅读、也不去细想怎样处理，而是直接将其投放到列表中；收集结束后，再查阅这个列表中的链接，逐一浏览、归类，从而与之后的阅读、处理两个步骤衔接起来。当然，为了更好地服务于上述目的，这个列表至少应当具备如下特性：
在我之前的阅读流程中，并不存在满足上述需求的工具；唯一比较接近的是 Instapaper。但我更倾向于将 Instapaper 作为一个纯粹的长文阅读工具，如果将大量内容格式庞杂且很可能无须精读的网页堆积其中，不仅不符合其定位、也会破坏长文阅读环境应有的整洁和秩序。至于使用 OmniFocus 之类的 GTD 工具作为阅读列表，先前已有不少文章论证了其不合理性。因此，引入一个新的工具是必要的；正是在这样的需求驱动下，我开始了一次长达一个多月的寻找。
在明确需求后，我首先想到的工具就是内建的 Safari 阅读列表功能。作为一项「亲生」功能，Safari 阅读列表在体验上的优势不言而喻：无论是 Safari 的 Share Sheet、还是第三方 app 中长按链接弹出的菜单，你几乎可以在系统的任何一个角落找到它；通过 iCloud 的多端同步几乎是即时的；基本功能齐全，可以通过 Safari 的 3D Touch 菜单快速打开，可以自动获取网页的标题和概要，具备已读/未读状态的区分等等。
然而，这个乍看完美的解决方案并不经得起仔细推敲：首先，抓取链接标题的功能并非总是有效，在添加短网址和 Newsletter 里经改写的链接时，Safari 阅读列表往往不能正确抓取其标题，从而使得整个列表里堆积着一些「裸」的 URL，完全不具备可读性，而这类链接正是我每天需要大量添加的（这也可能是网络环境的问题，但即便这样也不改变问题的普遍性）。此外，Safari 阅读列表虽然可以借助 iCloud 的优势获得无缝的同步体验，但由于其只是 Safari 的一个功能组件，不能独立于浏览器而运行；而我在使用电脑时则往往需要用到 Chrome（相信很多朋友也是如此），这时再用 Safari 阅读列表来收集链接就十分不方便了。因此，我只能放弃这个最方便的原生解决方案，转投他途。
我第二个尝试的解决方案是使用 Pinboard。这是一个较为小众的在线收藏夹服务，且有每年 11 美元的收费门槛，在国外科技圈中有较高的知名度。我本来只用它来替换浏览器内建的收藏功能，但注意到它也支持将保存的链接标记为「unread」，并提供一个单独的「Unread」列表，因此也具备当作阅读列表使用的可行性。
Pinboard 在自身提供的 Web 端上可谓十分简陋，但它之所以为人称道，主要在于令人吃惊的 API 开放程度和第三方支持。因此，将链接保存到 Pinboard 的方式相当多元：你既可以使用官方提供的 JavaScript 书签，也可以使用众多第三方客户端，而 iOS 上著名的 Workflow 也提供了对 Pinboard 的支持。在实际体验中，我只需在收集链接时勾选上「unread」选项（很多 app 支持自动勾选），有空阅读时打开 Unread 列表逐一浏览即可。读完后，没有重复阅读价值的链接直接删除，希望保存的链接则去掉未读标记、打上标签，它就会自动从未读列表中消失。整个体验非常顺畅。
不过，这个解决方案的不足也是明显的，最主要的问题就是 Pinboard 本身不支持抓取链接的标题。当然，丰富的第三方支持一定程度上缓解了这一问题：例如，我使用的 Spillo（macOS 端）和 Pinner（iOS 端）两款客户端均支持在添加链接时自动获取网页标题。可惜的是，iOS 上的 Pinner 在添加链接时十分缓慢，在确保网络通畅的情况下，也往往需要 5 秒以上的时间（这也是该应用在 App Store 评论中最被诟病的一点），且在 Safari 之外的场合使用时往往抓取不到标题；更致命的是，其 Share Extension 在整个等待过程中始终处于前台可见状态，从而将其他 app 的操作全部挂起。对于以效率为首要追求的链接收集操作来说，这显然是不可忍受的。作为 iOS 上目前评价最高、更新最及时的 Pinboard 客户端，Pinner 的表现尚且如此；那些最近更新时间停留在一两年前 app 的使用体验，就可想而知了。
不过，我并没有直接放弃。考虑到 Workflow 也支持添加到 Pinboard，我便试着自己造一个轮子，组装一个简易的 Workflow 来解决问题。这个 Workflow 的原理大致如下：首先，从 Share Sheet 的输入中获取 URL，传输给「Get Details of Safari Web Page」这个动作抓取其名称（Name）。如果这个 Workflow 是从 Safari 中启动的，由于网页已经加载，上述操作就能直接获取网页标题。如果不是从 Safari 中启动，则上述操作只能将 URL 原封不动地传递下去；换句话说，其输出一定以 http://开头。为此，我们使用一个 If 判断将这种情况过滤出来，然后利用「Get Contents of URL」和「Get Name」两个动作，手动获取网页标题。最后，通过 Workflow 内建的 Pinboard 支持将链接和标题发布出去即可。实际体验中，这样做在效率和成功率上都要比借助第三方 app 插件高不少，在相当程度上满足了我的需求。
Pinboard + Workflow 的组合总体上让我比较满意，但也向我揭示了另外一种可能性：能否用同样的思路，将阅读列表完全文本化呢？这不仅有利于进一步摆脱平台和客户端的束缚，而且由于文本的同步几乎不需要时间，可以进一步提高整个流程的效率。为此，我首先以 Evernote 为载体进行了尝试。
作为链接的收集容器，我在自己的 Inbox 文件夹中建立了一条名为「URL Inbox」的笔记；然后简单修改上文提到的 Workflow，使其将获取到的链接和标题添加到这条笔记的头部（对应的 HTML 写法为 <a href="链接">网页标题</a>）。此外，为了增强这个列表的交互性和信息量，我又在每条链接的前面加上一个复选框（可以通过添加 <en-todo/> 这个 Evernote 的私有标签实现，见官方文档）、并在其结尾附上添加时间（藉由 Workflow 1.7 新增的魔法变量非常便利）。为了便于快速操作，我获取了这条笔记的 URL Scheme 并将其添加到 Launch Center Pro 的 Today Widget 和 3D Touch 菜单中，从而实现了随时访问。（直接跳转 Evernote 特定笔记的 URL Scheme 可通过其获取其分享链接，然后转写得到，参见官方文档，或使用我制作的这个简易 Workflow，但请注意我仅在自己的国际版账号进行了尝试。）
当然，作为半个纯文本爱好者，我也尝试了用 Dropbox 替换 Evernote。得益于 Editorial 对 Taskpaper 格式的良好支持，只要在 Dropbox 中建立一个以 .taskpaper 为后缀的文本文件，并将修改 Workflow 将链接和标题以 - [标题](链接) @due(today) 的格式写入其中，Editorial 就会自动以 todo list 的样式将其高亮呈现出来，还可以使用每行右端的手柄上下拖拽排序，读完网页后打勾标记即可。而在 Mac 端，nvALT 这一常用的快速笔记工具同样提供了对 Taskpaper 的基本支持，虽然不能为每一条链接显示出复选框，但可以通过在行尾添加 @done 的标签手动实现（可以用文本替换/Text Expander 进一步简化这一操作）。
本以为已经找到了最适合自己的解决方案，没过两天，话题作品 Linnk 宣布完成测试、正式发布的消息又让我看到了新的可能性。Linnk 是我从内测阶段就开始关注的产品；按照我的理解（未必准确），它大约可以看作是 Pinboard + Instapaper 的融合。作为一个采用 Freemium 模式的服务，Linnk 对免费用户有保存链接数量的限制，但这并不影响将其作为一个纯粹阅读列表的可用性。
不可否认，Linnk 本身是一个相当用心的产品，对于从纯文本解决方案转换过来的我来说，光是其清新精致的图标和界面，就足以构成使用理由。尤其令我惊喜的是，其 iOS 客户端的 Share Extension 响应十分迅速，大多数链接都能在一两秒间保存完毕，从而不会给收集流程造成不必要的干扰（这可能是由于 Linnk 的插件只保存 URL 本身，而抓取网页信息的操作则通过服务器在后台完成）；Today Widget 的设计也美观实用，可以随时下拉检阅自己保存的链接并直接访问；内建的网页重排、夜间主题等功能则更是锦上添花。相较于 Pinboard 第三方客户端那种让人抓耳挠腮的体验，Linnk 的流畅和完善简直让我产生了「受宠若惊」的感觉。
可惜的是，Linnk 土生土长的国内服务身份在带来诸多便利的同时，也成了一种「原罪」——它必然受到国内特殊网络状况的束缚。正如其文档所述，对于国内无法正常访问的网站，Linnk 无法保证正常处理。我的实际体验也确实如此：我每天大量阅读的《纽约时报》网站的大量链接，Linnk 都不能抓取其标题、更遑论进一步的文本重排了。当然，指出这一点并非是批评——我完全理解国内独立互联网服务在功能和生存间取舍的艰难；但对于以大量上述类型网站为主要信息来源的我（我们）来说，只能暂时遗憾地把 Linnk 收进第二屏，继续踏上折腾之路。
Copied 本身跟阅读列表可谓毫无关联：作为一款剪贴板管理 app，它本应与国内 app 圈知名的 Pin 归于一类。事实上，虽然很早之前就从 MacStories 的推荐中得知了这款 app、且有自己试用，我一开始也从未将其和阅读列表联系起来。而在 Pin 的功能逐渐完善后，我也有很长一段时间没有用过 Copied 了。
重新捡起这款 app 纯属巧合。Workflow + Evernote/Dropbox 的解决方案虽然满足了我大多数的需求，但仍有一个明显不足：操作起来略显繁琐。每次添加链接时，我都要重复「点击分享按钮/长按链接—点击 Run Workflow—选择 Workflow 运行」的流程，即要三步操作才能实现。一旦需要连续添加多个链接时，这就令人感到十分乏味冗余。考虑到 Copied 支持将多条剪贴板记录合成一条并分享，我便想到这样一种改进措施：先将链接保存到 Copied，然后一次性通过 Workflow 处理并写入阅读列表中。于是，我重新下载了 Copied 并开始试验。
但我很快发现这个措施的第二步完全是多余的：Copied 本身就能够抓取所保存链接的标题。再加上其对 macOS 和 iCloud 同步的支持，将其作为一个阅读列表来使用便完全可行了。实践也应证了这一构思的可行性：Copied 的 Share Extension 同样响应迅速，无需耗费多余的步骤和时间；基于 iCloud 的同步效率毫不逊于 Safari 阅读列表；应用界面和 Today Widget 简洁实用，便于随时查阅访问。另外值得称道的是，Copied 的 macOS 客户端同样水准较高，一些功能的设计也有意无意地便利了将其用作阅读列表的需求：例如，可以选中多条记录，并按 ⌘O 全部打开；可以设置为用 ⇧⌘C 在当前鼠标指针位置唤出窗口，并在失去鼠标焦点时自动隐藏等。
对 Copied 潜力的重新发现终于使得我一个多月的反复寻找告一段落，得到了一个在各个角度上都基本满足需求的「阅读列表」。
以上就是我对构建阅读列表的整个思考和探索过程。记录这个过程，并非是想要提供一个答案——我自己也仍然在持续思考新的可能性，而暂时令我满意的 Copied 也很可能并非最优解。事实上，我列举的这些 app 和服务并无绝对的优劣之分，每个人都可能因自己的需求不同而偏好其中的某一个。例如，如果你在全平台上都以 Safari 为主力、而且是「断舍离」主义的追随者，那么 Safari 阅读列表显然最适合你；如果你是一个重度的 Markdown/Taskpaper 使用者，笃信只有纯文本才是全在、全能的解决方案，那么用 Workflow 配合 Dropbox 可能最贴近你所熟悉的工作流；而如果你以国内网站、微信公众号为重要信息来源，或注重工具的美观度和设计感，那么 Linnk 肯定值得一试。更何况，这些工具自身也处在不断的迭代和更新中，新的工具也将不断进入我们的视野；因此，给出一个确定的答案是不必要也不可能的。
在文章的最后，我还希望借此机会，简单讨论一下所谓「折腾」app 的问题。去年以来，国内的 app 爱好圈逐渐开始反思不断「折腾」各类 app/服务，并为之投入大量时间和经济成本的必要性。很多论者指出，为了节省很少的操作步骤或时间而在各种 app 间反复尝试、切换是毫无必要的，花费的成本远高于其带来的价值；而那种展示、炫耀驱动下的「炫机」「晒主屏」行为则招致了更为激烈的批判。
在我看来，这种讨论是之前热浪消退后的一种理性回潮，应当说是十分必要的。事实上，在相对更加成熟的国外爱好者圈子中，也早有类似的讨论，很多博客和播客中都明确反对所谓的「fiddling」、也即「折腾」行为。但另一方面，用纯粹基于时间和效率的经济性考量来彻底否定「折腾」行为，也许同样没有必要。以我的上述经历为例：为了寻找这个最适合我的阅读列表，我花费的时间可能累计十数小时；即便最终成果能大大便利我的日常操作、节约我有限的注意力和时间，要收回投入的时间成本，恐怕短时间内是难以实现的——到那时候，或许我又找到更好的解决方案了。那么，能否因此就说我的探索是不经济的、因此是没有价值的呢？不同读者可能有不同的思考，但我自己的答案显然是否定的：如上所述，我找到的每个解决方案都有不同的适用场景，即使最终没有被用于搭建阅读列表，也很可能在今后的某个场合被我迅速想到而无须另外寻找；在反复试验的过程中，我还有一些原本目标之外的收获，例如，在调试 Workflow 的过程中学习了网页 API 的使用方法、在探索 Editorial 的过程中学习了正则表达式等。因此，如果说一定要给「折腾」的必要性施加一个客观标准，我想应该是「需求」：明确需求驱动下的「折腾」、无论纸面上的投入产出比，最终很可能是有效率的，反之亦然。
最后，探索 app 所能带来的精神愉悦也是不可忽视的。不知道有多少朋友小时候玩过一种叫做「电子积木」的玩具：将导线、二极管、电阻等基本电路元件封装成乐高那样可以自由拼接的积木，根据指南的指引，就能组装出逻辑电路、光控灯泡、收音机等等。
现在回想，当初电子积木所能实现的电路相当简陋，实现某个效果所要花费的精力，也远远高于用实打实的元器件组装之所需。类似地，在更高阶的用户、即「造轮子」的人看来，「折腾」app 或许也就像拼装电子积木一样，并不「Pro」，也不是最有效率的选择。这固然没错，可我至今仍然记得当初花费一个下午拼成的收音机发出声音时的满足感。同样地，我能体会到作为数字化「积木」的 app 实现需求时为我带来的愉悦；我赞赏它们向我揭示的可能性。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。