摘要
昨天我处理了一个接口授权问题。最开始它像是技术错误：某个发布相关接口无法调用。后来我发现，真正的问题不是接口失败，而是用户看到失败以后不知道下一步该做什么。
我最后把错误提示改成了一个可执行的引导：先判断账号状态，再解释可能原因，最后给出下一步动作。尤其是当账号本身不支持某项能力时，不再让用户继续翻菜单。
这篇文章讲的是如何把“报错”改成“用户能走完的路径”。
目录
- 接口错误为什么不能只显示原文
- 我先判断用户真正卡在哪里
- 为什么要先看账号主体
- 页面引导应该怎么写
- 长期收益
- FAQ
接口错误为什么不能只显示原文
很多系统的错误提示，其实只是把后端返回的话原样丢出来。
对开发者来说，这也许够用。看到错误码、接口名、权限信息，大概能猜到去哪查。但对普通用户来说，这些词没有路径感。他不知道问题是账号没权限、配置没填好、后台开关没打开，还是自己根本不该拥有这个功能。
昨天这个问题就是这样。接口名很技术，后台入口也有变化。如果页面只写“接口未授权”，用户会被迫去猜。
而用户一旦开始猜，体验就已经坏了。
我先判断用户真正卡在哪里
我把这个问题拆成几类原因。
第一类是账号主体问题。某些能力对不同主体开放程度不同，如果账号类型不满足，就不是配置能解决的。
第二类是认证状态问题。账号可能是企业主体，但没有完成认证，也会看不到相关能力。
第三类是配置问题。比如凭证、白名单、后台开发设置没有配好。
第四类是入口认知问题。用户可能已经打开了后台，但不知道该看哪个分类。
这几类原因不能放在同一个提示里混着说。应该先判断能判断的，再给下一步。
为什么要先看账号主体
这是昨天最重要的收获。
如果账号主体本身不支持某项能力，就不要继续引导用户去找菜单。因为他翻半天以后，只会发现根本没有那个入口。
这种体验很糟糕。系统明明可以提前告诉他“你现在不需要继续找这里”，却让他走了一圈。
所以我把引导顺序改了：先确认账号主体和认证状态，再讲接口权限。如果主体不满足，就直接告诉用户这不是一个配置问题。
这不是少给信息，而是减少无效动作。
页面引导应该怎么写
我希望页面提示能回答四个问题。
第一个问题：现在发生了什么？
第二个问题：最可能的原因是什么？
第三个问题：用户下一步去哪里看？
第四个问题：如果当前条件不满足，还能不能继续？
只要这四个问题回答清楚，用户就不会被错误码困住。
我也尽量避免在页面里堆接口细节。接口名可以保留给需要排查的人，但主文案应该用用户能理解的话说：这是某类发布能力，不是一个随便打开的普通开关。
长期收益
长期看，这种改动会让产品从“控制台”变成“助手”。
控制台把错误告诉你。助手会告诉你为什么错，以及你下一步该不该继续。
对内容发布系统来说，这很重要。用户来这里不是为了研究接口权限，而是为了把文章发出去。系统能多判断一步，用户就少走一段弯路。
FAQ
为什么不直接告诉用户去开某个接口？
因为有些账号根本没有这个能力。直接让用户去找入口，会制造无效操作。
技术接口名还要不要显示？
可以显示，但不应该作为主要说明。主说明要解释成用户语言。
这类错误最该前置什么判断？
账号主体、认证状态和配置完整性。这三项决定用户能不能继续。