 

## 一、一个下午的迷失

那是一个普通的周二。

我的屏幕上开着zed三个窗口。左边是 webapp 的项目，中间是兼职项目的前端代码，右边是自己折腾的小工具——一个试图用 Rust 写但进展缓慢的玩具项目。

三个项目，三种状态。webapp到了修改阶段，兼职有个 bug 要处理，玩具项目需要从另一份代码里抄一段逻辑过来。

我需要把这些项目重新排列。论文和兼职代码放在主屏幕并排，玩具项目扔到副屏幕偶尔瞟一眼。

我想把webapp移到新窗口。

于是我去找那个功能。

Recent projects 打开了。项目列表出现了。我的三个项目赫然在列。但，没有"移到新窗口"的选项。

我去菜单栏里翻。窗口菜单？文件菜单？视图菜单？都没有。

我打开了 threads sidebar。找到了。在一个线程的右键菜单里，藏着"在新窗口中打开"的选项。

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-11859176/c3e14b835498331599e05ca5a1469816.png)

我用了它。功能产生了效果。但一种说不清道不明的低落感留下来了。

不是功能不存在的问题。功能存在。是功能存在的方式有问题。

我把这种感觉记了下来。

---

## 二、功能的可发现性困境

这引出了一个有趣的问题：一个功能，如果存在但不易找到，它算存在还是不存在？

一方面，从技术的角度看，功能当然存在。代码写好了，合并了，发布了。你可以在 threads sidebar 里找到它，点击它，使用它。

从用户的角度看，功能的存在性却没那么确定。一个需要翻两层菜单、换一个界面才能找到的功能，对于那些不知道它存在的用户来说——它真的存在吗？

这就是软件设计中一个经典的张力：**功能的存在感**与**功能的可发现性**，往往是两回事。

我把这种张力称为**"功能可实现性困境"**——
为了实现一个功能，工程师需要把它放到某个地方。但那个地方，与用户预期它该在的地方，未必重合。

这个困境，你无法通过"多放几个地方"来解决。每个地方都有代价。每个菜单项都意味着视觉负担和认知负担。

但有时候，你必须这么做。

---

## 三、可发现性的边界

国外人做软件都比较强调设计的可用性（availability），里面其中一条就是从用户角度的易见性。

Zed 新版本在一个地方添加了这个功能：recent projects modal。

当你按下 cmd-shift-p，recent projects 弹出来。你看到你当前打开的项目。在每个项目旁边，现在多了一个按钮——"在新窗口中打开"。

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-11859176/9cb3fc0609fa3938ef0f4fda4d3136f5.png)

当鼠标放到项目上的时候，会出现一个向右上角的箭头，点击这个项目就会在新的窗口打开

![在这里插入图片描述](https://developer.qcloudimg.com/http-save/yehe-11859176/185f99086122034019d39cf954cbdefd.png)

这个改变看似微小。一个按钮，一个位置的变化。但它触及了一个深层的问题：功能应该出现在用户预期它出现的地方。

Recent projects 是用户管理项目的地方。用户在 recent projects 里看项目列表，这是"项目的管理界面"。把"项目相关的操作"放在"项目的管理界面"里——这是合乎直觉的。

然而，合乎直觉的设计，并不总是默认的设计。因为设计者有自己的视角。

这让我想起马奇在《经验的疆界》中讨论的一个论点：经验教给我们的，往往是我们已经知道的事情。设计者每天使用自己的产品，他知道功能在哪里，他的经验告诉他"这个功能是存在的，而且很容易找到"。

但一个新用户，没有这种经验。他的直觉告诉他"功能应该在 recent projects 里"。他的直觉没错。

问题在于：谁的经验，更接近真实的使用场景？

---

## 四、"低智学习"与"高智诠释"的类比

如果你允许我借用马奇的一对概念，我想说：用户寻找功能的方式，类似于两种学习模式。

**低智搜索**：用户不去理解软件的架构，不去记忆功能分类的逻辑。他只是在一个界面上找，找不到就去另一个界面找，直到找到为止。这是盲目但高效的——只要功能存在，最终总能找到。

**高智诠释**：用户试图理解"功能应该在哪里"。他会根据界面的名称、布局、功能分组来推断功能的位置。他会想："recent projects 是管理项目的地方，所以移动项目的功能应该在这里。"

两种方式各有优劣。

低智搜索鲁棒，但不高效。你总能找到，但你浪费了时间。高智诠释高效，但有风险——如果你的推断是错的，你会花更多的时间去修正它。

Zed 的这个改变，本质上是在做一件事：让"高智诠释"的用户，不必因为他们合理的推断而付出代价。

用户推断"移动项目的功能应该在项目管理界面"，这个推断是合理的。
以前，这个推断是错的。
现在，这个推断是对的。

一个微妙的改变，但它的意义超出了功能本身。

---

 

## 六、亦此亦彼的设计哲学

我必须承认：Zed 的这个功能，在 threads sidebar 里就已经能够使用。从"功能存在"的角度看，它已经满足了需求。

但从"功能可被发现"的角度看，它还有改进的空间。

亦此亦彼：
- 功能既已经存在（在 threads sidebar 中）
- 功能又需要被放在更明显的地方（在 recent projects 中）

这两种表述，都可以是对的。它们并不矛盾。

Zed 的选择是：承认两者都对，然后在两个地方都放上功能。

这种亦此亦彼的设计哲学，体现了一种认知：软件设计不是寻找最终答案，而是在多个合理的选项中，选择那个让更多用户更舒服的选项。

---

## 七、选择的能力

用户现在有了更多的选择。

Threads sidebar 里可以移动项目到新窗口。Recent projects modal 里也可以。两个地方，两种路径，同一个结果。

这不是冗余，这是多样性。

有人习惯用 sidebar——他继续用 sidebar。
有人习惯在 project list 里操作——他现在有了这个选项。
有人可能需要——但更多人可能不需要——拖拽的方式来管理窗口。

选择不是浪费。选择是自由。

当你不喜欢一条路径时，你可以走另一条。当你忘了另一条时，你可以走你习惯的那条。

马奇在讨论适应与创新的张力时说：组织需要稳定性来保持效率，也需要变化来保持活力。这两者不是取一个舍一个的关系，而是同时需要维持的平衡。

功能的位置，也是如此。

稳定性：已知的路径保持不变——threads sidebar 的功能还在。
变化性：新的路径被开辟——recent projects 现在也可以操作。

软体设计中的稳定与变化，在新的窗口图标里，取得了一次微小的平衡。

--- 

## 最后

文章写完后，我又去试用了几次这个功能。

它在我预期的地方。我按 cmd-shift-p，recent projects 弹出来，我点击那个按钮。窗口打开了。

预期的位置，预期的效果。

功能的起点就是这样——在你预期的位置，做你预期的事情。

一切都安静了。

软件设计的诗意，大概就在这种安静里。

我的屏幕上开着zed三个窗口。左边是 webapp 的项目，中间是兼职项目的前端代码，右边是自己折腾的小工具——一个试图用 Rust 写但进展缓慢的玩具项目。

Zed 全新效率技巧，效率++

开发工具

客户端

探讨软件功能可发现性与用户体验的微妙平衡。从Zed编辑器"在新窗口中打开"功能的位置调整出发，分析功能存在性与用户预期之间的张力，揭示优秀设计应同时满足技术实现与直觉体验。通过马奇的学习理论，阐释低智搜索与高智诠释在界面交互中的应用，提出"亦此亦彼"的设计哲学，强调选择自由对提升用户体验的重要性。

软件设计

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Zed 全新效率技巧，效率++-腾讯云开发者社区-腾讯云

Zed 全新效率技巧，效率++

Zed 全新效率技巧，效率++

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐