在线阅读处理流程：从需求、到方法、再到工具

怎么处理自己每天摄取的信息是个经久不衰的话题。对于我来说，这个话题背后是三个大的要解决的问题：

  • 让我每天能够摄取我感兴趣的新东西，而且最好不减少摄取源（Unfo 别人或者取消订阅一些网站）。
  • 让我每天能够消化这些东西。标准是能今日文今日读，不拖不积；该批注的批注，该做摘要的做摘要。
  • 让我以后想要找到这些信息的时候能第一时间找到，这是重中之重。

除了硬性要求，在体验上我则希望尽量能够完成地简单舒服，具体来说是：

  • 简单：步骤少、涉及的工具少
  • 舒服：能够离线、抓文完整

能解决这三大问题的，在我看来就可以称为一个成功的流程。一个流程里某一个具体的工具是不太重要的，起码在「在线阅读」这个流程里不重要。工具只是来完成它在这个流程里的任务，能完成这个任务的，都是好工具。所以我认为每次讨论阅读的时候都会陷入工具的争执本身就说明讨论的脱轨。有太多讨论没有设定共同的需求和需要解决的目标问题，最后都落到工具上甚至对工具的某些设计元素的个人审美上，让人感觉非常遗憾。

我所用的工具也未必是正解（事实上我现在在用的也是妥协解），不过我会在文中阐明为什么在用这些工具，最后也会统一再陈列一遍。如果你有更偏好的替代品，也可以使用你自己的选择。如果你在用的工具在某个环节能够更好地解决问题，非常欢迎你详细说明它的好处，让我和更多读者从中受益。

  • 1. 概述
  • 2. 收集
    • 2.1 后内容聚合类服务跟 RSS 的不同
    • 2.2 收集用的工具
    • 2.3 书写错误易发现
  • 3. 阅读
    • 3.1 阅读用的工具
  • 4. 进一步处理
    • 4.1 精读
    • 4.2 没办法在移动设备上处理的内容
    • 4.3 进一步处理的工具
  • 5. 回顾
    • 5.1 日常流程

概述

我目前使用的流程是：

  1. 收集：RSS、后内容聚合类服务、社交服务等；
  2. 阅读：在来源里感兴趣的内容发稍候读， 在稍候读服务中集中阅读文章；
  3. 进一步处理：移动设备和稍后读无法完美处理的文章，需要将其加入任务管理系统，以便提醒和做进一步处理。

收集

我们的信息来源大多来源于下列服务：

  • RSS 订阅
  • 后内容聚合类服务：Flipboard、Google News、轻芒阅读 等
  • 微信公众号
  • 社交：微博、Twitter 等

这些来源都比较好理解，不过也许与别人不同的是，我在同时使用 RSS 和轻芒阅读。我想解释一下为什么我两者都在用，在我眼里 RSS 和后内容聚合类服务有什么区别。

后内容聚合类服务跟 RSS 的不同

前面出现了好几个「后内容聚合类服务」这样看起来很装腔的词，使用它的目的是为了跟 RSS 做区分。

我在用 Flipboard 之类的服务后感觉这种东西跟 RSS 明显不能放到同一个类别里去。两者的区别是一重一轻。所谓「轻」，是上手即读，随时可以放下；所谓「重」，是严选内容，未读必须清空。

传统的 RSS 服务不会给你推荐任何内容，喜欢 RSS 的人非常清楚自己为什么要用 RSS 以及要看什么，但这样的人是少数，少到让 Google 放弃了这项「伟大的」业务。之后出现了各种小企业百家争鸣，再到不一样的 Flipboard 和类似服务红极一时。Flipboard 这样的内容聚合类服务的目标群众是更广泛的普通人，他们不是把自己的在线阅读需求想得这么清楚的人。这些人需要装了应用打开就有东西可看，所以内容聚合类服务一开始就会给你推荐一些平台内的热门信息源。Flipboard 现在甚至只让你选择一些大的类别，好像它认为用户不需要在乎文章是哪来的，只要有东西刷出来就行。

Flipboard 可能是个极端，但也不难看出，这类服务本身想要做到的，就是你每次打开就能给你刷出来一些新东西。而这个服务的目标用户，大概也不会要求自己至少每次都浏览关注的所有订阅源的文章标题。所以它没有「未读数」和「清空」的功能来辅助你做这件事，于是就不会给多数用户带来阅读压力。这些服务，我觉得用「刷」要比用「读」更合适。我「刷」这些服务的时候，我的心态就像刷微博，闲了没东西看了，打开看看，不想看了就关了，整个心态很「轻」。

但 RSS 不是这样的，RSS 重，真正的 RSS 使用者只会因为一个网站产出的大部分内容乃至频率都合自己口味，不想错过哪怕一条可能对自己有用的文章才会去订阅。我们订阅这样的网站，就是为了能够篇篇不漏地看这个网站产出的内容，起码要看标题。所以，就需要「未读数」来提醒我们有多少篇还没读，不清空未读数，我们会有一种压力和负罪感，我们会觉得该吸收的东西没有吸收到。

正是因为这种不同，我们可以同时运用两种服务。很多人在 RSS 里订阅了太多新闻向的网站，这些网站的特点是发布内容频率高，内容更新短平快，内容时效是非常短。这样的内容按我的定义是不应该放在 RSS 里的，它们应该放在后内容聚合类服务里。

我个人在用的后内容聚合类服务是轻芒阅读（之前叫豌豆荚一览），它不像 Flipboard 那么极端。它依然是按信息源而不是按类别让用户选择关注的内容，也有接近传统 RSS 客户端的列表式排版。所以我暂时是把新闻类和稍感兴趣的内容放在这里，没东西看了，就打开划两下。虽然轻芒阅读的展示方式是我所习惯的，但它的问题是，还有不少国外信息源它抓不到，不少公众号也不支持。

收集用的工具

如果想做到最初提出的三个目标的第三项——以后想要找到这些信息的时候能第一时间找到——我们就不该在哪看到文章就在哪读，因为这样将直接导致我们查找文章的一个重要途径——阅读环境彻底失效（更详细的说明见 阅读 部分）。所以我提倡先把文章收集到一处，再读。所以这部分的工具要做好的就是收集，收集的过程越简单越好。所以这些工具应该被看重的是，它们能不能最简单地把你想读的文章发到你所用的稍后读服务里。

在我用的服务和工具里：轻芒阅读本身既是服务，也是客户端，而且支持 Pocket，很符合我的使用习惯；微博和 Twitter 也有支持 Share Sheet 的客户端。剩下的两项，微信公众号文章和 RSS，前者是知名的难啃，很难融入传统流程；而后者，RSS，要分为服务和客户端。在我的流程里，服务的挑选有一定的要求，客户端却不重要。

RSS 服务的选择

在文首提出的三个目标的第一项，是「让我每天能够摄取我感兴趣的新东西，而且最好不减少摄取源」；第二项，有一句「今日文章今日读，不拖不积」。这两项目标，转化为对 RSS 服务的要求，则是：

  1. 筛选功能：可以在已有的订阅源（Feeds）中，做初步的筛选，让这些订阅源中可能产生的，我不感兴趣的东西不进入我的流程中来；
  2. 组织功能：对于我特别感兴趣的一些内容，要能组织在一起，让我在阅读的时候可以首先从我最感兴趣的部分开始阅读；
  3. 这项服务要被大多数主流 RSS 客户端支持；
  4. 在我的流程里比较特殊的一项：对 IFTTT 有一定的支持，因为我需要和我的稍后读服务（Pocket）进行联动。

除此之外其实也有一些基础的要求，比如考虑这个服务的商业模式和维护成本，它能不能长久地运营下去。以及你是否可以把你的订阅轻松地转移出转移到这个服务等等。这些因为和本文关系不是太大，不多提了。

针对上面四个要求，我目前选择的服务是 Feed Wrangler。

对于筛选，Feed Wrangler 提供了 Filter 功能。在这里，你可以针对一个或多个订阅源，制定过滤规则。Feed Wrangler 的过滤规则主要是匹配标题和内容的文字，对于情况比较复杂的匹配，可以使用 AND、OR、NOT 这样的表述；对于整句的表述，最好用半角引号 ' 框出来；对于并列，可以用半角逗号 , 将关键字隔开。

Feed Wrangler 的 Filter

譬如，用官方的例子，你可以在 Filter 的 Keywords 里这样输入：

donuts, french fries, cheese

去屏蔽含有任一关键字的文章。但如果情况比较复杂，你也可以运用 AND 等表述，来适配你想过滤的文章：

(donuts OR 'french fries') AND NOT 'ice cream'

这句的意思是，过滤掉提到 donuts 或者 french fries 但是没有提到 ice cream 的文章。也就是说，有 donuts 但没有 ice cream，或是有 french fries 但没有 ice cream 的文章，都会被过滤。

对于组织内容，Feed Wrangler 提供的是 Smart Stream。因为和 Filter 用的是一样的过滤方式，所以两者界面相近。只不过 Filter 是替你「挡」内容，Stream 是替你「聚」内容。

Feed Wrangler 的 Stream

通过 Smart Stream 你可以把那些你着重关注的领域的内容提取出来；也可以把那些要留下，但是只看标题知道怎么回事儿就行的放在一起。

比如说，针对前者，你可以挑几个科技网站，把它们关于 Apple，甚至 iPad Pro 的文章聚在一起，形成一个 Smart Stream；针对后者，我从 @文刀漢三 那里学到一个思路，把在 AppShopper 里追踪的应用的变化进行了 RSS 订阅，这样可以看到那些我想要或者有了但没装在设备上的应用的功能变化。但是这些变化并不主要，了解即可，我也肯定不会把它们保存到稍后读去，所以专门放在一起，扫一眼就「全部标记为已读」。

在目前的 RSS 服务里，Feed Wrangler 并不是功能最强大的，但它属于恰好满足我需求的。包括但拥有更多可能性的 RSS 服务诸如 Inoreader、Newsblur 等都是不错的选择。

为什么说 RSS 客户端不重要

说 RSS 客户端不重要原因有两个，根本原因是后面会详述的「阅读环境统一化」。而且客观来看，不难发现近来各站点有不支持 RSS 或仅支持输出 RSS 摘要的趋势。对于这些网站，RSS 客户端失去了阅读优势，甚至还不如把它们的社交账户放到一个 List 里，反正都要点开原文，放到一个 List 里还减少了操作步骤。

从我意识到这个情况开始，我在 RSS 客户端里做的就只是预览标题，然后把感兴趣一点的内容发送到稍后读服务中去，在那里做阅读。所以对我来说，这里关键的事情变成了如何最有效率地把文章发到稍后读服务。

RSS 客户端一般都支持 Share Sheet，一般人的第一反应大概是 Share Sheet 发送内容过去。但是 Share Sheet 点的次数多一些，而且也需要等待菜单出现，为了使操作更简单，我利用 IFTTT，将星标文章后的文章，发送到 Pocket。

IFTTT 动作下载

注意：本动作仅支持 Feed Wrangler 用户，也有其它服务可以做到联动 IFTTT，需要做别的动作。

至于为什么用星标这个办法，是因为星标是 RSS 的基本功能，几乎没有不支持它的客户端。有的 RSS 客户端可以直接打星标，有的用手势划一下就可以打星标，这个操作一般都在最明显和最顺手的地方。

微信公众号的文章怎么融入这个流程

微信公众号的体验和 RSS 是不能比的：它刻意选择自立山头、必须在线读、排版良莠不齐、无法保存与同步阅读进度、阅读过程中极易受干扰…

但邪门儿了的是，有的内容生产者就只选择微信公众号这一个平台，比如我看的，唯一的公众号：中国物理学会期刊网。

对于我来说微信公众号的文章是收集过程中的一块硬骨头，原因在于三个方面：

  1. 很难融入到现有流程里
  2. 直接发送到 Pocket 无法读公众号文章里的图（Instapaper 可以）
  3. 从 Pocket 保存到 Evernote 也没图

对我来说，这些转化为要解决的问题是：

  1. 将公众号文章 RSS 化
  2. 从 RSS 到 Pocket 实现保存图片
  3. Evernote 可以保存公众号文章中的图片

第一个问题，可以用 微广场 这个服务来代劳，它也可以把简书、知乎之类的内容生成 RSS。免费账户可以添加 10 个订阅。你可以在你个人页面找到你追的公众号，然后点公众号卡片里的 RSS 标识，就能获取链接。

微广场的 RSS 获取位置

微广场这个服务可以做到获取微信公众号文章的全文及图片：

文章来自中国物理学会期刊网公众号，客户端为 Unread

这样好像看起来可以顺势解决 Pocket 那不能存图的问题，但事实上，当你从 RSS 客户端分享微广场生成的文章时，得到的只是一个跳转链接，存到 Pocket 或 Instapaper 里的文章连标题都没……

微广场生成的 RSS 发送到 Pocket & Instapaper 的文章

所以把微信公众号文章融入到「RSS - 稍后读」这个传统流程的计划在我的流程里算是破产了。但好在我追的这唯一的公众号文章，我都基本上必须批注或者做摘要，所以我可以接受从微信复制文章链接，然后直接将其保存到 Evernote。于是问题进入第三步，能不能直接把公众号文章直接带图存到 Evernote。

最简单的方法是直接用 T_Bryan 做的 这个 Workflow。把公众号的链接复制，然后跑一下这个 Workflow，文章就存到 Evernote 了，包括图片。

但因为微信用的是 WebP 格式的图片——这也是为什么 Pocket 不能读图的原因——Evernote 现在只可以在笔记里显示图片而不能为图片建立索引。也就是说即便你是高级账户，你也不能从 Evernote 里搜索这些公众号文章里图片中的文字。从 Instapaper 保存到 Evernote 里的公众号文章中的图片也是如此。

所以总的来说，公众号的问题在目前这个阶段，能做到的只有 RSS 化，或者直接保存到 Evernote 去，二者只能择其一。

按照我的思路，完美解决这个问题的方法有三个：

  1. 微信想开了支持 RSS；
  2. 微广场或类似的「公众号 to RSS」服务能把公众号文章中的 WebP 转为传统的图片格式，并且不多提供一步跳转链接；
  3. Pocket 和 Evernote 对 WebP 进行完整支持。

以上就是收集方面的所有内容，可以说除了微信无法完美解决以外，其它都有便捷的途径做到文章收集。

阅读

如何用稍后读服务阅读我写过 另一篇详细的文章 ，在这里我想解释一下为什么我认为要尽量一处阅读。

能把读过的文章的核心知识记下来固然是我们所希望的，后文也会提到为了这一目标我的流程里提供了什么方法。但是，客观地说，上面的 IFTTT 动作，是我 2016 年 5 月 11 日做出来的，到现在（2016-12-30）已经发送了 1700 篇文章到我的 Pocket。这么多文章，我不可能把所有文章的核心知识都记下来，但是我可以说，这些文章，只要有网，都能再很快找到，做播客的时候跟和别人聊天的时候我经常做这件事，这就是阅读环境统一的好处。

阅读环境是找文章最重要的途径，你或许会忘了文章内容，对标题的记忆也模模糊糊（尤其是现在这个刻意把标题起得跳脱不符合常规思考的环境下），但如果你的阅读环境单一的话，你就有了一个最可靠地查找文章的方式，你只要可以确定一篇文章是在某个服务里读的，你甚至可以用地毯式过标题的方式去排出来这篇文章。但是如果你阅读环境根本不统一，那首先你就不知道去哪找，然后再用搜索引擎去搜文章，根据我的经验，能搜到的可能性也很小。

我们对文章的印象是根据自己的理解被变形了的，经过的时间越久这个现象就越严重。文章中的关键字可能会被我们替换成我们更熟悉的概念。所以本身是靠关键字的搜索引擎在这时候只能帮倒忙，无论你多么熟悉搜索引擎的搜索语法。

稍后读是最适合做阅读这件事的地方，它本身就是为了优化阅读体验而生，目前也没有像 RSS 一样被针对得那么厉害。稍后读内容可以离线阅读，Pocket 和 Instapaper 都支持搜索，Instapaper 最近还把全文搜索给免费了。除此之外，我在《用 GTD 的方法结束稍后读》里还提到了目前如何用稍后读工具能够加快阅读速度的问题，在这里简单概括是两点：

  • 整理。在一段时间内阅读同类文章要比阅读不同文章效率高。
  • 使用朗读文本功能。如果你不需要练习阅读速度，外语文章让系统读你来跟着看是更快读完一篇文章的办法。

不过，在我个人看来，稍后读服务只能做泛读，不能做精读。虽然所有文章都要先存在稍后读服务里，但读的时候一旦发现（不必读完全文）一篇文章需要做进一步处理，就应该把它发送到更合适的地方。

阅读用的工具

稍后读客户端，从支持平台的完整度、被第三方支持程度、API 拓展度、作品本身完成度来看，能够提出来说的只有两家：Instapaper 和 Pocket。Instapaper 最近做了全面免费，Pocket 也在找发力点（从 Beta 的功能来看是偏社交）。所以这两家看起来一段时间内不会被别家赶上。

这两个工具，在美感或者说设计、甚至一些功能上（比如 Instapaper 能在阅读界面以弹出菜单来显示脚注），我更喜欢 Instapaper。但在需求上，更能满足我的是 Pocket。原因也在《用 GTD 的方法结束稍后读》里提到过，主要是因为标签，这里简单总结：

  • 标签系统：对于文章这种形式，标签分类比文件夹更加灵活。实质上，在虚拟的系统里，标签本身就包括了文件夹的属性。文件夹也是装东西，标签也是装东西。但东西只能放到一个文件夹里，却能贴上不同的标签。
  • 标签跟随文章归档：Pocket 中文章的标签，无论是未读状态还是归档状态，都是附在文章上的。而 Instapaper 的文件夹里的文章，一旦被归档被和其它文章一样被冲到一堆儿了，不便查找。

但是，我猜大概还是会产生 Instapaper 和 Pocket 孰优孰劣的争执。这可以围绕很多方面来争，但对于一个稍后读服务，我觉得最核心的功能，是抓文。而 Instapaper 和 Pocket 在抓文方面，对于中文内容来说，支持都不完美。而且这件事，也不能用「覆盖度更好或更差」去下判断。这就像有 A 和 B 两个流媒体服务，你想听的大部分歌手的歌，两个库都有，但某位歌手的歌，A 库里没有，那你就没有其它选择，只能选 B，或者不听。这种状态不能用概率或者覆盖量去对比哪个服务支持的中文站点更多，而是有就是有，没有就是没有，对于需求有差异的个人来说，他要阅读的任何一个站点的支持都是重要的。所以在这点我不会去妄下定论说哪一家对中文站点覆盖度更高，继而推荐大家使用那个服务。

但，值得注意的是，由 Ai Search 的开发者 iTodd 团队在开发一款标签收藏兼稍后读的服务，名为 Linnk。在和作者的沟通后，我了解到了他们针对网站覆盖问题的思路：

付费订阅用户有一项特权——Linnk 会优先针对这些用户提出的要求适配的网站进行优化排版。

但客观地说，初期的 Linnk 肯定在支持平台的完整度、被第三方支持程度、API 拓展度、作品本身完成度等地方比不过 Pocket 和 Instapaper。在作品完善到一定程度之前，我也只是对其充满期待。

进一步处理

进一步处理其实分为两个部分，一个还是对文章本身的进一步处理，也就是对文章的精读。另一部分，是有的文章提到的内容，没办法在我们当时的阅读环境和工具上直接实施，需要再放入任务管理软件的合适位置等着进一步处理。

精读

前面说「稍后读服务只能做泛读」，主要是因为它对文章的进一步处理的方式的缺乏。而且我认为，稍后读从定位上来说，也不可能真正去做文章接下来说的精读所需要的功能。

精读在我的流程里分为三个等级：

  1. 资料级，这类文章要批注或摘抄；
  2. 知识级，这类文章要总结知识点，知识结构；
  3. 论文级，这类文章得打印出来好好读。

批注

批注侧重于用例和细节，有时候，道理很糙，例子很妙；也有时候，你觉得这里对那里不对，想在文章里批判一番。总之，这些东西摘出来就不成体系，需要放在文章里才能有更好地理解。

需要批注的文章也可以细分，但简单来说就是，高亮就行的和要对文章有复杂批注（比如删减和评论）的。前者，我放在 Evernote 里批注，用 Instapaper 的也可以在 Instapaper 里直接批注。后者需要把文章导出成 PDF，然后再用 PDF 批注应用来批注。后者这里我这有个简单的例子：The Verge-APP STORE 2.0.pdf\1

，这种批注的目的是减少被分享人阅读的时间，直接显示出文章态度和重点，客观事实，以及自己的看法。

摘抄

摘抄和批注不一样的是，摘抄的句子可以单独拎出来用，不需要放到上下文去理解。因为我主要用 Pocket 阅读，所以我做了个从 Pocket 里摘抄文字到 Evernote 的 Workflow。

总结知识点

总结是把文章的内容抽象化，抛去它的例子和解释，只提取最核心的概念。

很多人说碎片阅读不叫学习，我一直以来也这么想，但我突然觉得，你怎么定义学习？我的答案是，这个东西你感兴趣，通过阅读，你可以把文章里的知识用你的方式讲出来，那你就完成了一次学习。

但想做到「把文章里的知识用你的方式讲出来」，是很难的，要求文章足够好，你理解得足够到位。比如说，关于吃，人们都说「白肉（鸡肉等）」比「红肉（猪肉牛肉等）」好，鱼肉又比这两种都好；豆好、豆腐好、牛奶好、坚果好；还有「少食多餐」好。但你问这么跟你说的人，很少有人能把这个道理简单地讲给你的。

实际原因很简单，因为这些食物蛋白质含量高，而为什么少食多餐，是因为蛋白质一定期间吸收量有限。但为什么蛋白质含量高就好，吸收过量的蛋白质为什么不好。因为蛋白质是人体的肌肉、头发、皮肤、血管、内脏、眼球等等器官的主要组成部分，而过量吸收的蛋白质会变成脂肪。

其实还能再问出来一些问题，比如「补充蛋白质是不是就能长肌肉跟头发」，在这里就不展开了。这里想说明的是，要想把文章的知识变成你的，你要建立一个小型的知识系统，由非常根基的容易理解和记忆的事实出发，以非常好理解的口号式的短语结尾（比如「少食多餐」），把中间的问题系统地搞明白。

最后把脑子里的知识点用自己的方式——以脑图也好，简单的 List 也好——串起来，再配着文章一起存到 Evernote。

打印

打印这个需求针对的是电子屏幕上不愿意读，但你还觉得这种文章重要到了应该读完的那种文章。对于我个人来说，它的判断方式很简单。在读稍后读的时候，我会下意识地看右边的进度条。如果在第一次滑动它的时候，我发现进度条很小而且滑动幅度也很小，我就会心里一沉（比如 这篇）。如果这是篇外语的文章，大多数情况下，我就会把它撂下，看别的。

这种类型的外语文章，我都会选择打印出来看，因为从效率和学习角度来看，打印出来的益处更多：这种文章打印出来读得快，因为不废眼；纸也不会出现下拉弹窗提示我消息；批注起来也更舒服。

而且把文章打印出来以后，你可以把它从稍后读给剃掉，这样阅读这个任务就分化成了两组任务。一边是屏幕上的，一边是纸上的。屏幕上的大长文没了，纸上的文章虽然长但数量不多，压力也会小一些。

看完批注完以后，扫描，上传回 Evernote。

没办法在移动设备上处理的内容

像 Mac 的技巧教程、软件测评、一些工具的 DIY 教程还有购物推荐等等。这些文章在移动设备（阅读的主环境）上无法马上操作，我们也不应该正读文章就跑去逛淘宝，但如果你把这些文章就这么留在稍后读服务里，也不合适，因为会增加你的阅读压力，而且想不起来对其做进一步处理。对于这种文章，我的考虑是，先判断实施的优先性，如果优先度很低（比如比较冷门的 DIY），就直接打标签（DIY）后归档，以后想起来了再在稍后读服务里找。如果优先度高（某个心仪已久的 Mac 应用降价），晚上回家就必须得搞，那就把文章放到任务管理软件，同样也要把文章归档。

进一步处理的工具

不管是精读还是其它的处理方式，实际上都从稍后读服务里把文章发到了一个新的地方。稍后读里就可以把这篇文章给归档了。但是，会有一种这样的情况，你在 Pocket 归档了，Evernote 里的也忘了看了，或者在 Evernote 里要精读的文章被你当天加到 Evernote 里的其它内容给冲乱了。

为了避免这种情况，我把那些需要进一步处理的文章，放在了我的任务管理工具里。这也让我意识到了对任务管理工具的新的需求——它与第三方服务的连通性。传统的任务管理工具无法简单地做到这点，我脑子里马上出现了 Todoist 这个服务，它对 IFTTT 的支持恰好能让我做到我想做的。

我实际上做的，是在 Pocket 中建立一组 Todo 的标签：

0 todo
0-1 print
0-2 annotate
0-3 note
0-4 download

每一个标签，都配有一个 IFTTT 动作，动作的模式都是一样的：

IFTTT 动作

它做到的是：当我在 Pocket 里将一篇文章标记了一个标签，比如是 0-1 print，就会自动把文章发送到我 Todoist 的 From Pocket 列表里，然后建立一个名为：任务指令 + 文章名称 的任务，比如「打印：在线阅读处理流程：从需求、到方法、再到工具」。

Todoist 会在任务上自动做可点链接的处理，你点任务名，就可以跳转到文章。

硬件

在精读这个流程里，除了服务和软件之外，iPad 搭配 Smart Keyboard 是我的硬件选择。

因为 Evernote 对 iPad 的外接键盘的快捷键有很好的支持，其中高亮的快捷键和 Mac 端一致，都是 ⌘ + ⌃ + H。所以在 iPad 上阅读需要精度的文章的时候，可以用方向键来导航，到需要高亮的地方用快捷键高亮。

用键盘完成选择和高亮

而且，总结知识点，也需要用到 iPad 的分屏功能。右边随便开一个支持分屏的笔记软件，左边打开 Evernote。然后知识点总结完以后，粘到 Evernote 里那篇文章的文首。

Evernote & Drafts

屏幕右边我的工具是 Drafts，因为我可以用 Markdown 写。编辑完毕后用内置的 Markdown Preview-Swiss 来生成富文本，再把富文本存到 Evernote 里。

回顾

我的目的是：

  • 每天能够摄取我感兴趣的新东西，而且最好不减少摄取源。
  • 让我每天能够消化这些东西。标准是能今日文今日读，不拖不积；该批注的批注，该做摘要的做摘要。
  • 让我以后想要找到这些信息的时候能第一时间找到，这是重中之重。

为了在实际操作中简单且舒服地解决这些目的，在流程中我运用了这些工具：

收集

  • 来源处要有过滤系统来阻隔我们没有兴趣的信息，所以我用了 Feed Wrangler 的 Filter。其实最好社交网站的客户端也使用那些可以针对性地屏蔽消息的，如 Tweetbot。
  • 通过 IFTTT 做到打星标即可将文章发送到稍后读服务，而不是在 App 内使用 Share Sheet。
  • 微广场可以把微信文章生成全文 RSS 但不能分享至稍后读服务。
  • 因为我要读的公众号文章很少而且要批注，所以会直接通过 Workflow 保存到 Evernote 中。

阅读

  • 要在一个地方阅读是因为「阅读环境的统一性」。
  • 我选择 Pocket 是因为它是标签系统，以及其标签与 Evernote 的兼容性。还有其它我在《用 GTD 的方法结束稍后读》提到的因素。

再处理：

  • 需要进一步处理的文章，分为两部分：精读和执行。
  • 精读的文章分为三种：批注（高亮即可和复杂批注）、摘要、打印。
  • 执行和精读的文章都要在 Pocket 中打上相应的 「Todo」 标签，通过 IFTTT 发送到 Todoist，来提醒自己不要忘了处理这些文章。

日常流程

  1. 首先，参考《用 GTD 的方法结束稍后读》把你的稍后读读完，我行你也行；
  2. 早上起床先看 RSS 和 Twitter，扫完标题收集到 Pocket 后，正式起床；
  3. 出门的电车上看稍后读，设备一般是 iPhone；
  4. 回家的电车上用 Evernote 批注和做摘要，设备是 iPad Pro；
  5. 到家在 iMac 上处理那些要下载的软件和 Mac 技巧之类的文章。

重要的不是工具

这篇文章想要分享的，除了我自己实践已久而且行之有效的线上内容阅读方法之外。也想分享一个我的观点——不要脱离需求地针对工具进行讨论。工具的存在是出于需求，简单的需求需要一个工具，复杂的需要多个工具间的合作，只要需求明确，工具的选择实际上并不会有多大的空间。

讨论的前提是要明确讨论者有共同的需求，大多数讨论终结到「各有各的使用情景」，这样的讨论即便不能说是「压根不该出现」，也可以称之为无效讨论。

我的流程里选择的工具甚至服务，除了 Evernote，可以说都没有限定死，可以依个人喜好来修改更换。所以我希望，如果这篇文章引发了一些讨论，不要再次落回到「因需求甚至审美不同产生的工具选择」上。

  1. Checked 第 14 期在群里分享的资料。 ↩︎
赞 (0)

相关推荐