dsh plugin market 为什么搜不到新插件：DeepSeek Harness 索引、分类与关键词曝光

插件包发布成功的第二天，作者在 dsh plugin market 里搜自己的名字，结果什么都没有。 他以为市场出了故障，其实条目可能还卡在发布、索引、分类、搜索字段或详情页这五个环节中的某一环。曝光不是发布成功的自动结果，而是一条逐段放行的链路。

先别怀疑市场：dsh plugin 的曝光要过五个环节

包能安装，不代表能被看见；发布、索引、分类、搜索字段与详情页完整度，各自管一段。

很多人把「搜不到」当成单点故障，于是反复刷新页面或者重新提交。更有效的做法是先承认它是一条链路，再找出断点在哪。市场只负责展示索引里的条目，而条目能不能进索引、落在哪个类目、被哪些词命中，是几件彼此独立的事。

把五个环节按顺序列出来，断点通常就在最靠前的那一处：

1. 发布：包名、版本与发布者能在 npm 对上。
2. 索引：条目详情页已生成，且能直接打开。
3. 分类：条目落在与功能匹配的类目。
4. 搜索字段：包名、显示名、描述、作者能被搜到。
5. 详情页完整度：描述、安装命令、版本、更新时间齐全。

这五段有先后关系。包没发布，后面的索引和分类都无从谈起；索引没生成，分类再准也不会出现在浏览页；字段写得再漂亮，搜索不命中依然等于零。判断顺序应该从上游往下游走，不要一上来就改描述。

一个很实用的中间判据是详情页能不能直接打开。能打开，说明发布和索引至少通了一段；打不开，就先停在上游，别去研究关键词。这个判据比看搜索框结果稳定得多。

发布只是把包放上货架：DeepSeek Harness 的 dsh plugin 还要等索引

发布成功只证明包可解析，索引是另一套流程，它有延迟，也可能因为元数据不全而跳过。

发布环节要核对三样东西：包名是完整的 npm 名而不是显示名，版本与市场条目一致，发布者与仓库归属对得上。任何一样不符，市场即使收录了，也会指向一个装不上的包。这类问题在详情页里一眼就能看出来，不需要猜。

索引通常由市场侧的任务完成，作者能控制的只有元数据是否齐全。描述为空、入口字段缺失、版本格式异常，都可能让条目被跳过。它不一定报错，作者看到的只是「搜不到」，于是误以为发布失败。

我在排查时习惯先打开 DSH Plugin Hub 里该插件的详情页。页面存在而搜索为空，说明问题在字段或分类；页面本身不存在，才回到发布与索引。这个顺序能省掉很多无效刷新。

如果确认是索引延迟，能做的只有等待，同时把字段补齐。等待期间反复重新提交没有意义，反而可能制造重复条目。把下一次发布要用的描述先准备好，时间才不算白等。

分类决定谁会撞见你：DSH插件 的类目不是装饰

分类浏览是搜索之外的第二条入口，选错类目不会让插件消失，但会让它出现在没人找的地方。

市场分类承担的是「我不知道叫什么，但我知道我要什么」这类需求。用户会点开「记忆」「工作流」「界面增强」这样的类目逐页看，而不是输入精确包名。条目落错类目，就等于放弃了这部分流量。

分类错误很常见，因为作者最了解实现，却不一定了解用户的语言。一个做会话归档的插件，作者可能归到「存储」，用户却会在「记忆」里找。判断方法很朴素：看同类插件出现在哪一页，再看那一页的用户会带着什么问题进来。

分类与搜索字段也会互相影响。有的市场会把类目名作为隐式关键词参与匹配，类目选对，某些宽泛搜索就更容易命中。这不是玄学，只是字段来源比你填写的表单更多。

改分类通常比改包名容易，也不影响已安装用户。发现曝光差时，先检查这一项，成本最低。如果同类插件都集中在某一页，跟着放通常比自创分类更容易被找到。

搜索字段决定命中：DeepSeek Harness 用户不会按你的命名去搜

搜索靠字段匹配，不靠你觉得名字好不好听；包名、显示名、描述与作者，各自覆盖不同的搜索习惯。

包名是身份，也是英文用户最可能输入的东西。它应该包含功能关键词，而不是只有品牌前缀。显示名面向人读，可以更自然，但也要带上功能词，否则中文用户搜「记忆」时永远碰不到你。

描述的前两句权重很高，既参与搜索，也决定用户在结果列表里点不点。写清「解决什么问题、在什么场景用」，比堆一排形容词有效。作者名则是一个被低估的字段，熟悉你其他插件的人会直接搜作者。

中文与英文搜索词的分裂值得单独处理。DSH插件 的中文用户可能输入「记忆插件」，英文用户输入 memory plugin，两者都不该落空。把两种说法自然写进描述，比在标题里硬塞关键词更耐看。

字段修改通常比索引刷新快。改完先用包名、显示名、作者名各搜一次，再看描述里的功能词能不能命中。三种搜索词至少两种能找到，才算字段合格。

详情页完整度是最后一公里：dsh plugin 的条目要经得起点开

搜到只是开始，详情页要能回答「它做什么、怎么装、现在是什么版本」，否则点击也会流失。

用户从搜索结果点进来，通常只停留几十秒。描述是否具体、安装命令是否可直接复制、版本与更新时间是否新鲜，决定了他是继续安装还是返回。字段负责被看见，详情页负责被信任。

我见过不少条目，描述只有一句话，安装命令指向一个已经改名的包，更新时间停在半年前。这样的页面即使排在搜索结果第一，也很难转化。更糟的是，用户会把安装失败归因于市场，而不是条目本身。

完整度不需要写成一篇长文。把能力边界、依赖条件、最小安装步骤和当前版本写清楚，已经超过大多数条目。截图和示例可以有，但不能替代文字说明，因为搜索和摘要素材都来自文字。

不管它叫 DSH插件 还是 DeepSeek插件，用户在详情页里寻找的信息是一样的：这东西能不能解决我的问题，装上会不会把环境弄乱。两个叫法指向同一类扩展，不必在条目里二选一。把用户真正会问的问题写进描述，比纠结称呼更有用。

发布者怎么自检曝光：DSH插件 上架后的五个动作

自检要模拟真实用户路径，从搜索到安装走一遍，任何一步卡住都算曝光未完成。

自检不需要工具，按用户会做的动作重走一遍就够了。每一步都记下结果，别凭印象判断。走完再回看，问题通常自己会浮出来。

先用完整包名搜索，确认条目出现在结果里，且版本是最新发布的那一版。只有精确包名能命中，说明显示名与作者字段还没有参与匹配。再用显示名和作者名各搜一次，任何一次落空都值得回头改字段。

打开分类浏览，确认条目落在用户会去找的那一页，而不是一个冷门类目。类目选错不会让插件消失，却会让它出现在没人找的地方。同类插件集中在哪一页，通常就是用户带着问题会点开的那一页。

点进详情页，核对描述、安装命令、版本与更新时间是否齐全且一致。描述要能回答它做什么、怎么装、现在是什么版本，缺一项都会让点击流失。安装命令指向已经改名的包，是最常见也最伤信任的错误。

最后按详情页给出的命令实际安装一次，确认依赖完整、装完能加载。装不上时先分辨是包本身解析失败，还是详情页命令过期，两者的修法完全不同。把这次实际执行的命令与版本记下来，才是可复用的证据。

走完这五步，通常能定位到具体哪一段断了。只有全部通过，才值得去讨论推荐位和排序，否则再多的曝光也接不住。定位到之后先修那一段，不要同时改五个地方。

自检结果最好写下来，尤其是搜索词与命中情况。下次发新版本时可以直接对比，省得每次从零开始猜。记录不用很正式，时间、搜索词、命中与否三列就够。

来源：DSH Plugin Hub 插件条目、dsh-plugin-hub 仓库、开发第一个插件。