dsh-next-hint — 回合结束后，输入框里自己浮出一句「接下来可以问什么」（Tab 采纳，不自动发送）

[xiaoshenming]

TL;DR — 一轮对话结束、输入框是空的时候，第一行自己浮出一句「接下来可以问什么」的灰字；按 Tab 采纳进草稿，绝不会自动发送。Claude Code 那种 prompt suggestions 的 DSH 版。

┌──────────────────────────────────────────────────┐
│ 顺便把失败的那两个用例也修了          Tab 采纳   │  ← 回合结束时浮出
└──────────────────────────────────────────────────┘

仓库：https://github.com/xiaoshenming/dsh-next-hint （MIT · 非官方 · 独立开发）

它凭什么值得装

• 懂上下文：建议由一笔独立的辅助请求生成，读的是这个会话最近几轮的真实内容（改了哪个文件、哪个测试红了、停在哪一步），不是「继续？」这种模板。
• 不碰你的回车：采纳 = 往草稿里插一段普通文本，Ctrl+Z 可以撤回；代码里根本没有「发送」这条路径。
• 很安静：没配路由 / 模型超时 / 被限流 / 输出不合规 —— 一律没有灰字，也不弹任何错误，日志里最多一条 warn。
• 不传你的对话：浏览器只发一个 sessionId，会话内容由宿主在本机进程内读一次，不落盘、不进日志、不出进程。

安装

桌面端：设置 → 插件 → 添加 git 包 github:xiaoshenming/dsh-next-hint#main，重启一次应用（插件在启动时进花名册）。CLI 等价写法见 README。

兼容

• 实测环境：DSH Desktop 0.2.1-rc.2 / Windows。
• 宿主半边用 ctx.llm + ctx.sessions + ctx.webServer.register；浏览器半边挂在官方槽位 conversation.composer.dock 上，灰字节点自己画（官方没有开放行内 hint 的写入口）。
• 版本 0.x：上游一改这些缝，灰字可能先坏；找不到编辑器锚点时它会安静地不出。

几个实现取舍（给写插件的同学）

• 判定在浏览器，生成在宿主：草稿空不空、人是不是正在打字、看的是哪个会话，只有浏览器知道；让宿主猜只会猜错两遍。
• 一次请求-响应：没有 SSE、没有长连接、没有服务端缓存；取消就是 AbortController.abort()。
• 辅助请求照抄会话标题插件：独立 system instruction、独立超时、最低推理档，失败不碰主对话。
• 设计记录与逐行出处都在 docs/ 里（ADR-0004 双半包新时序、ADR-0005 渲染接缝），行号可复查。

In English: dsh-next-hint paints a ghost suggestion on the composer's first line when a turn settles. Tab accepts it into the draft; nothing is ever sent. It reads the session's own last few turns on the host, spends one decoupled auxiliary request, and fails silently. Measured on DSH Desktop 0.2.1-rc.2 (Windows), MIT.

同类：写完之后才发现的

发布前扫了一遍社区，才发现三天前已经有一个几乎同款的 Composer predictions（dsh-composer-prediction）。两边都是「回合结束 → 一笔辅助请求 → 灰字 → Tab 采纳」，都复用 ctx.llm、都把推理档压到模型最低档 —— 看来这是这类功能的自然解。

差异在接缝上：它挂 conversation.input.overlay、自带设置页与配置持久化 RPC、按会话缓存建议；我走官方槽位 conversation.composer.dock、宿主无状态（一次 POST 一来一回）、配置直接用宿主的 schemastery 设置页。取舍不同，各有各的脆点。

两个别同时装：都会往输入框里画灰字，也都会每轮各花一笔模型调用。

[xiaoshenming]

0.1.1 已发布 —— 修的就是「灰字有时有、有时没有」。

根因不在客户端竞态：系统指令最后一行自己留了逃逸口
If nothing sensible follows, reply with the single word: NONE。
短对话 / 寒暄 / 纯问答时模型频繁照做，cleanHint 按约定丢掉 NONE → 204 empty → 没有灰字。

实测（DSH 0.2.1-rc.2，隔离 web profile + 真实会话，4 轮）：2 轮 204 empty；
把 204 的 reason 里的原始输出解出来就是 NONE。同一组提示词修后 4/4 出灰字。

改了什么：

• 指令删掉 NONE，改成「即使回合很短也要给一条具体的下一句」；
• 收到空/拒答时用更严格的指令再问一次（只在这一种失败上多花一笔调用）；
• max-tokens 截断但首行可用时照常采纳；
• 浏览器中途离开时中止辅助请求并立刻释放单会话单飞闸门，下一轮不再被 gated 误拒。

版本 0.1.1（4e8d6d4，CI 绿）。更新：设置 → 插件 → 本插件 → 更新；
如果新版本没生效，重启一次应用。

顺带说一句：桌面 profile 由应用独占，dsh plugin --profile desktop ... 会被 CLI 拒绝 ——
README 里的 CLI 例子已经改成 --profile web（6c42a6d）。

另外重申：别和 dsh-composer-prediction 同装，会画出两条 ghost + 每轮两笔调用。

[xiaoshenming]

0.1.2：IME 组合期不再画灰字。

• 触发闸门与「已画灰字是否仍有效」的检查都会读编辑器根上的 data-composer-composing：组合期不请求、不画。
  我们这边 composer store 会晚一拍，这正是之前「闪一下又消失」的来源。
• 来源：dsh-composer-prediction 作者在 Composer predictions — ghost-text next-message suggestions for the DSH composer #10053 的回复 —— 他的可见性只看 composer store（组合文本已反映在 store 里），
  建议在 data-composer-composing 置位期间直接抑制。
• 顺带修正同类对比：两边都是浏览器侧判定 + 宿主无状态路由，真正的差异在挂载点、设置页、会话缓存与 Esc。
• 版本 0.1.2（866ac58，CI 绿）。更新：设置 → 插件 → 本插件 → 更新；没生效就重启一次。

[xiaoshenming]

0.1.3：与 dsh-composer-prediction 的共存规则落地。

• dsh-composer-prediction@0.7.7 检测到本插件会整段暂停自己（它把 dsh-next-hint 写进已知 ghost 包，并读我们的 data-next-hint* 标记）。
• 0.1.3 起我们的灰字节点带共享属性 data-composer-ghost，只在真的画出来时才有；第三方可以按「此刻是否有 ghost」动态让位。
• 我们不反向让位：双向让位会让两个都装的人什么都看不到；规则是单向的 —— 我们在，它暂停。
  data-next-hint-anchor 是常驻节点，不能当「正在显示」的信号。
• 版本 0.1.3（236a6dc，CI 绿）。更新：设置 → 插件 → 本插件 → 更新；没生效就重启一次。

[xiaoshenming]

0.1.5：安全性补丁 + 同类全景。

• /api/next-hint 现在要求 DSH owner admission（ctx.connection.admit + peer.principal.kind === "owner"）；之前只有 loopback/同源，本机任意进程带 sessionId 就能花 token。来源是同类 dsh-composer-predictions 1.2.2 的安全修复。
• 采纳失败（draftRev 变了 / 正在提交）时立即清掉灰字，不再留一条点不动的 stale 建议。
• 同类现在四家：我们、dsh-composer-prediction（Amir）、dsh-composer-predictions（Stijnus）、dsh-reply-suggestions（jabingu）；另加互补的 dsh-input-assist。对比和 backlog 已写进 docs/RESEARCH.md 3.3 / docs/TASKS.md 3.5。
• 下一步优先：Esc、切会话恢复、设置页、npm 发布、多候选、用量统计；rc.3 只做了源码缝扫描，真机还没跑。
• 版本 0.1.5（928bea5，CI 绿）。GitHub 源更新：cd ~/.dsh/profiles/desktop && pnpm update dsh-next-hint，再重启。