DSH 桌面端多项基础能力缺失，且被推给第三方插件实现——请作为标配纳入官方排期

[raphael-y7]

以下不是新功能建议，而是桌面客户端的及格线。这些问题中的大多数，目前在 DSH 里要么完全不存在，要么只能靠用户自行安装第三方插件补齐。把基础能力外包给社区插件，等于把产品质量责任和用户数据安全一并转嫁给用户。这不是一个正式桌面产品应有的策略，请认真对待。

一、通知提示音：缺失

现象：桌面端没有通知提示音。经核查核心代码，不存在通知音相关实现（无 playSound / notificationSound / notification-sound / soundEnabled 等标识；唯一的 AudioContext 出现在语音输入相关模块，唯一的系统通知用于「强制更新」提示，且显式设置了 silent: true）。

影响：模型等待审批、任务完成、发生错误时，用户切到其他窗口就完全无从知晓。这恰恰抵消了「后台运行」这一核心价值——用户被迫一直盯着屏幕，否则就可能在关键节点上长时间空等。

需求：任务完成、需要审批、发生错误三类事件可分别开关提示音，可在设置中配置。

定性：通知不是锦上添花。一个在后台跑任务、需要人来审批和纠错的客户端，不在关键时刻发出声音，就不具备作为生产力工具的基本条件。

二、对话 ID：官方要求提交，产品却不提供查看入口

官方反馈表单明确写着「建议使用 /feedback 命令获取日志，并提交 session ID」。但桌面端界面没有任何入口可以查看或复制 session ID。

这不是疏忽，是流程上的自相矛盾：官方支持流程所依赖的信息，产品本身不提供。用户为了报一个 bug，必须先学会翻本地目录、识别压缩格式、解压会话日志，才能拿到这个 ID。要求普通用户做到这一步，是不合理的。

需求：会话信息处直接显示完整 ID，并支持一键复制。

三、技能与 MCP 管理：设置页没有对应面板

设置页现有面板为：通用、账号、模型、插件、插件清单、会话日志、Shell、子代理、Web 搜索、Agent Loop。其中没有技能管理，也没有 MCP 服务器管理。

而技能与 MCP 恰恰是 DSH 的两大核心扩展机制。官方在文档和宣传中反复强调可扩展性与生态，产品界面却不提供最基本的管理入口，用户只能手工编辑配置文件，且无法在界面中查看当前生效的技能、来源与启用状态，也无法诊断 MCP 连接失败的原因。

需求：设置页提供技能列表（查看、启用/禁用、来源与内容查看）与 MCP 服务器管理（增删改、连接状态、错误诊断）。

定性：一个把可扩展性当作卖点的产品，必须为扩展机制提供一等公民的管理界面。只宣传生态、不给管理入口，是把复杂度推给用户。

四、归档会话无法删除：只进不出的数据黑洞

归档功能存在，但归档之后没有删除入口。

影响：归档会话持续占用磁盘，用户无法清理。用户以为「归档」是整理，实际结果是永久堆积。随着使用时间增长，这个目录只增不减。

需求：归档会话支持彻底删除，并提供明确的二次确认。

定性：任何提供归档的产品都必须同时提供删除。只归档不删除，是把存储成本和后续处理负担转嫁给用户。

五、第三方供应商：智谱端点不完整、命名不可识别

已核查：DSH 内置了两个智谱供应商，zai（api.z.ai）与 zai-coding-cn（open.bigmodel.cn）。但两者都只指向编程端点 /api/coding/paas/v4，智谱开放平台的标准端点 https://open.bigmodel.cn/api/paas/v4 并未内置。结果是：持有普通 GLM API Key 的用户无法使用智谱。

另外，国内站在界面中的显示名为「Z.AI Coding CN」，用户无法从名称判断这是智谱国内站，实际使用中极易被误认为不存在。

需求：补齐智谱标准端点；将国内站改为可识别的名称。

六、核心诉求：以上必须是官方标配，不能靠第三方插件补

这六项里，多数属于桌面客户端的基础能力。目前的现实是：基础能力缺口被社区插件填上了，官方则维持缺失。这不能作为长期方案，理由如下。

1. 安全边界问题。第三方插件运行在会话上下文内，能够读取对话内容。要求用户为了获得基础功能而引入第三方代码，等于让用户用数据安全去换取可用性。基础能力尤其不应走这条路。

2. 发现成本问题。新用户不知道插件存在，只能长期忍受功能缺失，甚至误以为产品本就如此。基础能力不应依赖用户自己去发现和安装。

3. 可持续性问题。第三方插件多为个人维护，可能随时停更；宿主版本升级后也可能失效。把基础功能建立在这类依赖之上，是不可接受的。本机已安装的提示音能力即来自第三方插件 dsh-notify-me（作者为个人开发者），而非官方组件——这正好说明缺口是由社区补的。

4. 一致性问题。官方界面有统一的语言、主题与交互规范，第三方插件难以保持一致，且每次宿主升级都需要重新适配。基础能力的体验不应由外部插件的适配节奏决定。

5. 责任问题。官方支持流程要求用户提供 session ID，产品就必须提供查看入口。让用户安装第三方插件来满足官方自己的流程要求，在逻辑上说不通。

七、结论与明确请求

以上六项，多项属于桌面客户端的基础能力，不应以「社区可以自己解决」为由长期搁置。请官方：

1. 将上述能力纳入官方排期，作为桌面端标配实现；
2. 对「基础能力依赖第三方插件」这一现状给出明确态度：如认为某项确应由插件承担，请说明理由与长期支持方案；
3. 至少在官方界面中提供官方支持流程所必需的信息（session ID）。

---

环境：DeepSeek Harness 0.2.0-rc.2（desktop profile），Windows 11。

核实说明：以上除「技能与 MCP 管理面板」「归档会话删除入口」两项为代码层核查（未逐项点击界面确认）外，其余均已在代码层核实。

[raphael-y7]

补一项缺失：批注（对回答局部进行回复或提问）。它应与上面五项并列，作为桌面端的基础能力。

批注：无法对回答的局部进行回复或提问

现象：助手回答只能整条处理，没有针对局部文本的操作入口。选中回答中的任意一段文字后，既不能对其发起回复或追问，也不能把该片段连同问题一起发给模型。会话界面中助手消息的动作行只提供整条消息级动作（复制、分支、反馈），粒度停在「整条回答」这一层。

经核查核心代码，会话与输入框相关包中不存在「取当前选区 → 注入下一条消息」的实现（检索 annotateSelected / selectedAnnotation / quotedText / quoteBanner 等标识均无命中）。即：选区在界面上只是浏览时的选中状态，无法成为可引用的语义单位。

影响：用户对一段长回答中的某一句、某个结论、某段代码有疑问时，只能把那段话手工复述一遍，再补一句「我说的是上面第几段」。回答越长，定位成本越高、歧义越大；用户被迫用「重新描述」代替「指一下」。

这与对话式产品的实际使用方式直接冲突：长回答、多步骤推理、代码与文档片段，本来就需要点对点的追问。缺少批注能力，等于把定位与复述的成本全部转嫁给用户，也让模型的回答质量难以被精确反馈——用户无法说清「你到底哪里错了」，只能整体重问一遍。

需求：

1. 选中助手回答中的任意片段即可发起批注：可只标记（标出「就是这里」），也可附一段说明；
2. 批注连同输入框中的问题一并发送，且不在用户消息气泡中重复展示大段原文（以芯片/角标形式呈现，悬停可见）；
3. 模型能按条对应回复（如 Annotation 1: … … Annotation N: …），并在回答中保留批注与原文的对应关系；
4. 批注可跨消息、跨轮次累积，并可逐条移除。

定性：批注不是高级功能，而是最基本的沟通方式。它解决的是「用户想指的东西就在屏幕上，却指不了」这一问题。讨论区、代码评审、文档协作早已把「对局部直接评论」视为标配；一个以长文本和代码为主要产出物的对话客户端，没有理由缺失它。

补充说明（实测）：该缺口在社区已有第三方实现——omdsh-dev/dsh-annotation（选中回答文字→批注→随消息发送，模型按 Annotation N 逐条对照回复，声明「零核心改动」，★138），以及 skyhancloud/dsh-client-ui-quote（选中→引用横幅）。这既证明该能力真实可行且已有现成实现，也再次印证上面第六节的问题：一项基础交互能力，又一次由社区插件补齐。

---

核实说明：本节两项结论均为实测——核心代码检索无「选区注入」实现（DSH 0.2.0-rc.2）；社区已有对应第三方插件（2026-10-11 查询）。