开发 dsh plugin 怎么预览 Hub 条目：DeepSeek Harness 包元数据与 bundle 自检

开发 dsh plugin 时，你在仓库里看到的是代码，用户看到的是 DeepSeek Harness 的 Hub 条目；两者之间的距离由三份文件决定。 package.json 给出身份，bundle 决定能不能加载，描述文件决定第一眼印象。预览的意义，就是在提交前把这三份文件合成一个用户视角。

提交之前，用户看到的 DeepSeek Harness 条目其实已经决定了

条目不是提交后生成的，绝大多数字段在你打包时就已经固定。

很多人把 Hub 当成一个发布之后再去填的表单：先提交，再看效果，不行再改。实际上条目的绝大部分字段在你打包时就已经固定，Hub 只是把它们读出来渲染。

用户第一眼看到的是显示名、一句话描述、分类和版本；点进去之后看到的是安装命令、依赖、更新时间和截图。决定这些内容的不是 Hub 的编辑框，而是包元数据与描述文件。你在本地改一个字段，条目就变一次，不需要等审核。

所以「预览」不是看页面好不好看，而是检查信息是否自洽：显示名能不能对应回包名，描述说的功能是否真的存在，分类是否和用户搜索的词对得上。这三件事在提交前就能验证，而且成本极低；同类条目可以直接在 DSH Plugin Hub 对照。

package.json 决定的是 dsh plugin 的身份，不是介绍

包名是身份，版本是坐标，作者是归属，三者都不该为了好看而改。

包名是身份，版本是坐标，作者是归属。这三样东西一旦发布就不该随意改，因为用户、脚本和其他插件的依赖都指向它们。

最常见的错误是把显示名当包名用。显示名可以写得友好，比如带空格、带中文，但包名必须稳定、可安装、能在 npm 上解析。两者不一致本身不是问题，问题是不一致到无法对应——用户搜到「记忆助手」，点进去却看到一个完全无关的包名，信任当场就断了。

版本也容易出岔子。仓库打了 tag，package.json 里的 version 忘了改，条目展示的版本与用户实际装到的版本就会差一截。预览时把这两处对一遍，比事后解释「以实际安装为准」省事得多。

作者与仓库字段同样值得检查。它们决定了用户遇到问题时去哪里找源代码。如果仓库链接指向一个空仓库或者 fork，条目看起来再完整，也只是一个没有售后的页面。

bundle 决定 dsh plugin 能不能被加载，条目再漂亮也没用

条目预览只能证明 Hub 认识这个包，不能证明 DeepSeek Harness 能加载它。

条目预览只能证明「Hub 认识这个包」，不能证明「DeepSeek Harness 能加载这个插件」。这两件事经常被混为一谈。

bundle 声明入口、能力与加载方式。入口路径写错、清单缺字段、能力声明与实现不符，都会导致同一个现象：安装成功，条目正常，插件却停在 PENDING 或根本不出现。用户在条目页看不到任何异常，因为问题发生在加载阶段，不在展示阶段。

验证方法很直接：在一个干净的 profile 里从零安装，重启，然后看插件状态是否进入 ACTIVE。不要用开发目录直接跑，也不要用已经装过旧版本的 profile，那些环境会掩盖入口问题。

如果你在本地开发模式里能看到条目，但安装后状态不对，优先查 bundle，而不是继续改描述。描述影响的是「有没有人点进来」，bundle 影响的是「点进来之后能不能用」。

描述文件决定用户第一眼看到的 DeepSeek Harness 条目

决定第一眼印象的是文字字段，不是截图。

描述文件里最值钱的不是截图，是文字。用户搜索时匹配的是名称、描述和分类，截图不参与匹配。

一句话描述要回答三个问题：这个插件做什么、解决谁的什么问题、有什么明显限制。只写「强大的记忆插件」等于没写，因为每个插件都可以这么写。写「把会话记忆落到本地文件，支持按项目隔离，不提供云端同步」，用户立刻知道它适不适合自己。

分类决定发现路径。分错类的插件不会消失，但会出现在错误的筛选结果里，点击率极低。预览时用分类浏览一遍，看它和同类插件是否放在一起，比只看详情页有效。

名称与描述还要能承接中文搜索。很多条目字段是英文，用户用 DSH插件、DeepSeek插件 搜不到时，会以为插件不存在。描述里自然带上中文说法，能减少这类误判。

在本地做一次预演：把自己当成 dsh plugin 的搜索者

预演要按用户路径走一遍，而不是打开详情页看一眼。

预演不是打开详情页看一眼，而是完整走一遍用户路径。找一个没装过这个插件的 profile，从搜索开始：

1. 用三种词搜：包名、显示名、作者名各搜一次，确认都能命中同一个条目。
2. 从条目安装：复制条目里的安装命令，直接在终端执行，不要改用你熟悉的私有命令。
3. 重启看状态：插件应进入 ACTIVE；停在 PENDING 就回到 bundle 检查。
4. 打开详情页：确认版本、依赖、更新时间、仓库链接都能正常渲染。
5. 卸载查残留：卸载后看配置与缓存目录，残留是否在可接受范围。
6. 换环境复现：在另一台机器或另一个 profile 重复一次，确认不是本地环境侥幸成功。

这套预演大约二十分钟，能提前发现大部分上架后才会暴露的问题。尤其是第 2 步和第 6 步，很多人只在开发环境里点过「安装」，从未按条目命令从零装过。

上架前最后一遍：dsh plugin 的五个对照

五项对照不需要新工具，只需要把仓库里的值和用户看到的值放在一起。

下面五项是提交前的最后检查。它们不需要新工具，只需要把仓库里的值和用户看到的值放在一起对。

五项里最容易糊弄的是描述，因为它没有客观标准；最容易翻车的是入口，因为它不影响条目渲染。把这两项当作硬门槛，其余三项通常不会出问题。

预览的终点不是「看起来不错」，而是「一个没看过你代码的人，能靠条目完成搜索、判断、安装和卸载」。做到这一步，提交只是走个流程。

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