Wox 开发者环境搭建：从终端提速到插件自研

启动器在工具链里的位置

开发者的工具链通常已经很完整：编辑器、终端、版本控制、浏览器、数据库客户端。启动器不是要替代其中任何一个，它的位置在这些工具之间。

换句话说，它解决的是「调度」问题：把「切到终端 → 切目录 → 敲命令 → 切回编辑器」这一串动作收进一个框里。

理解这个定位，就不会期待它做 IDE 的事，也不会因为它「功能不如 IDE」而失望。

第一层：终端提速

终端是开发者最常切换过去的窗口，也是启动器收益最直接的地方。

把高频命令搬出终端

不是所有命令都需要开终端。查看状态、跑一次构建、查询一个值，这类「执行完看结果就关」的操作，放在启动器里更合适。

典型的是 git 状态类命令：查一下当前分支、看有没有未提交改动。这些操作一天要做很多次，每次开终端都是浪费。

绑定工作目录

这是最关键的一步。命令本身往往很短，真正麻烦的是「先 cd 到正确的目录」。别名如果只绑命令不绑目录，多数情况下会失败。

正确做法是把目录和命令一起绑定。这样一条别名就等价于「进目录 + 执行命令」。

第二层：目录导航

开发者要面对的目录比一般用户多得多：多个项目、依赖目录、日志目录、配置目录、构建输出。

项目目录

给每个活跃项目配一个别名。p1、p2 这种编号式适合项目多且常换的人；api、web 这种语义式适合项目稳定的人。

如果项目太多记不住，用 folder: 加关键词：folder:api 会列出所有名字含 api 的目录。

特殊目录

有几个位置值得单独配入口：hosts 文件所在目录、日志目录、本地配置目录、构建输出目录。这些位置平时不怎么去，但需要去的时候往往很急。

依赖目录

排查问题时经常需要进 node_modules 或类似目录看某个包的实现。用 folder:node_modules 能快速定位，但要注意这类目录数量多、体积大，不纳入全盘索引会更清爽。

第三层：代码检索

IDE 的全局搜索很强，但它有一个前提：你得先把 IDE 切到前台。

启动器的文件检索解决的是「不在 IDE 里的时候」这个场景。你在浏览器查文档、在终端看日志、在聊天窗口沟通时，都能直接呼出搜文件。

常用写法很简单：file: 加文件名片段加扩展名。比如 file:route ts、file:config json。

它的优势不是比 IDE 更准，而是随时可用。两种检索方式并存，各管一段场景。

第四层：插件自研

前三层都是配置，第四层是写代码。这一层的门槛高，但也是启动器从「工具」变成「基础设施」的地方。

什么情况下值得自己写

• 需要接入公司内部系统，市面插件不可能覆盖
• 某个操作你每天做，但没有任何现成工具
• 需要把多个步骤串成一个命令

如果只是「想让某个功能更快一点」，先试试别名能不能解决。别名零成本，插件有开发和维护成本。

从最小插件开始

不要一上来做复杂功能。最小可用插件只做一件事：接收输入、返回一组结果、选中后执行一个动作。

开发时把动作实现成「复制到剪贴板」，这样逻辑还没打磨完也能立刻验证参数解析是否正确。

五条实际可用的起步配置

如果不想全部铺开，先配这五条，能覆盖大部分日常：

1. 三个活跃项目的目录别名
2. 一条 gs（git status）
3. 一条绑定目录的本地服务启动命令
4. 一条打开当前项目日志目录的别名
5. 一条 file: 检索习惯（不配也行，养成输入习惯即可）

用一周之后，你会自然发现还缺什么。那时候再加，比现在猜更准。

与其他工具的分工

最后厘清边界，避免期待错位：

启动器的位置很明确：处理那些「不值得开一个大工具」的小动作。认清这一点，它就是一个稳定的效率提升；认不清，它就会变成又一个装了不用的软件。

整合之后的实际效果

只看单条配置，收益都很小。四条主线都配好之后，变化体现在三个可感知的地方。

变化一：窗口数量减少了

找文件不再需要开资源管理器，跑一次性命令不再需要开终端。一天下来任务栏上的窗口数量会明显变少，切换时的视觉搜索成本随之下降。

变化二：中断变短了

原来「想到要查个东西」到「看到结果」之间隔着一串操作，现在压缩成两三秒。这个差别不在于省下的时间，而在于中断短到不足以让你忘记刚才的思路。

变化三：晚上收尾变简单了

这是最容易被忽略的一点。窗口开得少，临下班时该关的东西也少。而「关掉十几个窗口和标签页」本身是个相当消耗意志力的动作。