利益相关声明： 作者与文中产品有直接的利益相关（开发者、自家产品等）

Matrix 首页推荐 

Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。 
文章代表作者个人观点，少数派仅对标题和排版略作修改。

本文速通：最近用了 Raycast，真的很棒！但是没有好用的中文 OCR 插件，不怎么会写 Typescript 的我，在 ChatGPT 的指导下，整了一个小插件。开发过程非常不严肃，充满了野路子，不敢妄称指南，所以就用指北替代一下吧。

原来少数派也用 Raycast？

最近，少数派首页上的一篇文章吸引了我的注意：Raycast 该怎么用？我们帮你准备了一份实用指南。

其实我关注 Raycast 也有一段时间了。在他们初期的 Beta 阶段时，我就已经申请了内测。作为一个和 Spotlight 对标的产品，在原有搜索功能的基础上，对搜索结果进行了更好的呈现。同时，丰富的插件社区也让他的可用性大大增强。

作为联想，我最优先想到的对标产品是 Utools 和 Alfred，都有很好的搜索结果和丰富的第三方插件社区。但是他们各自也都有一些小小的问题。

首先聊聊 Utools。不得不说 Utools 在 MaxOS 上的搜索做的确实不够优秀，且在性能上也有不小的问题，使用翻译等网页插件响应时间过长。在搜索上，Utools 也不尽如人意。在 Windows 上，有 Everything 对 NTFS 格式的加持，Utools 也确实有足够优秀的效率。而在 Linux 和 MacOS 上，姑且不说没有了搜索性能带来的红利，插件设计也发生了严重割裂。和 Windows 的文件查找使用了不同 UI ，而且不能对文件进行预览。这些都限制了 Utools 在 Mac 以及 Linux 平台上取得更大的成功。而且在前些年，不合理地收费行为属实是让 Utools 口碑崩坏的一张烂牌。在剪贴板、录屏等最吸引用户的核心插件上，Utools 加上了「仅限会员」的使用限制。但是日子还得过，而且有好心人提供的第三方插件作为替代，我也就这么用下去了。

再聊聊 Alfred。作为老牌产品，Alfred 的设计非常精妙，不得不提的是，它对开发者来说出乎意料友好。哪怕是编程小白，面对 Alfred 的插件编辑也可以一目了然。既有丰富的节点可以拖拽使用，也可以在 Shell 节点中进行各种操作，兼顾了不同编程能力的用户。相比之下，Raycast 和 Utools 的开发依赖 Typescript 和 JavaScript，对开发者还是有相对比较高的门槛的。以及最重要的一点，Alfred 有一点小贵，而且其中大部分功能都有平替。作为价格敏感的用户，我最终还是没有选择长期使用 Alfred。

所以，在 Raycast 横空出世之后，我果断选择了这一新秀。精致的 UI 以及对苹果原生的设计吸引了我。此外 Raycast 的竞争力还凸显在 AI 上。它将 ChatGPT 中的许多功能直接接入，提供了「文章润色」、「代码修改」等内置 Prompt，极大的提升了生产力。根据我个人的 OpenAI API 的使用频率，我的月使用量在 $8-12 之间不等。这个区间和 Raycast 的价格区间不谋而合。如果我没有充值 ChatGPT，我大概率会直接选择 Raycast Pro 了。

所以……我最终的决定是，使用「免费版 Raycast」 + 「ChatGPT 插件」。毕竟自己还是个学生党，能省点还是省点吧。Pro 提供的 AI 可以用 ChatGPT 插件替代。免费版可以提供一周的剪贴板记录，这对我个人而言也非常够用，Pro 提供的过多记录反而会有潜在的安全问题。

在整理了自己的需求之后，我慢慢地把自己 Utools 的插件迁移到 Raycast 中，大部分 Utools 工具在 Raycast 上都有对应的插件，而且 Raycast 的全局快捷键功能让插件使用变得更加方便。一切都是那么完美，直到昨天晚上和朋友聊天的时候，发生了一些尴尬的小插曲。中途想将网页图片上的文字复制给他，所以使用了 Raycast Store 中的 「Recognize Text」 插件。可是不论我怎么扫描，都只能识别出乱码。一开始以为是 OCR 的问题，以为图片不够清楚。可是图片存储到本地之后，MacOS Preview 中原生的 OCR 是可以进行精确识别的，那么问题就锁定在了插件上。

ChatGPT 助力，开发不再难

如果只是需要使用插件可以跳过本章节，在后记 1 和 2 中对插件如何使用进行了介绍。

既然发现了问题，就要解决问题。而从其他成功案例中汲取经验无疑是一条捷径。作为一个 Utools 的老用户，对它的各种 OCR 文字识别插件都有一定的使用经验。大体上来看，Utools 大部分的 OCR 插件都是通过调用 API 进行实现的。为此，当时我自己还注册了搜狗和百度账号，当时的 API Key 和 Secret Key 还有存留。所以我脑海中一个最为直观的想法是：直接做个新的 OCR 插件，支持 Baidu OCR API。

虽然说起来轻松，但是我看到 Raycast 的插件开发介绍页面时，心里还是咯噔了一下。上来就是一个 import { ... } from '@raycast/api'，陌生的包让我直接感到了害怕。不过稍加浏览之后，发现 raycast package 里的各个组件模块都有丰富且完善的例子作为参考。稍稍放松了下来之后，就开始莽起来了。

首先整理思路：我需要的是获取 OCR API Key，连同将剪贴板中的图片一并送入 OCR API，将最后的结果复制回剪贴板中。拆解之后，就是 4 个简单的小步骤：

思路明确之后，开始逐个击破。在 Raycast Create Extension 中填写了插件的名称、功能等信息之后，使用模板创建了一个插件：

插件的基本信息和模块在 package.json 中进行注明，参考官方指南的 Manifest 页面。这里参考了 Raycast preferences 中的说明，设置了 API Key 和 Secret Key 的输入窗口。直接把 Key 在代码中写死确实过于僵硬了。

代码主体则在 src 目录下，开发语言是 Typescript。我的个人开发习惯是模块化设计，我把最重要的 OCR 功能模块进行了独立实现，放在 utils.ts 文件中。为了更好的使用 Baidu OCR，我在官方文档中进行了浏览和检索。出乎我意料的是，官方不仅给了 API 手册，还给了一些调试工具。最让我惊讶的是，官方直接给了不同语言的范例。这下好了，可以直接可以抄作业了。

登录百度智能云的控制台，选择「文字识别」服务。在「公有云服务」-「API 在线调试」中，可以看到如下的界面；

直接拿了 Node.js 的「通用文字识别-标准版」的代码。不过代码是 JavaScript 的，和 Typescript 有一些差异，直接编译会有一些报错。而我个人其实并没有太多的 Typescript 开发经验，仅限于在别人的代码上涂涂改改。所以我借助了 Raycast AI 的帮助，趁着自己还没结束 Beta 版本的使用，赶快多薅点羊毛。

问题在 import 模块上，拷贝过来的代码上有大量的 require('xxx') 。在 JavaScript 中，确实没有问题，但是 Typescript 中发生了报错。我认为这个大问题是两个潜在问题共同构成的：

1. 如何在 Typescript 项目中安装对应的 JavaScript 包
2. 如何在 Typescript 中正确的使用他们

Raycast 的回复也让我非常满意：

之后是关于剪贴板的处理，Raycast Clipboard 中有详细的关于复制和粘贴的接口说明。初次使用的时候我遇到了一些小小的问题，尽管我获取了剪贴板中的图片路径，但是无法对文件内容进行读取。为了测试，我使用 console.log 输出了剪贴板中文件的路径：

我的个人猜测是，可能是其中的 %20 导致的，其正确对应的字符应该是空格，而编码之后变成了这样的形式。那么事不宜迟，问问 GPT 我应该怎么读文件：

两次问答之后得出了我想要的结论，让我非常满意。之后的步骤就是将之前的工作串联起来，我也很快就弄出了自己满意的插件：raycast-baidu-ocr。

在这里再次对 ChatGPT 表达诚挚的感谢。出于偷懒，我直接对剪贴板中的图片进行识别。于是自用的 Baidu OCR 插件就这么诞生了。

后记 1：发布真的太难了……

做完一切之后，我也想试着发布这个插件，但是随之而来的繁琐步骤也确实让我产生了动摇。

在 Raycast Publish 上对插件的发布进行了详细的规范：

• 图标设置，需要有 512x512 的 png 格式图标
• 代码风格规范
• 文档说明和补充
• 初始页面，对于需要 API 输入的插件需要设置引导页面让用户输入 API……

规范确实是一件好事情，不过这些也确实打消了我共享插件的热情。但是我个人觉得，Raycast 的插件社区未来一定会有更好的发展空间，有了规范的插件社区管理和运维，就不容易出现管理上的问题了。

所以作为一个懒人，我就直接偷个懒，选择在少数派上发布自己的插件了。使用方法也非常简单，在下载 Github 上的代码之后，使用 Raycast 的 「Manage Extensions」，即可将插件导入：

之后在插件配置中输入自己的 API Key 和 Secret Key 即可使用：

由于这款插件更多的目的是自用，所以使用方法和 Recognize Text 插件有所区别：

1. 使用系统默认的截图「Copy picture of selected area to the clipboard」，或者使用第三方可以将截图复制到剪贴板的工具
2. 使用 Raycast 呼出插件
3. 识别出的文字已经在剪贴板中了

这里如果少数派有好心人愿意帮忙，可以一起交流探讨一下后续发布的事情，非常欢迎大家和我进行讨论交流。此外还有很多提升和发展的空间：

• 兼容更多 OCR API
• 二维码识别
• 换行自动处理
• 更详细的文档
• ……

后记 2：中文识别有没有可能是……

思来想去，我觉得目前位置的 OCR 插件不应该这么鸡肋。如果 MacOS 的 Preview 都能够自动识别中文和多语种混合，那么 Raycast 的 OCR 理应也可以做到才对。

在这种好奇心驱使之下，我重新审查了一下 「Recognize Text」 的代码。他的 OCR 确实也是直接调用了 MacOS 原生的接口，而且通过 Swift 语言，直接对 OCR 部分进行了封装。那么 Swift 中 OCR 能否支持中文呢？ChatGPT 给出了肯定的答案，并且塞给了我参考代码：

之后的事情也就变得简单起来了，具体步骤如下：

首先 Clone 了原项目的地址：ScreenOCR - Github。之后同样在「Manage Extensions」中导入插件。

在项目的 Sources/recognize-text/main.swift 的 68 行加上中文和英文的支持： 

request.recognitionLanguages = ["zh-Hans", "en"]

最后，编译 Swift 模块并打包插件： 

npm run build-swift
npm run build

此时，Recognize Text 插件也能够识别中文了。

小结

这次的开发故事确实是一个非常不严谨的整活。代码风格、开源规范等一系列的开源社区的规矩我也没有过多注意，也请大家轻喷。毕竟是一个自用项目，我觉得勉强也说得过去。Raycast，确实是一个好工具。而 ChatGPT 也确实是我现在日常开发的助力神器。期待 GPT 早日帮我处理发布、代码规范等后续的繁琐步骤，真正解放生产力。

后续

关于多语种识别的问题已经向 ScreenOCR 作者提交 Pull Request，相信多语种的 OCR 很快就会正式进入 Raycast Store 了。

> 下载 少数派 2.0 客户端 、关注 少数派公众号，解锁全新阅读体验 📰

> 实用、好用的 正版软件，少数派为你呈现 🚀

© 本文著作权归作者所有，并授权少数派独家使用，未经少数派许可，不得转载使用。