简而言之： 自动补全假设「回复」主要是个打字问题。它通常不是——它是个决定问题。而且在搜索框里猜错只损失一次按键；在给主管的回复里猜错，损失的是一个你没选过的立场。所以我们做的是「词之前的那一步」，而不是词本身。
自动补全几乎是所有人给这类工具提的第一个建议，我们也明白为什么。你打半句，它替你补完。这是「AI 确实在干活」最直观的证据。
我们早期试过它的形态，然后停下来了。下面是理由——它其实解释了产品里大部分其他决定。
自动补全不才是最该做的功能吗？
是的。而且在很多场景里它就是对的选择——代码编辑器、搜索框、电子表格。那些领域的下一个词确实能从前面推出来，猜错也是免费的：你忽略它，继续打。
回复这两条都不成立。 下一句说什么，推不出来——因为它取决于一个还没做出的决定。而猜错也不免费——因为这些话是要发给一个人的，而他会记住。
所以那个最能展示 AI 的功能，恰恰站在流程上最错的位置：站在打字那一端，而不是决定那一端。
自动补全对「回复」做了什么假设？
三个假设，每个都不成立：
它假设难的是把字写出来。 对大多数难回的回复来说不是。词是最便宜的部分。真正花掉十分钟的是决定要不要答应、要不要拒绝、要不要要一点时间。自动补全让便宜的部分更便宜，而贵的那部分原封不动——这也正是为什么一份更快的草稿不会让消息变轻松，我们在按下发送前的那 12 分钟里试着讲过这件事。
它假设下一句能从上一句推出来。 在回复里，下一句取决于不在消息里的上下文：你认识这个人多久、你是不是已经错过一次期限、你愿意被什么人设绑住。一个替你把句子补完的模型没有这些，它会按最常见的模式来填——通顺、通用，而且有点不对。
它假设一个建议是容易拒绝的。 建议并不中立。一句话一旦出现在眼前，它就形成了锚：你此刻是在改别人的立场，而不是在挑自己的立场，而默认值就变成了「同意」。 这是「谁在做这个决定」的一次真实转移，只是伪装成了「方便」。
为什么在这里猜错代价更大？
因为这里的失败不是错别字。
在搜索框里，一个糟糕的建议代价是一次按键。在一条回复里，一个替你猜了日期、承诺或亲疏程度的建议会被发出去——而这下就成了一个你没做过的承诺，白纸黑字，给了一个会拿它来要求你的人。想撤回，就得再发一条更尴尬的消息。
而且这些错误是安静的。自动补全不会产出明显错误的话；它产出的是看似合理的话，而这恰恰让它难以审计。你得把每一个生成的从句都当成不是自己写的来读一遍——而认真读，比写还慢。
把这两点合起来，这个功能就有个奇怪的属性：它对的时候省时间，错的时候花掉的时间比省下来的还多，因为你现在得去核对。对一个「唯一目的就是减轻回复分量」的工具来说，这是一笔坏买卖。
那我们做了什么？
不是「少用 AI」。是把 AI 对准另一个时刻。
- 先读懂处境。 温和还是坚决、简短还是详尽——早一点、明白地说出来。这一步定下来，后面大部分的方向拉扯就消失了。
- 给方向，不给结论。 当一条回复可以合理地往三个方向走时，你看到三个方向，一键选一个。你仍然在做决定；你只是不再独自、无提示地做这个决定。
- 不知道就问。 如果日期或数字只有你知道，它应该停下来问，而不是编一个。这是为什么它不确定就问你，而不是编一个和你不需要更聪明的 AI，你需要一个会问的里的整套论证。
- 从不替你发送。 你决定，你发送。这个工具没有任何代你回复的能力——这是让其余一切都值得信任的那一条保证。
这套设计的代价是真实的：在那些「自动补全本来会猜对」的场合，它更慢；而且它会问你一些你有时不太想回答的事。我们认为，对要发给一个人的话来说，这个交换是对的。 很多工具不会同意——而对某些类型的写作来说，它们不该同意。
以后会加自动补全吗？
不会做这里描述的那种形式——在你朝一个人打字的时候替你把句子补完。那会把工具放回决定的错误一侧，而这套设计存在的意义正是为了避开这一点。它不是我们「暂时没排上」的功能，而是我们认为属于另一种工具的功能。
我们更愿意被信任，而不是被觉得厉害。加入等候名单——BreatheReply 是一个 Windows 桌面应用：先读懂处境、给出方向，遇到只有你知道的事实时会停下来问你。它从不替你发送：你决定，你发送。