本文实测环境Windows DeepSeek Harness 官方桌面客户端Electron。文中的路径统一用环境变量表示示例属于脱敏写法插件本身是公开仓库 MeteorNOX/DeepSeek-Balance-Whale-Widget。起因我想给 DSH 装一个右下角常驻的余额挂件显示 DeepSeek 余额、今日已用和每轮对话消耗。这类插件在 DSH 里叫 bundle 插件正常情况下一条命令就能装。插件的 README 给的命令是这样的dsh plugin--profile web add dsh-whale-widget我照做了接着折腾了十几分钟。问题不在命令写错了而在我装错了 profile。这篇把整个过程记下来因为这类装成功了但界面什么都不显示、控制台也不报错的问题第一反应很容易怀疑插件坏了。第一步先确认你在哪种 DSH 里DSH 有两种常见运行形态命令行起的dsh web和官方 Electron 桌面客户端。两者读的是不同的 profile而 profile 决定了插件装到哪里、界面从哪里读。不用猜环境变量里写得清清楚楚Get-ChildItemenv:|Where-ObjectName-likeDSH_*我的输出里有三个关键项DSH_HOME 用户目录\.dsh DSH_PROFILE desktop DSH_PROFILE_DIR 用户目录\.dsh\profiles\desktopDSH_PROFILEdesktop就是答案我现在跑在桌面客户端里它读的是desktopprofile不是web。对应的 profile 目录长这样一个 profile 就是一个独立的小工程%USERPROFILE%\.dsh\profiles\desktop\ ├── package.json # 依赖 dsh.profile.bundles插件清单 ├── pnpm-workspace.yaml ├── pnpm-lock.yaml ├── cordis.patch.yml # 用户自己的补丁层 └── node_modules\所以 README 里那条--profile web命令在这个环境下装完是落在webprofile 里的桌面窗口从desktop读自然一个字都读不到。表现就是右下角什么都没有控制台也没有报错。不是插件的问题是它被装到了另一间屋子。第二步用客户端自带的 CLI 装进 desktop profile这里有个小坑通用的dsh命令行按设计拒绝碰desktopprofile会直接报error: profile desktop is managed exclusively by the Electron application那不让你用是不是就只能手动去改 profile 里的文件不必。桌面客户端自己带了一个 CLI它能正常操作desktopprofile$dsh$env:LOCALAPPDATA\Programs\DeepSeek Harness\resources\runtime\cli\bin\dsh.cmd$dshplugin--profile desktop add dsh-whale-widget执行结果就是一次普通的 pnpm 安装dependencies: dsh-whale-widget ^0.3.18 Done in 2.1s using pnpm v11.7.0这一步不需要手工改任何配置文件。命令跑完profile 的package.json里依赖和插件清单都已经自动写好了{dependencies:{dsh-whale-widget:^0.3.18},dsh:{profile:{bundles:[deepseek-ai/dsh-base,deepseek-ai/dsh-web-app,dshmarket,dsh-whale-widget]}}}如果你手上是本地资源包或开发目录把包名换成link:仓库绝对路径即可link:是软链安装改了源码立刻生效但装完之后不能再移动或重命名那个目录。第三步分清宿主半区和客户端半区这是整件事里最有价值的一段。DSH 插件通常分两半宿主半区跑在 DSH 主进程里负责注册 HTTP 路由、读凭据、写账本客户端半区一段前端脚本由宿主注入到页面里执行负责画界面。两半的活了没有要分开判断不然只会看到没反应三个字。判断宿主半区直接探测插件注册的路由。这里要注意 DSH 有一层浏览器信任栅栏不带会话凭据的裸请求会返回 401/403这是预期的——它恰好说明路由已经注册好了curl.exe-s-o NUL-w%{http_code}nhttp://127.0.0.1:端口/dsh-whale/size.json# 401路由已注册被信任栅栏拦下再拿一个同前缀但肯定不存在的路径做对照curl.exe-s-o NUL-w%{http_code}nhttp://127.0.0.1:端口/dsh-whale/definitely-not-real.json# 404说明上面的 401 不是所有请求都 401而是路由真的在一次对照就能定性401/403 挂上了404 没挂上。判断客户端半区桌面端的前端注入表是在宿主启动时一次性收集的没有运行时刷新路径。也就是说插件是启动之后才装进去的话宿主这半区能立刻热加载但页面拿不到注入行——界面就永远不会出现。这不是 bug是运行期装的插件没赶上开门时间。结论很朴素装完必须重启一次桌面客户端。重启之后我实测到的现象是DSH 的运行目录里出现插件自己的状态文件随时间更新说明宿主在持续记账弹窗/挂件的设置文件生成说明前端脚本真的跑起来了界面右下角出现挂件余额、今日已用正常显示。如果重启后仍然什么都没有可按插件 README 的顺序检查assets/是否完整缺图缺声不会报错只会静默降级、凭据是否配置、以及是否有下载管理器把挂件音效的请求抢去当下载任务。第四步卸载与两个容易踩的点卸载就是把add换成remove$dshplugin--profile desktop remove dsh-whale-widget两个要点安装方式二选一不要混用。同一个插件既有 npm 包也能从 GitHub 仓库直接装。两种方式装的是同一个包名先后安装会并存冲突要换方式先remove再add。profile 是隔离的。web里装了不代表desktop里有反过来也一样。以后看到Dsh 插件装了没反应第一步就该确认DSH_PROFILE。这次得到的一条通用经验排查这类问题先问三个问题能省掉大部分瞎猜我的程序读的是哪个 profileDSH_PROFILE一查就知道插件的宿主半区活了吗探一个它自己的路由401/403 也算活客户端半区需要重开程序才会加载吗注入表在启动时收集 → 是文中结论的状态说明已验证desktopprofile 的安装命令可正常执行并自动写入依赖与dsh.profile.bundles重启客户端后挂件可显示宿主侧记账与状态文件正常更新。未验证其他 DSH 版本的 profile 行为是否完全一致插件的长期稳定性以上步骤在 macOS / Linux 下的等价路径本文只覆盖 Windows。
