最近整理 832OS 的时候，我重新想了一下自己到底怎么用 Raycast。

以前我会把它理解成启动器：搜应用、打开链接、跑脚本。现在我更愿意把它当成个人系统的入口层。

它不负责保存知识，也不负责替我思考。它最适合做一件事：把那些已经固定下来的动作，用最快的方式接起来。

1. 越固定，越适合 Raycast

有些动作其实不需要 AI 参与。

比如打开一个固定页面、创建一个固定格式的 Issue、把剪贴板内容发到某个入口。这些事情交给 Agent 当然也能做，但每次都要等它理解、判断、调用工具，反而慢。

我的经验是：

需要判断的事，交给 Agent。
已经固定的动作，交给 Raycast。

Raycast 的价值就在这里。它不是另一个复杂系统，而是把固定动作压缩成一个很轻的入口。

更新：最终我还是使用 Agent command 命令来做，因为这个剪切板 完全不符合用户习惯

2. 固定页面，用 Quicklinks

我经常要打开 832OS 的 GitHub 仓库、Issue、Discussion、Actions、Projects、Pull Requests。

这些都是固定 URL，没必要写脚本。Raycast 的 Quicklinks 就够了。

它的好处很直接：

• 搜得到。
• 打得快。
• 不需要维护代码。
• 不需要额外权限。

这类入口越轻越好。

工作里也一样。经常要打开的内部系统、后台页面、监控页面，只要是固定地址，都适合放进 Quicklinks。比每次先打开浏览器再搜索要省心很多。

3. 固定动作，用脚本

更新：这个给的启示是，自己“想”出来的东西，自己动手干了，也许实践以后才能知道，想的对不对 ，比如下面流程，完全不合理，为什么要一个编辑写好内容，复制，然后再通过Raycast 发送，参与的角色和路径一旦长了，就一定会有问题。

还有一类事情不是固定页面，而是固定动作。

比如我有时会在 flomo、Obsidian 或任意编辑器里写下一段内容，然后希望快速发到 GitHub Issue 或 Discussion。

我现在的流程是：

写好内容
复制全文
Raycast 一键发送
GitHub 承接

这里 Raycast 只负责触发脚本，真正的承接对象还是 GitHub。

Issue 用来放待办、问题、bug、需要处理的动作。

Discussion 用来放想法、开放问题、长期讨论。

这样边界很清楚：

• 写作在 flomo、Obsidian 或任意编辑器里完成。
• Raycast 负责把动作打出去。
• GitHub 负责承接协作对象。
• 832OS 负责长期结构和内容沉淀。

Raycast 不参与写作，也不变成新的内容仓库。它只是入口。

4. 插件不一定是答案

Raycast 有 GitHub 插件，可以看 Issue、PR、Workflow 和通知。

但我自己的用法里，最常用的并不是“在 Raycast 里完整管理 GitHub”，而是把几个固定动作做顺。

如果只是打开固定页面，Quicklinks 更轻。

如果是创建固定对象，脚本配合 gh 更可控。

如果是需要读上下文、改代码、看日志、判断问题，那就交给 Codex 这类 Agent。

所以我不会追求把所有 GitHub 操作都塞进 Raycast。Raycast 只管最短路径。

5. 小坑：中文剪贴板

这次也踩了一个很实际的坑。

从 Raycast 脚本读取中文剪贴板，再发到 GitHub Discussion 时，内容出现过乱码。

问题不在 GitHub，而在脚本执行环境。Raycast 启动脚本时，环境变量不一定和终端完全一样，编码可能不稳定。

最后的处理也很简单：

• 脚本里显式设置 UTF-8。
• 用纯文本方式读取剪贴板。
• 如果读到明显乱码，就停止发送。

这种问题不大，但它提醒我：本机自动化要尽量简单，边界越清楚，越容易排查。

6. 结论

我现在使用 Raycast 的方式，可以压缩成一句话：

Raycast 不做源头，只做入口。

固定页面用 Quicklinks。

固定动作用脚本。

需要判断的事情交给 Agent。

长期内容仍然回到 832OS。

这样 Raycast 就不会变成另一个需要维护的系统，而是把已经存在的系统轻轻接起来。