写作与表达：设计与设计文案微文案技艺 · 报错的人性 · Voice & Tone 体系 · 文案检查表

微文案是界面里那些不起眼的小字——按钮、标签、占位符、提示。它们字数最少，却出现在用户正要做决定的那一秒，成为全部的引导。

用户不「阅读」界面，他们扫描。在每个要做决定的瞬间——点不点这个按钮、填不填这一栏——能依靠的只有那几个字。通用词（「提交」「确定」）把决定又推回给用户：点了会发生什么？而具体到动作与结果的词，替用户消除了不确定。这是体验设计里成本最低、杠杆最高的一处：不改一行布局，只换几个字，转化率和信任感就动了。微文案的功夫不在辞藻，在于站在用户犹豫的那一刻，替他把下一步说清楚。

• ✓ 按钮、表单标签、空状态、确认弹窗、引导提示——一切用户要做决定的触点
• ✓ 写完自检：每个按钮是否回答了「点下去会发生什么」
• ✗ 误区：用「提交／确定／取消」这类通用词，把判断的负担丢给用户
• ✗ 误区：拿占位符当标签用——用户一开始输入，提示就消失，转头就忘了这栏填什么

好的报错只做三件事：用人话说清发生了什么、为什么、现在怎么办。绝不甩错误码，绝不责怪用户。

报错出现的时刻，用户已经受挫了。此时一句冷冰冰的「操作失败」或一串「Error 500」，是在伤口上撒盐。报错的本质是一次对话：用户做了某事没成，系统该像一个冷静的同事那样回应，而不是像一台报警器。还要警惕责怪——把「你输错了」换成中性的描述，主语从「你」移开。一条合格的报错有清晰的三段解剖结构，照着填即可。

• ✓ 表单校验、网络错误、空结果页、权限拒绝——任何「事情没成」的时刻
• ✓ 给开发者看的日志可以带错误码；给用户看的界面只留人话
• ✗ 误区：把堆栈、错误码原样抛给普通用户，徒增恐慌
• ✗ 误区：只说「出错了」却不给下一步，或用「你」开头变成指责

声音（voice）是产品的人格，始终如一；语气（tone）随情境而变。一个声音，多种语气——正如一个人在婚礼和葬礼上，是同一个人，话却说得不同。

一个人随手写一两句靠直觉，但一个产品有几百个文案触点、由多人协作——没有统一的声音，文案就会人格分裂：这一页活泼俏皮，那一页公文官腔。Voice 是固定的几个形容词（如「友好但不轻浮、专业但不端着」），写进规范文档，让所有人对齐。Tone 则要读场景：用户刚支付成功，可以欢快；刚撞上报错，就要克制体贴。最常见的灾难，是用同一种「俏皮」语气覆盖所有场景——在用户丢了数据时还卖萌，再统一的声音也变成冒犯。

• ✓ 建立产品文案规范、多人协作、跨团队对齐时，先定 voice 再谈 tone
• ✓ 写每条文案前先问：用户此刻什么心情？该用什么语气接住他
• ✗ 误区：把 voice 和 tone 混为一谈，以为「品牌很活泼」就处处卖萌
• ✗ 误区：在报错、付费、隐私等严肃场景硬塞俏皮，灾难时刻还在开玩笑

界面上的字比文章更要省——用户是来完成任务的，不是来读你的。终稿前过一遍清单，第一刀永远是：能不能删掉一半？

Krug 的「砍一半，再砍一半」听着夸张，实践中却真能逼出大量「客套话」与「指示性废话」——欢迎辞、过度说明、礼貌缓冲。每个多余的字都在挡路。但砍字不是唯一标尺；一张实用的检查表至少四问：① 清晰（用户秒懂吗？）② 简洁（能更短吗？）③ 对话感（像人说话吗？）④ 有用（读完知道做什么吗？）。短而含糊和长而清楚之间，永远选清楚——砍字是为了让指引更锋利，不是为了字少。

• ✓ 任何界面文案的终稿审计；onboarding 与空状态是废话重灾区
• ✓ 终稿前逐条过四问：清晰 / 简洁 / 对话感 / 有用
• ✗ 误区：用「happy talk」开场白热场，把说明书整本塞进界面
• ✗ 误区：为了短而牺牲清晰——过度缩写、堆术语，用户反而更懵