桌面版会话窗口缺少 Ctrl+F 关键字搜索（附根因定位与可用原型实测）

[furoute]

功能建议：桌面版 DSH 会话窗口内缺少 Ctrl+F 关键字搜索

提交渠道：GitHub Discussions → Ideas
仓库：https://github.com/deepseek-ai/deepseek-harness
日期：2026-10-02（2026-10-03 更新：补充实测数据与可用原型）

一句话：底层全文检索引擎已就位，但桌面版既没开启它、也没有 Ctrl+F 入口，
导致用户在"在对话里找一句话"这个最基础的场景上无路可走。
附带的原型插件已在本机实测可跑通，可直接参考实现思路。

---

一、问题描述

在桌面版 DSH 的会话窗口中，无法搜索聊天内容的关键字：

• ❌ 当前会话内：按 Ctrl+F 无任何反应，无法在正在浏览的对话里查找/高亮关键字
• ❌ 跨会话：无法在历史会话中检索正文内容
• ⚠️ 侧边栏的搜索框只能匹配会话标题和工作区名称，搜不到消息正文

期望行为（与浏览器、办公软件一致的通用交互）：

在会话页面按 Ctrl+F → 弹出搜索条 → 输入关键字 → 页面内实时高亮所有匹配 → 支持上一个/下一个跳转、显示 第 n / 共 m 处。

这不是配置问题——新手用户第一反应就是按 Ctrl+F，按下去毫无反馈，会直接判定"DSH 坏了"。

---

二、复现步骤

1. 打开桌面版 DSH（0.2.0-rc.2，Windows）
2. 进入任意一个内容较多的会话
3. 按 Ctrl+F
4. 预期：出现搜索条并高亮匹配
   实际：无任何反应

同理，在侧边栏搜索框输入某个只出现在消息正文里的关键词（非标题），结果为空。

---

三、根因分析（含源码位置）

我已定位到三处确凿证据，供官方参考：

证据 1：主进程未注册 Electron 原生 find 菜单角色

app.asar/lib/main.js 第 11930 行：

const refreshApplicationMenu = () => {
    Menu.setApplicationMenu(Menu.buildFromTemplate(
        process.platform === "win32" ? devToolsItems : [ /* macOS 完整菜单 */ ]
    ));
};

其中 devToolsItems 仅含两项：

const devToolsItems = [
    { role: "toggleDevTools", visible: false },
    { role: "toggleDevTools", visible: false, accelerator: "F12" }
];

Windows 分支只有 DevTools 两项，没有 Electron 标准的 role: "find"。因此 Ctrl+F 未被任何处理器接管，webContents.findInPage() 也从未被调用。

补充：macOS 分支走了 platformMenus()，但同样未见 find 角色。

证据 2：全部可绑定快捷键命令中没有任何搜索命令

@deepseek-ai/dsh-client-shortcuts 注册的命令全集（共 14 个）：

browser.new            chat.quota-notice      fixed.complementary
fixed.mention          fixed.newline          fixed.send
fixed.slash            page.close             response.stop
settings.open          sidebar.left.toggle    sidebar.right.toggle
terminal.new           workspace.files

没有任何 search.* / find.* 命令，因此即便用户想通过「快捷键设置」自行绑定 Ctrl+F 也无从下手。

证据 3：全文搜索出厂即关闭，且 Web 侧边栏刻意只搜标题

@deepseek-ai/dsh-base/cordis.patch.yml 第 141–153 行（官方原文注释）：

# Full-text session search is opt-in. `openAt: never` keeps
# ctx.sessionQuery mounted — exact reads, titles, and lineage traces
# (session export, subagent-fork Workspace inheritance) stay available —
# while search calls fail with SESSION_QUERY_SEARCH_DISABLED and SQLite is
# never opened; the Web sidebar search matches titles and workspace names
# only. Deployments enabling content search override `openAt` to
# `first-search` or `startup` in a later patch layer (profile
# cordis.patch.yml or a --patch overlay), typically with a durable `path`.
- id: session-query-sqlite
  name: '@deepseek-ai/dsh-session-query-sqlite'
  config:
    path: ':memory:'
    openAt: never

这是设计如此：底层 dsh-session-query + dsh-session-query-sqlite（SQLite FTS5 全文检索）已具备完整能力（searchSessions / searchEvents，支持分页、摘录、元数据过滤），但默认 openAt: never 使其永不打开，调用会返回 SESSION_QUERY_SEARCH_DISABLED。

---

四、值得强调的一点

底层能力其实是完备的——dsh-session-query 的 README 明确写了：

searchSessions(request) / searchEvents(request) — 全文搜索分页结果，由挂载的后端实现
既能跨会话搜索，也能在单个会话内搜索，并支持游标分页

也就是说，缺的不是引擎，而是"界面入口"和"默认开启"：

层面	现状
底层引擎 dsh-session-query(-sqlite)	✅ 已安装，FTS5 全文检索完备
默认配置	❌ openAt: never，搜索被关闭
GUI 界面	❌ 无 Ctrl+F，无会话内搜索条
可绑定快捷键命令	❌ 无 search 类命令
面向模型的工具 dsh-tool-session-query	❌ 未随发行版提供（README 有引用但包不存在）

顺带一提：dsh-session-query-sqlite 的 README 里提到该能力面向的使用场景之一正是「/resume 既往工作检索」，可见会话内检索本就是规划中的能力，只是尚未落到 UI。

---

四之二、实测：即使把开关打开，中文依然搜不到（关键新证据）

这一节是本建议最希望官方关注的部分。

实测 1：开关生效了，但索引里没有内容

按官方注释的指引，把 session-query-sqlite 从 openAt: never 改为 first-search，
并给出持久化索引路径：

- id: session-query-sqlite
  name: '@deepseek-ai/dsh-session-query-sqlite'
  config:
    path: 'C:\Users\<user>\.dsh\cache\session-search.db'
    openAt: first-search

重启 DSH 后：

• ✅ 索引库确实被创建了：~\.dsh\cache\session-search.db（36 KB）
• ❌ 但库中 0 个会话、0 条内容（persisted_sessions = 0、persisted_docs = 0、global_generation = 0）

即：开关生效、后端启动，但没有把任何历史会话索引进去，所以搜索必然返回"无匹配会话"。
这一条建议官方排查：桌面版组合下该后端是否缺少索引数据的触发路径（是否只在写入时增量索引、而不会回填历史？）。

实测 2：unicode61 分词器不适用于中文（即使索引修好也依然搜不到）

该后端使用 SQLite FTS5，默认 unicode61 分词器，未做中文处理。
用与 DSH 完全相同的表结构复现，并用 fts5vocab 导出真实切出的 token：

被索引的文本	查询词	结果
这个关键字能不能被搜索到	关键字	❌ 0 命中
同上	搜索 / 会话 / 当前会话	❌ 0 命中
DSH 的会话搜索：全文检索（FTS5）后端	全文检索	✅ 1 命中（恰好被 ： 和 （ 夹成整词）
同上	DSH / FTS5	✅ 1 命中（英文本身是独立 token）

fts5vocab 显示索引里实际的 token 是：

「这个关键字能不能被搜索到」      ← 整句变成一个 token
「我需要的是在当前会话页面里」
「能搜索到关键字的效果」
「的会话搜索」
「全文检索」
「dsh」「fts5」

三段中文文本只切出 8 个 token。中文只有在"正好等于一整段被标点/空格/英文隔开的文本"时才能命中，
日常"在句子里找一个词"的用法完全搜不到。

⇒ 因此"把侧边栏搜索接上正文召回"这一条建议，必须同时换成分词方案（如中文双字切分 / bigram 后再入索引），
否则即便索引修好、开关打开，中文用户依旧搜不到。

---

四之三、可用原型：已实测跑通的 Ctrl+F 插件

为了验证"这个功能做出来是什么样"，我们用 DSH 自己的客户端插件机制做了一个原型
（不改动 DSH 本体，通过 ~/.dsh/profiles/desktop/cordis.patch.yml 挂载）：

• 位置：~/.dsh/local-plugins/dsh-find/（package.json + lib/index.js 空 host 半 + lib/client.js 界面半）
• 走 DOM 文本级子串匹配，因此中文关键词可正常命中
• 高亮用 CSS Custom Highlight API（::highlight()），不修改 React 渲染的 DOM，不会被重渲染冲掉
• 查找范围限定在 [data-slot="conversation.session"]，取不到时退化为整页
• 流式输出时用 MutationObserver + 防抖重算

本机实测结果（DSH 0.2.0-rc.2 / Windows 11）：

操作	结果
Ctrl+F	✅ 弹出查找条并聚焦
输入中文「搜索」	✅ 1/73，页面上 73 处全部高亮
Enter	✅ 1/73 → 2/73，滚动到下一处
Esc	✅ 关闭并清除高亮

配套截图见附件 01-CtrlF搜索栏与高亮.png、02-中文搜索73处命中.png。

这个原型的意义在于：它证明了"会话内 Ctrl+F 高亮"在现有架构下完全可行，
而且给出了一个绕开 FTS 中文问题的实现路径。官方若愿意，可直接参考该思路做官方实现；
也可以考虑提供一个面向模型的 conversation.search 命令。

---

五、建议方案（供参考）

按实现成本从低到高：

1. 最小可用：在主进程 Windows 菜单补上 Electron 原生 role: "find"，或直接拦截 before-input-event 中的 Ctrl+F 调用 webContents.findInPage() —— 即可立刻获得 Chromium 原生的页内查找/高亮，几乎零 UI 工作量。

2. 会话内搜索条：在会话视图内实现搜索条 UI（复用现有 ctx.shortcuts 注册一个 conversation.search 命令），支持高亮 + 上下跳转。走文本级匹配可顺带绕开 FTS 的中文分词问题（见第四节之二实测 2）。

3. 跨会话内容搜索：将 session-query-sqlite 的 openAt 默认改为 first-search（配合持久化 path），让侧边栏搜索支持正文召回；
   同时需要把索引管线改为中文可分词的方案（双字切分 / bigram），否则中文召回依然失效。
   另建议排查第四节之二实测 1 中"索引库已创建但 0 条记录"的问题。

---

六、环境信息

项	值
DSH 版本	0.2.0-rc.2（ProductVersion 0.2.0.0）
操作系统	Windows 11 (NT 10.0.26300.0)
发行渠道	nightly
会话数据规模	106 个会话 / 约 45 MB（~/.dsh/sessions/**/session.v4.jsonl.zstd）

---

七、附：会话数据格式观察（非问题，供参考）

会话以追加式多帧 zstd 存储（session.v4.jsonl.zstd），单个会话最多可达 2000+ 个独立 zstd 帧。用 Node 24 原生 zlib.zstdDecompressSync 逐帧解压可完整还原事件流。

这一格式对「会话内搜索」有兴趣的实现方可能有用：由于是追加式，增量索引（只解压新增帧）会非常高效。

---

一句话总结：底层全文检索引擎已就位，但桌面版既未开启它、也未提供 Ctrl+F 入口，导致用户在最基础的"在对话里找一句话"场景上无路可走。建议优先补齐 Electron 原生 find 角色——这是投入产出比最高的一步。

[furoute]

补充：实测截图与原型说明

上面提到的截图，这里一并说明内容（图片较大，需要手动拖入 — 见文末步骤）：

截图 1 — Ctrl+F 搜索栏（面板外观）
右上角对话区顶部居中的胶囊形查找条，自左至右：🔍 放大镜图标 → 输入框（内容「功能建议.md」）→ 计数 1/2 → 竖线分隔符 → ▲ 上一处 → ▼ 下一处 → ✕ 关闭。
整条为圆角 999px + 半透明模糊（backdrop-filter: blur(6px)），并自动避开桌面窗口右上角的窗口控制按钮。

截图 2 — 中文关键词命中的高亮效果
输入中文「搜索」后，计数显示 1/73，页面内 73 处「搜索」全部高亮：

• 当前项：橙色（#ff9100）
• 其余项：黄色（#ffd54f）

这正是 DSH 内置 FTS5 unicode61 分词器做不到的 —— 中文连写会被切成整词（见上文实测 2）。

原型插件代码结构（约 290 行，单文件）

~/.dsh/local-plugins/dsh-find/
├── package.json          # dsh.client 声明 + peerDependencies
└── lib/
    ├── index.js          # host 半：空 apply()，仅为出现在插件组合中
    └── client.js         # 浏览器半：全部界面逻辑

关键实现片段（供官方参考）

高亮 —— 用 CSS Custom Highlight API，不插入任何 DOM 节点，因此不会被 React 重渲染冲掉：

var all = new Highlight();
var active = new Highlight();
for (var i = 0; i < state.ranges.length; i++) {
    if (i === state.index) active.add(state.ranges[i]);
    else all.add(state.ranges[i]);
}
CSS.highlights.set("dsh-find-all", all);
CSS.highlights.set("dsh-find-active", active);

::highlight(dsh-find-all)    { background:#ffd54f; color:#1a1a1a }
::highlight(dsh-find-active) { background:#ff9100; color:#1a1a1a }

匹配范围 —— 限定在对话区，取不到时逐级退化：

function scope() {
    return document.querySelector('[data-slot="conversation.session"]')
        || document.querySelector('[data-slot^="conversation"]')
        || document.body;
}

按键拦截 —— 捕获阶段监听，确保优先于编辑器：

document.addEventListener("keydown", onKeyDown, true);

流式输出时用 MutationObserver + 400ms 防抖重算匹配。
桌面端特有的定位处理：placeBar() 保证 top 不低于 52px，避免压到窗口控制按钮那条区域。

---

如果官方愿意采纳，我个人觉得最小改动、最大收益的是这一条：
在主进程 app.asar/lib/main.js 的 Windows 菜单分支补上 Electron 原生 role: "find"，
或拦截 before-input-event 里的 Ctrl+F 调用 webContents.findInPage()。

这样几乎零 UI 工作量就能让所有用户立刻获得 Chromium 原生的页内查找高亮，
而且是 Electron 内置能力，不需要维护自定义搜索条。

（截图的原始文件如果需要，我可以再想办法提供。）

[furoute]

[furoute]

勘误与数据订正（作者补充）

感谢维护者与社区阅读。经复核，原帖有两处需要更正，特此说明——其余根因与实测结论均已在 0.2.0-rc.2 上复核无误，不受影响。

---

一、勘误：Electron 没有可直接唤出查找条的菜单 role

原帖第五节建议 1 与结尾一句话写道：

「在主进程 Windows 菜单补上 Electron 原生 role: "find" …… 几乎零 UI 工作量」

这个说法不成立，在此更正。 我核对了 Electron 官方文档（docs/api/menu-item.md），role 的完整可选值共 48 个：

undo, redo, cut, copy, paste, pasteAndMatchStyle, delete, selectAll,
reload, forceReload, toggleDevTools, resetZoom, zoomIn, zoomOut,
toggleSpellChecker, togglefullscreen, window, minimize, close, help, about,
services, hide, hideOthers, unhide, quit, showSubstitutions, toggleSmartQuotes,
toggleSmartDashes, toggleTextReplacement, startSpeaking, stopSpeaking, zoom,
front, appMenu, fileMenu, editMenu, viewMenu, shareMenu, recentDocuments,
toggleTabBar, selectNextTab, selectPreviousTab, showAllTabs, mergeAllWindows,
clearRecentDocuments, moveTabToNewWindow, windowMenu

其中不存在 find / findNext / findInPage 中任何一个。
浏览器里那条查找 UI 属于 Chromium 浏览器外壳，不是 Electron 暴露的菜单角色；editMenu 的官方描述也只是 "Undo, Copy, etc."，同样不含 Find。
所以「补个 role 就有原生的、零 UI 成本的查找条」是不对的，感谢指出。

更正后的最小改动路径（两条，均需自绘查找条 UI）：

1. 主进程侧：在 webContents 上监听 before-input-event 捕获 Ctrl+F，自行提供查找条界面；
   匹配与高亮可交给 webContents.findInPage(text[, options])（配合 found-in-page 事件与 stopFindInPage）。
   注意这仍是"需要自绘 UI"，并非零成本。
2. 渲染层侧：文本级子串匹配 + CSS Custom Highlight API 高亮。
   这条路径本机已实测跑通（见原帖第四节之三），约 290 行、以本机客户端插件形式挂载，
   不依赖 FTS 索引，天然支持中文——恰好绕开了下面第二节的中文分词问题。

---

二、数据订正：会话数口径

原帖第六节写「106 个会话」，精确说法应为：

口径	数量
会话目录数	102
日志文件数	106（48 个 session.jsonl.zstd + 44 个 session.v3.jsonl.zstd + 14 个 session.v4.jsonl.zstd）
数据总量	约 45.7 MB

即：有 4 个会话目录下同时存在多种格式的日志文件。
这一点对实现方有实际影响——同一会话的多个日志文件并非严格的超集关系，
例如某个会话 session.jsonl.zstd 有 11075 行、而其 session.v3.jsonl.zstd 只有 1476 行，
两边各有对方没有的行。因此读取时应按会话目录合并全部日志，而非只取其一或按文件平铺，否则会漏内容或重复计数。

---

三、截图状态：无需重传（已内嵌）

先前担心的「截图仅显示为链接」问题不存在——本页评论中的 5 张截图均已通过
user-attachments 正常内嵌（<img> 标签，非裸链接），未登录用户亦可正常查看。

---

以上两处更正不影响原帖的核心结论：桌面版没有会话内 Ctrl+F 入口，
且自带全文检索路径存在「索引为空」与「unicode61 不支持中文」两个已实测的问题。

[furoute]

English summary (for triage)

Title: In-conversation find (Ctrl+F) is missing on DSH desktop; and the bundled session search cannot match Chinese.

Problem. On DSH desktop 0.2.0-rc.2 (Windows 11), pressing Ctrl+F inside a conversation does nothing.
The app never references webContents.findInPage, and none of the 14 registered shortcut commands is find/search related.
The sidebar search box matches session titles and workspace names only, not message bodies.

Two verified findings that matter more than the missing UI:

1. Enabling the bundled backend is not enough. Following the documented override
   (session-query-sqlite → openAt: first-search with a durable path) does create
   session-search.db, but the index stays empty — persisted_sessions = 0,
   persisted_docs = 0, global_generation = 0. History is never indexed in the desktop composition.
2. The tokenizer cannot handle Chinese. The FTS5 table uses unicode61 with no CJK handling,
   so a run of Chinese characters collapses into one token. Indexing
   …这个关键字能不能被搜索到… returns 0 hits for the query 关键字, while DSH / FTS5 match normally.
   fts5vocab confirms the actual tokens, e.g. the whole clause 这个关键字能不能被搜索到 is a single term.
   Even with a populated index, Chinese keyword search would still fail.

Correction to an earlier suggestion in this thread. My first post suggested that adding an Electron
menu role: "find" would give a native find bar at zero UI cost. That was wrong. Electron's role
list (48 values — undo, copy, editMenu, viewMenu, … windowMenu) contains no
find / findNext / findInPage. There is no built-in role that opens a find bar; any solution needs
its own bar UI. The two viable minimal paths are:
(a) main process — intercept Ctrl+F via before-input-event, draw the bar, and delegate matching to
webContents.findInPage(text[, options]) with the found-in-page event and stopFindInPage;
(b) renderer — text-level substring matching with highlighting, independent of the FTS index.

Suggested priority: (1) ship an in-conversation find bar using text-level matching — it works for
CJK and does not depend on the index; (2) fix the desktop-side indexing path and adopt a CJK-aware
tokenization scheme (e.g. bigram pre-split); (3) consider shipping the model-facing dsh-tool-session-query.

Prototype (verified working). A ~290-line local client plugin, mounted through
~/.dsh/profiles/desktop/cordis.patch.yml with no changes to app.asar, already provides Ctrl+F
with highlighting (CSS Custom Highlight API), a current / total match counter, and next/previous
navigation. Verified on 0.2.0-rc.2: typing the Chinese query 搜索 reports 1/73 with all 73
occurrences highlighted; Enter advances, Esc closes and clears.

Session storage note (may be useful for an indexer). Logs are append-only multi-frame zstd
(session.v4.jsonl.zstd, up to 2000+ frames per session). One session directory may hold several log
formats side by side (session.jsonl.zstd / session.v3.jsonl.zstd / session.v4.jsonl.zstd), and they
are not strict supersets of one another — e.g. one session has 11075 lines in session.jsonl.zstd
but only 1476 in its v3 file, each containing lines the other lacks. Readers should merge all logs per
session directory rather than pick one. Because the format is append-only, incremental indexing
(decompressing only newly appended frames) is cheap.

[furoute]

关联：本线程与 #4752 是同一底层问题的两个侧面（并补一条中文分词缺陷的实测）

看到 #4752 First-class cross-conversation history search，
发现两帖指向同一个底层事实——session-query 家族已随发行版交付，但因默认 openAt: never 而未生效——
只是关注面不同，建议合并参考：

	#4752	本线程 #8713
关注面	模型侧：agent 能否检索既往会话	人侧：用户能否在会话里 Ctrl+F 查找
核心诉求	启用并清晰暴露已交付的检索能力	补齐会话内查找 UI + 修复中文检索
共同根因	session-query-sqlite 默认 openAt: never；tool-session-query（官方仓库已有源码）未随桌面版组合挂载	同左

本线程可补充 #4752 的两条实测（#4752 中未覆盖）

1. 即使把开关打开，索引里也没有内容

按官方注释指引把 session-query-sqlite 改为 openAt: first-search + 持久化 path 后，
索引库确实被创建（36 KB），但 persisted_sessions = 0、persisted_docs = 0、global_generation = 0
——开关生效、后端启动，却没有索引任何历史会话。这一条建议官方排查：桌面版组合下该后端
是否缺少历史回填的触发路径（是否仅在写入时增量索引？）。

2. unicode61 分词器不处理中文（即使索引修好也依然搜不到）

session-query-sqlite 使用 SQLite FTS5，默认 unicode61。用相同表结构复现，
并用 fts5vocab 导出真实 token：一段 …这个关键字能不能被搜索到… 被切成一个 token，
因此查询 关键字 返回 0 命中，而 DSH / FTS5 等英文可正常命中。

⇒ 这意味着 #4752 中"enable and expose it clearly"的目标，若仅打开开关、不动分词方案，
对中文用户仍然无效。建议同时采用 CJK 友好方案（如 bigram 预切分）。

各侧现状小结

层面	现状
底层引擎 session-query / -sqlite	✅ 已随发行版交付（桌面版已装）
默认配置	❌ openAt: never（搜索恒返回 SESSION_QUERY_SEARCH_DISABLED）
模型工具 tool-session-query	⚠️ 官方仓库已有源码（packages/session-query/tool-session-query/），提供 session_search、session_event_search、session_trace、session_event_trace、session_event_read 五个只读工具；但桌面版未随组合挂载
用户侧 Ctrl+F / 会话内查找 UI	❌ 无（全部 14 个可绑定快捷键命令中无 search/find 类）
中文分词	❌ unicode61 不适配

一个已跑通的客户端侧原型（供参考）

本线程附了一个约 290 行的本机客户端插件（不改动 app.asar）：
文本级子串匹配 + CSS Custom Highlight API，实测中文查询「搜索」→ 1/73 全部高亮，
Enter 前进、Esc 关闭。它绕开了 FTS 索引，因此天然不受中文分词问题影响——
可作为"会话内查找"的最小实现参考。

（另注：本线程先前一处建议"补 Electron 菜单 role: "find" 即可零 UI 成本"有误，
Electron 的 48 个菜单 role 中并不存在 find，已在 勘误评论 中更正。）

---

一句话：两帖合起来看更完整——#4752 指出"能力已交付但未启用"，本线程补上
"即使启用，中文仍搜不到" 与 "用户侧还缺 Ctrl+F 入口"。

[Fortda]

感觉挺有价值的，怎么没人回？是不是发General的bug比较好

[furoute]

感谢关注和建议 🙏

两点说明：本仓库 Issues 未启用（has_issues: false），官方 CONTRIBUTING 也写明问题与建议走 Discussions，
所以这里就是当前唯一正式渠道；分类方面，Ideas 的官方定位是「Share ideas for new features」，
本线程属于功能建议，放这里更对口。

如果这个功能对你有用，欢迎在楼层顶部 👍 投一票，帮助维护者看到需求强度。

[qjlyg]

我也觉得很神奇，居然没多少人需要这个功能吗

[furoute]

【更正 · 2026-10-06】关于"原创性主张"的自我修正

本线程第 4 条评论中，我把「session-query-sqlite 使用 unicode61、中文被切成整 token、故中文搜不到」
作为实测发现提出。经检索，这一条并非首次提出：

• #1999（2026-08-15）早已指出同一问题，
  且方案比我们更完整——包括可配置 tokenizer / tokenizerExtension、schema 版本 8→9 自动重建索引、
  限制 tokenizer 取值以防 SQL 注入，并附了命中对照表。
  本线程应将其视为独立复现，而非新发现；建议后来者先读 Feature proposal: configurable FTS5 tokenizer for session search (Chinese support) #1999。

需要说明的是：本线程的结论本身不变——该 tokenizer 行为经我们独立实测确认，
且它仍是"即使打开出厂开关、中文用户依然搜不到"这一判断的依据。
更正的只是归因：首次提出权不在本线程。

我们发帖前只做了单一关键词检索，未做同义替换与时间正序回溯，因而漏掉了 #1999。
把这条记在这里，也提醒后来者：同一问题在不同帖子里的标题用词可能完全不同。

一个顺带的观察：这类需求为什么容易被低估

检索过程中我们统计了一下，同一诉求至少有 6 处独立来源，散落在多个分类中：

帖子	角度	时间
#1999	FTS5 unicode61 中文分词（含完整方案）	08-15
#3771	跨会话检索插件	08-21
#4029	Ctrl+F 会话内查找插件	08-22
#4752	模型侧跨会话检索（一等能力）	08-27
#7946	会话搜索必然失败（附错误码）	09-26
#8796	搜索命中后不定位、不高亮	10-04

这些帖子的标题用词各不相同（Ctrl+F / find in chat / session search / 中文搜索…）、
分散在不同分类（Ideas / General / Show Your Plugins），且彼此没有交叉引用。
结果是：从任何单一帖子的视角看，它都像"孤例"——这也是社区中有人感叹
"居然没多少人需要这个功能"的原因。并非需求不存在，而是诉求被分散了。

以上仅为观察，供维护者评估需求优先级时参考。

[furoute]

同感，我也一度觉得"这么基础的功能怎么会缺"

不过这两天翻了一圈，发现可能需要的人不少，只是需求分散、互相看不见：

• #1999（08-15）：FTS5 unicode61 不做中文分词，并给出完整修复方案（可配置 tokenizer、schema 8→9 自动重建索引、取值白名单防注入）；
• #4029（08-22）：社区已做出 Ctrl+F 会话内查找插件（dsh-client-find-in-chat）；
• #4752（08-27）：模型侧跨会话历史检索；
• #8796（10-04）：搜索命中后不定位、不高亮。

另有 #7946（会话搜索必然失败）、#3771（跨会话检索插件）等；这些帖子分在 Ideas / General / Show Your Plugins 三个分类，标题用词各异，彼此零交叉引用，所以单看任一帖都像孤例。

另：本线程第 4 条评论里把「unicode61 不支持中文分词」当作实测发现——更早的来源是 #1999（早一个半月），我们已在本线程第 9 条评论做了更正。

如果这个功能对你有用，除了楼层顶部的 👍，也可以去上面几个帖子点赞或补充使用场景——把分散的需求连起来，比单帖更容易被看到。