DSH Plugin market 与官方文档该信谁：DeepSeek插件信息源冲突时的判断顺序

查 DSH plugin 时，DSH Plugin market、官方文档与 GitHub 不是三个可以互相替代的答案。 它们分别回答「有没有」「怎么用」和「实际行为是什么」，混着用就会得到互相矛盾的结论。 把问题先分类，再决定打开哪个来源，比在三个页面之间来回跳要省时间得多。

DSH Plugin market 与官方文档回答的是不同问题

市场负责发现，文档负责契约，仓库负责事实，三者不能互相代答。

当你想知道某个能力有没有现成插件时，市场是最直接的入口，文档里通常不会维护插件清单。 当你已经选定插件，需要知道配置项、调用方式和限制时，文档才是主来源，市场描述最多算摘要。 当实际行为与描述不符，或者你需要判断某个历史版本改了什么，只有仓库能给出可核对的证据。

用错来源的代价很具体：拿市场描述当接口说明，会在配置时反复试错。 拿文档去判断某个版本是否存在，也会徒劳，因为文档描述的是能力区间，不是发布清单。 先把「我在查存在性、用法还是行为」说清，后面的取舍几乎没有歧义。 这三者之间不是替代关系，而是接力关系。

DSH Plugin market 的强项是存在性与版本索引

市场条目由作者填写，适合确认身份与版本，不适合承诺运行行为。

包名、发布者、当前版本和更新时间这几项相对可靠，因为它们直接来自条目的元数据。 功能列表、支持平台和「一键安装」之类的文案则没有强制校验，可能超前于实际实现，也可能长期没更新。 元数据能核对，文案只能参考，两者的可信度不在一个层级。

同一个插件在市场里出现两个相似条目时，先比包名，再比发布者，不要凭显示名合并。 如果条目描述与 npm 上的包元数据不一致，以包名为锚点去核对，而不是相信任何一侧的文案。 市场最适合回答「它存在吗、最新版是多少」，这两个问题之外的判断都要另找证据。

市场条目也会出现重复收录，两个条目指向同一个包名时，以发布者与包名为准合并。 遇到描述里出现「官方」字样，先看发布者是不是对应组织，再决定要不要信。 条目信息本身不承担兼容性承诺，这一点要一直记住。

DeepSeek Harness 官方文档的边界：承诺不等于当前实现

官方文档描述的是已承诺的接口与约束，但它也有版本滞后的问题。

文档通常按 Harness 版本维护，你打开的页面可能对应旧版本，也可能已经写上了尚未发布的改动。 很多 DeepSeek插件 的用法在文档里只有一段概述，真正的边界条件仍要回到插件自己的 README 或源码。 文档页面如果带版本选择器，先切到你实际使用的版本再读。

读文档时要先确认它对应的版本区间，再看配置示例是否与你的版本匹配。 如果文档写了支持、装完却不能用，优先检查版本与平台是否落在声明范围内，而不是立刻怀疑文档造假。 文档的价值在于给出官方承诺，出问题时它也是判断「这算不算回归」的基准。

信息冲突时，DSH插件先对齐版本号

大部分「说法不一致」不是信息源错了，而是它们描述的不是同一个版本。

市场条目展示的是当前可用版本，文档对应某个 Harness 版本区间，仓库则可能停在某个标签或主分支上。 本机装的又是另一个版本，四个版本号不写在一起，比较就没有意义。 只对齐其中两个，仍然可能得出看似冲突的结论。

把市场版本、文档版本、仓库标签和 dsh plugin list 的输出并排记下，冲突往往会自动消失。 如果四个版本对齐后仍然矛盾，才需要判断哪一方更新、哪一方更接近代码。 版本对齐之前，不要急着下「文档过时」或「市场骗人」的结论。

对齐版本时不要只记大版本号，补丁号差异也可能改变行为。 把四个版本写进同一行记录，比散落在聊天记录里可靠。 下一次再遇到冲突，先翻这条记录，而不是重新猜。

取舍顺序：代码事实高于 DSH Plugin market 描述

越接近代码的来源越可信，市场描述在行为问题上优先级最低。

按距离代码的远近，依次看这五个来源：

1. 仓库当前代码与标签，确认实际行为。
2. 发布说明与 changelog，确认某个版本改了什么。
3. 官方文档，确认官方承诺的用法与边界。
4. 市场条目，确认存在性与版本索引。
5. 社区文章，只作为线索。

优先级只在冲突时启用，平时不必每次都从仓库读起。

这个顺序不是绝对的等级制，而是按问题类型排的优先级。 查「有没有」时市场仍然最快，查「怎么用」时文档仍然最方便，只是在两者冲突时才启用这条顺序。 任何影响安装决策的描述，都要有一个可验证来源兜底，否则就只能当参考。

一套可复用的 DSH Plugin market 查证习惯

先确认存在，再确认版本，然后看用法，最后才看行为与评价。

从市场按包名搜到条目，记下发布者与当前版本，这是整个查证的起点。 接着到 npm 确认包可解析、版本号与条目一致，排除条目信息滞后的可能。 然后读官方文档的配置与调用说明，再回仓库看实现、issue 与最近变更，最后才参考安装量和评分。

这套顺序不要求每次都走完，问题越靠近行为，越应该往后走。 如果结论能用三行写清「包名、版本、依据」，说明来源用对了；写不清，通常是又混用了来源。 养成记录版本与出处的习惯，下一次遇到冲突时就不必从头猜。

如果查证结论影响团队选型，把来源链接和访问日期一起留下。 信息源会更新，留下时间点，别人才知道你的结论对应哪一刻。 这比在群里复述一段结论更有用，也更经得起回查。

市场、文档与仓库各自解决一段路，真正可靠的做法不是选一个最权威的来源，而是让它们在同一组版本号下互相印证。 对 DSH插件 的使用者来说，能说清「这个结论来自哪里、对应哪个版本」，比记住任何单一渠道都更重要。 结论可以更新，但出处和时间点要保留。