fd/rg 之上，是否还需要 fuzzy / semantic 搜索工具？

[tt-a1i]

一句话问题：在已有 fd / rg 之上，是否还需要 fuzzy / semantic 搜索工具？

这不是 commit 计划。倾向 Discuss。本轮未安装、未运行下列包。不提议新安装器。Pi 继续拥有 install / update / uninstall。

为什么目录里这个机制看起来有趣

冻结身份（last-seen 2026-09-08）：

包	版本 / 日期	来源
@ff-labs/pi-fff	npm 0.10.6（2026-08-30）	https://www.npmjs.com/package/@ff-labs/pi-fff · https://github.com/dmtrKovalenko/fff
@gotgenes/pi-colgrep	npm 1.5.3（2026-08-19）	https://www.npmjs.com/package/@gotgenes/pi-colgrep · https://github.com/gotgenes/pi-packages/tree/main/packages/pi-colgrep

一个是 native fuzzy 文件 / 内容搜索，一个是 ColGrep 语义检索。都是小工具，不是第二套代码智能 IDE（那是 #163 的 LSP / pi-lens）。

和 OpenPI 已有能力的重叠

OpenPI 已有 fd / rg（extensions/file-search/），且已列入 CHILD_SAFE_PACKAGE_TOOL_NAMES。再加 fuzzy / embedding 搜索会增加常驻或按需工具面，直接打在 #300。#163 研究的是 LSP diagnostics / symbol，不是 fuzzy。

六问（AGENTS.md）

1. 哪条 Pi seam？ 普通检索可用 Pi bash + 用户自己的 fd/rg，或 OpenPI 已暴露的 fd/rg。没有第三条「搜索控制面」。
2. 模型判断还是运行时不变量？ 「搜什么、读哪处」是模型判断。输出有界、路径不逃出 Trust、child 分类是运行时不变量。
3. 正交机制还是工作流？ 一个额外 search tool 可以是正交的。若做成 codebase index daemon / 跨会话 embedding 库，就滑向 Memory / 第二控制面（memory: 研究 Project-scoped Durable Learning，并严格区分事实、经验与 Skill #167 已排除自动 memory）。
4. 更强模型会不会直接用 Pi 原语？ 这是本帖的主测试。 更强模型更会写 rg 模式。若收益只出现在弱模型上，OpenPI 不应加工具。
5. 成功 / 失败证据？ 对照同一批定位任务：调用次数、token、首结果延迟、错误文件率。fuzzy 命中不能替代「读到的内容和磁盘一致」。semantic miss 必须是 miss，不能编造符号。
6. 权限如何停和清？ 若增加模型可见工具，必须 child 分类。embedding 索引若落盘，要有停用 / 删除 / 不注入凭据。不新开 /search-setup；要配置就走 /openpi-setup。

结论倾向

Discuss，不是 Adopt。 默认假设：fd/rg 已够，先用 #313 的证据标准证伪「还要第三种搜索」。不 merge 上述包，不建语义索引产品。

关联：#163（LSP，不是本帖）、#300、#313、#299、#314、#167（不要做成 memory）。研究记录：docs/research/PI_COMMUNITY_PLUGIN_SURVEY_2026-09-08.md。

[tt-a1i]

2026-09-08 目录第二轮：AST 结构搜索/替换不是本帖的 fuzzy / semantic 文本搜索。

code-yeongyu/pi-ast-grep 为 git-only（main 4a7d1be，2026-06-05），未进 Gallery。问题开在 #510。@gotgenes/pi-colgrep 仍只属于本帖。

本轮未安装、未运行。不在这里重开搜索工具清单。

[tt-a1i]

2026-09-09 源码对照：#503 现在有独立记录，不再只被 CODE_INTEL 吸收成一句「继续 Discuss」。

Canonical：docs/research/EXPERIMENT_FUZZY_SEARCH_2026-09-09.md（OpenPI a9b40f0）。只读 clone / npm tarball 在 /tmp/openpi-fuzzy-search-2026-09-09/。未 pi install，未运行 FFF native / colgrep / 模型。

冻结身份未变：@ff-labs/pi-fff 0.10.6（gitHead c6013ba）；@gotgenes/pi-colgrep 1.5.3（最后代码 9832a9f）。两包扩展源文件与本轮 clone HEAD 字节相同。不采用 fff nightly 0.10.7-nightly.7f8537e。

结论仍是 Discuss，不是 Pilot / Adopt：

• fuzzy 不是第三原语。 fffind / ffgrep 仍回答「哪个路径 / 哪一行」，只是 neo-frizbee + frecency。默认立刻 setActiveTools；path 可通过 aux 搜出 workspace；enableHomeDirScanning / followSymlinks 默认开。README 把 fff-multi-grep 和 grep default 100 写成产品表面；源码里 multi-grep 要 PI_FFF_MULTIGREP=1，grep 默认 limit 是 20。
• semantic 是另一种检索函数，不是新的生命周期缝。 colgrep 走用户自备 ColGrep（tree-sitter 单元 → ColBERT）。默认 indexOnStartup: true → 后台 colgrep init -y .；argv 没有 --；截断临时文件不在 session_shutdown 清理。它不是 LSP（code-intelligence: 研究按需加载的 Pi-native LSP 能力，而不是常驻第二套 IDE Runtime #163），也不是 AST-grep（LSP（#163）和文本搜索（#503）之外，是否还需要 AST 结构搜索/替换原语？ #510）。
• 两包都是未分类第三方，会漏进 in-process child（loader 只过滤 pi-intercom）。不要 pi install。
• 更好模型测试未跑。默认继续假设已加载的 OpenPI fd/rg 够用；证伪必须用 Evidence and Evaluation：怎样证明一项 Agent 能力值得它的完整成本？ #313 的强基线，不能拿上游 Semble NDCG 或「少几次 grep」宣传图。

不提议新安装器，不新开 /search-setup。AST 仍走 #510。