DSH WorkBuddy Connect
corrinehu/dsh-workbuddy-connect将 WorkBuddy 桌面 App 包含的模型自动接入 DeepSeek Harness,在 DSH 对话窗口里零配置使用。
将本机登录的 WorkBuddy 模型接入 DSH,支持逐模型图片输入开关、账号切换,以及带每日签到的只读积分概览。
dsh-connect-workbuddy
English · 安装 · 工作原理 · 账号池 · 更新日志 · 问题反馈
一个独立的 DeepSeek Harness (DSH) bundle 插件。它把本机已登录的 WorkBuddy 账号(国内版与国际版 WorkBuddy AI 均支持)接到 DSH 的模型选择器,同时提供账号池、可勾选的模型管理,以及一套围绕积分的只读能力:每次刷新按上游目录自动读取每个模型的积分倍率(x0.79 这种,倍率完全由上游给出,插件不写死也不猜)、逐模型开关图片输入、多账号切换与账号池自动换号、每日签到、以及卡片与输入框里胶囊式的只读积分读数。国内版与国际版是两个并行的供应商(`workbuddy` / `workbuddy-global`),可同时使用;插件设置卡片以 tab 区分两者,方便统一管理。只需本机 WorkBuddy 的登录态,或在浏览器里登录一次即可。
WorkBuddy 已开始限制非官方客户端请求。本项目不保证相关接口长期可用,上游一旦收紧限制,插件可能失效。请先阅读文末「免责声明」,自行评估账号风险。使用官方 WorkBuddy 客户端始终是最安全的选择。
需要说明的是,这个插件的目的很普通:省掉在 WorkBuddy 客户端和 DSH 之间来回切换的麻烦。你已经在自己的机器上登录了 WorkBuddy,插件只是把那份已有的登录态接到 DSH 的模型选择器上,让你在写代码的地方直接用到它——不提供账号、不共享凭据、不绕过计费。每一次调用都消耗你自己账号的额度,按上游给出的倍率真实扣费,插件从不修改账号状态,也不附带任何提权或刷额度的能力。
它依赖的是 WorkBuddy 客户端自身的接口(非官方开放 API),所以上游调整时插件可能需要跟着调整——这是这类工具的常态,也是这条提示存在的原因。请自行评估账号风险后再决定是否安装。
workbuddy provider(GLM-5.3、DeepSeek-V4-Pro、Kimi-K3、MiniMax-M3、Hy3 等),国际版注册为 workbuddy-global provider(GPT-5.6、Gemini-3.5-Flash、GLM-5.3、Kimi-K3 等)。有账号的区域其模型会出现在 DSH 模型选择器里:两边都有账号时两组同时可选,不同会话可以各选一边,互不干扰。本机没有账号的区域不列出任何模型(该区域一个请求也发不出去,列出来只会点到就失败);只要在该区域登录一次,「重新检测账号」或重启后模型就会自动出现——provider 本身始终注册着,因为它的设置卡片正是登录的入口(重新检测在账号池区块里)。模型名内嵌上游积分倍率(如 GLM-5.3 · x0.79),与 WorkBuddy 自身模型菜单一致;活动时段显示的是折后价——「夜间折扣」开着的时候,卡片与选择器上的数字一起变成 x0.06,活动一过自动回到原价,不需要重启(#120)。NO_ADAPTER,卡片会在关闭态的 tab 上明确提示这一点,不会静默失败。hidden 不可见,因此也不进入无障碍树)。第三栏「能力」放的是授权类开关——允许调用本机 CodeBuddy CLI、允许模型自主生图、积分读数显示在哪——它们点一下即生效、从不经过保存,而且每一个都留着长自己子选项的位置(CLI 的工作目录、生图的尺寸或价格上限),所以不挤在账号表格上方那一小条里。第四栏「诊断」是只读的事实表:当前区域、上游域名、真正在服务的账号名、登录有效期、目录里共几个模型、启用了几个、账号池开关,以及上游最近一次错误的原文(原样引用,不翻译、不概括)——这一栏存在的唯一理由就是能被整段贴进问题反馈,所以里面没有任何会改设置的控件。supportsImages 是平台侧声明,不等于模型能看图,不参与判定)。用户仍可随时手动勾选,勾选状态保存在本地。每个模型行还有「可关闭思考」(`off`)勾选框:决定要不要为该模型提供「完全关闭思考」这一档位。默认由内置复核名单给出(上游声称可关闭、实测却对它返回 HTTP 400 的 9 个模型默认不勾),你可以按模型改勾/取消——取消用于当前不需要该档位的模型;名单内那 9 个模型不可勾选(行上标「拒绝 off」,悬停有说明):该档位被勾上后不只是多一个选项,pi-ai 会把它当作所有未指定档位请求的默认值,压缩摘要请求正属于这一类,勾一次等于让该模型的每一次 /compact 都 400 / 11133(issue #83)。名单外的模型仍完全由你的勾选与自身声明决定;首次保存即写入你的勾选,之后不再重算。/v3/config 时带 8 条促销 + 1 条等级标记,国际版带 5 条 + 1 条;取证与判定规则见 docs/PROMO_BADGE.md。)POST /v2/chat/busy,一次最多 50 个 id,免费、不动账号状态)回答「这个模型此刻多忙」,插件在每次刷新目录时顺带问一次,把等级画成模型名旁边的一枚小人图标:排队人数 = 小人个数(正常 1 个黄人 / 轻微拥堵 2 个橙人 / 极度拥堵 3 个红人),空闲则是一枚绿色小火箭(没人排队 = 可以全速跑)——空闲不画成「绿色的 1 个人」,因为 12px 下「没人等」与「有 1 个人在等」必须一眼分开;不可用是一个划掉的小人。探针没回答的 unknown 一律不画,「没被告知」不会被当成「一切正常」;颜色跟随主题,title 悬停文字(「极度拥堵」四个字)仍在。等级不落盘:目录是能活过重启的事实,负载只是那一分钟的事实,所以等级只盖在运行时目录上、随进程消失,探针失败只记一条 warn,绝不挡住目录刷新。国内版实测这条探针在 CLI 与 App 两种身份下答案逐字节相同,50 个 id 的上限也真实存在(62 个 → HTTP 400),19 个模型 186 ms 返回。国际版没有这个徽标,因为国际网关根本没有这条接口 —— 实测 www.workbuddy.ai 对 /v2/chat/busy 回 404(/v3/chat/busy、/v2/models/busy 等同族路径也全是 404),而同一份凭据读它的 /v3/config 正常返回 28 个模型、没有任何负载/排队字段。这不是本插件没实现,也不是配置或权限问题:上游国际版从未提供这个数据。所以国际版只显示模型名与活动徽标,探针那条请求失败后安静退化成「没有徽标」,不会挡住模型列表,也不会用延迟或积分去猜一个「忙不忙」。6020 等待、6021 队列满、6022 已达上限)。撞上它们时,插件不再给一句上游报错,而是「模型排队中:你排在第 8777 位,队列共 9021 个请求。请稍后重新发送这条消息,或换一个模型」。排队不会触发换号:队列跟随的是模型与平台级的队伍,换个账号拿到的还是同一个位次,所以这里既不走账号池也不额外烧请求(上游 /v2/chat/queue/status 回的 message 是 i18n key 而不是人话,插件因此从不转述它,只用自己的措辞)。排队不会自动重发,也不会被自动重试——插件没有排队轮询循环(它需要排队答案在 OpenAI 兼容通道上的真实信封,没测到就不写),并且明确告诉宿主不要重试(x-should-retry: false):一次排队在几千位之后,重试十几次也轮不到,只会把真实请求白白花掉。位次报出来,由你决定是重发还是换模型。Retry-After 响应头(也没有 X-RateLimit-*),但它把重置时间写在响应体里——{"code":6004,"msg":"…将在 2026-09-30 02:30:30 UTC+8 重置…"}。插件从响应体解析该时间(并按其声明的 UTC 偏移换算,不受你本机时区影响),因此卡片能直接显示「✗ 被限流 · 2026/9/30 02:30:30 之后可再用」。三处来源都没说时,插件不编造倒计时,如实显示「上游未给出何时恢复」。限流不会去借月周期包的刷新时间(那会让人为几秒的限流去等几周)。成功即无冷却:这个网关在 200 响应上也会带 Retry-After,值是账号月度积分包的刷新时刻(实测 2026-11-01 00:00 +08:00),它不是「你在此之前不能用」——所以成功的行只显示「✓ 可用」,绝不附「之后可再用」;旧版本已经写进文件的那类记录会在读取时自动治愈。探测在后台发起,凭据不会传到页面;结果不写入设置,也不改变你已保存的勾选。两点需要知道:① 它真的花钱——实测一次报 credit 0.02(被限流时直接 429,几乎不花)。因此只能按单个模型手工点,没有「测试已勾选」这类批量按钮:一次覆盖整个列表就是一次不可控支出(服务端也据此只接受单个模型,多模型请求会被拒)。② 上游虽宣称 1M 上下文,但节流线远低于此;插件按模型的原生窗口向 DSH 宣称(3.5.0 起不再默认压到 200K),所以 DSH 很晚才压缩对话——长会话撞限流是这条机制的直接结果。想让 DSH 更早压缩,就在模型行上手动设一个「DSH 上下文预算」上限(可选 200K / 500K / 模型原生窗口)。
POST /v2/images/generations,hunyuan-image-alpha 模型),产物是 24 小时有效的 COS 签名 URL,插件会提醒你及时下载。它真的花钱:实测约 5.71 积分/张,所以工具描述里直接写了单价,失败后有 30 秒冷却(但参数写错、没登录、模型不存在这三类一分钱没花,不进冷却),也不提供「一次画四张」这类不可控支出的参数。工具定义是手写的 raw JSON Schema,没有引入任何新依赖。取证、协议与联调记录见 docs/IMAGE_GEN.md。WB CN · 1,072),按本会话当前选中的模型自动切换区域:选中 WB CN 的模型就显示国内版余额,选中 WB AI 的模型就显示国际版余额;用其它 provider 的模型时该读数完全不出现。每 5 分钟自动刷新,也可点开手动刷新。点击读数弹出面板:按账号列出的余额表格,点某一行即可切换到该账号(与卡片上的账号选择是同一个设置);当前不能用的账号会在行内标出原因(如「被限流」「积分耗尽」),标注口径与账号池表格一致。面板里的余额只在打开时才去查,因此不会让 5 分钟的后台刷新按账号数翻倍。要关掉某一边,就在卡片对应区域的 tab 下取消勾选「在输入框工具栏显示积分读数」;该区域的供应商被关闭时,读数不显示、开关也置灰。同一个开关下面还有「显示位置」这一行:默认在输入框工具栏(与模型选择同一行),改成「输入框下方」后读数落到轮次/步数/token 统计那一行——装了别的插件把工具栏座位占掉时用得上。active && !claimed 才显示,claimed 整行消失,活动过期(active 翻 false)自动消失——不用本地时钟去比 `end_time`,本机时间偏了也不会与服务端打架;end_time 只用于 3 天内临期高亮。active 单独看不行:已领取的账号 active 仍为 true,只看它会让领过的账号永远挂着待领取。读取复用签到的管线(每账号一次、30 分钟缓存、账号池关闭时不发请求),任一接口失败按「未读」处理,不会把一次失败缓存成「全都没福利」。行尾是一个实心琥珀色的胶囊按钮「领取」,一次只领一个账号的一个活动:没有「全部领取」,因为一次点击花掉的是一份不可撤销的真实权益,写路由也强制要求 `accountId`,请求本身无法批量领取。领取前重新读取状态再判定,已领取或已过期一律 409 且不调用上游;领取后用上游的新读数作答并刷新卡片,不做乐观更新——即使上游静默失败也不会留下「已领取」的假象,成功后同时清掉该账号的福利缓存,按钮不会顶着旧状态赖着不走。$DSH_HOME/workbuddy-vault//.json,一账号一文件),桌面 App 的认证文件始终只读、永不被改动。账号表格每一行右侧有「测试」与「删除」:测试与批量测试走同一套探测,结果可比;删除只删插件自己存的那份,并把这个账号暂时隐藏:删掉后立刻消失,也不会被自动轮询带回来;点「重新检测账号」即可找回(重新登录或导入同一账号也会清除隐藏记录)。桌面 App 的登录始终不动——删除是「本插件不再列出它」,不是退出 App 登录。「导出 / 导入账号」可把凭据搬到另一台机器:多选导出 JSON → 选文件后先看脱敏预览(只显示字段与是否有 token,明文不进预览)→ 勾选导入。导入按账号去重覆盖,只有确认属于该区域的记录才入库,认不出的域名会被跳过并如实计入「已跳过」。详见账号池。status / doctor / logout,按区域报告登录与积分,无需浏览器即可确认宿主状态。cliBridge.enabled 后插件多出 codebuddy_ask 工具和 /codebuddy 指令,跑完把结论回注给会话模型。关闭时插件行为与之前完全一致。它绕开的是客户端指纹层,不是账号层:用的仍是本插件 vault 里的同一批账号,所以不该把它当成「封号之后的免死金牌」。详见 CLI 路线。DSH PiAiAdapter(每个 provider 一套)
-> 安全 loopback shim(每区域一个随机端口 + 进程内随机 secret)
-> WorkBuddyUpstreamClient
-> 国内版 https://copilot.tencent.com/v2/chat/completions
-> 国际版 https://www.workbuddy.ai/v2/chat/completions
-> WorkBuddy SSE
-> DSH 本地执行工具并回传结果国内版与国际版各持一套完整的运行时栈——凭据 store、模型 catalog、回环 shim、adapter——按凭据域名(workbuddy.ai / codebuddy.ai → 国际版,其余 → 国内版)隔离可见账号,所以两个区域的账号可以同时在线、同时被不同会话使用。国际版有两个品牌域名:桌面端登录在 workbuddy.ai,CodeBuddy CLI 登录在 codebuddy.ai,两者都是国际版。
模型目录按区域取自各自的正确来源,两者都是 App 自己读的那份 /v3/config,且都以 App 自己的客户端身份去读(WorkBuddy/ WorkBuddy/ CLI/,即桌面端 buildVlmGatewayHeaders 拼出的那个头)。这一步是必需的:/v3/config 按客户端通道下发不同的产品配置,CLI 通道的答复是 App 通道的严格子集,既不发布 `modelPromotions` 也不发布 `modelTiers`——用 CLI 身份读,国内版的活动徽标就会一个都画不出来。聊天与探针仍以 CLI 身份发送(会话身份三元组绑在聊天通道上),只有目录读取换成 App 身份。国内版若 /v3/config 取不到,会退回旧的 /v2/enterprises/personal/models 并记一条日志,所以只在降级时使用。积分概览走 https://www.codebuddy.cn/v2/billing/meter/get-user-resource(国际版账号自动路由到其凭据所属的国际网关,workbuddy.ai 或 codebuddy.ai——两个品牌域名的凭据互不通用),均为只读接口。
凭据读取自 WorkBuddy 桌面 App 自身的 auth 文件(只读);刷新得到的 token 按区域存放在 $DSH_HOME/.workbuddy-auth.cn.json 与 $DSH_HOME/.workbuddy-auth.global.json(双账号同时在线互不覆盖;旧的单文件 .workbuddy-auth.json 作为迁移来源保留读取),桌面端文件永不被写入。
加密凭据字段:新版桌面端(Windows 先行)把 auth 文件里的 accessToken / refreshToken 从纯字符串改为 {"$wbEncrypted":1,"envelope":"…"} 的 AES-256-GCM 信封,账号昵称 `nickname` 同样被加密(不解密就会退回成一串 uin 数字)。信封用的是 App 自身构建期内置的字段密钥,并非用户密钥,因此插件不内置任何密钥副本,而是在需要时用 ELECTRON_RUN_AS_NODE 调用已安装 App 的原生绑定(electron_browser_workbuddy_storage.loggerGet())取回同一份载荷并就地派生密钥——也就是「向写下这个文件的那个构建本身询问」。密钥只在本进程内存中缓存,不落盘、不进日志;纯字符串文件(macOS 与旧版 Windows)走原路径,一次子进程都不会启动。其中的 account.phoneNumber 虽同样加密,插件不读取也不显示。若 App 安装在非常规位置,用 WORKBUDDY_APP_EXECUTABLE 指定其可执行文件。
一台机器上往往登录过多个 WorkBuddy 账号。账号池把这件事收成一次点击:把要用的账号勾进池子,然后「签到勾选的账号」或「测试勾选的账号」;再打开启用账号池,插件就会在请求失败时自动换号接着跑。
每个区域(国内版 / 国际版)各有独立的一池:成员与目标模型互不影响——两边的账号本来就属于不同的上游栈。签到只有国内版有:海外区域不显示签到按钮,也没有那一列。
warn,写明因何失败、换到了下一个账号。它只控制「插件要不要自己决定」,不控制「你能不能操作」。
· 账号池 开启 · 账号池 关闭 谁服务 · 由排序自动选出(可用优先 → 快过期先花 → 积分高 → 凭据新) · 你在账号池里手动选「使用哪个账号」 请求失败 · 自动换下一个可用账号重试 · 不换号,如实报错 一键签到 / 一键测试 · 可用 · 仍然可用 目标测试模型 · 可改 · 仍然可改
最后两行是刻意的:签到与测试是手动动作,它们作用于你勾选的成员,与「插件是否自动路由」是两件事。之前把按钮也挂在开关上,导致关掉账号池就再也没法签到或测试——而「关闭」本该是「我手动来」,不是「什么都不许做」。
手动选择账号在哪里:账号池区块里。关闭账号池时,该区块会显示一行「使用哪个账号」的下拉,选定即生效(写回本区域的账号槽,与凭据失效时的「切换到可用账号」走同一条已验证的写入路径);开启账号池时这一行不显示——那时由排序决定,一个改了不生效的下拉比没有更糟。账号的发现(「重新检测账号」)、勾选、签到与测试全部集中在这个区块里,所以账号管理只有一处。
唯一的硬约束:池里一个成员都没勾选时,批量动作一律拒绝。空的池绝不退化成「那就对全部账号执行」——那是唯一会花掉你没授权过的积分的解读。
第 2 条为什么排到第 3 条前面(issue #70):这两条此前是严格字典序——先比积分总量,只有总量完全相等才比到期时间。而总量几乎从不恰好相等,于是「快过期优先」实际上从未生效过:一条「不花就作废」的规则被另一条完全遮蔽,等于死代码。真实病例里,某账号有 196.4 分当天作废,只因为比另两个账号少约 1,200 分就永远排在最后,那 196 分必然烂掉。
代价也要说清:这条规则会让临期 1 分的账号排到余额 5 万的账号前面。这不是缺陷——积分是通用的,不花那 1 分它确定会损失;而余额 5 万的账号下一轮还在。唯一的真实代价是临期账号可能不够跑完一个请求,这时由既有的换号逻辑接手。
probeModel,因而同样继承两个实测结论:限流按请求体积触发、恢复时间写在响应体里而不是响应头),得出该账号此刻能否用这个模型。测试目标是哪个模型:默认是该区域目录里倍率为 0 的免费模型(实测国内版当前只有 hy3 一个;不写死名字,因为上游会改倍率——deepseek-v4.1-flash 就已从 0 变成 0.11),也可以在下拉里指定一个具体模型。指定的模型若已离开目录,手动动作会明确拒绝(target-model-stale),而不是偷偷换一个——你点的是「测这个模型」,换掉就是答非所问。
成本与边界:测试是真实请求,指向免费模型时(倍率 0)几乎不花钱,但它不是零成本的空转;签到则会真实领取当日奖励。两个动作都只在你点按钮时执行——插件不提供自动签到,卡片上也不放一个永远点不动的开关。
「本机有登录」不等于「要拿它去签到和花积分」。成员默认空,必须逐个勾选(或点「全选」);空池不会退化成「全部账号」——没勾选时两个批量动作直接拒绝,而不是替你把所有账号跑一遍。
勾选是一次草稿编辑:点「保存」才落盘,未保存时保存按钮带 dirty 指示;切走或关掉卡片,草稿仍在。
账号一律在账号池里管:成员勾选就是现在的账号选择面,「重新检测账号」也在那一块。原先那个「账号选择」下拉在有账号池之后是自相矛盾的——池开启时由排序决定谁服务,它改什么都不生效,却看起来像权威;顶部状态行还可能显示成 A、下拉显示成 B。
所以区域状态行也跟着改:池开启时不再报出某一个账号名(多个账号同时登录是常态,用单数说「已登录:A」本身就是错的),只陈述本区域可用、由池决定用谁;池关闭时才报出那个账号——那时它确实是唯一答案。状态行旁边的圆点与 token 过期时间讲的是「这个区域能不能用」,和「谁在计费」是两件事,后者由账号池区块负责显示。
探测结果 · 对轮换的意义 可用 · 可入选 被限流 · 暂时出池,按上游给出的重置时间自动回池(上游没说时间就按 30 分钟兜底,不编造倒计时) 积分耗尽 · 出池,按月周期包的刷新时间回池 连不上上游 / 失败 · 暂时出池,30 分钟后自动回池——这类结果说的往往不是账号,而是一次网络抖动或上游 5xx 凭据被拒 / 模型不存在 · 出池,只能靠手动「测试」回池:一个需要重新登录,一个是本区域不再提供该模型,等待都修不好
关键一条:「被限流」「连不上上游」都不等于不可用。它们恰恰是最值得等的那两类状态——当成永久失效剔除,正好丢掉池子里本来最能用的账号,而且当池内每个成员都被这样剔除时,池子就没有任何候选,自动换号会无处可去,你只会看到上游原始报错。
为什么只有限流/欠费/瞬时故障会自己回池:这三类要么由上游写明了恢复时间,要么由插件按 30 分钟兜底;而「凭据被拒」「模型不存在」等待都无意义,只能由你手动重测或重新登录来刷新。插件不再有自动复测定时器(见下),所以后两类的唯一出路就是手动动作。
模型管理一个、账号池一个,这是刻意保留而非漏合并:两者的草稿域不同,合并后一次写入失败会连累另一边(模型目录写不进去,就连池偏好也存不了);一个共享的「放弃」还会在一次误点里同时丢掉两份草稿。两边都是验证写入——写不成功不丢弃草稿,否则用户的编辑就永久丢了。
池里还有一类状态不走草稿:探测结果、冷却时间、当前轮换到的账号。它们是观测事实,由插件自己高频写入。原因很实际——草稿是覆盖式的,若观测结果也进草稿,你手工点一次「保存」就可能把插件刚写进去的结果回退成几分钟前的旧值。
⚠️ 版本要求:DSH 0.1.7-rc.1 及以上(当前窗口:`0.1.7-rc.1` ~ `0.2.x` 正式版)。 自 v2.1.0 起本插件只支持 DSH 0.1.7-rc.1 及以上的宿主(旧版宿主无法通过依赖解析安装本版);0.1.5 及更早的宿主请停留在 v2.0.15。自 v2.1.2 起上界放宽为 `<0.3.0-0`,0.3.0 线被明确拒绝。详见下方受支持的宿主范围。
DSH 的随包门禁(packages/boot/app-boot/src/plugin-compatibility.ts 的 evaluatePluginCompatibility)会逐条核对本插件声明的 dsh-* peer 范围;只要有一条不满足,整个组合包会被跳过(进入 skippedBundles,仅打印到 stderr)——provider 不注册、卡片不出现、模型列表清空,而页面上没有任何报错。
宿主版本 · 判定 0.1.7-rc.1 ~ 0.1.7-rc.2 · ✅ 支持 0.2.x 正式版(0.2.0、0.2.1 …) · ✅ 支持(2.1.2 起实测) 0.2.x 预发布(0.2.0-rc.1、0.2.1-rc.1 …) · ⚠️ 不落在声明范围内,见下方说明 0.3.0-0 及以上 · ❌ 明确拒绝(该线尚未验证) 0.1.6 及更早 · ❌ 明确拒绝(0.1.5 线请停留在 v2.0.15)
关于 `0.2.x` 预发布(v4.7.0 更正):此前本表把 0.2.0-rc.1 写作「✅ 支持」,那是错的。npm semver 规定:预发布版本只有当一个比较器在同一条 `major.minor.patch` 元组上带预发布标签时才被放行。
现声明>=0.1.7-rc.1 <0.3.0-0只对0.1.7-x开口,<0.3.0-0又排除了0.3.0元组,因此
`0.2.1-rc.1` 这类版本两条比较器都不满足(satisfies('0.2.1-rc.1', …) === false)。实际影响很小:宿主门禁只校验@deepseek-ai/dsh*命名空间,且 rc 宿主上本插件按link:/ 手工安装照常加载。
这不是靠改范围能解决的问题——任何静态范围都覆盖不了「任意 0.2.x 预发布」,已逐一实算否证五种写法(见 CHANGELOG 4.7.0)。等宿主发 0.2.1 正式版即自然成立。上界写作<0.3.0-0而非<0.3.0:DSH 至今全部 tag 都是预发布(-alpha.N/-rc.N),只写<0.3.0会放行整条0.3.0-alpha.1/0.3.0-rc.1这条从未验证过的线,围栏形同虚设——这正是 2.1.2 修掉的缺陷形状。该口径由tests/dsh-line.spec.ts守卫(含预发布悬崖的用例)。
🪟 平台支持:Windows、macOS、Linux 三者并列支持。 Windows 是一等目标平台,不是「顺带能跑」:CI 在 windows-latest 上跑完整套件,凭据路径、进程心跳、App 可执行文件定位、设置写入四处都有 Windows 专属分支与测试,并且修复只对 Windows 生效的缺陷时,以 Windows 用户回报的现场与真机取证的加密向量为准(见 CHANGELOG 的 2.0.6 / 2.0.11 / 2.0.12 各节)。见下方平台支持一节了解各平台的具体差异与已知限制。前置:已安装并登录 WorkBuddy 桌面 App(插件复用 App 的登录状态)。
推荐使用 DSH 插件命令安装 npm 已发布版本:
dsh plugin --profile desktop add dsh-connect-workbuddy或直接通过 npm 安装:
npm install dsh-connect-workbuddy安装、更新或卸载 bundle 后,需要重启对应的 DSH 进程。
⚠️ 刚发布的版本请写「精确版本号」,不要依赖浮动范围。 pnpm 有新版本等待期(minimumReleaseAge,默认 24 小时),所以一个版本刚发布不久时,浮动范围会被静默压回上一个版本:声明^4.4.2时它仍解析到4.4.2,而写精确的4.4.3则立即拿到4.4.3。由于两种写法都「安装成功」,表现是「升级命令跑完了、版本却没变」,很容易被误判成发布失败。已实测(隔离目录、pnpm 12.3.4、--lockfile-only,未触碰用户环境):
| 目标写法 | 解析到的版本 |
| --- | --- |
| 浮动 ^4.4.2 | 4.4.2 ⚠️ || 精确 4.4.3 | 4.4.3 || 浮动 + --config.minimum-release-age=0 | 4.4.3 |想立刻用上新版,请写精确版本号:dsh plugin --profile desktop add dsh-connect-workbuddy@4.4.4。过了等待期之后,浮动范围会自然跟上。插件在 Web、Desktop、TUI 三种界面下均可运行,按你使用的 profile 选择对应命令:
dsh plugin --profile web add dsh-connect-workbuddy # Web
dsh plugin --profile dsh-tui add dsh-connect-workbuddy # TUI三个平台都是受支持目标;下列差异是实现事实,不是「尚未支持」的委婉说法。要改这一节,请同时改 docs/WINDOWS.md——那份文件是平台相关约束的登记处。