介面會説話：用戶怎麼理解你的文案

「確定」是最忙的按鈕，也是最沒用的

數一數你今天點過多少次「確定」。它出現在刪除、提交、退出、覆蓋、清空的彈窗裏，同一個詞替一百種後果背書。問題就出在這：按鈕自己不帶答案，答案在正文裏，用戶必須讀完整段話，才知道這一下點的是什麼。「確定 / 取消」配對是偷懶，把閲讀成本推給了用戶。

處方是讓按鈕把後果帶在身上：「刪除呢 3 條」替掉「確定」，「留着」替掉「取消」。這樣哪怕正文一個字沒讀，掃一眼按鈕也能安全作答。Cooper 在《About Face 4》第 21 章給功能對話框立過同款規矩：標題要用動詞。標題説清在確認什麼，按鈕説清點了會怎樣，兩頭都不讓用戶猜。

「在功能對話框的標題中使用動詞。」
Alan Cooper，《About Face 4》第 21 章：動詞帶着動作和後果，名詞和「提示」什麼都不帶。

這條規矩還有一個測試版本：把彈窗正文遮住，只看標題和按鈕，能不能安全作答。能，文案就合格；要回頭翻正文，就還是「確定 / 取消」的偷懶變體。先看幾組對照，找找動詞按鈕的手感。

場景	偷懶版	攜帶後果版
清空購物車	確定 / 取消	清空 12 件 / 先留着
退出編輯	是 / 否	保存並退出 / 丟棄改動
解綁手機號碼	繼續 / 返回	解綁 1382046 / 不解綁

注意「攜帶後果版」的另一個副產品：數量和對象一併寫進按鈕（12 件、138****2046），等於替用戶做了最後一次核對。誤操作大多發生在「我以為揀嘅係另一批」，按鈕把對象報出來，這層誤會當場消解。

用戶的詞，系統的詞

按鈕之外，第二個重災區是名詞。介面上寫着「字段 user_mobile 校驗失敗」「違反唯一性約束」，這些詞一個用戶都不認識，它們是從數據庫和日誌裏直接端出來的。Cooper 在第 14 章把根子挖了出來：開發者把數據庫的需求放在用戶的需求前面，軟件成了替 CPU 服務的，用戶反倒像在替軟件打工。

第 14 章還有一條被引用得很多的原則：出錯可能不是程式的問題，但是程式的責任。手機號碼少一位、用戶名重複，都算用戶的「錯」，但把錯誤翻譯成用戶聽得懂、改得動的話，是程式分內的事。連菜單名都逃不過這條：Cooper 認為「文件」這個菜單名都是實現模型的詞，發票應用的菜單就該叫「發票」，用戶管自己的東西叫什麼，介面就叫什麼。

系統的詞	它其實想説	病根
此操作無法撤銷	「此操作」指邊個操作？説出來	系統視角的指代，用戶要自己回憶上一步
Error 422	哪裏填得不對、怎麼改	HTTP 狀態碼是寫給開發者的日誌（第 2 節的病歷）
Session 已過期	登入過期了，重新登入就行	Session 是實現模型的詞，用戶的詞是「登入」

AI 寫介面時特別容易犯這個病：它對着數據結構生成文案，字段叫什麼，標籤就叫什麼。你不攔，數據庫就直接上台演講。下面動手改一個彈窗，三處文案逐條換成人話，看 mock 當場變樣。

動手 · 改寫一個彈窗，mock 即時變

左邊這個刪除確認彈窗出自 AI 產出的真實水平：標題「提示」、正文含糊、按鈕「確定 / 取消」。右邊三處逐條點「説人話」，每改一處，彈窗當場更新，三處全改完再做遮正文測試。

按鈕文案改寫器改寫 0 / 3

場景：用戶勾了 3 封郵件點刪除。點右側每條的「説人話」，左邊彈窗即時變

mail.example.com/inbox

提示

確定要執行此操作嗎？此操作無法撤銷。

取消確定

標題提示説人話 →

刪除這 3 封郵件？

「提示」零信息量。功能對話框標題用動詞（第 21 章），動作和數量都擺進標題，用戶第一眼就知道在確認什麼。

正文確定要執行此操作嗎？此操作無法撤銷。説人話 →

刪除後會進「已刪除」，保留 30 天，之後才永久消失。

「此操作」是系統視角的指代，用戶要自己回憶剛才點了什麼。正文該交代的是後果的細節：東西去哪了、留多久、還救不救得回。

按鈕取消 / 確定説人話 →

留着 / 刪除這 3 封

「確定 / 取消」把答案全押在正文上。按鈕攜帶各自的後果，危險的那顆換成紅色，正文一個字不讀也不會點錯。

對決 · 哪個彈窗更危險

危險的定義先説清：用戶沒讀懂也會點下去的那種，才叫危險。上一節的狼來了實驗演過，用戶處理彈窗的平均耗時讀不完一行字，文案模糊的彈窗等於在盲點裏放了一把刀。下面兩個彈窗都在刪客户數據，點你敢把用戶交給的那個。

模糊文案 vs 明確文案 A/B 對決

點你敢把用戶交給的那個，投完揭曉另一個危險在哪

方案 A

crm.example.com/customers

警告

此操作將影響所選數據，確定要繼續嗎？

取消確定

影響什麼數據、影響成什麼樣，全靠用戶腦補

方案 B

crm.example.com/customers

刪除這 3 位客户？

會同時刪除他們名下的 24 條跟進記錄。刪除後 30 天內可以在回收站找回。

留着刪除這 3 位

對象、連帶後果、退路，三樣都寫在明面上

動手 · 把系統語翻譯成人話

按鈕練完練名詞。下面五條都是 AI 愛直接端上介面的系統語，每條從兩個翻譯裏挑出真正的人話。小心，有個別選項只是把系統語打扮了一下，骨子裏還是日誌。

系統語翻譯題 0 / 5

每條選一個翻譯，選錯有解釋，可以再選

DB_CONN_TIMEOUT

A數據庫連接超時（錯誤碼 10060），請稍後重試。

B剛才沒連上伺服器，你寫的內容已存在本機，網絡恢復後會自動重試。

打扮過的系統語。「數據庫」「錯誤碼」還是實現模型的詞，用戶不關心哪個環節超時，關心的是我的東西丟沒丟、接下來要不要管。

對。隻字不提數據庫，先交代用戶最怕的事（內容沒丟），再交代要不要行動（不用管，會自動重試）。技術故障自己消化，這是第 2 節三要素的名詞版。

字段 user_mobile 校驗失敗

A手機號碼少了一位，現在是 10 位，補上就能提交。

B手機號碼格式不合法，請檢查後重新輸入。

對。user_mobile 翻成「手機號碼」只是及格綫，説出「少了一位」才算把校驗結果翻譯完，用戶不用數就知道怎麼改。

「不合法」加「請檢查」，等於讓用戶自己當校驗器再跑一遍。程式明明知道差在哪，説出來是它的責任（第 14 章）。

Session 已過期，Token 失效

A會話憑證已失效，請重新獲取訪問令牌。

B登入過期了，重新登入就能接着編輯，草稿已經保留。

把 Session 翻成「會話憑證」、Token 翻成「訪問令牌」，詞是中文了，模型還是實現模型。用戶的詞典裏只有「登入」。

對。用戶的詞（登入）、明確的出路（重新登入）、最要緊的安撫（草稿還在），一句話三件事全辦了。

404 Not Found: /orders/8291

A請求的資源不存在，請確認地址是否正確。

B這筆訂單找不到了，可能已被撤銷。去「全部訂單」裏看看，或者聯繫客服幫你查。

「資源」「地址」都是 HTTP 的詞。用戶點的是一筆訂單，他的世界裏沒有資源，只有訂單。

對。用用戶的詞（訂單）説清現狀，給兩條出路（去列表、找客服）。404 這種死胡同頁面，出路比解釋更值錢。

該操作違反唯一性約束

A這個用戶名已經有人用了，換一個試試，比如加個數字。

B數據重複，操作被拒絕，請修改後重試。

對。「唯一性約束」是數據庫給自己立的規矩，用戶眼裏這件事叫「名被人佔咗」。順手給條建議（加個數字），把死胡同變成岔路口。

「數據重複」比「唯一性約束」好懂一點，但哪個數據重複、跟誰重複、怎麼辦，一個都沒説。翻譯要翻到用戶能行動為止。

錯誤信息三要素，第 2 節講過了

聊到這裏你可能想起第 2 節的錯誤文案改寫器：發生了什麼、為什麼、怎麼辦。那套三要素管錯誤信息的骨架，這一節管的是骨架裏每個詞的選法，兩邊拼起來才是完整的文案功。三要素不重教，跳轉卡在這。

本章引用 · 狀態三件套：loading、空態、錯誤態錯誤信息三要素（發生了什麼、為什麼、怎麼辦）和三條弱文案的完整改寫，第 2 節講透了，點這裏跳過去。

最後一道綜合題，把這一節的按鈕功和上面的三要素合在一起考。

關文檔時還有改動沒保存，按鈕組怎麼配單選

選錯也有解釋，選到對的為止

A「確定 / 取消」，正文寫明會丟失未保存的改動

B「保存並關閉 / 不保存 / 取消」，三顆按鈕各帶後果

C「是 / 否」，正文問「要保存嗎？」

D「知道了」，告知改動將丟失

本節要點

✓

按鈕攜帶後果：「刪除呢 3 條」替掉「確定」，「留着」替掉「取消」。驗收標準：遮住正文只看標題和按鈕，還能安全作答。

✓

用用戶的詞：Session、字段名、錯誤碼都是實現模型的詞，別端給用戶（Cooper，《About Face 4》第 14 章）。翻譯要翻到用戶能行動為止。

✓

出錯是程式的責任：用戶的輸入可以有錯，把錯講成聽得懂、改得動的話，是程式分內的事。措辭不責備用戶，三要素骨架在第 2 節。

✓

給 AI 提需求的話術：「按鈕文案寫明動作和數量，禁用『確定 / 取消』配對；介面文案禁止出現字段名、錯誤碼、Session 等系統詞」。介面細節到此講完，下一節開始把這些要求翻譯給 AI 聽。

內容來源：小山學堂「交互工程」專題原創；部分交互原則整理自《About Face 4：交互設計精髓》。