1.0.0 实测反馈：hybrid 短文件偏置与冷启动、报错重复、pattern/query 参数名不一致、model 模式统计冗余

[connieli326]

sift-light 1.0.0 使用反馈（2026-09-22，MCP stdio 直连，Claude Code / macOS arm64 + Linux arm64）

先说结论：精确搜索（literal / regex / files / 中文原文）全部即时命中、带行号列位，报错能自解释，scope 扩展有明确说明，比旧包好用。下面是实际测出来的几处可改进点，按重要程度排，每条都可复现。

1. hybrid 语义排序对短文件有偏置，中文查询正确文件排第 6

• 范围：一个 82 文件 / 529 passages 的 deploy/ 目录。
• 查询（zh-CN）：缓存 scope 补丁是怎么定位 Bun 模块的，conceptLimit: 10。
• 结果：正确文件 patch_cc_cache_scope.py（其 docstring 就写着 Bun StandaloneModuleGraph / module_info / bytecode）排 feat: add adaptive grep override #6；feat: initial Signal Grep release #1 verify_yuni_codex_full_access.py L1、feat: launch Signal Grep for Pi #2 yuni-api-bot.service L1、feat: add cumulative token metrics status #5 tg-workgroup.projects.example.json L1 —— 前排大多是"整个短文件当一个 passage"的命中。
• scoreProfile：top 0.878 / second 0.873 / median 0.818 / min 0.774，topMargin 0.005。分数挤在一起，默认 conceptLimit=3 时正确文件直接看不到。
• 同一问题英文（how does the cache scope patch locate the Bun module）正确文件排 feat: launch Signal Grep for Pi #2，说明模型对中文更弱，但短 passage 偏置两种语言都有。
• 建议：(a) 对极短 passage（如 <N tokens 或整文件单窗口）做长度归一/降权；(b) 当 topMargin 低于阈值时在结果里给一条"low confidence / 建议改用 literal 或加关键词"的提示，现在 scoreProfile 数据都有了，只差一句话的判断；(c) 若可能，换或可选一个多语言更强的本地模型。

2. hybrid 冷启动 53 秒、峰值 RSS 1.27 GB（82 文件）

• 首次 hybrid：elapsedMs: 52983，inferencePeakRssBytes: 1270431744，进度大部分时间停在 phase: model-loading；需要 5 轮 mode: await。
• 缓存热后同一目录任意查询 ~1 s，conceptCacheHits: 530，RSS 降到 ~178 MB —— 缓存设计是好的。
• 建议：MCP server 启动后在后台预热模型（或提供 SIFT_LIGHT_CONCEPT_PREWARM=1），并在 README 里写明首次 hybrid 的时间/内存预期；否则 agent 第一次用会以为卡死。

3. E_MODE_FIELDS 报错把同一段恢复指引重复了三遍

• 触发：{"mode":"files","pattern":"cache_scope"}（files 模式要 query）。
• 返回约 1.2 KB，其中 "mode=files does not accept pattern; … Fields are flat … mode=files accepts: …" 这段在 Error details、sift-light failed:、Recovery action: 三处逐字重复。
• 在 SIFT_LIGHT_MCP_OUTPUT_MODE=model 下这是纯上下文浪费。建议只保留一处完整指引，其余引用。

4. 参数名不一致：内容搜索用 pattern，files / hybrid 用 query

• 同一个工具、同一个"我要找的字符串"，换个 mode 字段名就变了，agent 很容易传错（上面第 3 条就是这么触发的）。
• 现在的报错说 "no semantics-preserving automatic request is available"，但对 files 模式而言 pattern→query 语义是保留的。
• 建议：files 模式接受 pattern 作为 query 的别名（或反之），至少在报错的 recovery 里给出自动改写后的完整请求。

5. model 输出模式下 hybrid 结果页仍带 ~2 KB 的 JSON 统计

• 一次 hybrid 结果里 Counts / Scope / Coverage / Stats / Source generation / Semantic judge / Operation 七行 JSON，合计约 2 KB，每次查询都带。
• model 模式的定位是给模型省上下文，这些诊断信息适合折叠成一行摘要 + 一个可选的 mode: "diagnostics" 再展开。

顺带的好话（不用改）

• 搜不到时会明确写 "requested path had no matches; project root was also searched"，不会静默返回空。
• 中文 literal 搜索命中精确到列，UTF-16 列位说明也写在结果里。
• 报错虽长，但每条都把该改哪个字段说清楚了，改一次就对。

环境：sift-light 1.0.0（npm），Node 25.6.1（macOS，pi install npm:sift-light 路径）/ Node 22.22.2（Linux arm64，npx -y --package sift-light@1.0.0 sift-light-mcp --stdio），SIFT_LIGHT_MCP_OUTPUT_MODE=model，enforceSearch: prefer，locale: zh-CN。

[lightsifter]

1.0.1 的实现已通过 PR #95 合并到 main，逐项回报这份 1.0.0 反馈：

• 短 passage 排序偏置：加入有界长度修正，同时保留原始 cosine 分数。语义结果仍只是候选，需查看源码取证；中文召回质量也不能保证每次正确文件都排第一。
• 冷启动与内存：优化了推理顺序、批量和 CPU 线程；首次未缓存的语义搜索仍可能需要数十秒、工作进程占用超过 1 GiB。这是当前本地模型与索引工作量的实际资源成本，不应解释为每次精确搜索都要付的成本，也不是内存上限或零泄漏证明。为避免阻塞日常开发，1.0.1 在 Pi、OMP、MCP 中默认关闭向量；普通精确搜索不加载模型。需要 concept/hybrid 的用户可在有效配置中显式设置 vectorSearchEnabled: true、安装模型并重启。不会静默降级。
• 错误重复：压缩重复的报错与恢复文本。
• pattern/query：files 模式误传普通 pattern 时给出保持 scope 的完整 query 恢复请求；字段契约仍区分内容搜索与文件名发现。
• model 输出：压缩语义结果诊断文本，保留覆盖、进度和恢复信息。

本地验证包括 505 项通过、3 项条件性跳过，真实本地模型测试、Claude/Codex/Kimi MCP 流程和 npm 打包检查通过；PR 的必需 CI（Linux、macOS、Windows、CodeQL、质量门禁）也全部通过。Jev 候选分类仍是可选功能，向量关闭时不会运行。后续版本若要再降低冷启动和内存，建议以可复现的具体语料和设备数据单独跟踪；本 issue 在 1.0.1 的范围内结案。

[lightsifter]

发布补充：v1.0.1 Release 已上线，npm 的 sift-light@1.0.1 已发布且 latest 指向 1.0.1。本机使用该 npm 包直连 MCP 验证了中文精确搜索可用、默认关闭向量时 concept 明确报错；临时测试目录已清理。首次语义搜索的时间与内存取舍仍如上条说明。