DSH | Reply Suggestions | 推荐下一句追问，回车填入草稿

[jabingu]

非官方社区项目，由我独立开发和维护。

项目：jabingu/dsh-reply-suggestions · 当前仓库版本：0.1.16 · MIT

我做了一个 DSH 输入框推荐插件 Reply Suggestions：助手回答结束后，根据上一轮问题和回答推荐下一句追问，在空输入框中显示灰色文字。按一次回车把它填入草稿，编辑后再自行发送。

可以做什么

• 推荐下一句追问：跟随当前对话的模型，使用 DSH 已配置的凭据，不需要另填 API Key。
• 回车填入、Escape 隐藏：第一次 Enter 只接受推荐；之后按 DSH 原有规则发送。可修改或忽略推荐，保留 Shift+Enter 等组合键的原有行为。
• 避开正在输入的内容：有草稿、附件、引用或待处理队列时延后生成；任务运行时不显示推荐，切换会话时清理旧请求。
• 查看推荐的 Token 用量：插件详情页保留两张统计卡片，左侧可切换今天、昨天、近 7 天、近 30 天，右侧显示历史总量；自动采用 K/M 单位，重启后保留记录。
• 费用估算和价格更新：对官方 DeepSeek Flash/Pro 按公开人民币 API 价格估算费用范围；支持手动更新价格，以及每天、每 3 天、每周、每 30 天或仅手动更新。

演示

这张图由真实 0.1.16 插件客户端的测试夹具输出生成，并置于模拟对话页面，非 DSH 桌面实录。对话和推荐为演示数据，没有调用模型。

安装

1. 打开 DSH 的「插件」页面，先检查是否已安装 dsh-reply-suggestions；已安装时使用更新入口，避免重复添加。

2. 在「添加插件」的包名或地址栏填写：

   https://github.com/jabingu/dsh-reply-suggestions
   

3. 加载并启用后，完全退出并重启 DSH。

4. 完成一次普通对话，保持输入框为空，等待灰色推荐出现；按一次 Enter 填入，修改后再发送。

仓库包含构建好的 Host 和客户端文件，无需自行构建。目前按官方桌面版 DSH 0.2.0-rc.2 适配，peer 版本锁定为 rc.2；其他版本需要另行核对接口。

模型消耗与统计范围

每次新生成推荐会额外调用模型，即使没有采用推荐，也会产生该次用量。 插件只取上一轮正文，用户问题最多 400 字符、助手回答最多 1,200 字符，不传整段历史或推理块；推荐输出上限为 96 Token。对 DeepSeek 的推荐请求关闭深度思考，不改变主对话设置。

已完成推荐会缓存，相同的并发请求共用一次生成。统计读取、切换时间范围和更新价格不会调用模型。

统计只记录本插件生成推荐的用量，不包含主对话或其他插件，使用模型流返回的实际 usage。开始记录前没有保存的历史无法补回；未返回用量的请求会标为未知。用量文件不保存对话正文、附件或凭据。

费用是公开 API 价格估算，不代表账号套餐、赠送额度或实际账单；其他提供方或未知模型不套用 Flash/Pro 价格。

与 DSH 的集成和验证

插件通过 DSH 的客户端入口加载，使用 conversation.input.overlay 显示推荐，通过原生草稿动作填入文字；Host 使用 Typert/Gateway RPC 和 llm.stream 生成推荐，统计挂载在插件详情页。

0.1.16 的 Node 22/24 CI 在 Windows 和 Linux 四组任务中均通过全部 66 项测试，构建、产物一致性、客户端语法和打包检查也通过。本机还用官方 rc.2 的 Cordis、Typert、Gateway 和 SlotCore 验证了 RPC、用量计数及重启恢复，模型使用测试替身。

早期版本的推荐交互曾在真实 rc.2 桌面端验证；本版没有重新完成全部桌面视觉及真人输入法验收，实际效果仍需按使用环境核对。

欢迎试用，也欢迎在仓库提 issue，反馈 DSH 版本、复现步骤和截图。

[xiaoshenming]

Another same-kind plugin here (dsh-next-hint: turn-end → ghost → Tab, stateless host POST). Your Enter-to-fill and usage/cost cards are the two things I'm taking notes on.

Two questions:

1. How do you arbitrate the first Enter against the native submit/queue path? We use Tab partly to avoid that; your acceptedUntilKeyUp capture-phase guard looks right, but does it also hold when the composer is in a queued/steering state or when an IME composition just committed?
2. For usage: which stream field do you read? We call ctx.llm.prepareCall + BlockAssembler; I don't see usage on the assembled finish. Do you read a terminal chunk / finish.usage, or the adapter's stream events?

We just closed our owner-admission hole (connection.admit) and a stale-ghost-on-refused-insertion bug, both from Stijnus's 1.2.2 notes. Your cost transparency is in our backlog.