raycast/extensions：一个把 macOS 启动器变成自动化平台的巨型仓库
扩展 Raycast 所需的一切。 Raycast 扩展 Raycast 让您只需按几下按键即可控制您的工具。
秒懂
- 它是什么？
- 这个仓库收纳了 Raycast Store 里所有扩展的源码、文档和 React 示例。它解决的是“如何让工具用键盘就能控制”的问题，但它的体量和社区规范决定了它只适合特定人群。
- 适合谁用？
- 适合谁：日常重度使用 macOS、愿意用键盘替代鼠标、并且有 TypeScript 和 React 基础的人。你可以从 developers.raycast.com 的 API 文档开始，先读仓库里几个小型扩展的源码，再尝试提交自己的第一个扩展。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它到底解决什么问题
Raycast 是一个 macOS 上的启动器，但它的野心不止于启动应用。这个仓库的存在说明一件事：Raycast 想让你用几下按键就控制所有工具。问题在于，每个工具都有自己的界面和操作方式，统一控制需要桥接层。这个仓库就是桥接层的集合。它包含了 Raycast Store 里所有扩展的源码，以及用 React 扩展 Raycast 的文档和示例。换句话说，你不需要从零开始写桥接代码，而是直接借用社区已经写好的扩展，或者参考它们来写自己的。它的目标读者是两类人：一类是想直接安装扩展来用的普通用户，另一类是想为 Raycast 写新扩展的开发者。前者去 Store 安装即可，后者需要研究这个仓库。
仓库里有什么，以及它是怎么组织的
从 README 看，这个仓库不是单一项目，而是一个巨大的 monorepo。每个扩展是一个独立的目录，有自己的 package.json 和源码。主语言是 TypeScript，扩展的 UI 层基于 React。这意味着你写扩展时，不是用传统的方式来构建界面，而是用 React 组件来描述命令的输入输出。数据流大概是这样的：用户在 Raycast 里输入关键词，触发某个扩展的命令，扩展的 React 组件渲染结果，用户按回车或点击来执行动作。仓库本身不包含运行时，运行时是 Raycast 应用提供的。所以这个仓库更像是一个内容库，而不是一个可独立运行的软件。它的价值在于积累，所有扩展共享同一个 API 和设计模式，让后来者可以模仿。
怎么开始：文档、示例和社区入口
README 给出了明确的起点。第一步是访问 developers.raycast.com 来了解 API。第二步是去 Raycast Store 安装现成的扩展。如果你想提交自己的扩展，必须阅读并遵守三份文档：Community 指南、Extension 指南和 Acceptable Use Policy。这些文档在 manual.raycast.com 和 raycast.com/aup 上。反馈渠道是 GitHub issues，专门用来处理 API 相关的问题，包括 bug、改进建议、开发者体验和文档。仓库还提供了几个示例模板，链接在 developers.raycast.com/examples。实际命令是 git clone https://github.com/raycast/extensions.git，然后进入某个扩展目录安装依赖。但注意，仓库里没有给出具体的 npm install 或 build 命令，你需要参考单个扩展的 README 或 package.json。
一个明显的局限：依赖 Raycast 本体
这个仓库的所有扩展都依赖 Raycast 应用本身。没有 Raycast，扩展就是一堆无法运行的 TypeScript 文件。这意味着你不能把扩展移植到其他启动器上，也不能在 CI 环境里无头运行。如果你不是 Raycast 的用户，这个仓库对你毫无用处。另一个限制是，扩展的开发体验完全绑定在 Raycast 的 API 上，而 API 的演进由 Raycast 公司控制。如果 API 发生破坏性变更，所有扩展作者都要跟着改。这种集中式模式的好处是统一，坏处是单点依赖。README 没有提到扩展的测试策略或持续集成，所以你不清楚扩展的代码质量如何保证。仓库的体量很大，但没有任何构建或测试的顶层说明，这对新手来说是个障碍。
它不适合哪些场景
如果你要控制的是 Windows 或 Linux 上的工具，这个仓库帮不了你。Raycast 是 macOS 专属，所有扩展都跑在 macOS 上。如果你需要的自动化逻辑很复杂，比如跨应用的数据流、后台定时任务，扩展模型可能不够用。Raycast 扩展本质上是对用户交互的响应，不是后台服务。你无法用这个仓库来构建一个无人值守的自动化系统。另外，如果你不想用 React 写界面，而是偏好纯命令行或原生脚本，这个仓库的示例会显得多余。它的设计哲学是“用 React 描述一切”，这对不熟悉前端生态的工程师来说是一种负担。
替代方案：Alfred 的工作流和 Keyboard Maestro
如果 Raycast 的扩展模型不适合你，Alfred 是另一个 macOS 启动器，它的工作流（Workflow）系统采用不同的方式。Alfred 的工作流可以用图形化界面来拼接节点，也可以写脚本来实现逻辑，不强制你用 React。它的生态更老，积累的第三方工作流也很多。另一个替代是 Keyboard Maestro，它不只是一个启动器，而是一个宏工具，可以录制和触发任意 macOS 操作。区别在于，Raycast 扩展是声明式的，你写一个 React 组件来描述界面和动作；Alfred 工作流是过程式的，你定义输入、处理和输出；Keyboard Maestro 则是事件驱动的，你设定触发条件。如果你喜欢代码和 React，Raycast 更顺手；如果你喜欢可视化编排，Alfred 更直接；如果你需要系统级的自动化，Keyboard Maestro 更强大。
维护成本与许可证
这个仓库采用 MIT 许可证，所以你可以自由使用、修改和分发扩展代码，只要保留版权声明。但注意，MIT 许可证只覆盖代码本身，不覆盖 Raycast 的 API 或应用。你的扩展要运行，必须依赖 Raycast 的专有软件。维护成本方面，因为仓库是集中管理的，Raycast 公司会审查提交的扩展，你需要遵守社区指南。这意味着你的扩展不是提交完就完事，后续如果 API 更新，你可能需要跟着更新。README 没有提到扩展的版本管理策略，所以你无法从文档中知道扩展是否会自动更新。从仓库结构看，每个扩展是独立的，所以你可以单独维护自己的扩展，不必关心其他扩展的变化。但如果你使用别人的扩展，你需要依赖原作者的维护意愿。
编辑结论
适合谁：日常重度使用 macOS、愿意用键盘替代鼠标、并且有 TypeScript 和 React 基础的人。你可以从 developers.raycast.com 的 API 文档开始，先读仓库里几个小型扩展的源码，再尝试提交自己的第一个扩展。不适合谁：对命令行和快捷键无感、或者只想用现成工具而不想写代码的人，这个仓库对你没有直接价值。采用前需要先验证两件事：一是 Raycast 本身是否是付费订阅，二是你的扩展是否符合仓库的 Community 和 Extension 指南以及 Acceptable Use Policy，否则提交可能被拒。这个仓库的真正门槛不在技术，而在社区规范。
社区笔记