开场：「确定」是最忙的按钮，也是最没用的

数一数你今天点过多少次「确定」。它出现在删除、提交、退出、覆盖、清空的弹窗里，同一个词替一百种后果背书。按钮自己不带答案，答案在正文里，用户必须读完整段话才知道这一下点的是什么。「确定 / 取消」配对是偷懒，把阅读成本推给了用户。

一句话速览：「删除这 3 条」比「确定」诚实。按钮动词要说清后果，标签用用户的词，别把数据库字段名端给用户。

一、让按钮把后果带在身上

「删除这 3 条」替掉「确定」，「留着」替掉「取消」。 这样哪怕正文一个字没读，扫一眼按钮也能安全作答。Cooper 在《About Face 4》第 21 章给功能对话框立过同款规矩：标题要用动词。

验收标准：把弹窗正文遮住，只看标题和按钮，能不能安全作答。 能，文案就合格；要回头翻正文，就还是「确定 / 取消」的偷懒变体。

场景	偷懒版	携带后果版
清空购物车	确定 / 取消	清空 12 件 / 先留着
退出编辑	是 / 否	保存并退出 / 丢弃改动
解绑手机号	继续 / 返回	解绑 138****2046 / 不解绑

注意「携带后果版」的副产品：数量和对象一并写进按钮（12 件、138****2046），等于替用户做了最后一次核对。误操作大多发生在「我以为选的是另一批」，按钮把对象报出来，这层误会当场消解。

二、用户的词，系统的词

界面上写着「字段 user_mobile 校验失败」「违反唯一性约束」，这些词一个用户都不认识，它们是从数据库和日志里直接端出来的。Cooper 在第 14 章把根子挖了出来：开发者把数据库的需求放在用户的需求前面，软件成了替 CPU 服务的，用户反倒像在替软件打工。

第 14 章还有一条被引用得很多的原则：出错可能不是程序的问题，但是程序的责任。 把错误翻译成用户听得懂、改得动的话，是程序分内的事。连菜单名都逃不过这条：「文件」这个菜单名都是实现模型的词，发票应用的菜单就该叫「发票」。

系统的词	它其实想说	病根
此操作无法撤销	「此操作」指哪个操作？说出来	系统视角的指代，用户要自己回忆上一步
Error 422	哪里填得不对、怎么改	HTTP 状态码是写给开发者的日志
Session 已过期	登录过期了，重新登录就行	Session 是实现模型的词，用户的词是「登录」

AI 写界面时特别容易犯这个病：它对着数据结构生成文案，字段叫什么，标签就叫什么。你不拦，数据库就直接上台演讲。

三、改写示范：一个删除弹窗的三处文案

位置	弱文案	人话版
标题	提示	删除 3 封邮件？
正文	确定要执行此操作吗？此操作无法撤销。	这 3 封邮件将从收件箱删除，无法恢复。
按钮	取消 / 确定	先留着 / 删除 3 封

改完再做遮正文测试：只看标题和按钮，能不能安全作答？

四、把系统语翻译成人话

系统语	人话翻译
DB_CONN_TIMEOUT	刚才没连上服务器，你写的内容已存在本机，网络恢复后会自动重试
字段 user_mobile 校验失败	手机号少了一位，现在是 10 位，补上就能提交
Session 已过期，Token 失效	登录过期了，重新登录就能接着编辑，草稿已经保留
404 Not Found: /orders/8291	这笔订单找不到了，可能已被撤销。去「全部订单」里看看，或者联系客服帮你查
该操作违反唯一性约束	这个用户名已经有人用了，换一个试试，比如加个数字

翻译要翻到用户能行动为止——别只是把系统语打扮一下，骨子里还是日志。

五、综合题：关文档时还有改动没保存

选项	判断
「确定 / 取消」，正文写明会丢失	❌ 按钮不带后果
「保存并关闭 / 不保存 / 取消」，三颗按钮各带后果	✅ 每颗按钮自带动作和后果
「是 / 否」，正文问「要保存吗」	❌ 是/否不携带后果
「知道了」，告知改动将丢失	❌ 没有给退路

本节要点

• 按钮携带后果： 「删除这 3 条」替掉「确定」，「留着」替掉「取消」。验收标准：遮住正文只看标题和按钮，还能安全作答。
• 用用户的词： Session、字段名、错误码都是实现模型的词，别端给用户。翻译要翻到用户能行动为止。
• 出错是程序的责任： 用户的输入可以有错，把错讲成听得懂、改得动的话，是程序分内的事。措辞不责备用户。
• 给 AI 提需求的话术： 「按钮文案写明动作和数量，禁用『确定 / 取消』配对；界面文案禁止出现字段名、错误码、Session 等系统词」。