Slack 新富文本输入框为何令人抓狂：一场 WYSIWYG 与 Markdown 的用户体验之争

本文剖析 Slack 新版 WYSIWYG 输入框的致命交互缺陷——从连字符解析到光标定位，揭示富文本编辑器在工程可用性上的灾难性失败，并探讨 Markdown 心智模型的不可替代性。

背景：一场悄然上线的交互革命

2019年11月初，Slack 开始分批向用户推送其 Web 界面的全新“所见即所得”（WYSIWYG）文本输入框。截至本文发布（11月20日），该功能已覆盖作者参与的多个工作区。表面上看，这不过是一次常规的界面升级；但对重度用户而言，这无异于一场日常沟通习惯的强制拆迁。

更令人沮丧的是，Slack 官方在 Twitter 上的回应明确表示：没有提供回退到传统 Markdown 编辑模式的选项。如果你习惯了用 包裹代码、用 * 强调文字，那么抱歉，请适应新纪元。

核心问题：不是“不习惯”，而是“不可用”

普通的界面改动，顶多让用户需要一些学习成本；但 Slack 这次的新输入框，存在大量连“编辑”都做不好的基础性缺陷。这些不是“我打错了一两个字符导致渲染异常”的小问题，而是“我找不到任何办法恢复格式，除非删掉整条消息重打”的灭顶之灾。

缺陷一：反引号（Backtick）的解析逻辑错乱

在 Markdown 中，当你输入：

when you do foo() it foos the bar

渲染结果自然是你想要的：when you do foo() it foos the bar（其中 foo() 为等宽字体）。

但在这个 WYSIWYG 编辑器中，同样的输入序列，显示结果却变成：

when you do `foo() it foos the bar.

注意，闭合的反引号没有被识别！开头的那一个反引号被当成了孤立的转义符，而结尾的闭合反引号似乎被丢弃或误读。用户如果想要正确显示，必须打完闭合反引号后手动按一下右方向键（将光标从一对反引号内部移出到其右侧，再输入空格），才能触发编辑器对代码片段的重新解析。

对于一个有着数十年 Markdown 输入肌肉记忆的用户来说，这种反人类的操作无异于要求一个熟练打字员每次输入完句号后都要额外敲击一次 Ctrl 键。

缺陷二：光标在代码跨距内的“穿越”失效

更糟的还在后面。假设你已经成功让 foo() 正确显示了代码格式。这时（在按回车之前）你发现，你其实想输入的是 bar.foo()，而不是 foo()。

在旧版 Markdown 接口中，逻辑很简单：按左方向键，把光标移动到 foo 的字母 f 前面，然后键入 bar. 即可。编辑器的行为完全可预测——它只是把 bar. 插入到了文本流中。

但新版 WYSIWYG 编辑器表现如何？即使光标在字符 f 前时，界面清晰地显示光标位于代码片段内部（具有该片段格式的视觉反馈），你键入 bar. 后得到的结果却是：

when you do bar.foo() it foos the bar

没错，你输入的文字竟然出现在了代码片段之外（即等宽字体的范围之外），而反引号也被重新显示了出来，仿佛编辑器在你输入时暗中将光标“弹”出了代码段边界。

作者推测，目前唯一能在代码片段开头插入文字的办法是：用鼠标选中该片段的首个字符，然后直接键盘输入覆盖它——这样新输入的文字才会被赋予该片段的现有格式。而这种操作方式，对于经常在代码中修正函数名的人来说，简直是一场灾难。

缺陷三：多下划线（__）被误判为斜体嵌套

作者是 C++ 程序员，熟知在代码中 __self、_private_member 之类的命名法十分常见。在 Markdown 中，两个连续下划线内嵌的文本通常用于加粗或者保留原样（取决于具体实现），但这打破了 WYSIWYG 的“所见即所得”假设。

作者给出一个具体的例子：往新输入框里输入：

increment self._private_member by one

期望的渲染结果是清晰显示代码片段内容 self._private_member。令人气愤的是，WYSIWYG 编辑器会将其渲染为：

increment <code>self.<i>privatemember\ by one

编辑器把 _private_ 首尾的两个下划线当做了斜体控制符，并将这段文本渲染成了“斜体的等宽字体”。这在 Markdown 规范中（如群成员 Alexander Dupuy 指出的）技术上几乎不可能生成：Markdown 允许在斜体或加粗内部包含等宽字体，但反之（在等宽字体内部包含斜体）并没有合法语法。

这种渲染不仅破坏了代码显示，还直接打破了用户对输入内容的掌控感——用户根本无法通过常规 Markdown 手段生成这种字体效果，但编辑器却擅自应用了它。对于经常在代码中使用多下划线的开发者，这直接迫使他们在输入时提心吊胆，时刻警惕编辑器是否“自作主张”。

为什么作者说“我宁愿不格式化”

作者坦言，因为上述交互问题的困扰，他已经开始减少在 Slack 上使用格式化功能的频率——明明想要的是代码高亮，却宁愿直接打纯文本，不添加任何星号和反引号，只为维持持续顺畅的输入速度。这是一种典型的“效率自我保护”：当错误发生的成本高于格式化带来的价值时，用户会选择放弃功能。而这，恰恰是产品设计中的最大警告信号：当用户被迫放弃你这新功能的初衷来避免它带来的阻碍时，这个新功能就是失败的。

跨浏览器差异与“侥幸”心理

有趣的是，作者最初发布这篇文章时，只是在自己常用的 Safari 浏览器中验证了前两个 bug，并未料想其在 Hacker News 上会大火（拿到2776分和上千条评论）。之后，他在 Chrome 上再次测试，发现了令人意外的结果：

1. 第一个反引号 bug：在 Safari 上复现，但在 Chrome 上则不会发生；而且 Safari 中需要按右方向键而非额外空格键才能触发修正。
2. 第二个光标 bug：在两个浏览器里都能复现，这证明其交互逻辑在结构上是错误的。
3. 第三个下划线斜体问题：在 Safari 和 Chrome 中均能复现。

这种跨浏览器的差异加深了问题的严重性。一个跨平台的企业协作工具，如果在不同的浏览器上交互行为都截然不同，那对于跨团队协作（有人用 Chrome、有人用 Safari）来说就意味着：同样的输入操作在不同同事眼里会呈现完全不同的结果，造成沟通混乱。

不完全的“胜利”：迟来的偏好设置（12月3日更新）

在文章持续发酵后，Slack 终于在 2019年12月3日于浏览器版本中新增了一个选项：Preferences → Advanced → Format messages with markup（写作设置 → 高级 → 使用标记格式消息）。

这看起来是一种妥协，但细究之下依然充满槽点：

• 设置的作用域是每个工作区：你在工作区 A 设置了，切换到工作区 B 需要重新设置，全局偏好不生效。
• 只影响浏览器端：即使你在 Web 网页里关闭了该选项，Android 移动应用依然强制使用 WYSIWYG 界面。
• 移动端的高级设置中，根本没有找见 Markdown 相关选项。

这带给用户的体验依旧是支离破碎的。我们不禁要问：为什么一个声称“为用户提高工作效率”的工具，其底层的格式输入模型却要如此抗拒 Markdown 这个被开发者社群广泛验证有效的标轻记语言？

技术本质：为什么 WYSIWYG 不如 Markdown？

如果你从未写过代码，或许会觉得 WYSIWYG 是一种更“友好”的输入方式。但仔细分析此次 Slack 的失败案例，我们能触及一个更核心的技术层面的认知：

Markdown 的本质，是把“语法”和“语义”的绑定完全交给用户。 用户输入的每一个字符，都在字面上忠实反映了文本的结构。无论光标在哪里，用户永远知道退格键会删掉什么。

而 WYSIWYG 编辑器通常后台维护一个 DOM 树或文档对象模型（如 Slate.js），并且试图在用户输入时实时猜测用户意图。它通过监听输入事件、重排节点结构来实现“格式化即时生效”。但问题是：当一个用户的输入样式是非标准（下划线作为代码段一部分），或是在代码段内编辑、光标定位时，富文本编辑器的自动格式化算法就会轻易地猜错方向（如把闭合反引号归属错节点、或在光标穿越内联格式边界时误建新节点）。更重要的是，一旦猜错，系统不会给用户任何可作用的“字符串”来修正，因为格式已经变成了不可见的元数据。

因此，对于大量依靠符号输入的开发者群体，Markdown 实际上是可预测的、纯文本的安全协议；而 WYSIWYG 是“所见即所得”的谎言——它让你在没有掌握内部规则的前提下，想当然地进行输入操作，却隐藏了实际执行逻辑。

产品建议：一个合理的“回退”按钮

作者的核心诉求其实相当朴素——至少在当时（包括不少 HN 评论者），他想要 Slack 提供一个简单的开关（禁用 WYSIWYG，回退到纯 Markdown 输入），即可解决上述几乎所有的痛点。但 Slakc 的固执还在于：一旦全新的编辑内核上线，回退到旧的 Markdown shell 可能需要额外的“语法解析+叠加层”的开发，这间接承认了团队对新交互设计的失败。因此，产品方宁可用一个复杂的“格式消息”偏好设置去安抚部分用户，也不愿撤销发布。

从现代软件工程实践角度，我们可以总结出的教训是：

• 对于重度用户仍依赖文本符号输入的场景（如聊天、开发协作），引入 WYSIWYG 前必须确保“所见即所得”的底层交互模式 100% 覆盖所有 Markdown 的转义与嵌套情况，否则宁可暂时不做。
• 任何编辑器升级都应提供保留传统模式的“功能开关”，直到新模式的错误率与效率能够达到旧模式的水平。
• 当基础交互（打字与光标定位）被破坏到“无法编辑”的程度时，仅提供一个“关掉完整预览”的设置是远远不够的；需要真正回退到一个纯文本环境。

结语：我们想要的只是打字如飞

这起发生在 Slack 身上的典型事件，其实并非孤例。从 Discord 的插入框到 GitHub 的 Markdown 编辑，再到各类笔记软件，无数产品试图将富文本编辑的“便捷”强加给文字工作者，却忽略了“盲打直达”的核心用户需求。

对于开发者而言，输入框应当是一块透明玻璃，而不是一扇藏有房间布局的暗门。如果有哪一天，必须考虑“输入完反引号后还得按右箭头才能保存格式”的话，那这个工具早已失去了存在的意义。

作者作为软件工程训练领域的资深讲师，用自己真实的输入障碍，把产品迭代的傲慢与代价摆在了所有技术决策者的桌子上：请把选择权还给用户。

原文链接：Slack’s new WYSIWYG input box is terrible