作为截图 OCR 的「始作俑者」，我要说几句…

首先，证明一下我是这个需求的提出者

这是我和 Jason 的聊天截图，无任何伪造。看完以后应该可以判断出来，截图 OCR 这个需求是我先跟 Jason 提出来的。

然后这是第二个证明，这是我当时花了一个小时写出来的 OCR 工具：CapOCR ，你们可以看看时间，最后一次提交是 11 月 4 日。

然后接下来是做个自我介绍。

我是一名兼做 ID 与 UX 的设计师，不还算不上，目前正是大四，以下是我的 博客 与 作品集，有兴趣的小伙伴可以看看。

没有兴趣听我一句总结：

在这个话题下我的身份是对效率类工具有深刻洞察力的用户和半吊子码农。

截图 OCR 存在很大的需求，但是普通人无法意识到这个细分领域的机会

这是第二个要说的部分，截图 OCR 这个需求确确实实存在，而且没有被很好地满足。以下进行详细展开。

从一个很简单的问题开始：为什么我能意识到？因为我用了一个大纲软件叫「幕布」。

用一句话来介绍「幕布」这个大纲式写作工具的话，它就是文字工具的思维导图。

它有什么用呢？简单来说就是可以像思维导图那样来记录文字。好处就是，可以用结构化的方式来记录资料，并且无限细分下去。这就非常适合来整理文本资料或者梳理知识体系，非常适用于如今的碎片化学习。

事实上我在整理自己的知识体系的时候，有两类资料是最常用的，一类是网页资料。网页资料非常容易处理，我直接复制粘贴就好。而另一类则是书籍，很多都是以 PDF 形式存在的。而中文类的 PDF，要把内容拷贝出来，就非常困难。没有 OCR 工具根本实现不了。

比如说上图的部分内容我一开始是自己手打进去的。

很多不错的资料都是在一本本书籍当中的，当我尝到结构化梳理知识的甜头之后，我越发需要把一本本书中的信息梳理到我的幕布知识树中。而类似这样的次数越来越频繁，迫使我去寻找 OCR 工具。

但是，现有的工具均满足不了我的需求

我一开始是找到了微软的 Onenote 自带的图像识别功能，但是它的问题有两个：一个是图片复制进去之后，我必须等图片同步完，过一段时间才能看到复制 OCR 文字的按钮，但是一方面 OneNote 上传很慢，另一方面这个识别过程也没有任何识别进度的提示，我往往要等好久才能看到复制 OCR 文字这个选项；第二个是复制出来的文字之间，必然包含着空格，这个很难受，必须做一次替换。所以貌似是最「轻量级」的解决方案，但是最后的体验却是非常「重」。当次数比较少的时候，这个功能还凑合着用，但是面对以上我所描述的需求场景时，次数变得极为频繁的时候，就变得非常「难用」了。

然后接下来是 ABBYY FineReader、OCRKit、Prizmo 等一系列 Mac 上有名的 OCR 工具。这些工具清一色的需要手动导入图片，等待识别，再导出文件。注意！！我识别一段话需要特么截个图保存到本地，然后再导入图片，再导出文件，再打开文件，再复制进幕布！这个过程都够我全部手打完外加喝一小口奶茶了。何况 ABBYY FineReader 这个号称是识别率最高的 OCR 工具，在面对中英文混合甚至一些普通中文图片的时候，识别率都差的要死。

各位看官注意，我再总结一下我的需求：在幕布和书籍文档各占用一半屏幕的情况下，最「丝滑」地完成文字转移工作。

丝滑的终极要求如下：

• 识别过程中最小程度影响工作流。（反例：ABBYY FineReader 等普遍 OCR 工具和网页端的截图 OCR 工具）
• 识别出来的文字最好能够还原书籍中的样式。比如保证段落不变，加粗不变、序号不变等（反例：OneNote 的 OCR 工具和 ABBYY FineReader 一些特殊场景下的识别结果）

第二个要求基本上很难有完美能够实现的，但是主要的问题在于：90%以上的 OCR 工具第一条都没法满足，对整个工作流的影响太大，使用的体验太「重」。另外，FineReader 的全文识别在这个场景太重，根本用不到，实际需要的不过是一些片段。而能够满足第一条的 OCR 工具要么识别率不行，要么是太 Geek 的东西。

所以我最后得出的结论是：Mac 端根本 「没有」 能够满足以上需求场景的 OCR 识别工具。 而面对这个需求场景下，我自己能想出来的最直观的方法是：截图进行 OCR 识别，然后将识别出来的文字复制到剪贴板，出来的文字如果可以用就直接粘贴，如果不行就在这个面板里面稍微编辑一下再复制，这样就十分完美了。

PS：在发这篇文章之前，我又翻了一下一些人提到的 OCR 工具，有些的确是没见过（主要都是英文工具的），但是英语的 OCR 工具我是根本提不起兴趣去试的—— 90%以上会是中文读不出来或者识别不好。更何况有些是要在 Mac App 中先买了才能测试。所以作为一个普通用户，我得出的结论还是没变。

所以当有人提到：

我没有怼完发一个链接，而是自己花两个小时做一个，是为了告诉大家，这个东西多不值。

我只能呵呵，交互？大哥，你用了全世界都在用的交互，截图，出 ocr 文字，这种交互在 win 上有多少？在 mac 上有多少，你创新有多少，哗众取宠的推广和某些用心，大家不是傻子，看得出来你想玩啥的好么

“额，因为产品需求太普遍，类似于 hello world 一样，每个学习过模式识别的人都做过类似的东西，这种东西是没办法商品化的。而且市面上免费的同类产品汗牛充栋，很容易找到替代品”

我忍不了。

我必须站出来把这个需求给你们讲清楚，你们特么又没感受过这个需求场景，瞎比比啥！？我问问哪个产品能够满足我的需求了？你们特么有花时间研究过么？有找过么？要是真有我有必要费那么多心思找和试那些工具？要是真有我特么为啥后面还要自己写？！

怎么发现的 OCR 接口？

有人说 Jason 弄的不过是一个信息不对称。但是很抱歉的是，他一开始也不知道这个东西，还是我给他说的。但是怎么样发现的呢？

本来已经忘了，但是我翻了下自己的浏览器历史记录。

历程大概就是用 Google 搜了一堆之后试用了 ABBYY FineReader 和一些其他的识别工具，但是不满意。过了一个月想起这个事情换了个关键词搜，结果就搜到了百度 OCR。

可能当时百度 OCR 在打广告，不然如果按照今天的搜索结果来，我可能就会用腾讯的 API 了。

然后我当时正好在学 JS，作为一个半吊子码农，就自己照着百度的 OCR 工具写了个脚本，连正则表达式还是照着网上抄的，更不会做什么封装。看我的记录应该是 11 月 1 号写完的，花了 1 个小时不到，就 30 行不到的代码。

我的操作逻辑是：

快捷键截图 -> 按快捷键利用 iPic 上传图片 -> 快捷键粘贴获取的链接到第 22 行 -> 快捷键运行脚本 -> 快捷键复制打印值。

整个过程只需要 5 次快捷键。

那为什么会用这种操作逻辑，原因就是我不懂怎么读取本地图片，更不懂怎么把截图的图片复制到剪切板。看到百度 API 可以直接用网络地址，正好我也有用 iPic 上传图片，那就偷个懒直接上传地址。然后这个可笑的正则表达式更是为了方便我直接粘贴 iPic 返回的地址，不用去手动处理掉 Markdown 语法，返回的其实就是图片的网络链接。

哪怕在真正的使用过程中，我必须要开着 Atom，但是还是用着非常爽，哪怕还是要切换一个次页面，按 5 下快捷键，但是整个体验已经远远甩 ABBYY FineReader 等 OCR 工具好几条街了，同时识别率惊人地好。

作为一个效率类工具的「领先用户」，我一直追求更加丝滑的用户体验。

关于「领先用户」，Eric von Hippel 是这么定义的：

领先用户是在市场普及之前的数月或数年就体验需求并能从产品创新中大幅受益的用户。

来源：THE SOURCES OF INNOVATION. Eric von Hippel.1988

但是由于我的编程水平才刚刚入门（既不懂正则，也不懂数据结构，更不懂单元测试，最多就能做个 Demo，哦不，按 CaptuocrToy 的实现程度，这个连 Demo 都算不上），很难在短时间内实现到我最终的意图。 所以我寻思着，要是能够更加爽就好了。

感受用户需求，思考解决方案，促成产品，满足需求。

然后我就找上了 Jason，有了你们一开始看到的对话。（能认识 Jason 也是因为 iPic。我用 Markdown 来进行信息的管理，处理图片的时候这个工具非常受用。）

再接着，Jason 的在我跟他描述完整个需求后的第四天，就把这个工具做出来了。

在我跟 Jason 提这个需求（ 11 月 9 日）的四天之后(11 月 13 日)，Jason 就把内测版工具发给我测试了。

当然，我知道这个工具的开发肯定用不了四整天（他后来也有提，原型可能就一天），但是说实话，我当时是十分惊讶的。因为我并没有指望着 Jason 会去做我的提议。我相信大部分人的想法肯定都是这样：

“额，因为产品需求太普遍，类似于 hello world 一样，每个学习过模式识别的人都做过类似的东西，这种东西是没办法商品化的。而且市面上免费的同类产品汗牛充栋，很容易找到替代品”

另外在写 CapOCR 时我观察到百度 OCR 识别接口有人在 2015 就做过封装，放在了 V2 上。但是没有一人能够像我发现这种具体的需求场景，然后促成某个产品。如果有，我相信 2015 年就有 iText 这类工具出现了，但是很遗憾，两年过去了我还是没有找到。没有一个人在懂了「模式识别」或者在知道 OCR 识别 API 之后再去深入挖掘过真正的用户需求点，做个什么产品出来。 大部分程序员都是会掉入技术本身这个陷阱，这一点在我学习编程的过程中感触非常深刻。所以如果 Jason 对这个不感兴趣，我以后这方面懂了的话还是会做的，毕竟需求在那里，大家只是视而不见。

再回到实现出 iText 这个问题上，正是因为我知道大部分程序员抱有如上的想法，所以我只是抱着侥幸心理去和 Jason 提，并不指望他就会照着我的意见去做。而且目前我自己写的那个小脚本也能凑合着用。

但是让我感到惊讶的则是他真的去做了这件事情。至少在这次 iText 里，Jason 的行动非常完美地验证了他朋友圈的这句话。

「感受用户需求，思考解决方案，促成产品，满足需求。无 Title 」。

作为结果，iText 可谓是开创了一个细分领域，在一片蓝海中找到了红海，没有毛病。

而且正如 Jason 在另外一贴中所述，他在完成第一版原型之后，一直在做的都是「段落识别」这个非常强烈的需求，而这个需求，是我跟他提的另外几个重要特性之一，并且足以拉开和其他 OCR 工具的距离。

当然有人可能会说，如果你把这个需求告诉我，我也一样会给你开发出来巴拉巴拉的。但是很可惜，我并不认识你。能够认识 Jason 也是因为在某些人眼中 “污染环境 Mac 环境” 的 iPic 这个工具。你们放不下身段去做一些没技术含量的工具，自然看不到那些体量巨大的用户需求，接触不到新的想法。

毕竟这不是技术上的问题，而是思维方式上的差距。技术的目的是更好的解决问题，而不是作为内耗的工具。

针对工具本身的分析

再拿 CaptuocrToy 和 iText 这两个工具本身进行一下分析。

CaptuocrToy 肯定没有认真考虑过界面，背景的颜色使得字基本看不出来，而 iText 则是用相对亮一点的颜色，使得文字能够比较清晰。另外显示图片这件事在前面这个需求场景中并不是一个必要的元素，因此每次都显示图片只是对空间信息的浪费，对用户的干扰，相比之下，iText 就处理得当。

而且另一个关键的「段落识别」这个特性：

在经过段落文字优化的 iText 对一整个段落识别良好，但是直接调用 OCR API 的结果就是一个段落也被拆成好几段。这个不是个例。在 iText 优化之前一样存在这个问题。（上周识别了一份 18 页的英文文献，基本上每个段落都是像这样识别不好。）但是新版本（ 1.1.2 ）改进了很多。

还有一个小细节，CaptuocrToy 的截图识别快捷键是 CMD + SHIFT + C，作者肯定没意识到这个快捷键是被 Finder 的「电脑」给占用了。看了下首选项也没有给改的设置，如果无法快捷键识图，那么这个工具算是鸡肋了 1/3 吧。而 iText 则是给出了快捷键配置选项，同时默认的快捷键一般情况下也没有被占用。

以上这些地方，就是对用户需求理解不深刻，导致的「画虎不成反类犬」。另外事实上，按我前面所述的需求场景的定义下，CaptuocrToy 已经可以算是抄袭了吧。至少我没有在 Mac 端看到有另一款和 iText 一样的工具。而这两个软件的操作和使用逻辑完全一样，程序的实现逻辑应该也完全一致。

但是抄袭不抄袭，对我来说倒是无所谓，也许多一种选择似乎也是好的。

但是，我们还是需要小心「子贡」

无意间看到 V2 上大家的讨论，说实话，本来不想出面，但是后来意识到这个问题其实严重，还是觉得必须声援 Jason。

因为，如果大家都在反对 Jason 这样的行为，到最后吃亏的还是用户，换句话说，吃亏的还是我。

这个事件本质和「子贡拒金」非常类似。

春秋时期，鲁国法律规定：如果鲁国人在外国看见同胞被卖为奴婢，只要他们肯出钱把人赎回来，那么回到鲁国后，就可以从国库领取报酬和奖金。这道法律执行了很多年，很多流落他乡的鲁国人因此得救，得以重返故国。

后来，孔子的一个学生，叫子贡，很有钱。他从国外赎回来了鲁国人，但却拒绝了国家的报酬和奖金，因为他自认为不需要这笔钱，情愿为国分担赎人地负累。孔子却批评他，说：“子贡做错了。从今以后，鲁国人将不会从别国赎回奴仆了。”

鲁国原先的法律，所求的不过是人们心中的一个‘义’字，只要大家看见落难的同胞时能生出恻隐之心、只要他肯不怕麻烦去赎这个人、去把同胞带回国，那他就可以完成一件善举。事后国家会给他补偿，让这个行善举的人不会受到损失，而且能够因为他心中的‘义’ 而得到大家的赞扬。长此以往，愿意做善事的人就会越来越多。所以这条法律是善法。

而子贡的做法，固然为自己赢得了更高的赞扬，但是同时也拔高了大家对‘ 义 ’的要求。往后那些赎了人之后去向国家要钱的人，不但可能再也得不到大家的称赞，甚至可能会被国人嘲笑，责问他们为什么不能像子贡一样为国分忧。子贡此举把‘义’和‘利’对立起来了，所以不但不是善事，反倒是恶行。因为这样，自子贡之后，很多人就会对落难的同胞装做看不见了，因为他们不像子贡那么有钱，或者他们不像子贡那么喜欢出风头。于是，很多鲁国人会因此而不能返回故土。所以孔子才批评子贡。

这个道理同样适用于此。大家需要警惕的不是那些赎同胞的「鲁国人」，而是「子贡」啊！也许这次有了开源的 CaptuocrToy，大家都很开心。但是轮到下一个新的需求了呢？如果因为怕被舆论说没技术含量，又要收费之类的闲话导致开发者不愿意去开发没技术含量的付费软件，导致用户提出的需求哪怕付费也没法没法满足。这个亏，估计就只有用户自己吃了。但是「子贡」可不管啊，毕竟他做 APP 就有七位数的年收入呢。 所以在这里，我还是觉得大家要小心「子贡」啊。

最后的总结

虽然 Jason 没有提到我给他的启发，不过对我来说无所谓，毕竟结果是这个工具满足了我的需求，还会不断优化，那我找 Jason 目的就已经达成了。 iText 一个月 6 块钱不足一顿饭，但是这对我来说，却是我自我完善知识系统必不可少的工具之一。而实际上一开始就打了对折，一年也就 30 块，可以说是非常划算了。举个例子，用 iText 配合欧路词典我在几天之内就翻译完了一份 18 页的学术文献，没有 iText 高效提取文字，我至少要多花十几小时，并且还要有两三倍以上的耐心。这种程度的价值转换，可以说是超值了。

像 iText 这样的产品需求在我脑子还有不少，只是志不在此，能力和精力也有限，所以更希望是有更多的人能够像 Jason 这样来实现更多的产品需求，并持续完善下去，给大家的生活带来更多的便利，而不是重复造轮子。

所以在 iText 这个产品上，我的感悟和 Jason 在朋友圈里发的这段话一样。大家应该考虑一下能不能够做个众筹平台，而不是像这次一样，为了个收费模式、交互模式、技术难度内耗半天，大家都累。

好吧，啰嗦了一堆话，也算是对这档子事做了个自我总结。如果有小伙伴对我感兴趣，可以留言交流一下~