找 DSH plugin 的三条路：DeepSeek Harness 插件市场、命令行与 GitHub

找 DeepSeek Harness 插件有三条路，它们不是替代关系，而是各有所长的三段：市场用来「发现」，命令行用来「确认」，GitHub 用来「核验」。 只走一条路会各踩各的坑：只看市场会拿到条目信息不全的候选、只逛 GitHub 会找不到可安装的包名、只信命令行则完全看不到「有没有更好的替代」。所以高效的做法是固定顺序——市场圈定 → 命令行确认包名与版本 → GitHub 核验维护状态与依赖，三段走完通常几分钟，比在某个渠道里反复试错快得多。

DSH plugin 的三条路各自能看到什么

一句话结论：市场看分类与热度、命令行看包名与版本、GitHub 看源码与活跃度——三者的信息几乎不重叠，所以缺一条就会瞎一块。

方案 A：市场优先（不知道要什么时）

一句话结论：需求模糊时从市场分类进，是最快的「把候选变具体」的方式。

1. 先想清场景再进市场（而不是从总榜开始看），按分类定位。
2. 拿条目说明对照需求：说明里写清「解决什么问题、依赖什么、怎么装」，这三项能过就进候选。
3. 把候选列成小清单：名称 + 一句话作用 + 依赖，三步就够。
4. 进第 4 节的组合流程做确认与核验。
5. 判断依据：评分 > 热度——热度只帮你排序，需求匹配才决定选谁（读法见 DSH Plugin Hub 的排行与榜单怎么看）。

方案 B：命令行优先（已知道包名时）

一句话结论：命令行的价值在「确认」不在「发现」——包名、版本、依赖三项一次问清，避免装错。

1. 查询包是否存在与有哪些版本（示例，用 npm 生态的通用查询）：

npm view <插件包名> versions --json
# 预期：返回可用版本列表，用于确认你想要的版本确实存在

2. 确认依赖：npm view <插件包名> dependencies，看是否含需要编译的原生模块（ARM 与容器环境要特别注意）。
3. 装并立刻验证：

dsh plugin add <插件包名>@<版本>
dsh plugin        # 预期：清单中出现该插件与指定版本

4. 顺手记版本：这一条是后续回滚与多机对齐的依据（见 给 DSH plugin 锁版本与回滚）。

方案 C：GitHub 优先（要看源码与活跃度时）

一句话结论：决定「要不要长期依赖」时看 GitHub——源码、提交、议题三处能回答「它还在不在、会不会突然坏」。

1. 看提交与发布节奏：最近一次提交/发版距今多久，是否与 DeepSeek Harness 近期的变化同步适配。
2. 看议题与已知问题：有没有长期未处理的关键问题、有没有与你的使用场景相关的讨论。
3. 看 README 的依赖与权限：这份文档也是你判断「装之前要准备什么」的主要依据。
4. 回到命令行确认可安装形式，再决定是否装——GitHub 上的代码不等于可安装的包。
5. 判断依据：维护活跃度 > 星标数——星标反映曾经的关注，提交节奏反映现在的状态。

DeepSeek Harness 插件的组合查找：三段式流程

一句话结论：市场圈定 → 命令行确认 → GitHub 核验，三段顺序固定，能同时避开三条路各自的盲区。

1. 第一段（发现）：在市场按分类找到 2-3 个候选，记录名称与作用。
2. 第二段（确认）：用命令行核对包名、可用版本与依赖，排掉不存在的版本与不满足的依赖。
3. 第三段（核验）：对剩下的候选去 GitHub 看维护状态与已知问题，决定试哪一个。
4. 一次只装一个：同场景多个候选都值得试时，逐个装、逐个验证，避免冲突混在一起分不清责任（排查见 DeepSeek Harness 插件冲突总览）。
5. 装完留档：把「包名 + 版本 + 来源」记进插件清单。

DSH plugin 三条路各自的盲区与踩坑

一句话结论：市场的坑是「信息靠发布者填」、命令行的坑是「不知道找什么」、GitHub 的坑是「代码不等于可装」。

1. 市场盲区：条目信息由发布者提交，缺依赖说明的条目会让你在安装时才发现问题（装前一定要看依赖）。
2. 命令行盲区：没有发现能力——你不知道包名时，命令行帮不上忙。
3. GitHub 盲区：仓库里可能有多个包、也可能根本没发布到公共源，导致「看得到却装不上」。
4. 共同盲区：三条路都看不到「你的环境是否满足」（原生依赖、权限、本体版本），这一层只能靠装后验证。
5. 补充渠道：关于 DeepSeek Harness 生态的讨论区与社区帖也能发现插件，但信息质量参差，建议只用来「发现线索」，确认与核验仍走上面两段。

DSH plugin 排查注意事项

一句话结论：找插件的问题多半是「用错渠道」而不是「插件不存在」——先换渠道，再换关键词。

1. 市场搜不到→ 换关键词、去 GitHub 按话题找、或确认本体是否已内置该能力。
2. GitHub 找到了但装不上→ 回到命令行确认包名与版本是否发布。
3. 装上了但不好用→ 转向装后验证与冲突排查，而不是继续换渠道找「更好的」。
4. 总在换插件→ 先写清需求短句再用场景反查，比反复试更省时间。
5. 团队协作→ 把「结果」写进插件清单（谁提供、什么版本、为什么选它），比只留包名有价值。
6. 修复状态如实：本文渠道能力描述基于 DSH Plugin Hub 的公开页面与官方仓库的发布约定；市场上实际有哪些排序、筛选与标记项随页面迭代，dsh plugin 的子命令形式请以本机 --help 输出为准。

只想解决「从哪下载」而不做维护性判断，见插件下载渠道：市场、GitHub 与 npm。

来源：DSH Plugin Hub 插件条目、apps/cli/README.md、docs/user/develop/basic/publish.md。