dsh-web-ui 插件准入指南：5 步判断你的插件能否进全家桶-平芜编程栈

dsh-web-ui 插件准入指南：5 步判断你的插件能否进全家桶

【免费下载链接】dsh-web-uiPlugin and skin collection for DeepSeek Harness (DSH) Web UI - task board, git graph, right-side panel, remote mobile UI, pet, live token stats, and skin center.项目地址: https://gitcode.com/gh_mirrors/ds/dsh-web-ui

dsh-web-ui 是 DeepSeek Harness（DSH）Web UI 的插件与皮肤全家桶——任务看板、Git 图谱、右侧面板、远程移动端、桌面宠物、实时令牌统计与皮肤中心都出自这个仓库。社区插件想进来，别急着提 PR，先跟着本文走一遍完整的准入流程：先做自检归类，再选收录或登记通道，最后对照合规红线与检查清单，确保一次通过。

先做一张准入自检：你的插件属于哪一类

在动手提交之前，先回答一个关键问题：这段代码的版权到底归谁？这个答案直接决定了你的插件走哪条收录路径。家族仓库欢迎社区插件，但收编必须透明，所有规则都写在仓库的 docs/plugins.md 里。你可以用下面这张自检表快速归类：

插件状态	判定标准	对应处理方式
活跃且有上游维护	上游还在持续更新	不搬代码，fork 或作为依赖引用
满足收编条件	上游停更、无活跃上游、或作者明确授权托管	git subtree 迁入，保留完整历史
触犯合规红线	无 LICENSE、作者未授权、版权归属不明	一律不收编

自检完成后，绝大多数情况都能对号入座。接下来我们分别看这两条合法通道怎么走。

能引用就不搬代码：活跃上游插件的正确去向

如果你的插件活跃且有上游维护，家族仓库不会搬运你的代码。正确的做法是 fork 到 dsh-external 组织维护，或者作为依赖被全家桶引用——这样既保留上游关联，又能随时 merge 上游的更新；全家桶只负责注册它的安装入口，其余交给上游自己迭代。

记住这句强对比：能引用的不搬代码，要收编的必留痕迹。只有当你明确想放弃上游、把插件正式托管进家族仓库时，才需要考虑收编。

要收编必留痕迹：合规审核看什么

满足收编条件（上游停更、无活跃上游、作者授权托管）后，迁入动作本身也有硬性要求：

用git subtree add迁入，保留完整 git 历史；
必须保留上游 LICENSE 文件与作者署名（包内 LICENSE、README 作者声明）；
在包 README 记录来源仓库与迁移日期；
版权归原作者，本仓库仅托管、不主张版权。

合规红线只有三条，碰任何一条直接出局：无 LICENSE、作者未授权、版权归属不明。这条底线保护了原作者权益，也让每个用户用得安心——全家桶里收录的每一段代码都有清晰出处。

一个插件从提交到上线的完整流程

确认走收编路径后，按下面七步推进。需要提醒的是：全新功能、新插件暂不接受直接 PR，先提 issue 讨论、确认后再动手，这是仓库贡献指南（CONTRIBUTING.md）的明确约定。

提 issue 讨论插件方案，确认收编意向；
跑脚手架生成标准骨架：node scripts/dsh-plugin-new <name>，自动产出双语 README 三件套与 AGENTS.md 模板；
实现逻辑：src/index.ts是 host 半区（跑在 dsh 进程侧），src/client/是 browser 半区（Web GUI 侧），src/core/放两侧共享的纯逻辑；
注册进聚合包：把- ../<name>追加到packages/dsh-web-ui-all/aggregate.yml的patchFrom和deps，再运行node scripts/aggregate.mjs；
构建验证：pnpm install后跑pnpm -r build；
本地挂载验证：node scripts/link-profile.mjs把全家桶链接进 profile，重启dsh web确认插件行生效；
提 PR：按模板填写、门禁全绿、用户可见功能附截图证据、使用 AI 编码时如实披露。

收录不等于一劳永逸：五个必须遵守的包级规范

被收编的插件还要遵守全家桶的通用规范，确保生态一致：

命名：新包一律dsh-前缀，npm 包名@linxin666/dsh-*；
挂载：只通过cordis.patch.yml+ profile 机制挂载到 DSH Web UI，绝不修改 DSH 源码；
类型来源：只能基于官方 NPM SDK（@deepseek-ai/*），禁止 tsconfig 指向任何 DSH 源码 checkout；
双语纪律：主包 README 必须中英配对（README.md+README.zh.md+README.i18n.yaml），任一侧改动要同步另一侧；
测试纪律：每个包必须有vitest run可通过的测试，行为变化必须带测试。

这五项是 CI 门禁的一部分，缺一不可——它们共同保证了全家桶装得齐、跑得稳、改得动。

不想被收编？还有一条轻量登记通道

如果只想让更多人发现你的插件，而不想把代码迁入仓库，可以用社区插件索引：它只收录链接、不搬代码，条目版权归原作者。在设置 → 社区插件里，每个条目都链接到作者自己的仓库，目前 Data Agent、dsh-TUI、天书 TUI 等社区插件都是这样登记的。登记只需三步：

在packages/dsh-community-plugins/community.json追加条目：id/name/nameEn/author/repo（https:// 仓库 URL）必填，description/descriptionEn/npm可选；
运行node scripts/community-index重新生成注册表，并提交生成的community.ts；
运行pnpm community:check校验数据与生成物一致，这是 CI 门禁。

提交前对照这份清单，避开最常见的被拒原因

最后，把最容易踩坑的四种情况摆在桌面上，提交前逐条核对：

代码没有 LICENSE，或版权归属说不清——红线问题，直接拒绝；
全新功能 / 新插件跳过 issue 直接开 PR——会被打回，先去讨论确认；
只改文档的 PR（标题以 docs: 开头）——会被自动关闭，文档改动先提 issue；
门禁不过——typecheck、test、docs:check 必须全绿；涉及聚合包、画廊、皮肤中心时还要跑 aggregate:check / gallery:check / skin-center:check；提交信息与文档禁带 emoji。

下一步做什么？如果你是插件作者，先读仓库的 docs/plugins.md 与 CONTRIBUTING.md，确认自己的插件满足收编条件，再按流程提 issue、实现、过门禁。如果你是普通用户，也可以放心——设置页里出现的每一个插件，都经过了同样的合规审查。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考