界面会说话：用户怎么理解你的文案
「删除这 3 条」比「确定」诚实。按钮动词要说清后果，标签用用户的词，别把数据库字段名端给用户。亲手改写一个弹窗的三处文案
本页解决的问题
先给结论「界面会说话：用户怎么理解你的文案」要解决的关键问题是什么？
「删除这 3 条」比「确定」诚实。按钮动词要说清后果，标签用用户的词，别把数据库字段名端给用户。亲手改写一个弹窗的三处文案
把品味变成产品可重复的行为。 有用的结果不是一句“我觉得更好”。它应该是一条看得见的规则、一个小例子，以及判断体验何时低于标准的方法。
记录一个前后对比，让别人不用听解释也能看懂质量线。
表面更精致了，却没有减少用户的不确定感。
数一数你今天点过多少次「确定」。它出现在删除、提交、退出、覆盖、清空的弹窗里，同一个词替一百种后果背书。问题就出在这：按钮自己不带答案，答案在正文里，用户必须读完整段话，才知道这一下点的是什么。「确定 / 取消」配对是偷懒，把阅读成本推给了用户。
处方是让按钮把后果带在身上：「删除这 3 条」替掉「确定」，「留着」替掉「取消」。这样哪怕正文一个字没读，扫一眼按钮也能安全作答。Cooper 在《About Face 4》第 21 章给功能对话框立过同款规矩：标题要用动词。标题说清在确认什么，按钮说清点了会怎样，两头都不让用户猜。
Alan Cooper，《About Face 4》第 21 章：动词带着动作和后果，名词和「提示」什么都不带。
这条规矩还有一个测试版本：把弹窗正文遮住，只看标题和按钮，能不能安全作答。能，文案就合格；要回头翻正文，就还是「确定 / 取消」的偷懒变体。先看几组对照，找找动词按钮的手感。
| 场景 | 偷懒版 | 携带后果版 |
|---|---|---|
| 清空购物车 | 确定 / 取消 | 清空 12 件 / 先留着 |
| 退出编辑 | 是 / 否 | 保存并退出 / 丢弃改动 |
| 解绑手机号 | 继续 / 返回 | 解绑 138****2046 / 不解绑 |
注意「携带后果版」的另一个副产品：数量和对象一并写进按钮（12 件、138****2046），等于替用户做了最后一次核对。误操作大多发生在「我以为选的是另一批」，按钮把对象报出来，这层误会当场消解。
按钮之外，第二个重灾区是名词。界面上写着「字段 user_mobile 校验失败」「违反唯一性约束」，这些词一个用户都不认识，它们是从数据库和日志里直接端出来的。Cooper 在第 14 章把根子挖了出来：开发者把数据库的需求放在用户的需求前面，软件成了替 CPU 服务的，用户反倒像在替软件打工。
第 14 章还有一条被引用得很多的原则：出错可能不是程序的问题，但是程序的责任。手机号少一位、用户名重复，都算用户的「错」，但把错误翻译成用户听得懂、改得动的话，是程序分内的事。连菜单名都逃不过这条：Cooper 认为「文件」这个菜单名都是实现模型的词，发票应用的菜单就该叫「发票」，用户管自己的东西叫什么，界面就叫什么。
| 系统的词 | 它其实想说 | 病根 |
|---|---|---|
| 此操作无法撤销 | 「此操作」指哪个操作？说出来 | 系统视角的指代，用户要自己回忆上一步 |
| Error 422 | 哪里填得不对、怎么改 | HTTP 状态码是写给开发者的日志（第 2 节的病历） |
| Session 已过期 | 登录过期了，重新登录就行 | Session 是实现模型的词，用户的词是「登录」 |
AI 写界面时特别容易犯这个病：它对着数据结构生成文案，字段叫什么，标签就叫什么。你不拦，数据库就直接上台演讲。下面动手改一个弹窗，三处文案逐条换成人话，看 mock 当场变样。
左边这个删除确认弹窗出自 AI 产出的真实水平：标题「提示」、正文含糊、按钮「确定 / 取消」。右边三处逐条点「说人话」，每改一处，弹窗当场更新，三处全改完再做遮正文测试。
危险的定义先说清：用户没读懂也会点下去的那种，才叫危险。上一节的狼来了实验演过，用户处理弹窗的平均耗时读不完一行字，文案模糊的弹窗等于在盲点里放了一把刀。下面两个弹窗都在删客户数据，点你敢把用户交给的那个。
按钮练完练名词。下面五条都是 AI 爱直接端上界面的系统语，每条从两个翻译里挑出真正的人话。小心，有个别选项只是把系统语打扮了一下，骨子里还是日志。
聊到这里你可能想起第 2 节的错误文案改写器：发生了什么、为什么、怎么办。那套三要素管错误信息的骨架，这一节管的是骨架里每个词的选法，两边拼起来才是完整的文案功。三要素不重教，跳转卡在这。
本章引用 · 状态三件套：loading、空态、错误态错误信息三要素（发生了什么、为什么、怎么办）和三条弱文案的完整改写，第 2 节讲透了，点这里跳过去。最后一道综合题，把这一节的按钮功和上面的三要素合在一起考。
按钮携带后果：「删除这 3 条」替掉「确定」，「留着」替掉「取消」。验收标准：遮住正文只看标题和按钮，还能安全作答。
用用户的词：Session、字段名、错误码都是实现模型的词，别端给用户（Cooper，《About Face 4》第 14 章）。翻译要翻到用户能行动为止。
出错是程序的责任：用户的输入可以有错，把错讲成听得懂、改得动的话，是程序分内的事。措辞不责备用户，三要素骨架在第 2 节。
给 AI 提需求的话术：「按钮文案写明动作和数量，禁用『确定 / 取消』配对；界面文案禁止出现字段名、错误码、Session 等系统词」。界面细节到此讲完，下一节开始把这些要求翻译给 AI 听。
内容来源：newwebplay AI「交互工程」专题原创；部分交互原则整理自《About Face 4：交互设计精髓》。
从「「确定」是最忙的按钮，也是最没用的」把感觉变成判断
「数一数你今天点过多少次「确定」。它出现在删除、提交、退出、覆盖、清空的弹窗里，同一个词替一百种后果背书。问题就出在这： 按钮自己不带答案，答案在正文里 ，用户必须读完整段话，才知道这一下点的是什么。「确定 / 取消」配对是偷懒，把阅读成本推给了用户」指出，AI 降低了做出“能用”成品的门槛，读者真正需要练的是看出哪里不对，并把感觉说成可以执行的要求。
观察用户的下一步，而不是只看表面
「处方是让按钮把后果带在身上：「删除这 3 条」替掉「确定」，「留着」替掉「取消」。这样哪怕正文一个字没读，扫一眼按钮也能安全作答。Cooper 在《About Face 4》第 21 章给功能对话框立过同款规矩：标题要用动词。标题说清在确认什么，按钮说清点了会怎样，两头都不让用户猜」可以转成几个可观察的问题：用户是否知道现在发生了什么，是否知道下一步做什么，出错或空白时能否恢复，以及信息层级是否让重要内容先被看见。
漂亮不等于容易用
把「给 AI 提需求的话术： 「按钮文案写明动作和数量，禁用『确定 / 取消』配对；界面文案禁止出现字段名、错误码、Session 等系统词」。界面细节到此讲完，下一节开始把这些要求翻译给 AI 听」用在第二个页面或流程上，记录一个具体犹豫点和一个改动后的用户动作；能被观察到的变化，才是体验改善。
从「「确定」是最忙的按钮，也是最没用的」走到「用户的词，系统的词」
「「确定」是最忙的按钮，也是最没用的」先把问题落在「数一数你今天点过多少次「确定」。它出现在删除、提交、退出、覆盖、清空的弹窗里，同一个词替一百种后果背书。问题就出在这： 按钮自己不带答案，答案在正文里 ，用户必须读完整段话，才知道这一下点的是什么。「确定 / 取消」配对是偷懒，把阅读成本推给了用户」上；到了「用户的词，系统的词」，讨论继续推进到「按钮之外，第二个重灾区是名词。界面上写着「字段 user_mobile 校验失败」「违反唯一性约束」，这些词一个用户都不认识，它们是从数据库和日志里直接端出来的。Cooper 在第 14 章把根子挖了出来：开发者把数据库的需求放在用户的需求前面，软件成了替 CPU 服务的，用户反倒像在替软件打工」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
评估体验时，把抽象的“好看”或“顺手”换成用户动作：他是否看懂状态、找到了下一步、能从错误中恢复，并且愿意继续使用。
- 「「确定」是最忙的按钮，也是最没用的」：数一数你今天点过多少次「确定」。它出现在删除、提交、退出、覆盖、清空的弹窗里，同一个词替一百种后果背书。问题就出在这： 按钮自己不带答案，答案在正文里 ，用户必须读完整段话，才知道这一下点的是什么。「确定 / 取消」配对是偷懒，把阅读成本推给了用户
- 「用户的词，系统的词」：按钮之外，第二个重灾区是名词。界面上写着「字段 user_mobile 校验失败」「违反唯一性约束」，这些词一个用户都不认识，它们是从数据库和日志里直接端出来的。Cooper 在第 14 章把根子挖了出来：开发者把数据库的需求放在用户的需求前面，软件成了替 CPU 服务的，用户反倒像在替软件打工
- 「最后的要点」：AI 写界面时特别容易犯这个病：它对着数据结构生成文案，字段叫什么，标签就叫什么。你不拦，数据库就直接上台演讲。下面动手改一个弹窗，三处文案逐条换成人话，看 mock 当场变样
最后的「最后的要点」把讨论落到「AI 写界面时特别容易犯这个病：它对着数据结构生成文案，字段叫什么，标签就叫什么。你不拦，数据库就直接上台演讲。下面动手改一个弹窗，三处文案逐条换成人话，看 mock 当场变样」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。