最近整理 832OS 的过程中，我顺手把 Raycast 也重新定位了一下。

以前我对 Raycast 的理解比较简单：它是一个启动器，能搜应用、跑脚本、打开链接。现在我觉得更准确的说法是：

Raycast 是个人系统的入口层。

换言之，固定的WorkFlow，就应该用他，他执行很快，你想想，如果是在 Codex 或者 claude code 中告诉 Agent 新建一个 Issue，那么要等他思考🤔，等很久，但是使用 RayCast ，它会快很多很多。并且其实后面这些脚本也可以告诉 Agent 。

它不应该保存知识，也不应该变成新的内容源头。它最适合做的，是把已经存在的工具和系统快速接起来。

1. 固定页面，用 Quicklinks

我经常需要打开 832OS 的 GitHub 仓库，看 Issue、Discussion、Action、Project。

这种场景没必要写脚本，Raycast Quicklinks 就够了。

比如：

• 832OS
• 832OS Issues
• 832OS Discussions
• 832OS Actions
• 832OS Projects
• 832OS Pull Requests

这些本质上都是固定 URL。用 Quicklinks 的好处是简单、稳定、可搜索，不需要维护脚本，也不需要额外权限。

这类入口应该越轻越好。

这个在工作中也管用，比如内部系统经常使用到的，就可以使用这个功能，不然，每次打开浏览器然后搜索，挺费劲的

2. 浏览和管理，不用 GitHub 插件

Raycast 有官方 GitHub 插件，可以看 Issue、PR、Workflow、通知，也可以搜索仓库。

但还是要定制符合自己定制的，所以，写个脚本，配合 gh cli 完全得会更好

3. 快速发送，用剪贴板脚本

我平时的想法可能来自 flomo、Obsidian，也可能只是任意编辑器里的一段文字。

最自然的流程不是再打开一个新写作工具，而是：

写好内容
  -> 复制全文
  -> Raycast 一键发送
  -> GitHub Issue / Discussion

所以我做了两个脚本：

• Send Clipboard to 832OS Issue
• Send Clipboard to 832OS Discussion

规则也很简单：

第一行 = 标题
剩余内容 = 正文

• Issue 用来承接待办、行动项、bug、需要处理的问题。
• Discussion 用来承接想法、开放问题、长期讨论。

这样做的好处是，

• Raycast 不参与写作，只负责发送；
• GitHub 负责承接协作对象；
• 832OS 本地不需要再同步一份 Issue 或 Discussion 的影子目录。

4. Raycast Notes 不一定要用

一开始我也想过：能不能用 Raycast Notes 来写 Issue？

后来发现没必要。

如果只是“先写一段，再复制发送”，那 flomo、Obsidian 或任意编辑器都已经能做。再引入 Raycast Notes，只会多一层临时工具。

所以现在的边界是：

flomo / Obsidian / 任意编辑器：负责写
Raycast：负责发
GitHub：负责承接
832OS：负责长期结构

工具不是越多越好。入口越清楚，系统越稳。

5. 一个小坑：中文剪贴板乱码

这次还踩了一个很实际的坑：从 Raycast Script Command 读取中文剪贴板，发到 GitHub Discussion 后变成了乱码。

原因不是 GitHub 渲染问题，而是脚本执行环境里的编码不稳定。Raycast 启动脚本时，环境变量不一定和终端完全一样。

修法也很直接：

• 脚本里显式设置 UTF-8 locale。
• 用 pbpaste -Prefer txt 读取纯文本。
• 如果读取结果已经出现明显的乱码替换字符，就停止发送。

6. 结论

这次 Raycast 的使用经验可以压缩成一句话：

Raycast 不做源头，只做入口。

固定链接用 Quicklinks。

个人固定动作 用脚本。

写作仍然交给 flomo、Obsidian 或其他真正适合写作的工具。

这样 Raycast 就不会变成另一个复杂系统，而是把现有系统轻轻接起来。