DSH 插件市场我装了 9 个,一周后只留了 3 个

DSH 插件市场我装了 9 个，一周后只留了 3 个

装了 9 个 DSH 插件，一周后只剩 3 个：留下的全是基础设施类，不是功能类

DSH插件

有件事我没好意思跟人说：我的 DSH 里躺了六个插件，其中一个从装上那天起就没成功运行过，我还是留了它一整周。

不是忘了卸。是每次想卸的时候都会想「万一明天用得上呢」，然后一周过去，它连一次都没跑起来。最后我打开插件目录，对着那串名字愣了几秒，决定干一件早就该干的事：全删，然后一个个重装，装一个用一天，用不上就当场卸。

这次我装了 9 个。一周后留下 3 个。下面是过程，包括那个我至今不确定该不该留的。

先说个背景。DSH 这个 harness 现在星数 280405（2026-11-13 查的），pushed_at 是 11-13，一天内还在更新。它的设计思路是「万物皆插件」：模型、工具、UI、上下文管理全都可以换。听起来很爽。

实际用起来的问题不在功能，在于「可选的东西太多了」。插件市场那个项目 dsh-market 有 12301 星，列表一页一屏，每个插件都有三行说明，每一行看着都像你现在就需要。我一晚上能点掉十几个 install 命令，然后第二天完全不知道哪个在起作用。

我之前那六个插件就是这么来的。所以这次我给自己定了规矩：

• 装一个，用一天真实工作，不许用 demo 场景糊弄
• 判断标准只有一条：一天下来它有没有让我少做一件事，或者少想一件事
• 没做到就卸，不留「以后可能用得上」

写这篇的时候我还没看到第二天，所以标题那个「一周后只留了 3 个」是结果，过程是这样的。

我的日常工作大概是三类：改自己那个用 Rust 写的数据库管理平台的边角功能、给几个客户写脚本处理数据、还有就是在 DSH 里连着跑一些重复的查询和整理。所以插件我基本按这三个场景去试，不按「酷不酷」去试。

装上第一个插件之前，我先做了一件小事：把之前的所有插件全卸了，包括那个从没跑起来的。卸完的 DSH 启动明显快了半秒多，这个数我没精确测，但能感觉到——以前敲完命令要等一下，卸完几乎是回车就出提示符。

这个细节后来救了我。因为它让我意识到：插件不是零成本加装的东西，它在启动路径上。

表里「精选列表里」那六个，都来自 awesome-dsh-plugin 那个仓库（24563 星）。我没写具体名字不是藏私，是因为这些插件更新的频率太快，我这周用的版本下周可能就换了个名字，写出来反而误导人。它们的共同点是：功能描述都非常有道理，用起来都不算坏，但都没有强到「我的工作流缺了它不转」。

留下的三个里头，有一个是我一开始最不想装的。

dsh-market：这个不用多解释，它就是装东西的入口。但真正让我留下它的不是「能装插件」，是它能看别人的配置清单。我翻了几个配置之后发现一个规律：用得久的人，插件数普遍在 4 到 6 个之间，而且大部分是基础设施类的，不是功能类的。这跟我原来的直觉反着来——我以为插件越多越强。

dsh-context：这是我一开始最不想装的，因为它的说明看起来像「又一个 UI 美化」。结果装完第二天就派上用场了。我在处理一份比较大的导出文件时，发现它给的上下文用量比我想的高了一截，前后两轮加起来已经接近我在意的那条线。这个信息在原始界面里要自己去翻，翻到的时候已经晚了。它没有帮我省操作，它帮我提前发现了问题。

dsh-TUI：官方首推的那个。我对终端界面有偏见，觉得能跑就行，花时间折腾界面是浪费。但它让我改口的原因是，我每天在终端里待 6 个小时以上，而这个东西实打实让我少看了不少滚动输出。

这里说一句可能得罪人的话：dsh-TUI 是我这三个里唯一「只花钱不赚钱」的。它带来的是舒适度，不是效率。如果你的终端只是偶尔敲两下，别装，它就是纯粹的外观消费。

卸掉的六个，功能上各有各的好，但它们失败的原因几乎是同一个：它们都需要我改变已经成型的习惯，而收益只出现在特定场景里。

拿那个 diff 插件举例。它的逻辑是：每次修改文件前，先给你看一段即将发生的变更。这个设计在多人协作的代码库里非常合理，但我现在的场景是「一个人改一个自己的项目」，我知道我要改什么，多一道确认就多一次打断。

日志插件也一样。它的价值是「回头能查」，但我一周里一次都没回头查过。这周没查不代表它没用，只是说明：对一个单人项目来说，出问题的时候我宁可去读源码也不愿意读日志。

记忆插件我拖了两天才卸，因为它确实让我少打了几行字。但它的问题更微妙：它记住了我的偏好，然后开始在某些时候自作主张。有一次我让它整理一份客户名单，它自动套用了我之前用过的表结构，省了我两分钟，也让我在检查的时候多花了两分钟确认字段对不对。这笔买卖不划算。

这里我想给一个不太讨喜的判断：精选列表里的插件，八成是给别人写的。写插件的人有自己的工作流，他的痛点未必是你的痛点。awesome 这个仓库的价值不在于「照着装」，在于让你知道这个生态能做到什么程度，然后自己判断需不需要。

装完第三天的晚上，我把那个从没跑起来的插件名字找出来了，又搜了一下它的 issue 区。发现一个很早的 issue，标题是启动时的一个小报错，下面有十几条回复，最后一条是作者说「下个版本修」。

那个「下个版本」我等了一周，没有等到。项目还在更新，pushed_at 一直是新的，说明作者还在干活，只是这个 issue 优先级不高。

我最后没卸它。原因不太体面：它的功能我确实想要，而目前没有替代品。

这件事让我对插件生态多了一个警惕：星数和新提交只能说明项目活着，不能说明你遇到的那个问题被修了。DSH 生态现在 24 小时都在更新，一个 issue 留在那里两周，很可能不是因为没人管，是因为没人觉得它重要。

试完这九个，我把流程固定成这样，下次不再靠感觉：

1. 先问「它能替我做掉哪件我每周都做的事」。答不上来，不装

2. 装上之后连用 3 天，记录至少 2 次「它确实帮上了」的具体时刻

3. 3 天里没出现第二次的，卸掉，不用等一周

4. 卸完观察启动速度，如果快了明显一截，说明这插件一直在影响性能，别急着装回来

5. 每个季度清一次，把「一周没用过」的插件全卸

第 5 条是我这次最想留下的。我原来那六个插件，全部都是「一周没用过」的状态。它们没有出错，没有报错，就是安静地躺在那里，每次启动都跟着加载，每次我翻列表都要多看一眼。

如果你刚开始用 DSH，别学我这样装一堆再筛。直接从 0 开始，装一个用一周，用不上了再说。

如果你是团队里唯一一个用 DSH 的人，也别急着推插件清单给同事。我这周的体验是：插件收益高度依赖个人习惯，我的三个「必留」拿到别人机器上大概率只剩一个。

还有一类情况要特别小心：别在赶活的时候装插件。我这次正好赶上一个相对松的窗口，每天能匀出半小时做这种试验。如果手头在赶交付，插件带来的任何一次意外打断，代价都比它省下的那几分钟高得多。

这篇讲的是「怎么筛」。但筛的过程中我发现一个更基础的问题：我其实不知道这些插件到底是怎么被 DSH 加载执行的。所以下一篇我打算拿 dsh-TUI 做样本，从头到尾走一遍安装过程——包括我卡在哪一步、抄了哪条命令、第一次跑起来报了什么错。

如果你也在这几天上手 DSH，可以先在我这里看看坑再动手。下一篇会给出可以直接复制的完整命令序列，不是截图式教程。

回到这篇的结论：9 个进 3 个出，留存率 33%。这个数字不高，但我认为它是正常的——把不用的卸掉，本身就比装上什么更重要。

你那边 DSH 里现在装了几个插件？有没有那种「从来没跑起来但一直没卸」的？我挺想知道是不是只有我这样。

你那边 DSH 里装了几个插件？有没有那种从来没跑起来但一直没卸的？

觉得有用，欢迎点赞、在看、转发

THANKS FOR READING