我曾经在 Orvia Mail 里面做过一个任务管理器。
它确实能工作：可以把邮件变成任务、追踪截止日期，还能让工作留在应用里。
后来我把它删了。
我也做过一个现在似乎每个软件都想拥有的 AI 聊天框。它同样能工作，我也把它删了。
这两个功能都没有崩溃，也没有测试失败。我删除它们，是因为它们已经好到足以留下；而留下它们，会改变 Orvia Mail 原本要成为什么。
几年前，开发时间还会充当一道粗略的筛选器。做一个功能需要足够久，我必须在动手前先证明这个想法值得做。
AI 编程工具改变了这个顺序。
现在，我可以在一天里试几种布局，重写一部分数据流，或者把草图变成可运行的测试，而这时我甚至还没完全决定产品是否需要它。
这种速度很有用。它也会让本来不够好的想法活得比应有的时间更久。
以前，一个薄弱的想法看起来很昂贵。现在，它看起来可能只需要一个下午。
可运行的代码只是第一笔成本
一个只需要一天就能做出的功能，可能会留在应用里很多年。在这段时间里，它需要界面中的位置、清楚的文字、翻译、测试、支持，以及 macOS 或邮件服务发生变化时的修复。
它还会改变人们理解产品其他部分的方式。
每一个永久存在的控件都会索取注意力，即使用户从来不点击它。人们仍然要看见它，弄清它做什么，再判断它和眼前这封邮件有没有关系。
一个按钮很容易被原谅。按钮足够多之后，简单的应用就会变成一组用户从未要求做出的选择。
邮件本来就要求人们一整天反复做几种小决定：阅读、回复、归档、删除，或者稍后回来。我不希望用户还没处理邮件，就先面对应用增加的一轮选择。
在 Orvia Mail 里，邮件在左侧。右侧会随着内容改变。
会议邀请可能显示日历操作。验证邮件可能把验证码放在触手可及的地方。收据可能显示真正重要的细节。很多邮件在右侧什么都不需要。
这比加一排固定按钮需要更多工作。固定工具栏容易构建，也容易解释；根据内容变化的操作则需要规则、仔细处理边界情况，以及克制。
屏幕之所以更简单，是因为我在用户打开邮件之前先替他们做了更多判断。
先让窗口安静，再让它变小
设计主窗口时，我做了同样的判断。
第一个版本采用了很多桌面邮件客户端都有的三栏布局。后来我问自己：Orvia Mail 真的需要三栏吗？
并不需要，所以我把它减成了两栏。
隐藏仍然要容易找到
后来，我又对侧边栏问了同一个问题。
它需要一直可见吗？用户阅读邮件时，里面的账户、文件夹和筛选器是否需要一直争夺注意力？
我认为不需要，所以现在 Orvia Mail 默认隐藏侧边栏。
这带来了另一个问题：我隐藏的任何东西，都必须在用户需要时仍然容易找到。
从界面里删掉一部分很容易。让它消失，同时又不让它变得难以触达，才是真正的设计工作。
任务应该属于提醒事项
起初，任务管理器看起来像一个显而易见的功能。
邮件里有很多工作：客户要求周五前回复，发票有截止日期，预订属于日历。把这些都留在邮件应用里，听起来很高效。
然后我把它做出来了。
第二个事实来源
这个功能很快就开始要求更多东西。它需要任务列表、优先级、重复任务、完成状态、筛选器、通知和同步。
这条路最后通向的是又一个需要用户维护的任务应用。
用户得先决定一项任务应该放在 Orvia Mail、提醒事项、Things、Todoist，还是他们已经使用的其他系统里。他们还得记住最终版本究竟在哪个应用中。
我解决了第一次点击，却创造了第二个事实来源。
让系统应用拥有任务
macOS 已经有成熟的应用负责这件事。Apple 允许应用通过 EventKit 创建和编辑日历事件与提醒事项。提醒事项可以使用 iCloud、Microsoft Exchange、Google、Yahoo 和 AOL 等账户。日历也可以使用互联网账户和 CalDAV。这样，任务或事件就能跟随用户已经选择的账户，而不是困在邮件客户端里。[1]
所以我保留了邮件真正擅长的部分。
Orvia Mail 可以识别邮件中的行动。用户也可以选中一段确切的文字，把它变成任务，然后由 Orvia 添加到提醒事项。
日期、会议和日程交给日历。
Orvia 理解邮件并完成转交。提醒事项拥有任务，日历拥有日程。
用户不必学习另一套任务系统，也不必猜哪一个列表才是最终版本。
我不认为一个应用应该拥有用户一天里的每个部分。Orvia Mail 应该把邮件做好；提醒事项负责记住；日历负责安排。
做任务管理器，让 Orvia 在功能表格里显得更完整。
删掉它，则让产品更诚实。
我不想让 AI 变成收件箱
AI 聊天框更难删除，因为它看起来像市场正在前往的方向。
Google 把 Gemini 摘要和写作工具放进 Gmail。Microsoft 给 Outlook 加入了 Copilot 聊天，可以回答关于收件箱和日历的问题。连接之后，ChatGPT 也可以在判断内容相关时自动参考 Gmail。[2]
这些产品指向同一个方向：收件箱变成通用 AI 助手可以使用的一大块上下文。
这可能很有用，但它也会改变产品的中心。
在普通邮件客户端里，用户打开邮件、读完，然后决定要做什么。
在 AI 驱动的收件箱里，用户从一个提示开始。模型决定哪些邮件重要、显示哪些部分，以及建议什么动作。
越宽的问题，需要越广的访问
如果有人问：“我上个月答应这个客户什么了？”模型需要的不只是当前屏幕上的邮件。它可能要搜索几个月的邮件、已发送邮件、附件、联系人和日历事件。
在一个主流实现中，OpenAI 说明，连接的 Google 应用可能会创建索引副本并同步内容，让 ChatGPT 提供更相关的答案。[3]
对于明确希望 AI 代理管理收件箱的人来说，这可能是合理的选择。
我不希望它变成打开邮件应用时必须支付的安静成本。
让 AI 出现在需要它的地方
我删除聊天框还有另一个原因。ChatGPT 和其他通用 AI 产品，本来就是通用 AI 产品。如果有人想让 AI 助手处理整个收件箱，那些产品大概会比一个缩小后放进邮件客户端的复制品做得更好。
Orvia Mail 不需要模仿它们。
它仍然会使用 AI。很长的邮件线程可能需要摘要。另一种语言的邮件可能需要翻译。粗糙的回复草稿可能需要帮助。
两行的邮件不需要这些。
一封私人便笺也不需要旁边永久坐着一个 AI 面板。
用户主动请求，或者邮件明显受益时，工具才出现。任务结束，它们就离开。
AI 在 Orvia Mail 里扮演辅助角色。它不会变成收件箱。
有些人仍然希望打开一封邮件，直接读完，再自己决定。我也在为他们做产品。
一个产品不必因为聊天框流行，就围绕聊天框重新组织自己。
一个月的检验
在做一个功能之前，我会问：这个问题出现得有多频繁，谁会遇到它，以及功能发布后会制造多少工作。
它需要新的设置吗？
它会增加一步吗？
一年后，我还会理解它为什么存在吗？
然后我会问那个最帮助我的问题：
如果它需要一个月，我还会做吗？
AI 会让一个薄弱的想法显得无害，因为第一版花不了多少时间。想象它需要一个月，会迫使我判断问题本身。
它是刹车，不是答案
有些决定我仍然会做错。
一个功能看起来很小，可能变得重要；另一个功能可能连续三天都显得不可或缺，之后却一直无人触碰。
这个问题不会直接给我答案。它只会阻止我把“做得很快”当成“应该发布”的理由。
任务管理器和 AI 聊天框没有通过这次检验。
留下属于邮件的工作
有些功能通过了。
Exchange 和共享邮箱支持通过了。一个用户因为公司运行自己的 Exchange 服务器，无法在工作中使用 Orvia Mail。
这不是一个小的视觉改进。没有它，产品对那位用户就无法完成主要工作。
服务器搜索也通过了。
我不喜欢为了存放几万封很少打开的旧 Gmail 邮件而购买更多 Mac 存储空间。设置新的邮件客户端时，我只需要把最近的邮件存到本机，以便快速访问和离线使用。
几年前的邮件不必一直占据硬盘。需要搜索时，让它们留在服务器上就好。
邮件客户端不应该要求完整的本地归档，才能让旧邮件可被找到。
Safe Reader 需要隐私，也需要阅读节奏
Safe Reader 也是一个“要做”的答案。
我测试过的邮件客户端大多可以拦截远程内容，但很多产品就停在那里了。远程追踪被拦截了，订阅信却留下破碎的间距、空白区域、缺失的图片，以及无法脱离版式独立存在的文字。
隐私设置完成了自己的工作，阅读体验却没有。
我希望 Safe Reader 同时解决这两个问题：拦截可以追踪打开行为的远程内容，同时不让邮件变得更难读。
我花了很多时间研究如何移除这些远程部分，保留真正重要的内容，再用清楚的字体、间距、行长和视觉顺序重建邮件。
我研究了 Instapaper 等阅读应用，特别关注它们如何处理长文中的字体、行长、间距和层次，然后把这些想法应用到邮件上。邮件 HTML 的差异可能非常大，每个发件人的结构都不一样。
拦截追踪器只是工作的一半。
邮件本身仍然要值得读下去。
我仍然认为 Safe Reader 只完成了一半。
邮件 HTML 并不一致，每个发件人组织内容的方式都不同。一套对某封订阅信有效的布局，换到另一封上可能就会失败。
我会在测试更多邮件时不断调整规则。Safe Reader 已经不止于拦截远程内容，但它还没有达到我希望的标准。
Exchange 支持、服务器搜索和 Safe Reader 都会带来长期工作。
它们解决的也确实是属于邮件的问题。
这是我现在努力守住的边界。
发布之后，说“不”更难
功能一旦发布，就可能有人开始每天使用它。
一个小选项可能变成日常习惯的一部分。之后再删除它，可能破坏工作流或削弱信任，即使真正使用它的人并不多。
所以，在发布前说“不”很重要。
一个功能今天可以取悦一小群用户，同时给其他所有人增加一个要看很多年的控件。
测试版本也能回答问题
删除能运行的代码，有时仍然让人觉得浪费。设计已经完成，测试也通过了，功能甚至可能有用。
但测试版本可以回答一个有价值的问题，而不必变成正式发布的功能。
任务管理器回答了一个问题：Orvia Mail 应该帮助用户把工作移出邮件，而不是再创造一个管理工作的地方。
AI 聊天框回答了另一个问题：AI 应该在需要的地方出现，而不是接管主窗口。
这些答案值得那些代码。
Orvia Mail 还会继续成长。我希望每次发布解决的问题，都多于它要求用户学习的东西。
有时，这意味着花几天做一个功能，亲自使用它，然后在其他人看到之前把它删掉。
这两个功能都能工作。
Orvia Mail 更好，是因为它们从未发布。