微文案：按钮、报错与空状态怎么说

界面上的每一句话，都在替产品解释自己。

一、三句话，三次误解

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

闻笛做一款发票开具工具。上线第一个月，客服里出现三类反复的问题。

第一类：「我点了提交，但它没反应。」按钮写的是「提交」，点击后进入 loading，成功后按钮恢复原样。用户不知道成功了，于是再点一次。

第二类：「保存失败是什么意思？」报错写的是「操作失败，请重试」。用户重试了三次，还是失败——因为真正的原因是发票抬头超过 40 字。

第三类：「我的发票去哪了？」列表为空时写着「暂无数据」。用户以为自己开票失败了，实际是筛选条件默认选了一个空月份。

三个问题都不是功能问题，而是界面没有说清楚。微文案不是装饰，它是交互的一部分：按钮说明动作，报错说明原因，空状态说明现状。

文案问题的成本很容易被低估。三次误操作、三条客服消息、一个用户流失，单看都不大，加起来却是一个人的产品最难承受的负担——因为客服没有别人可以转交。

改文案是投入产出比最高的设计工作。 它不需要改代码结构，不需要重新测试布局，改完立刻生效。一个人做产品时，优先改文案，再考虑改界面。

二、按钮：动词优先，控制字数

按钮文案决定用户对「点下去会发生什么」的预期。

按钮要写动词，不写名词。 「设置」「选项」是名词，用户不知道点下去是打开面板还是立即生效。

按钮要写对象，不只写动作。 「保存」不如「保存发票」，「删除」不如「删除这 3 张发票」。对象让用户确认自己没有点错。

字数预算：按钮 ≤ 6 字，主按钮 ≤ 4 字。 超过 6 字通常说明按钮承担了两件事，应该拆开或改写。英文按钮同理，控制在 3 个词以内。

危险操作的按钮要写清后果。 「删除」与「删除并清空回收站」是两个不同的承诺，不能共用一套样式和文案。

按钮文案不要用「确定 / 取消」。 它们只表示「我同意」，不表示同意什么。把按钮改成「删除发票 / 保留」，用户在点之前就知道结果。

按钮文案要随状态变化。 空闲时「保存发票」，进行中「正在保存…」，成功后「已保存」。按钮文字不变，用户就只能靠猜。

禁用态要说明原因。 一个灰掉的按钮如果不告诉用户为什么不能点，用户只会反复尝试。把原因写在按钮下方或悬浮提示里：「请先选择一张发票」。

中文与英文的预算要分开定。 中文 4 字的按钮，英文通常要 10–12 个字符。直接用中文长度约束翻译，英文一定会溢出或被迫缩写。

三、报错：三要素与固定句式

报错是用户最需要帮助的时刻。它必须回答三个问题。

发生了什么：发票抬头超过 40 字
为什么：当前填写了 52 字
下一步：请压缩到 40 字以内，或改用简称

三句缺一不可。只写「操作失败」等于让用户自己排查。

报错要具体到可执行。 「格式不正确」不如「日期需要写成 2026-10-24」。前者要求用户猜规则，后者直接给出规则。

报错不要暴露内部术语。 ECONNRESET、500 Internal Server Error、undefined is not a function 都不是给用户看的。转换成人话，同时保留技术细节到日志里。

同一类错误只写一句。 十个接口超时，不应该出现十种措辞。维护一张「错误类型 → 用户语言」的映射表，比在每处临时写一句更省力，也更一致。

报错要说「你」，不说「系统」。 「系统繁忙，请稍后重试」把责任推给一个抽象主体；「我们这边出了点问题，你的草稿已保存，请两分钟后再试」既承认问题，也告诉用户损失可控。

不要用感叹号和「抱歉」堆砌。 一次报错最多一个礼貌表达。过多道歉会稀释信息，也让界面显得慌乱。

报错文案长度控制在 40 字以内。 超过这个长度，用户只会扫一眼就关掉。需要解释更多时，给一个「查看原因」的展开入口。

错误提示不要自动消失。 需要用户处理的信息，停留时间应当由用户决定。三秒后消失的红条，等于没有出现过。

四、空状态与语气一致

空状态是用户第一次见到某个功能时的样子，它同时承担解释与引导。

空状态写两句话：为什么是空的，现在可以做什么。 「还没有发票。点击右上角「新建发票」，或导入上个月的记录。」

空状态不要写「暂无数据」。 它只描述了现象，没有提供任何下一步。用户看完之后仍然不知道该做什么。

空状态可以给一个示例。 一个预填的样例、一张示意图、一段 10 秒的演示，胜过三行说明。

空状态与「筛选后无结果」要分开写。前者是「还没有」，引导创建；后者是「有但没匹配上」，引导清除条件。两句文案混用，用户会以为数据丢了。

语气要一致。 同一个产品里，按钮说「保存」、报错说「操作失败」、空状态说「暂无数据」，三种语域并存，用户会觉得这是三个人做的。

选一种，然后所有界面文案都按它写。语气不一致比语气平淡更伤信任。

称呼也要统一。全篇「您」或全篇「你」，选一个。混用会让用户感到产品在两种人设之间切换。

语气可以有一点性格，但不要影响清晰。 一句俏皮话放在错误提示里，可能让正在着急的用户更烦。幽默适合空状态与成功提示，不适合阻断性错误。

中英文长度要分别定预算。 同一句按钮文案，中文 4 字对应英文约 10–12 个字符。直接把中文压到 4 字再翻译，英文会溢出按钮；反过来，英文简洁的写法翻译成中文可能显得生硬。

文案要能被搜索与替换。 所有界面文案集中管理，不要散落在组件里。否则改一句提示语要翻五个文件，语气一致性也无从维护。

写文案时给翻译留出余量。 中文按钮按 4 字设计，布局就要按英文 12 个字符预留宽度。等翻译完成再改布局，成本会翻倍。

五、行动清单与复算验收

• 导出全部按钮文案，标出不是动词开头的项
• 把超过 6 字的按钮改写或拆分
• 检查危险操作按钮是否写清后果
• 导出全部报错文案，逐条检查是否含三要素
• 把暴露内部术语的报错改写成用户语言
• 检查所有空状态，确认有两句话与一个入口
• 选定一种语域，写出三个示例句作为基准
• 把界面文案集中到一处管理，统计总条数

验收标准：能报出按钮文案的平均字数、报错文案中三要素齐全的比例、空状态带入口的比例。 三项都答不出的，说明文案还散落在代码里。

使用边界与实操验收

本文讲原语言界面文案的写法，不涉及文案如何外置成语言包，那属于文案外置：从硬编码到语言包 ；翻译与术语表属于翻译工作流：机翻、审校与术语表 ；状态本身的设计属于第 06 篇；首屏标题与副标题属于第 05 篇。

本文也不主张「所有文案都要短」。帮助文档、条款说明需要完整表达。这里说的字数预算是针对界面内的即时反馈，不包括需要阅读的长文本。

验证以真实客服问题为准：连续一个月，统计「不知道怎么操作」「不知道是否成功」「不知道去哪找」三类问题的数量。数字下降，说明文案在起作用；数字不变，说明改的还是措辞，不是信息结构。

另一个可操作的验收：让一个没用过产品的人独立完成一次开票，全程不提问。卡住的每一步，都对应一句需要重写的文案。

文案评审不需要开会。一个人做产品时，把界面里的所有文字按页面导出成一张表，从上到下读一遍，重复、矛盾、含糊的地方会自己浮出来。这件事一小时能做完，值得每个版本做一次。

关键参考与核验范围

本文的字数与句式为教学演示。核验日期：2026-10-24。

• Microsoft Writing Style Guide ：界面文案、错误信息与按钮命名的公开写作规范。
• GOV.UK Service Manual: Content design ：面向公众服务的文案写法与可读性要求。

上述两条只用于说明公开写作规范，不构成对任何风格指南的推荐。中文界面的字数预算为本文给出的教学口径，需按产品实际排版调整。

系列导航

• 上一篇：交互状态：空、加载、错误、成功与无权限
• 下一篇：视觉物料：图标、截图、演示图与素材清单
• 回到目录：一个人把产品做得像样：品牌、视觉识别与设计系统
• 相关阅读：文案外置：从硬编码到语言包 、翻译工作流：机翻、审校与术语表