夜雨聆风↑阅读之前记得关注+星标⭐️，😄，每天才能第一时间接收到更新
大家好，我是杰克王，AI 算法 6 年老兵。
一个插件仓库，看着好好的，装上就崩。
不是代码写得烂，是坑太隐蔽：cordis 被装出双份副本、tsconfig 少了关键三件套、patch 里的名字和清单对不上、构建产物里残留了一个 .ts 文件——每一个都能让运行时直接挂掉，而且不跑起来根本发现不了。
写 DSH 插件的作者们反复踩同一批坑之后，有人忍不了了，把所有踩过的坑做成了 33 项自动检查，一次扫描出完整体检报告。
这个工具叫 dsh-plugin-check，8 月 8 日刚开源，MIT 协议，目前 17 颗星（截至 2026-08-15）。星不多，但它背后的信号值得说说。
背景：DSH 插件生态已经长到 810 个项目了
昨天我们刚写过 DeepSeek Harness（DSH），那个 9.2 万星的"Agent 攒电脑"框架。
它的插件生态涨得比想象中快。社区插件市场 DSH Hub Workshop 上，现在已经挂着 810 个项目、803 个仓库、9 个分类（截至 2026-08-15 截图）。
生态爆发的另一面是质量参差。DSH 插件有自己的一套规矩：清单协议、patch 格式、Profile Bundle 安装规范，任何一个环节出错，插件装上就是坏的。靠人工 review 810 个仓库？不现实。
dsh-plugin-check 干的就是这件事：把人工经验变成自动门禁。
它怎么工作
注册一个叫 plugin_check 的工具，模型或 CI 直接调用，三个动作：
| Action | 干什么 |
|---|---|
check |
检查单个插件仓库，输出合规报告（verdict / errors / warnings / 修复建议） |
scan |
扫描父目录下所有 dsh-* 插件，出汇总报告 |
schema |
输出全部 33 项检测清单和判定标准，供人和模型核对 |
33 项检查按插件形态（registry / skill / tool-bundle / bundle 等）自动套用不同检查集，覆盖五类问题：
清单协议：manifest 缺失、name 不合法、没声明 patch patch 格式：格式错误、patch 名和清单不一致、row id 重复 构建陷阱：缺 tsconfig、import 缺 .ts 扩展名、产物残留 .ts 文件 生态合规：能否通过标准 Profile Bundle 安装、是否要求改 DSH 核心 hub 收录：是否被社区市场收录
安全模型做得挺克制
这个工具的设计原则，我觉得比功能本身更值得学：
只读：只用 readdir / stat / readFile，绝不修改、绝不构建被检查的仓库 零业务依赖：只用 Node 内置模块 不执行 tsc：构建陷阱全部用静态文本扫描判断，快，且无副作用 离线优先：hub 收录检查先读本地 catalog，失败了如实标注 skipped，不算警告
给 AI 用的检查工具，最怕的就是它偷偷动你的代码。这个"只读 + 如实汇报"的姿势是对的。
实测：先拿自己人开刀
作者先在组织内部 8 个插件上跑了一遍自检：time / encoding / json / calculator / csv / regex / markdown / session-health，全部 pass。
但过程不是白跑的——扫描顺带发现并修复了 4 个旧插件的真实缺陷：tsconfig 缺三件套（重建会产生坏产物）、缺 build/prepack 脚本。这些插件之前都在正常工作，没人知道里面埋着雷。
怎么用
装了 DSH 的话，一条命令装进 profile：
# 交互式（web）profile
dsh plugin --profile web add github:omdsh-dev/dsh-plugin-check
# 一次性任务（headless）profile
dsh plugin --profile headless add github:omdsh-dev/dsh-plugin-check
然后让模型自己跑：
dsh run "使用 plugin_check 工具检查一个插件仓库"
如果你在给 DSH 写插件，或者你的团队在维护一批插件仓库，这个工具值得放进 CI。17 颗星不代表它没用，只代表它刚出来。
仓库地址：github.com/omdsh-dev/dsh-plugin-check
DSH 生态现在处在"野蛮生长→建立秩序"的转折点上。810 个插件之后，谁先解决质量和信任问题，谁就拿到生态的下一个入口。这类"卖水"的工具，往往比插件本身走得更远。
觉得有收获，点个在看支持一下 👇 感谢阅读。我是杰克王，欢迎加微交流 🚀