当软件学会说话

Source: Dev.to

Introduction

人们并不会爱上技术。
如果你真的参加过一次用户入职培训——真正坐下来，而不是事后只匆匆看一眼幻灯片——你会注意到一种节奏。

• 一个人点击。
• 停顿。
• 再次点击。
• 犹豫。

那种成年人在不确定自己是否错过了显而易见的东西时的犹豫。随后是一抹小小的、带歉意的微笑。培训师介入，几乎凭记忆般顺畅地解释。用户点头。不是因为他们突然明白了，而是因为他们想继续前进。

如果你坚持足够久，就会看到这些时刻是如何累积的。

• 这里有一个细微的纠正。
• 那里有一个澄清的按钮标签。
• 一个被误解的流程再次用稍微不同的措辞解释。

没有戏剧性。没有出现在仪表盘上的数据。只有摩擦。几乎不可见，却始终存在。

后来，你会在支持队列里听到：

“我们能快速通个话吗？”
“我在哪里可以找到…？”
“我以为这意味着…？”

你也会在内部 Slack 频道里听到。如果你沿着这条路走得够远，最终会触及真实的成本。

一旦你看到它，最令人惊讶的是这种模式的普遍性。每个供应商、每个工具、每个平台都会围绕产品构建一个平行的解释宇宙，因为产品本身无法说明它是什么、能做什么，或用户接下来该做什么。这就是我们拥有庞大的文档门户、入职视频、知识库、AI 聊天窗口以及每天重复同一句话的耐心培训师的原因——整个解释生态系统围绕着我们很少承认的单一事实：大多数企业应用无法自行说明。

The Silence of Self‑Unexplaining Systems

一旦你开始注意到无法自我解释的系统的沉默，就再也无法忽视。你会在任何地方都认出它，甚至在巨头中也是如此。

SAP

你可能会期待这样规模的公司，拥有数十年业务软件经验，会把解释编织进其应用的结构中。然而即使是他们最现代的界面也把负担推向外部：帮助门户、覆盖层、文档中心。

Salesforce

Salesforce 也呈现类似的模式，只是以不同的形式出现。需要解释生态系统的原因在于产品无法自行阐述其结构。

Atlassian

Atlassian 的文档几乎拥有自己的引力场。即便如此，当有人站在 Jira 中尝试理解为其团队专门构建的工作流时，解释却在别处——在另一个标签页、另一个空间、另一个曾经被写下并由他人尝试维护的故事中。

这些公司都用巨大的资源和截然不同的策略来解决同一个问题。

A Glimpse from the Past: Eclipse RCP

在今天的 SaaS 浪潮、云时代以及模块化前端框架出现之前，有一段短暂的时光有人几乎破解了这个难题。Eclipse RCP，插件化企业工具的元老，曾把帮助视为一等公民。这是一个可能的世界的曙光：软件不需要一大堆解释陪衬，因为它能够自行说明。但行业向前发展，Web 应用接管了舞台，软件自我描述的理念从未真正走远。

Rethinking Help as Architecture

今天我们仍在承受这种缺失的残余。也许帮助并不是文档，而是基础设施。

如果帮助——我们一直视作事后补充的东西——本应是架构的一部分，会怎样？这个想法悄然出现，几乎像是我们刚刚走过的所有内容的余像：

• 入职培训中的犹豫。
• 培训师的重复。
• 围绕产品的庞大生态系统——门户、指南、教程、AI 助手——如同围绕一颗无法自持重力的星球的月亮。

如果帮助仅仅是内容——文字、图表、答案——那么更多内容早该解决问题了。但摩擦仍在，漂移仍在，安静且持续的成本仍在。

The Missing Meta Layer

几乎所有其他架构关注点都有自己的层：

• 数据 → 模型
• 逻辑 → 服务
• 边界 → API
• 状态 → 存储
• 布局 → 组件
• 通信 → 事件
• 执行 → 流水线
• 导航 → 路由

但当涉及帮助人类理解系统是什么、屏幕意味着什么、功能做了什么、某个操作如何融入更大图景时——没有层。只有一个空白，业界学会用文字去填补。这就是解释总是出现在应用之外的原因。

当你意识到这一点，之前的那些时刻——用户的犹豫、支持电话、庞大的知识库——就会有不同的视角。它们不再是沟通失败或培训不足的表现，而是架构缺失的症状。产品的沉默从来不是内容问题。

Envisioning a Structural Help Layer

如果你把帮助视为结构性的而非补充性的，那么缺失的形状会更加清晰。系统已经对自身了解颇多：

• 你所在的模块。
• 你正在查看的客户、发票、工单或工作流。
• 你是处于概览还是详情页面。
• 哪些操作可用，哪些被禁用。
• 哪些字段是必填，哪些状态有效，哪些转换合理，哪些会违反业务规则。

所有这些知识在应用内部脉动，悄悄指示系统能做什么、不能做什么。然而，这些信息从未被用来向屏幕另一侧的人类解释任何东西。应用生活在完美的内部清晰中；用户则在外部的猜测中摸索。两者之间缺少一层——一层能够像 UI 框架一样深刻理解应用结构的层。

What This Meta Layer Would Do

• 描述当前上下文：“你在这里。这块区域的功能是什么。接下来你可以做什么。”
• 随代码一起演进，在每次发布时更新，并随配置变化而适配。
• 使用模块和功能的语言，而不是文件和文件夹的术语。
• 提供一种原生、运行时集成的方式，让系统能够定位并安抚用户，轻声说：“我知道你在哪儿。我知道这意味着什么。让我给你展示。”

它不会取代培训师、支持团队或入职专家，但会赋予系统自己的声音——让它能够在不依赖外部、手动维护文档的情况下，引导用户。

Conclusion

一旦你想象出拥有这样一层的软体，想法几乎变得显而易见。功能最贴切、最准确的解释应当存在于实现它的代码内部，而不是通过英勇努力维系的平行宇宙中。然而我们尚未以这种方式构建系统——还没有。

因为缺失的元层把负担强加在人类肩上——培训师、支持团队、入职专家——他们手动完成本可以由软件自动承担的工作。引入结构化的帮助层可以把这份负担重新转回系统本身，使其能够自行说明，并最终帮助用户理解他们自己。