dsh plugin market 的 verified 徽章验证了什么：别把已验证当安全

看到 verified 徽章就点安装，是插件市场里最贵的一种误判：它把「来源能对上」读成了「代码没问题」。 在 dsh plugin market 的卡片上，verified 只是一个来源校验标记（2.2.5 索引）；它能帮你排除「条目是伪造的」这一类风险，却完全碰不到权限、依赖与构建脚本。这篇按语义拆开：验证了什么、没验证什么、你还要补什么。徽章出现在 DSH Plugin Hub 的市场卡片与条目页。

verified 字面验证了什么：dsh plugin market 的来源与基础信息

verified 验证的是「这条目从哪来、基础信息对不对得上」，不是「这个插件运行起来安不安全」。 把这两个命题分开，是读徽章的第一步。

1. 看到 verified，先确认它挂在哪个条目上，别把 A 插件的徽章记到 B 插件头上。
2. 点进详情，核对来源仓库与卡片上的名称是否一致。
3. 把 verified 当作「可以继续看」的入场券，而不是「可以直接装」的通行证。
4. 如果来源仓库都打不开，徽章再亮也不要继续。

来源校验的价值是真实的：它让你知道这个条目不是凭空出现的。但它的边界也同样真实——它检查的是「条目层」，不是「代码层」，更不是「运行时层」。

它不覆盖的三类风险：DSH plugin 的权限、依赖与构建脚本

插件真正的风险发生在运行时与安装时，而 verified 恰好不检查这两个时刻。 三类风险最值得逐项看：

1. 权限范围：插件要读写哪些目录、能不能起本地端口、能不能调用工具。功能只需要读一个配置，却申请了整盘访问，就是信号。
2. 依赖数量与来源：依赖越多，供应链面越大；依赖里出现来源不明的包，风险不会因为主包带 verified 而消失。
3. 构建脚本：从源码安装时，依赖可能在安装阶段执行脚本。带 verified 的条目也可能要求执行脚本，仍需你确认是否信任。

这三类风险有个共同点：它们都不在「条目来源」这一层，而在「代码怎么跑」这一层。徽章能证明条目真实，不能证明代码克制。

看到 verified 后，DSH plugin 还要补的三项检查

补检的顺序是「权限 → 依赖 → 构建脚本」，从影响面最大的开始。 三项都能在安装前后找到线索，不需要读完整源码。

1. 权限：在详情页或插件说明里找它声明的能力范围，对照功能判断是否超配。
2. 依赖：看依赖数量与来源，出现陌生 scope 或明显与功能无关的包时提高警惕。
3. 构建脚本：安装时若提示允许执行脚本，先确认仓库是否可信；不确定就拒绝，改用预构建版本。
4. 来源仓库：最后回仓库看最近提交与 issue，确认它不是只挂了一个空壳。
5. 记录结论：把这三项的判断写进自己的笔记，下次更新时可以直接复用。

三项检查不需要一次做完，但至少要在「接进日常工作流」之前做完。临时试用可以放宽，长期使用不能省。

三项检查的快速顺序

1. 先看权限是否超配，这一项影响面最大。
2. 再看依赖数量与来源，陌生包要逐个问「为什么需要它」。
3. 然后看构建脚本，不确定就拒绝执行，改用预构建版本。
4. 最后看仓库活跃度，确认出问题时有人能修。

四项走完还说不清，就把它放进隔离环境试用，不要直接进日常 profile。

与 Star、更新时间叠加：DeepSeek Harness 信任信号怎么组合

信任信号要叠加看：verified 管来源，更新时间管维护，Star 管关注度，三者回答三个问题，不能互相替代。 叠加之后，你能得到一张比单个徽章可靠得多的画像。

1. 先看 verified：没有徽章不等于不能用，但来源要多花一步核对。
2. 再看更新时间：近期有维护，说明出问题时有人响应；长期不动，要有自担风险的准备。
3. 再看 Star/Fork：只用来建候选池，不用来替代权限与依赖检查。
4. 三个信号冲突时，以「来源 + 维护」为主，热度最后考虑。
5. 把组合结论记下来，更新插件时对照一次，避免每次重新判断。

站内已经把这套组合拆得更细，见 DSH plugin 信任信号怎么读。这篇只强调一件事：verified 是组合里的一格，不是整张表。

什么时候该放弃一个 verified 的 DSH plugin

出现「权限超配、依赖可疑、脚本不透明、仓库失活」任意一条，就该放弃，而不是用徽章说服自己。 放弃不是保守，而是把风险挡在安装之前。

1. 功能只需要读配置，却要求访问整个用户目录或网络。
2. 依赖里出现与功能无关的陌生包，且来源仓库没有说明。
3. 安装要求执行未在文档里说明的构建脚本。
4. 来源仓库长期不更新，issue 无人回应，版本却一直在涨。
5. 插件描述与来源仓库对不上，或详情页缺关键信息。

这五条里，前三条是代码层风险，后两条是维护与来源风险。任何一条成立，都不该用「它有 verified」来抵消。装前检查的完整清单见 点安装前的 60 秒，卡片的其他信号见 市场卡片怎么读。