帮助入口需就近于问题发生处
别名: 帮助入口 · 就近帮助 · 上下文链接 · 切换成本
概念解释
帮助入口（contextual help entry）应出现在字段、错误、空状态、权限提示或复杂决策旁边，并预载当前对象、角色、版本和错误上下文。全局帮助中心仍是必要基础，但不能要求用户离开失败现场重新描述问题。这一条和同组另外两条分工明确：前两条决定"要不要文档""文档怎么组织"，这一条决定"用户站在问题面前时，那扇门开在哪、门里带着多少他已经不用再重复的信息"。
机制
从界面某个具体位置进入帮助时，系统其实已经掌握了大量诊断所需的信息：用户在哪个页面、选中了哪个对象、报错文案是什么、当前账号的角色和权限是什么。这些参数如果能自动带进帮助入口，就能把一篇本来适用范围很宽的长文档，直接缩小成只包含当前场景的那一段——用户看到的不再是"发票管理"这篇总览，而是"你此刻遇到的这个权限报错该怎么处理"这一段。反过来，一个远离问题现场的全局帮助入口，会强迫用户完成三次翻译：把界面上看到的现象翻译成文字描述、把这段描述翻译成检索词、再把搜到的通用答案翻译回自己当前的具体情况。这三次翻译中的任何一次出错，用户都可能查到不适用的答案却信以为真。就近入口把这三次翻译省掉，也顺带降低了用户中途放弃、转而回到界面里瞎试的概率。
边界
入口不是越多越好，密度过高本身会变成视觉噪音，让界面看起来处处都在提示"这里有问题"。低风险、容易理解的字段适合用悬停提示或可折叠的说明，把帮助做得克制；只有高后果的错误和真正复杂的决策点才值得放一个显式的、常驻可见的帮助链接，这是一个需要按风险分级、而不是统一处理的设计判断。安全与隐私场景可能限制把完整上下文自动传递给帮助系统或第三方支持工具，比如包含个人数据的字段值不能原样带入求助链接，这种情况下需要先做脱敏，只传递能定位问题类型的部分。此外，移动端小屏幕、屏幕阅读器的线性阅读顺序、以及被内嵌在第三方系统里的帮助面板，都需要单独验证入口是否可达、打开后能否顺利返回原任务，这几类环境下常见的失效是帮助面板打开后覆盖了原始表单，用户找不到回去的路。
怎么落地
- 为错误提示、空状态、权限不足提示和高复杂度字段各自配置帮助链接，并自动携带当前对象、版本和错误码作为上下文参数。
- 打开帮助内容时明确高亮当前适用的版本与角色范围，避免用户读到不适用自己账户的步骤；返回原界面时保留之前已经填写的内容和滚动位置。
- 从错误提示直接链接到对应解决方案，并提供一键创建支持请求的入口，请求自动附带脱敏后的诊断信息。
- 验证办法：分别在键盘导航、触屏、页面缩放和弱网条件下检查帮助入口是否可被发现、点开后是否可用，以及返回任务后原有输入是否完整保留，四种条件中任意一种丢失内容都算未通过。