
当你睁开眼睛而无人看你时,我曾渴望寻觅到你的目光
2026年7月中旬,Zed 新增了一个有趣的新特性,为 项目符号选择器 添加了一个实时预览窗格。当你在符号列表中上下移动选择时,右侧会立即显示该符号所在文件的代码。
这是一个看似顺理成章,实现起来却颇费周折的功能。它的出现,让 Zed 的符号搜索体验终于达到了了编辑器领域的一流水准。
在此之前,Zed 的项目符号搜索已经足够快。你按下 cmd-t(或 ctrl-t),输入部分类名或函数名,它能瞬间罗列出所有匹配的符号。但问题在于:列表里只有符号名和文件路径。
假设你搜索 getUser,返回了 10 个结果,分别来自不同的文件或不同的 struct 实现。你只能根据文件名和符号名去猜测,哪个才是你要找的那个。如果猜错了,就需要打开文件、关闭、再试下一个。
这种“试错式导航”让人心力交瘁,降低了模糊搜索本该带来的效率提升。感觉就像你跟一个人谈了一段时间恋爱之后发现他就不是你喜欢的那种人一样。

预览窗格解决的就是这个“确认”问题。当你选中一个符号,它的定义处代码片段会立刻展示在右侧。你不需要离开当前上下文,就能确认这个符号的上下文、甚至周围的代码,从而做出准确判断。

你只需要像text finder一样,点击下面的preview就可以开启预览

在 UI 设计上,Zed 保持了其一贯的克制:预览窗格并非强制显示,用户可以通过底部的按钮随时关闭它,回到纯粹的列表模式。这种“可选性”很重要,它尊重了不同用户的工作习惯,有些人可能更偏好简洁的列表,不希望被预览分散注意力。
这个 新特性的出现,引发了社区关于“编辑器应该提供何种程度的信息辅助”的讨论。
一位支持者指出,“预览窗格消除了记忆负担”。在大型代码库中,你不可能记住每个同名函数的具体参数。预览让你无需记住,只需辨认。这特别适合处理遗留代码或不熟悉的模块。
也有开发者表达了谨慎的担忧,他们觉得预览窗格可能增加 UI 的复杂性,分散对列表本身的注意力。他们对新增的“关闭预览”按钮表示欢迎,认为这是尊重用户选择权的体现。
在我看来,预览是“第二大脑”的延伸,项目符号选择器中的预览窗格,其重要性怎么强调都不为过。它代表了 IDE 类工具从 “被动响应查询” 向 “主动辅助决策” 的转变。
过去,工具负责“找到”信息,然后由用户的大脑负责“判断”和“整合”。预览窗格将“判断”这一步也前置到了工具中,让用户的大脑专注于更高层次的“创造”。这就像是在你的工作流中植入了一个微型代码审查员,在你做出选择之前,先帮你快速过目一遍候选者。
Zed 在这个功能上的实现,与其整体哲学一脉相承:快,但不止于快。它利用自身架构的优势,将预览加载的延迟降到最低,让这个“辅助决策”过程几乎感觉不到额外开销。这是 Zed 从一款纯粹的编辑器,向一个更智能的开发伙伴迈进的重要一步。
回到过去