背景
Zed 近期的一项新特性解决了一个看似微小却每天都在折磨开发者的问题：当你用文本查找器定位到某个匹配项、编辑完文件、再重新打开查找器时，上一次的搜索词丢失了——取而代之的往往是光标下某个毫不相干的单词。这次改进的核心，是重新排序了搜索框 query seeding 的优先级，把"上次查询"提到了"光标下文字"之前，并且把过滤条件也一并持久化。
改动前的优先级：
- 活动项目搜索查询
- 活动缓冲区搜索查询
- 选中文本或光标下文字
- 空
改动后：
- 活动项目搜索查询
- 活动缓冲区搜索查询
- 选中文本
- 上次查询（按项目持久化）
- 空
同时，团队明确提到：“JetBrains makes the same choice, entirely ignores word on the cursor for seeding query.” 这不是拍脑袋的决定，而是对成熟 IDE 设计哲学的致敬。
JetBrains IDEA：让工具记住你的意图
JetBrains 家族（IntelliJ IDEA、PyCharm、WebStorm 等）的做法很有意思。它们完全忽略光标下的单词，搜索框重新打开时要么保留上次的查询，要么显示选中文本（如果你确实选中了一段文字）。这背后的产品哲学很清晰：搜索是用户主动发起的意图表达，不应该被被动的光标位置所干扰。
在 IDEA 中，“搜索-编辑-再搜索"的循环非常顺畅。你可以在 20 个文件中找到所有TODO标记，逐个修改，每次重新打开查找框时它都记得你在找TODO。这种体验的核心不是"方便”，而是尊重用户的任务连续性。
更重要的是，JetBrains 的搜索过滤条件（正则、大小写、全词匹配）同样被持久化，甚至跨会话。你上次开了正则搜索，下次打开它还在。这种一致性降低了认知负荷——你不用每次重新确认"我现在是不是在搜正则"。
idea还有一点做的很好的是支持查看搜索的历史
只需要使用快捷键alt 下箭头
据说vscode也可以使用整个快捷键查看历史列表，但是实际上似乎并没有。
Zed 为什么选择跟随 JetBrains
Zed 作为一个用 Rust 编写、追求极致性能的新锐编辑器，它的产品决策一直都很"较真"。这次新特性的选择不是简单的"抄 IDEA"，而是对工作流连续性的深刻理解。
在代码审查、批量重构、追踪引用等场景中，开发者真正需要的是维持一个持续的搜索上下文。光标下的单词在绝大多数情况下只是"噪音"。Zed 的开发者说出了非常精准的一句话：“After editing, the cursor is usually sitting on an unrelated word, and previous search was lost.” 这就是每天在发生的真实场景。
把"上次查询"持久化到项目级别的数据库中，意味着即使关闭项目、过几天再打开，搜索上下文依然在。这种设计把搜索从"一次性操作"升级成了"项目状态的一部分"。
JetBrains 走的是**“尊重用户意图"路线**：你告诉我什么我就记住什么，我不瞎猜。搜索框是你的工具，不是我的展示台。这种保守策略在智能化时代看似"不够聪明”，但在高频操作场景中反而更可靠。
Zed 选择站在 JetBrains 这一边，我觉得是正确的。对于一个定位为"专业开发者编辑器"的产品来说，可预测性比聪明更重要。你永远不知道 VSCode 下次打开搜索框时会塞给你什么词，但你知道 Zed（和 IDEA）会忠实地记住你上次搜过什么。
当然，这次更新也引发了一个有趣的后续讨论：yara-blue 提出可以更进一步，做"可恢复的 picker"——不是记住查询再重建，而是压根不让 picker 真正关闭，只是隐藏起来。这有点像某些浏览器的"恢复关闭的标签页"设计。这个方向如果落地，搜索体验会再上一个台阶。
结语
这次新特性改动不大，却触及了编辑器设计的核心问题：工具应该在多大程度上"帮助"用户？VSCode 的答案是"尽可能多"，JetBrains 的答案是"只在被明确要求时"。Zed 选择了后者。对于每天要进行几十次搜索操作的开发者来说，一个不会随意篡改你查询内容的搜索框，可能比十个智能提示都更有价值。
