如何挑选 DSH 插件：从需求到安装清单
不靠 Star 盲选：用目标、证据、维护度和最小组合四步，挑出真正适合自己的插件，并形成可回滚的安装清单。
约 9 分钟读完
读完这篇你会
- 把“我想装点有用的东西”变成一个清楚的需求，而不是一份插件购物清单
- 用来源、维护度、权限和安装方式判断插件是否值得试
- 先装一个最小组合，并留下能回滚的记录
适用版本
Compatible with: dsh 0.1.x。本文讲的是选型与验证方法；具体命令以插件详情页和上游 README 为准。
第一步：先写一句你要解决的问题
“给 DSH 装插件”不是目标；目标应该是一个可以观察结果的工作问题。例如：
- “我想让 Agent 在一次任务里读截图并指出界面问题。”
- “我想把重复的日报整理流程变成一个可复用模板。”
- “我需要在终端里使用 DSH，而不是浏览器。”
把问题写成 场景 + 输入 + 期望输出。这样搜索时你会关注能力是否匹配，而不是被名字和 Star 数带着走。
| 模糊想法 | 更好的问题 | 该看什么 |
|---|---|---|
| 想要记忆 | 跨会话能找回项目决定 | 存储位置、检索范围、是否可导出 |
| 想要浏览器 | Agent 能操作一个已有登录态的网站 | 权限、浏览器范围、失败时是否可控 |
| 想做设计 | 根据文字生成可编辑的网页或演示稿 | 输出格式、依赖、示例质量 |
本站的场景组合适合把这个问题映射成一组候选；它不是“最佳插件榜”，而是你的第一轮筛选器。
第二步：先看四类证据，再看 Star
Star 是热度，不是兼容性或安全证明。对每个候选，先做四项检查：
- 来源是否清楚：仓库存在吗？README 是否能解释用途？作者和发布位置是否一致？
- 安装是否清楚：是否提供完整的
dsh plugin ... add命令？命令指向 npm、GitHub 还是本地路径？ - 维护是否可信：最近提交、发行说明、issue 回复和许可证至少要有一部分可查。
- 权限是否符合预期：主题插件不该要求 shell；读取本地文件的插件应该说明范围；涉及 token 的插件应该说明存放位置。
可以把插件详情页上的机审证据当作“资料是否齐全”的提示，而不是认证标志。信息不全不一定代表恶意，但意味着你需要多读 README，或先在独立 profile 里试。
第三步：用兼容性检查页做一次分诊
打开兼容性检查，输入完整的 owner/repo 插件 ID，并选择自己的系统与 profile。它会显示：
- 是否收录了安装命令、README 和仓库同步记录；
- 上游是否声明了 DSH 版本或平台；
- 命令是否带固定的 profile；
- 已抓取文本里是否出现需要人工审阅的高风险执行模式。
结果中的“没有声明”不是“不支持”。正确动作是回到上游 README 查证，或把插件放进一个试验 profile；不要把缺失信息自动当作通过。
第四步：只装一个最小组合
第一次不要为了“配齐工具箱”装十个插件。一个可控的最小组合通常是：
- 一个直接解决当前问题的主插件；
- 最多一个辅助插件，例如界面、日志或文件选择器；
- 一条记录：安装命令、安装日期、原仓库 URL 和卸载方式。
例如你要做视觉设计，先安装一个设计/视觉能力插件，跑通一次真实任务；确认输出、速度和权限都符合预期后，再考虑桌宠、主题或市场类插件。
目标：把产品需求变成一页网页原型
主插件：视觉/设计能力
验证任务：生成一个登录页并导出可编辑文件
回滚：记录 dsh plugin remove 所需的插件 ID
第五步：把“试用”变成一次可复现的验证
安装完成后，不要只看“命令没有报错”。做一个小而真实的验收任务：
- 能否在当前 profile 看见或调用该插件？
- 是否完成了 README 承诺的最小能力？
- 输出是否落在你预期的位置？
- 失败时提示是否足以定位问题？
通过后再把它加入日常工作流；不通过就卸载并记一行原因。这个记录会让下次选型更快，也能防止“装过但不知道为什么”的环境膨胀。
常见误区
Star 最高的就是最适合我的吗？
不是。大仓库的 Star 可能来自整个项目，子包未必就是你需要的功能。优先看任务匹配、安装说明和权限边界。
我可以直接在日常 profile 试陌生插件吗？
可以，但风险更高。涉及本地文件、网络、shell 或 token 时，优先使用独立 profile，并在安装前阅读 README 与命令。
找不到完美插件怎么办？
先选证据最完整、能完成 80% 任务的一个，保留剩余 20% 的手工步骤。等你确认真实缺口，再考虑第二个插件或自己开发。
下一步
已经选好插件但安装失败？继续看插件安装失败怎么排查。