随手抽屉 · Stash

中文 | English

使用 AI 时随手把「稍后再查 / 再问」的片段收起来放到「抽屉」，需要时直接从「抽屉」里拿出来就地追问 —— 全程低打扰、不打断心流。

工作包名 dsh-stash。

设计原则（最重要）

低打扰、不打断心流。

• 随手收：选中即存，无弹窗、不跳页、不打断当前对话。
• 就地问：追问在当前页面小窗口内完成，不开新页。
• 你只管专注眼前，念头先交给抽屉，稍后再抽出来处理。

这个名字「随手抽屉」就是这套心法的写照——「随手」= 低打扰、顺手；「抽屉」= 收纳，稍后抽出一条/几条就地追问，存与问两个动作都被覆盖。

两个核心使用场景

场景一 · 随手收藏（专注当下）

在当前的聊天页面下，可以通过选取一段文字或词组，添加到一个地方（抽屉）存储起来，专注于当前对话内容。后续再去做额外的对话或问答。

• 触发：查阅信息、调用文件、读回复时，遇到不认识的关键词、有灵感的内容、或任何想稍后再查的片段。
• 动作：选中一段文字或词组 → 收进「抽屉」。
• 效果：低打扰、不打断心流，专注眼前；念头先放一边，之后再统一处理。

场景二 · 随手抽屉（就地追问）

在当前的聊天页面下，可以通过选取一段文字或词组，或者从抽屉中，或者选取一个或多个内容，叠加在当前页面小窗口进行临时追问，追问时可以选择，是否加入上下文。

• 追问来源（可单选 / 多选）：
  1. 当前聊天页面选中的一段文字或词组；
  2. 抽屉中的一条内容；
  3. 抽屉中的一条或多条内容。
• 呈现：叠加在当前页面上的小窗口内就地追问，不开新页、不打断心流。
• 关键选项：追问时可选择「是否加入上下文」——加入则带当前对话背景，不加入则只围绕选中内容独立问答。

这是什么

• 一句话：把「此刻不想做 / 需要搜索但想稍后再做」的临时念头收起来，专注当前对话；需要时在页面浮窗里「抽一题」就地追问。
• 解决的问题：用 AI 时经常遇到某个关键词、某段内容触发新灵感，或不理解需要搜索，但此刻不想分心，也不想重新开新页面。
• 形态：DSH 插件（hybrid：宿主 remote + 存储 + LLM；客户端浮窗 UI + 文本选区捕获）。

目录地图（SDD 分区）

快速导航

• docs/vision/idea.md — 原始想法（完整，未压缩）
• docs/spec/feasibility.md — 可行性评估（结论：完全可行）
• docs/spec/api-contract.md — 宿主 remote API + 客户端槽位契约
• docs/plan/roadmap.md — 里程碑
• docs/issues/open-questions.md — 待决项（2026-08-20 已全部拍板）

当前状态

• [x] 阶段：M1 核心追问链路已接通（2026-08-20）
  • hybrid 插件：宿主 StashService（stash remote 命名空间 + storage-domain 持久化 + ctx.llm.stream 一次性追问）+ 客户端 shell.overlay 浮窗（开合/选区捕获/收藏删除/追问）。
  • 构建链路：scripts/build.sh（host → lib/host/）+ npm run build:client（tsdown → lib/client.js）实测零报错。
  • 注入链路：super-injector HTTP API 实测注入 → 自检（host ✓ / client ✓ / boot manifest 收录）→ 卸载 → 重注成功；卸载无功能残留（junction 删除有 injector 侧 macOS bug，见 scripts/README.md）。
• [x] 迭代：选区归属 + UI 重做 + 交互完善（2026-08-22）
  • 选区归属判定（selectionScope.ts）：哨兵探针 + 最近公共祖先锁定「对话内容容器」，界外文本不再弹菜单——落实「低打扰」原则（契约 api-contract.md §2.3）。
  • 浮窗 UI 重做：暖石墨×鼠尾草设计令牌（克制、低对比、不突兀），高保真原型见 stash-ui-redesign.html。
  • 交互：标签区滚动、面板折叠三路径（收起 / 点空白 / Escape）、追问时合并选中标签与输入框内容。
• [x] 待决项已全部拍板（2026-08-20，见 open-questions.md）
• [ ] 下一步：真机复测——选区归属精度（探针挂载）、标签区滚动、折叠三路径、追问合并，以及 LLM 真实追问与上下文开关、AC-1~AC-5 回归。

SDD 工作流

1. 愿景（docs/vision/）→ 2. 需求（docs/requirements/）→ 3. 规范（docs/spec/，先定契约再写代码）→ 4. 规划（docs/plan/）→ 5. 实现（src/）→ 6. 验证（tests/）。

原则：spec 即契约 —— 任何实现先回到 docs/spec/ 更新契约再动代码；想法变更从 docs/vision/ 层层下放。