前言¶

给 DeepSeek Harness（DSH）写插件，代码本身往往不是最花时间的部分。真正容易出问题的是两头：起步时要建目录、套模板、配依赖；发布前要跑类型检查、测试、打包预览、密钥扫描，还要确认包能装进一个干净的 DSH profile。这些步骤手工做一遍不难，难的是每次都不漏。

dsh-plugin-forge 把这整条链路搬进了 DSH 的聊天工作流，并在关键节点上设置了人工确认：模型可以干活，但不能替你批准阶段、建仓库或发包。下面介绍它的定位、安装与典型用法。

这是什么¶

dsh-plugin-forge 是由 luoyuejun9 维护的一个 DSH 插件，定位一句话可以说清：一个人工把关（human-gated）的插件创建、验证与发布工作台。

基本信息：

• 版本：0.1.0
• 许可：MIT
• 目标 DSH 版本：0.1.0-rc.6
• 运行环境：DSH Web profile
• 运行要求：Node >= 22.19

它把「一个插件想法」变成一串可追溯的产出：先生成版本化的规格，再生成安全的项目脚手架，接着跑验证拿到证据，做一次隔离的 DSH 安装检查，最后——只有在人工明确确认之后——才发布到 GitHub/npm。

DSH 的理念是「一切皆插件」，「怎么规范、安全地把一个插件做出来并发布出去」本身就是生态里的真实需求，dsh-plugin-forge 解决的就是这个问题。

核心能力¶

四个 v0.1 模板¶

新项目从模板起步，当前提供四种：

• tool-command
• skill-wrapper
• stateful
• bundle

/forge 命令与 Web Studio 卡片¶

插件面向 DSH Web profile，贡献了 /forge 命令，并在聊天里提供一张可重放的 Plugin Forge 卡片。这张卡片是原生 DSH Conversation Node，状态基于持久化的 forge/* 会话事件重建，因此重放对话、加载更多聊天历史之后，阶段状态依然在。

阶段推进只认人工确认¶

整条工作流里，只有 /forge continue 能把阶段往前推。模型可以读状态、做校验、跑检查、写入受限的实现文件，但不能批准阶段、不能创建仓库、不能发布包。发包这一步始终留在人手里。

安装与启用¶

用官方安装命令，把插件装进 Web profile：

dsh plugin --profile web add dsh-plugin-forge@0.1.0

安装完成后需要重新加载 DSH Web profile，之后 /forge 命令和聊天里的 Plugin Forge 卡片就可以使用了。

典型用法¶

下面是从 README 中照搬的完整流程，从环境检查一直到发布：

/forge doctor
/forge new dsh-my-plugin --type tool-command --title "My plugin" --description "A focused DSH capability"
/forge continue <forge-id>
/forge run <forge-id>          # scaffold
/forge continue <forge-id>
/forge run <forge-id>          # implementation assistance
/forge continue <forge-id>
/forge run <forge-id>          # verification
/forge continue <forge-id>
/forge release <forge-id> --dry-run
/forge publish <forge-id> --fingerprint <sha256>

按顺序拆开看：

1. /forge doctor 先检查环境是否就绪。
2. /forge new 创建新插件项目，指定类型、标题和描述。生成的项目必须是活动 DSH workspace 下的新目录。
3. 接下来是 continue 与 run 交替推进：先做 continue 进入下一阶段，再做 run，依次用于 scaffold（生成脚手架）、implementation assistance（实现辅助）、verification（验证）。
4. 经过上面的步骤，项目完成了脚手架、实现和验证，用 /forge release <forge-id> --dry-run 预演一次发布，不真正发包。
5. 确认无误后，/forge publish <forge-id> --fingerprint <sha256> 携带当前 release fingerprint 正式发布。

本地开发验证用这三条命令：

npm install
npm run check
npm pack --dry-run

安全边界¶

这个插件对「模型能做什么」划得比较细，几条规则都写在了文档里：

• 生成的项目必须是活动 DSH workspace 下的新目录。
• 模型只能写 src/、test/、schemas/、docs/ 这几个目录；模板、依赖、发布配置、.git 与凭据都受保护。
• 新增依赖须通过与一个小型 DSH/TypeScript 白名单的比对。
• 验证流程会跑 npm install --ignore-scripts、typecheck、test、build、pack preview、secret scan，以及一次干净的 DSH profile 安装。
• 发布需要当前 release fingerprint，项目有任何变更都会使既定的发布计划失效。
• Forge 会调用你已有的 git、gh、npm 会话，但不读取、也不存储它们的凭据。

适用场景与注意事项¶

适合谁：需要反复开发 DSH 插件、想把从创建到发布的流程固定成一条可重放工作流的开发者；尤其是希望模型负责执行、但发布决策留在自己手里的场景。

几点注意：

• 插件以当前 dsh 进程的权限运行，安装前建议先查看源码与许可证（MIT，仓库另有中文文档 README.zh.md）。
• 安装后需要重新加载 DSH Web profile 才能生效。
• 发布是人工确认制：--dry-run 不会发包，publish 必须携带有效的 fingerprint，项目变更后需要重新走发布计划。

结尾¶

dsh-plugin-forge 的价值不在替你多写多少代码，而在把「造插件」这件事里容易出错的环节——脚手架、验证、安装检查、发布——串成一条有人工闸门的流水线。如果你在给 DSH 生态写插件，值得试一试。

• 社区目录页（社区维护的独立站点，与 DeepSeek / 幻方无官方从属关系）：https://www.skillhub.cn/plugins/luoyuejun9/dsh-plugin-forge
• GitHub 仓库：https://github.com/luoyuejun9/dsh-plugin-forge