dsh-plugin-maker
中文 | English
Everything is a Plugin. Maker helps you build one without paying the same engineering cost every time.
dsh-plugin-maker 是面向 DeepSeek Harness 的插件开发工具集。
它不替你决定“应该做什么插件”，而是帮助你在真正开始开发之前回答几个更实际的问题：
- DSH 已经支持了吗？
- 有没有现成的插件可以复用？
- 这个需求到底需要插件，还是其他形态？
- 这个接口是不是已经稳定？
- DSH 更新以后，哪些地方需要重新验证？
Maker 关注的不是“多做一个插件”，而是让插件开发的重复工程成本尽可能低。
为什么需要 Maker
DSH 的一个重要设计是：
Everything Is a Plugin.
能力可以组合、替换、扩展。
自由度越高，开发者承担的工程工作也越多。
一个看似简单的插件需求，实际可能需要经过：
理解需求
→ 查 DSH 文档
→ 查源码
→ 找现有实现
→ 判断接口
→ 搭骨架
→ 开发
→ 验证
→ 打包
→ 安装
→ 再验证
如果这些步骤每次都从头开始，开发者和 Agent 都会反复支付相同的成本。
DSH 官方已经提供了很好的教程、Cookbook 和 capability seam 文档，但它们主要解决：
“怎么使用 DSH。”
Maker 更关注：
“怎么把这些已经存在的方法变成可重复的开发流程。”
核心思路
1. Reuse before invent
开始写代码之前，先检查：
本机已有能力
↓
生态已有插件
↓
DSH 原生能力
↓
成熟的工程做法
↓
最后才是自己实现
因此 Maker 有时候最重要的输出不是：
“这是一个新插件。”
而是：
“这个东西现在不需要造。”
如果现有方案只能覆盖一部分，Maker 更倾向于：
复用已有部分，只补真正缺失的部分。
2. 把稳定的工程事实交给工具
有些事情不值得每次都让模型重新判断。
例如：
- 插件目录结构；
- 入口形式；
- bundle 配置；
- export；
- 注册方式；
- 已验证的 DSH contract；
- 发布前检查。
这些内容适合变成：
可重复执行、可验证的工程动作。
因此 Maker 提供：
| 工具 | 作用 |
|---|---|
scaffold |
生成经过验证的最小插件骨架 |
check |
检查插件契约、发布要求和已知兼容性问题 |
vet |
接入第三方插件前进行体检 |
adopt |
自动应用少量安全、确定性的改造 |
impact |
扫描变更影响面 |
checklist |
将开发期固定动作变成可执行清单 |
3. 变化只观察真正相关的地方
DSH 仍在快速演化。
一个插件真正依赖的可能只是少数几个 runtime / package / client surface。
因此 Maker 不试图每次完整重读整个 DSH，而是：
插件实际依赖
↓
声明相关挂点
↓
观察上游变化
↓
命中相关挂点
↓
重新验证
这样升级关注的是：
“我的插件哪里可能受到影响？”
而不是：
“DSH 这次所有地方都发生了什么？”
两个自带 Skill
/plugin-studio-wizard
插件需求向导。
先判断：
现有本机能力？
↓
生态已有方案？
↓
DSH 原生支持？
↓
是否真的需要自己实现？
只有确定需要自建后，才进入具体的实现路径。
向导负责辅助判断，不替用户做最终授权。
/five-step-research
面向插件开发的快速调研流程：
平台能力
→
同生态方案
→
行业参照
→
工程实践
→
需求验证
用于在开始实现前快速确认“是不是值得做”。
怎么使用
生成插件
plugin_maker_scaffold
输入插件名和简单描述，生成符合 DSH 约定的最小骨架。
校验插件
plugin_maker_check
检查：
- plugin contract；
- bundle / export；
- 注册方式；
- 发布要求；
- 已知迁移事实；
- 基线兼容性。
接盘已有插件
plugin_maker_vet
对已有插件进行检查，并给出：
- 当前契约情况；
- 风险点；
- 依赖的官方 surface；
- 可能的挂靠位置；
- 建议关注的改造点。
自动应用安全改造
plugin_maker_adopt
只执行已经明确、安全、可验证的改造，不替开发者做开放式设计决策。
变更前检查影响面
plugin_maker_impact
在删除文档、重命名、调整接口或改变语义前，先检查引用关系，减少遗漏。
开发清单
plugin_maker_checklist
把已经确认的开发动作固定下来，避免每次重新回忆。
一个重要的边界
Maker 不是自动插件生成器。
它不会试图：
需求
→ 自动判断一切
→ 自动设计架构
→ 自动写完插件
它更倾向于：
需求
↓
先判断是否需要做
↓
确认已有能力
↓
缩小真正需要解决的问题
↓
把确定的工程工作工具化
↓
把开放性的判断留给开发者
所以 Maker 的重点不是：
让 Agent 替开发者做更多决定。
而是：
减少开发者和 Agent 在确定性工程工作上的重复成本。
独立使用
Maker 本身可以独立运行。
六个工具和两个 Skill 不要求其他协作插件才能工作。
对任何插件目录都可以使用 check / vet，而不仅限于 Maker 生成的插件。
协作相关动作在对应能力不存在时会自动隐藏。
上游观察默认按日运行；没有变化时不产生额外输出。
更多信息见：
为什么现在开源
Maker 最初与一些内部协作机制存在较深耦合。
经过持续拆分以后，它现在已经可以作为独立的 DSH 开发工具运行。
继续只在单一环境里迭代，能够获得的新信息越来越少。
下一阶段更重要的问题变成：
陌生开发者会怎么使用它？
他们真正需要的会是：
- Scaffold？
- Check？
- Vet？
- Research？
- Impact？
- 还是完全没有想到的其他东西？
这些问题只有真实的插件生态能够回答。
所以：
这次开源不是意味着 Maker 已经完成，而是内部实验阶段结束，外部使用阶段开始。
当前状态
当前版本以 GitHub tag 为准。
已覆盖的主要能力包括：
- 插件 scaffold；
- 插件 contract check；
- 第三方插件 vet / adopt；
- 影响面分析；
- 开发清单；
- 上游依赖观察；
- 插件开发向导；
- 快速调研 Skill。
已吸收部分 DSH 版本迁移事实，并持续通过源码、文档和实际运行验证更新。
安装
pnpm pack
dsh plugin --profile web add file:<本目录>/dsh-plugin-maker-<版本>.tgz
目录
lib/
工具实现
skills/
开发向导
调研 Skill
docs/
独立使用
工程规范
上游观察
问题与修复记录
一句话
DSH 给了插件化的自由，Maker 负责降低使用这种自由时产生的工程成本。
它不试图让插件越来越多。
更希望让真正值得成为插件的东西，更容易被做出来，也更容易被验证。
No comments yet. Be the first to write one.