AI 搜索工具的发现盲区

项目技术栈都挑好了，代码也写了一半，结果视频平台开始给我推一个看起来更适合的东西。

这不是我没问 AI，也不是我没调研。我确实问了，还问了不止一次。结果 AI 给我的候选不是冷门，就是像在念某些项目的 README。直到推荐算法把东西怼到我脸上，我才发现：哦，原来这个领域还有另一条路线。

感觉就像你都把地基挖好了，旁边路过一个人说：你怎么不用旁边那条路，大家都从那边进。

具体发生了什么

一个例子是 C++ 跨平台。

我一开始想当然就是 Qt。跨平台、C++、桌面应用，这几个词放一起，谁都会先想到 Qt。于是我顺着 Qt、QML 这俩看了一圈，十分满意。

结果过了一段时间，视频平台开始疯狂给我推 Dear ImGui。

这玩意儿压根不是传统桌面 GUI 那条路。它是 immediate mode GUI，更适合工具 UI、编辑器 UI、调试 UI、渲染管线 UI。Dear ImGui 自己也说得很清楚：它是 C++ 的轻量 GUI，强调 fast、portable、renderer agnostic、self-contained，而且主要是给程序员快速做工具和可视化调试界面的。

这就导致一个很抽象的问题：如果你问的是”C++ 跨平台 GUI 框架”，AI 很容易把搜索空间锁死在 Qt-like 框架里。它不是不知道 ImGui，而是它没有意识到你真正需要的可能不是”传统桌面 GUI”，而是”给项目做工具型 UI”。

另一个例子是 React UI。

如果拿 Vuetify、Element Plus 举例，AI 很容易去找 MUI、Ant Design、Chakra、Mantine、PrimeReact 这类传统组件库。这个方向不能说错，但它可能漏掉 shadcn/ui。

而 shadcn/ui 最要命的地方就在于它不是传统意义上的 component library。它官方文档里直接说：这不是组件库，而是你构建自己组件库的方式。组件代码会进你的项目，你可以直接改。

所以如果 AI 的脑子里是”找 Vuetify 的 React 平替”，它就会往传统组件库走；但如果它先展开”React UI 生态有哪些流派”，shadcn/ui 这种 copy-paste/open code 路线就应该出现。

问题就在这里：AI 很会回答，但不一定会先扩搜索空间。

B站推荐为什么反而能补刀

B站当然不比 AI 更懂技术。但推荐系统擅长的是另一件事：发现相邻圈层正在看什么。

你看 Qt、C++、桌面开发，它不需要理解你到底要做什么产品，只要发现一群相似用户还在看 ImGui、Slint、Tauri、Avalonia、raylib GUI，它就能把这些推给你。

AI 默认不是这么工作的。

AI 更像：

你给需求，我在已有概念里匹配答案。

推荐系统更像：

你看了这些东西，我看看相似的人还看什么。

前者适合评估，后者适合发现。

这就是为什么有时候你问 AI 半天，不如刷到一个视频标题有用——不是视频质量多高，而是它给了你一个你根本不知道该搜的关键词。

更深层的问题：LLM 的概率天性

这其实不只是”AI 搜索策略”的问题，而是 LLM 本身的架构限制。

LLM 生成回答的方式，本质上是从概率分布里采样：给定你的问题”C++ 跨平台 GUI”，模型会给”Qt”分配很高的概率，给”wxWidgets”中等的概率，给”Dear ImGui”一个虽非零但极低的概率——因为在训练数据里，ImGui 和”跨平台 GUI 框架”这个 query 的共现频率太低了。它更常和”immediate mode”、”调试工具”、”渲染管线”这些词出现在一起。

问题出在这个概率分布是生成式的，不是检索式的。

搜索引擎可以把所有网页都索引起来，你搜”GUI framework”它把含这个词的都列出来，有没有漏取决于倒排索引。但 LLM 不是——它在生成 token 时，每一步都是在当前上下文里选概率最高的路径。如果上下文里没有”工具 UI”、”immediate mode”这些词，那模型分配给那条路的概率质量就接近零。它不会绕一步想：”等一下，是不是还有一类东西我不太确定？我先去查查。”

这不是它能做到的。它不是一个在”检索 vs 不检索”之间做选择的系统，它只是一个在不断猜下一个词是什么的系统。哪怕加了联网搜索，搜索词也是由它自己生成的，这仍然经过同一个概率瓶颈。如果你不知道某个领域的存在，你就不会去搜它；你不知道该搜它，LLM 就不会帮你生成那个搜索词。

所以这个盲区不是”搜得不够努力”，而是架构层面的。模型训练完之后，它的先验分布就固定了。一个领域如果在训练数据里和你的提问方式关联不强，模型就不会自发达出通往那个领域的 token 序列。

这也是为什么 Deep Research 这类多步搜索工具能缓解但不能根除这个问题——它可以展开多组搜索词，但如果展开的方向还是落在概率高的那几条路里，冷门方向依然不会出现。

真正的问题不是搜索，而是搜索前

ChatGPT Search 会根据问题改写查询、发出多组更具体的搜索词。Deep Research 也已经是多步骤互联网研究了。但这些都没解决一个问题：

“它有没有联网”从来不是核心问题。问题是它在联网之前，知不知道：

• 用户其实是外行进入陌生领域。
• 用户给出的例子只是启发，不是边界。
• 任务目标不是快速推荐几个工具，而是先发现可能有哪些路线。
• 文档写得好不等于东西适合。
• 社区正在热的东西，可能不在传统关键词里。

这一步如果错了，后面搜得再努力，也可能只是把错误方向查得更完整。

另一个常见案例是 Traefik。AI 很容易被”现代、Docker-native、自动发现”这套叙事打动，好几个模型一起推荐，推荐得像吃了软文。但真迁移的时候，文档、边界、配置复杂度，那又是另一回事。

所以 AI 搜索不该只做 answer retrieval，它应该先做 search space expansion。不是先找答案，而是先找”可能有哪些答案空间”。

用户不应该先学会怎么问

有人可能会说，那你 prompt 写得不够专业。这话只说对了一半。

如果我一开始就知道要说”请先做技术路线地图、关键词扩展、相邻生态发现、社区热度扫描、反证检索”，那当然结果会好很多。但问题是，我都不了解这个领域了，我怎么会知道这些词？

尤其是技术选型这种场景，用户最大的问题不是”比较 A 和 B”，而是”我根本不知道还有 C、D、E”。一个好工具不应该默认用户已经知道怎么问。

所以这不是 prompt 水平问题，是产品模式问题。

AI 太喜欢给一个完整答案了。它默认会给你五个候选项、一个表格、一个结论，看着很舒服。但技术选型最怕的不是表格不整齐，而是漏掉关键类别。一个漂亮但召回不足的答案，其实比没有答案更危险——它让你以为自己调研过了。

我现在想要的工具模式

我希望 AI 搜索工具有一个很明确的模式，类似”技术选型发现模式”。

进入这个模式后，不要急着推荐，先展开地图。

比如我问 C++ 跨平台 UI，它应该先把路线拆开：

• 传统桌面 GUI：Qt Widgets、wxWidgets、GTKmm。
• 声明式 UI：Qt Quick/QML、Slint。
• immediate mode GUI：Dear ImGui、egui 这类思路。
• WebView 壳：Tauri、Electron、Wails。
• 游戏/编辑器工具链 UI：ImGui、raylib 生态。
• 平台原生 UI：WinUI、GTK、ArkUI 这种。

然后再问我：你做的是给普通用户的桌面软件，还是给开发者/创作者用的工具？你更怕 UI 丑，还是更怕工程复杂？你愿不愿意接受新范式？

React UI 也一样。别一上来就给 MUI、Ant Design、Chakra。先问清楚我到底要哪种东西：

• 传统组件库。
• Headless primitives。
• copy-paste/open code。
• Tailwind-first 模板。
• 后台管理系统。
• 动效/视觉组件。
• 自己沉淀 design system。

这样 shadcn/ui 才不会莫名其妙漏掉。

一个代码工具用的 prompt

后来我干脆把这个整理成了一个扩展 prompt，核心就是强制 AI 从”推荐模式”切到”发现模式”。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

我现在要做一个不熟悉领域的技术选型。不要直接推荐工具。

先执行搜索空间扩展：
1. 这个领域有哪些主流技术路线？
2. 有哪些相邻但容易被外行漏掉的路线？
3. 每条路线的典型关键词是什么？
4. 每条路线有哪些代表项目？
5. 哪些项目是社区热但不一定在传统榜单里？
6. 哪些项目文档/营销很强但实际使用可能有坑？
7. 请用官方文档、GitHub、包管理器、社区讨论、年度调查、视频平台关键词交叉验证。
8. 最后再按我的场景筛选。

我的场景是：____
我的约束是：____
我最怕的是：____
我偏好的是：____

输出：
- 领域地图
- 候选项长名单
- 候选项短名单
- 明显不适合的项目
- 最推荐的 1-3 个
- 为什么可能推荐错
- 我下一步该搜索哪些关键词

它不算神奇，但能防一个很常见的问题：AI 一看到你举例，就把例子当边界。

你说 Vuetify、Element Plus，它就找传统组件库。你说 Qt，它就找 Qt-like。你说 Nginx 替代，它就开始背 Traefik 的产品卖点。

它需要被强行提醒：例子只是线索，不是围栏。

又绕回 Agent 了

这件事最后还是绕回我之前那篇”推荐你使用 Agent”的想法。

现在 AI 工具对程序员和专业用户已经很好用了。你知道怎么拆问题、怎么写约束、怎么要求反证、知道什么时候该去 GitHub issue、npm trends、State of React、Reddit、B站和 YouTube 交叉验证，那 AI 会非常强。

但普通人——甚至只是”进入陌生技术领域的程序员”——不一定知道这些步骤。

所以真正缺的不是更聪明的模型，而是一个够好的产品经理，把这些流程藏进工具里。用户不应该先知道”搜索空间扩展”这个词，才能得到搜索空间扩展。不应该先知道”反证检索”这个词，工具才会帮他查坑。不应该先知道 shadcn/ui、Dear ImGui 这种关键词，AI 才能告诉他这些路线存在。

一个好的 AI 搜索工具应该能识别：你现在不是在问答案，你是在摸一个陌生领域的边。然后它应该先帮你把边界照亮，而不是在你手电筒照到的那一小块地方认真画地图。

总结一下

AI 搜索最大的问题，不是不会搜，而是太急着答。

技术选型里，答案质量不只取决于”推荐项对不对”，更取决于”有没有漏掉关键路线”。B站和 YouTube 推荐有时候能补上这个缺口，是因为它们擅长发现相邻圈层的热词——它们不管答案质量，先让你知道”还有这东西”。

而 LLM 的概率天性决定了它很难自发走到低概率的路径上去。这个盲区不是加个联网搜索就能解决的，它写在模型最基本的生成逻辑里。

所以最后就变成两件事同时做：

• 用 AI 做已有路线的评估和比较。
• 用推荐系统、社区、同行去发现你不知道你不知道的东西。

AI 不该替代发现入口，它应该升级成发现入口。

但在那之前，还是得靠我们自己多问一句：

你是不是漏掉了另一类答案？