Zed 官宣支持Code Lens

"我们从未真正“编写”代码，我们只是在符号的痕迹中，与那些既在场又缺席的幽灵进行游戏。编辑器不是透明的媒介，它是一个差异的工场——当你输入 if时，else的幽灵已在空白处低语；当你定义一个变量，它的“意义”便永无止境地被引用链所延异。"

上周五晚上十点，我正对着一个陌生的函数发呆。这个函数叫 processUserRequest，名字很诚实，但诚实得有点过分——它到底被谁调用了？有没有测试覆盖？会不会是那个半夜三点报警的罪魁祸首？

我习惯性地按 Ctrl+Click 跳转到定义，然后开始手动搜索引用。五分钟后，我意识到：我在用2026年的编辑器，干着2010年的活。

直到今天，我在Zed的更新日志里看到一行小字：

Added LSP code lens support, disabled by default. Use "code_lens": "on" in settings to enable

也就是说：你的代码，现在可以"自言自语"了。

Code Lens是什么？不是魔法，是"上下文外挂"

先说结论：Code Lens不是新功能，但把它放进"快如闪电"的Zed里，味道就变了。

用官方文档的话说，Code Lens是LSP（Language Server Protocol）的一个扩展能力，允许语言服务器在代码行上方或下方插入"小标签"，显示额外的上下文信息。比如：

• 这个函数被引用了 12次
• 这个接口有 3个实现
• 这个测试用例 最后一次运行是2小时前
• 这个API端点 关联了5个前端组件

听起来像IDE的"基础操作"？没错。但关键在于：这些信息是"活"的——它们来自语言服务器的实时分析，而不是静态的索引。

我个人的理解是：Code Lens像是给代码装了一个"实时弹幕"。你写代码的时候，不需要主动去查"这个函数用在哪"，它自己会告诉你。

用海德格尔的话改编一下："工具的本质，是让存在者自行显现。" Code Lens让代码的"关系网络"自行显现，而不是等程序员去挖掘。

Zed的"克制"：默认关闭，把选择权还给你

这里有个细节很有意思：Zed团队特意强调，Code Lens 默认是关闭的，需要手动在设置里开启[[3]]。

{

"lsp":{

"code_lens":"on"

}

}

为什么这么做？我猜有两个原因：

1. 性能洁癖

Zed的核心卖点是"120fps的丝滑"。Code Lens需要语言服务器持续分析代码关系，如果默认开启，可能会影响那些"极致轻量"用户的需求。用产品经理的话说："我们可以给你火箭引擎，但你得自己决定要不要点火。"

2. 认知负荷管理

不是所有人都喜欢"信息轰炸"。有些程序员偏好"干净"的编辑界面，只在需要时才查看引用。默认关闭，等于把"信息密度"的调节旋钮交给了用户。

这让我想起自己早期的一个教训：曾经给团队引入一个"智能提示"插件，结果大家反馈"屏幕上全是红红绿绿的标记，根本没法专注写代码"。后来才明白：好的工具不是"给得越多越好"，而是"给得刚刚好"。

也可以通过界面直接设置 点击最右边的切换图标，选择Code Lens

在这里插入图片描述

实战体验：当"剧透"变成"助攻"

开启Code Lens后，我的日常编码流程发生了微妙的变化。

场景1：重构前的"风险预判"

以前重构一个函数，我需要：

1. 搜索所有引用
2. 逐个检查调用上下文
3. 手动评估影响范围

现在？函数名上方直接显示 🔗 12 references。点击一下，侧边栏列出所有调用位置。再点一下，直接跳转到对应代码。

在这里插入图片描述

最爽的是：我不需要离开当前编辑位置，就能完成"影响分析"。这种"原地洞察"的感觉，像是给大脑装了个"快捷键"。

场景2：写测试时的"覆盖率暗示"

给一个新函数写测试时，Code Lens会显示 ✅ 0 tests。写完第一个测试，它变成 ✅ 1 test。这种即时反馈，比跑完测试套件再回头看报告，心理激励强了十倍。

这里再透露一个开启code lens的技巧，直接在命令面板开启

在这里插入图片描述

写完测试后，还可以直接点击run test，在右侧直接查看测试结果

在这里插入图片描述

用游戏化的话说：Code Lens把"写代码"变成了"打怪升级"，每个小成就都有视觉反馈。

场景3：协作时的"上下文共享"

和同事一起看代码时，我不需要解释"这个函数很重要，因为被很多地方调用"。Code Lens的 🔗 24 references 标签，本身就是最直观的"重要性证明"。

技术细节：不是"加个标签"那么简单

如果你以为Code Lens只是"在代码上方加一行文字"，那就太小看它了。

1. 语言服务器的"深度参与"

Code Lens的信息来源是语言服务器（LSP）。这意味着：

• Rust的 rust-analyzer 可以显示 Implementations: 3
• TypeScript的 tsserver 可以显示 References: 12
• Python的 pyright 可以显示 Tests: 5 passed

每个语言服务器实现自己的Code Lens逻辑，所以信息的质量和丰富度，取决于你用的语言工具链。

2. "懒加载"的性能优化

Zed的实现很聪明：不会一次性加载所有Code Lens，而是只在可视区域内渲染。滚动页面时，动态加载新的标签，卸载旧的。

这种"按需供给"的策略，既保证了信息丰富，又不牺牲性能。用程序员的话说："我们不是不给你看，我们是'聪明地'给你看。"

3. 可交互的"小部件"

Code Lens标签不是纯文本，它们是可点击的。点击 🔗 12 references，会打开一个"引用列表"面板；点击 ✅ 1 test，可以直接跳转到测试文件。

这种"标签即入口"的设计，把"查看信息"和"执行操作"无缝衔接，减少了上下文切换的认知成本。

信息展示的"度"，是工具哲学的试金石

用了一段时间后，我逐渐意识到：Code Lens的价值，不在于"显示更多信息"，而在于"在合适的时机显示合适的信息"。

举个例子：

• 当我在写新代码时，✅ 0 tests 的标签会"温和地提醒"我写测试
• 当我在重构旧代码时，🔗 24 references 的标签会"严肃地警告"我谨慎操作
• 当我在快速浏览时，这些标签可以暂时隐藏，保持界面清爽

这种"情境感知"的信息展示，才是Code Lens的真正魅力。

反观一些工具的做法：把所有可能的信息都堆在屏幕上，美其名曰"信息透明"，实则造成"认知过载"。用自嘲的话说："我不是需要更多数据，我是需要更少噪音。"

工具如何塑造我们的"编码直觉"

人类的经验展示了一种认知智慧

"真正的熟练，不是知道所有答案，而是知道在哪里找答案。"

Code Lens的深层价值，或许在于：它把"查找信息"这个动作，从"主动搜索"变成了"被动接收"。

以前，我需要"意识到自己不知道"，然后"主动去查"。现在，信息会"适时出现"，帮我"意识到自己可能忽略了什么"。

这种转变，看似微小，实则深刻。它改变的不是工具，而是程序员与代码的"对话方式"。

结语：当代码学会"说话"，我们该学会"倾听"

写到这儿，我想起了一个古老的编程笑话："最好的文档，是代码本身。"

但今天，这个笑话有了新解：最好的代码，是"会说话"的代码。

Zed的Code Lens，不是要取代文档，不是要替代测试，不是要自动化一切。它只是轻轻地、适时地、在你需要的时候，告诉你一些你可能想知道、但还没来得及问的事情。