AI UI 微文案：避免按鈕爆版與 Error Message 講廢話

01解決的工作問題

設計稿畫完之後，真正會出包的地方常常是留白處的那幾個字——按鈕、tooltip、表單驗證提示、error message、空狀態。這些字沒有人正式負責：設計師覺得是文案的事，文案覺得工程隨手打一打就好，工程為了先跑起來直接寫「發生錯誤」「確定」就上線。結果是三種反覆出現的災難：中文版量測正常的按鈕，換成英文或長一點的動詞就爆版；CTA 永遠是「確定」和「送出」，使用者不知道按下去會怎樣；Error message 只講「系統發生錯誤」，沒講發生了什麼、能怎麼辦、原因是不是真的查得到。用 AI 一次產出所有元件的文案很快，但 AI 一樣會犯同一個毛病——把「發生錯誤，請稍後再試」套用到每一種狀況，或是編一個聽起來合理但系統其實沒回傳過的錯誤原因。這個方法要控制的不是「文案好不好讀」，而是字元數、CTA 動詞、下一步指示、手機斷行、多語系、以及 Error 有沒有編造原因這幾個具體、可檢查的項目。

02什麼時候用、什麼時候別用

什麼情況下該用這一套

• {'t': '畫面已經有穩定的 wireframe 或高保真設計稿', 'd': '至少要有元件清單與大致的互動流程，AI 才有東西可以套用規則，不是憑空生文案。'}
• {'t': '團隊各頁面各寫各的 CTA 與 Error 文案', 'd': '按鈕動詞、Error 語氣、Empty State 處理方式沒有統一規範，是這個方法最直接見效的情況。'}
• {'t': '有手機版或多語系版本要顧', 'd': '字元數與斷行只有在跨裝置、跨語言比對時才會爆出問題，只看桌機中文版感受不到。'}

什麼情況下別用

還沒有畫面稿

先把 wireframe 或元件清單列出來，這個方法是替既有畫面配文案，不是幫你設計互動流程。

後端錯誤碼還沒定義清楚

Error 文案的核心是「已知原因才能寫」，如果系統本身連自己會回傳什麼錯誤碼都講不清楚，先跟工程對齊，不然 AI 只能全部寫通用話術。

受法遵或金融監理規範的定型化錯誤或警語

銀行、保險、醫療等產業常有主管機關規定的固定措辭，這個方法處理的是「有沒有講清楚、字元夠不夠」，不能覆蓋既定法規用語。

純粹的品牌語氣調性問題

如果問題是「我們的文案聽起來不像同一家公司」而不是「按鈕爆版、Error 沒有下一步」，先用品牌語氣一致化那個方法，兩者可以接著做。

誰會用到

設計／UX

你是這份對照表最主要的使用者與守門人——字元上限、斷行預覽最終都要套進你的畫面稿驗證，AI 生出來的長度用感覺看不出來，一定要實測。

行銷

Empty State 與部分 Error message 常常是使用者對品牌的第一印象，語氣要跟其他對外文案一致，但功能性（字數、下一步）優先於語氣好看。

品保／製造

Error 三分法是你測試的檢查點：每條 Error 文案回頭對錯誤碼，沒有佐證的原因要打回去改成通用話術，這是你能直接把關的具體項目。

資訊／資安

錯誤碼對照表要由你提供或確認，AI 編不出系統沒回傳過的原因，缺這份表 AI 只能猜，猜的部分要你事後逐一核對。

所屬工作情境

04完整步驟圖的文字版，逐步展開

一句話版（快速回顧）

1. 盤點畫面所有需要文案的元件與狀態，列出待寫清單，漏列的不會自動被生出來。
2. 訂好字元上限規格、CTA 動詞白名單、錯誤碼與已知原因對照表，這三份是 AI 產文案的規格輸入。
3. 請 AI 依規格產出多元件微文案初稿，每條標注實際字數。
4. 請 AI 檢查手機寬度斷行與 CTA 動詞是否踩到白名單外，標出超字數與怪斷行。
5. Error 一律三段式：發生什麼、能怎麼做、去哪找協助；原因只能寫對照到已知錯誤碼的，沒有佐證的一律通用話術，不可以編。
6. 人套進畫面稿覆核、跟工程對過錯誤碼，定稿後寫入 UX Microcopy Table 並分發給工程與 QA。

完整版（每一步誰做、產出什麼）

05開始前要準備什麼標「必要」的沒備齊就先別開始

畫面清單必要

列出所有需要文案的元件與狀態：按鈕（含 loading／disabled）、tooltip、表單驗證提示、error toast 或頁面、empty state。漏列的元件不會被生出來。

字元上限規格必要

依元件類型與斷點（手機／桌機）定的上限，例如「主要按鈕中文≤6字」。沒有這份規格，AI 只能用常識猜，猜出來的上限通常偏鬆。

CTA 動詞白名單必要

「送出／確認／繼續／略過／重試」這種固定動詞庫，避免這頁用「確定」那頁用「OK」。

錯誤碼與已知原因對照表必要

系統實際會回傳哪些錯誤碼、每個碼目前是否已知具體原因。這是 Error 文案能不能誠實寫下一步而不編原因的關鍵輸入。

需要覆蓋的語言清單可選

英文、日文等常常比中文長 30~100%，沒先列清楚語言範圍，斷行檢查只能做中文版。

既有品牌語氣規則（如有）可選

如果已經用 AI 品牌語氣一致化方法定過語氣規範，拿來對照，微文案不能違反既定語氣。

餵進去的東西要長這樣

畫面元件清單（含狀態）＋字元上限規格＋CTA 動詞白名單＋錯誤碼與已知原因對照表＋需要覆蓋的語言清單。

• 元件清單要含狀態，同一顆按鈕的預設／loading／disabled 要分開列。
• 字元上限依元件類型與斷點分別列，不是全站套一個數字。
• 錯誤碼對照表要註明哪些已知原因、哪些未知，未知的不能留白等 AI 補。
• 畫面若含真實使用者資料先代稱。
• 至少列出手機斷點寬度或字數上限的依據。

字元上限：主要按鈕中文≤6字、tooltip≤20字、表單驗證提示≤16字、error標題≤14字（手機斷點360px）
CTA動詞白名單：送出、確認、繼續、略過、重試、取消
錯誤碼對照表：409=時段已被預約（已知）、422=欄位格式錯誤（已知）、500=通用錯誤（原因未知，不可編造）
語言清單：英文（膨脹係數約150~200%）、日文（暫無參考，需人工估算）

畫面元件清單：
1.【按鈕】預約表單主要按鈕：預設／送出中／已達候補上限三態
2.【tooltip】候補說明圖示
3.【表單驗證】聯絡電話格式錯誤
4.【Error】送出失敗，系統回傳500
5.【Empty State】本月無可預約時段

06Prompt（快速／完整／進階）

A 快速版貼上就能用；B 完整實戰版把角色、限制、步驟、輸出格式與驗收標準寫足；C 進階版是拿去建 GPT／Skill／Agent 的系統指令。三種都附可替換變數、使用範例、預期輸出與人工確認點。

我要幫這個畫面產生介面微文案，請依下列規則逐一產出，並整理成表格：
規則：
1. 每個元件標明目前狀態（預設／hover／disabled／loading，如適用）。
2. 字元數：文案不超過{字元上限}，手機寬度下要能顯示，超過的請提供斷行後的樣子。
3. CTA 用詞只能從這份動詞庫挑：{動詞庫}，不要自創相近詞。
4. 每個 CTA 都要讓使用者知道按下去會發生什麼事，不能只是「確定」「送出」這種空詞。
5. Error 訊息一律三段式：發生了什麼（用使用者看得懂的話）／可以怎麼做（具體下一步）／需要協助時去哪。原因只能寫系統實際回傳、已確認錯誤碼對應的原因；沒有對應到已知錯誤碼的，一律寫通用話術，不可以自己猜原因。
6. Empty State 要包含：目前是空的原因（如果系統知道）＋使用者現在可以做的第一個動作。
7. 每條文案附字數統計。

畫面元件清單：{貼上}

我要幫這個畫面產生介面微文案，請依下列規則逐一產出，並整理成表格：（照母提示詞七條）

字元上限：主要按鈕中文≤6字、tooltip≤20字、表單驗證提示≤16字、error 標題≤14字
動詞庫：送出、確認、繼續、略過、重試、取消

畫面元件清單：
1. 【按鈕】長照服務預約表單最下方的主要按鈕，三種狀態：預設、送出中（loading）、已達候補人數上限（disabled）。
2. 【tooltip】「候補」兩個字旁邊的說明圖示，使用者常搞不懂候補跟預約差在哪。
3. 【表單驗證】聯絡電話欄位，格式不是台灣手機或市話號碼時。
4. 【Error】按下送出後，系統回傳 500，沒有更細的錯誤碼。
5. 【Empty State】「可預約時段」列表，目前這個月已經沒有任何開放時段。

【1. 主要按鈕】
預設：送出預約（4字）
送出中：送出中…（4字）
已達上限：已滿，加入候補（6字，超出上限1字，建議斷成兩行：已滿／加入候補，或改「候補登記」5字）

【2. tooltip】
候補是什麼：時段滿了可以先登記，有人取消會依順序通知你（19字，符合上限）

【3. 表單驗證：電話格式錯誤】
請輸入正確的電話號碼，例如 0912345678（15字，符合上限）

【4. Error：送出失敗，系統回傳通用 500】
發生了什麼：預約沒有送出成功
能怎麼做：請稍後再試一次，或直接來電服務台登記
去哪找協助：服務台電話（請填入實際號碼）
【原因未知，不可編造】——系統只回傳通用 500，沒有更細的錯誤碼可以對照，因此不寫「因為網路不穩定」之類的具體原因，只給下一步。

【5. Empty State：本月無可預約時段】
這個月的時段目前都已預約滿。
你可以先加入候補，或直接選下個月的時段（下個月時段已開放）。

【樣本不足的部分】
- 沒有拿到「候補通知」這個狀態的文案需求，若使用者被通知遞補成功，需要另外的訊息，目前規格沒有涵蓋。

以下是一版微文案初稿，以及對應的規格。請做完整檢查：

1.【斷行檢查】依手機寬度斷點（{手機寬度}），逐條標出超過字元上限、或斷行後語意被切壞的項目，並給出修訂版。
2.【動詞白名單檢查】逐條核對 CTA 是否只用了白名單裡的動詞：{動詞庫}。用了白名單外動詞的項目要標出來並建議替換。
3.【多語言長度檢查】對於需要支援的語言（{語言清單}），逐條估算翻譯後大約會膨脹多少百分比，標出換算後可能超出上限的項目。
4.【Error 原因抓漏】這是最重要的一步：逐條核對每個 Error 的「原因」是否真的能對照到{錯誤碼對照表}裡的已知原因。找不到對照的，直接標記【疑似編造，需改通用話術】，不要幫它找理由。
5.【總表】輸出修訂後的完整對照表，欄位為：元件／狀態、文案、字數、斷行預覽、CTA 動詞、下一步或說明、原因佐證（Error 限定，寫「已對照 XX 錯誤碼」或「通用話術，無對照」）、備註。

規則：
- 不得為了語意通順而放寬字元上限，超字的一定要標出來，即使沒有更短的寫法也要老實說「目前找不到更短的寫法」。
- 不得幫 Error 找一個對照表沒有的原因，即使聽起來很合理。
- 找不到多語言膨脹係數的語言，標【需要人工估算】，不要自己編一個數字。

初稿：{貼上}｜字元上限規格：{貼上}｜動詞白名單：{貼上}｜錯誤碼對照表：{貼上}｜語言清單：{貼上}

（貼上上一版產出的完整初稿表格，附上手機寬度 360px、動詞白名單、錯誤碼對照表：僅 500=通用錯誤已知無細分原因，以及語言清單：英文）

【1. 斷行檢查】
「已滿，加入候補」（6字）在 360px 寬度下會被壓成兩行且中間斷得很奇怪，建議改為「候補登記」（5字），符合上限且斷行不會切壞語意。

【2. 動詞白名單檢查】
第 3 項表單驗證訊息裡出現「請確認」，動詞庫裡沒有這個詞（有的是「確認」），建議統一改為「請輸入正確的電話號碼」，不使用「確認」當提示語裡的動詞，避免跟按鈕上的「確認」混淆。

【3. 多語言長度檢查】
「送出預約」譯為「Submit Booking Request」，中文 4 字對英文 22 字元，膨脹超過 400%，在主要按鈕上會被截斷，建議英文版改用「Book Now」或縮短原始中文文案的資訊量再翻譯。

【4. Error 原因抓漏】
第 4 項 Error 文案目前寫「發生了什麼：預約沒有送出成功」，原因欄位空白，這是對的，因為錯誤碼對照表裡 500 沒有更細的已知原因。標記：已對照 500＝通用錯誤，無細分原因，符合規則。

【5. 總表（節錄）】
| 元件/狀態 | 文案 | 字數 | 斷行預覽 | CTA動詞 | 下一步 | 原因佐證 | 備註 |
| 主要按鈕/預設 | 送出預約 | 4 | 不斷行 | 送出 | - | - | 英文版需另擬短版 |
| Error/送出失敗 | 預約沒有送出成功，請稍後再試或來電服務台 | 21 | 兩行 | 重試 | 稍後再試/來電 | 通用話術，無對照 | 500無細分原因，符合規則 |

【需要人工估算】
日文版目前沒有語言清單裡的膨脹係數參考，本次檢查未涵蓋，建議另外請熟悉日文 UI 文案的人估一次。

請把以下定稿的規格，寫成一份可以直接用來建立共用微文案助手的系統指令。

【系統指令要包含】
1. 角色與任務：只依規格產出或審查介面微文案，不負責決定互動流程或視覺設計。
2. 規格全文（照我提供的，不得增刪）：字元上限規格、CTA 動詞白名單、錯誤碼與已知原因對照表、需要覆蓋的語言清單。
3. Error 硬規則：原因只能對照到{錯誤碼對照表}裡已知的錯誤碼才能寫具體原因；沒有對照到的，一律輸出通用話術＋下一步，並在備註欄標「原因未知，不可編造」。這一條不得因為使用者要求「寫得更明確一點」而放寬。
4. 缺規格時的處理：使用者沒有提供某個元件的狀態、或某個錯誤碼不在對照表裡，一律先問，不要自己假設或編一個。
5. 輸出格式：固定欄位的表格——元件／狀態、文案、字數、斷行預覽、CTA 動詞、下一步或說明、原因佐證（Error 限定）、備註。
6. 多語言請求：若使用者要求某語言版本，且該語言不在既有膨脹係數參考裡，回報「需要人工估算」，不得自行編一個係數。

【另外請給我】
(a) 一份「使用說明」，寫給第一次用的設計師或工程看，含三個好例子與三個壞例子。
(b) 一份「維護說明」：規格要更新時該改哪裡（尤其是錯誤碼對照表新增碼時）、多久檢查一次、誰負責。

字元上限規格：{貼上}｜動詞白名單：{貼上}｜錯誤碼對照表：{貼上}｜語言清單：{貼上}

（貼上四份定稿規格：按鈕≤6字/tooltip≤20字/驗證≤16字/error標題≤14字；動詞白名單：送出、確認、繼續、略過、重試、取消；錯誤碼表：500=通用無細分原因、409=時段已被預約、422=欄位格式錯誤；語言清單：英文、日文，暫無膨脹係數參考）

【共用微文案助手 系統指令】

一、你的角色
你是本產品的介面微文案助手，只依規格產出或審查文案，不負責互動流程或視覺設計決策。

二、規格
（照錄字元上限、動詞白名單、錯誤碼對照表、語言清單全文）

三、Error 硬規則
原因只能對照到錯誤碼對照表裡已知的碼：409 可以寫「時段已被預約」，422 可以寫「格式不正確」；500 或任何不在表上的碼，一律輸出通用話術＋下一步，備註欄標「原因未知，不可編造」。使用者要求「寫具體一點」時，回覆：這個錯誤碼目前沒有已知原因，寫具體原因需要先跟工程確認並更新對照表。

四、缺規格時
遇到清單裡沒說明狀態的元件、或對照表沒有的錯誤碼，先問使用者，不自行假設。

五、輸出格式
固定欄位表格：元件/狀態、文案、字數、斷行預覽、CTA動詞、下一步、原因佐證、備註。

六、多語言
日文目前無膨脹係數參考，遇到日文請求回報「需要人工估算」，並提示：可先用英文係數（約120~180%）當粗估，但要人工覆核。

──────────

【使用說明（給第一次用的同事）】
好例子：
1. 貼上「付款失敗」畫面的元件清單與已知這個錯誤是 409（時段已被搶）。
2. 貼上一批要新增的空狀態清單，問「這些字數會不會超標」。
3. 貼上翻譯完的英文版，問「哪幾個按鈕會被截斷」。

壞例子：
1.「幫我把 Error 寫得更有說服力一點」——這通常意味著要求它編一個聽起來合理的原因，助手應該拒絕並說明。
2.「這個錯誤碼系統還沒定義，你先猜一個原因給我」——助手應該回報需要先補齊對照表，不猜。
3.「德文版沒有係數，你估一個」——沒有參考時只能給粗估並提示需要人工覆核，不能當作定案數字。

【維護說明】
- 新增錯誤碼時，第二節與第三節的對照表要同步更新，這是最容易被漏掉的一步。
- 每次改版新增元件時，字元上限規格要跟著斷點一起檢視。
- 負責人：〔填寫〕。更新後在共用位置註明版本與日期。

07產出應該長什麼樣拿到的東西要長這樣

UX Microcopy Table，每列一個元件狀態，欄位為：元件／狀態、文案、字數、手機斷行預覽、CTA 動詞、下一步或說明、原因佐證（Error 限定）、備註。

完成品：同一顆按鈕的兩種寫法：有沒有先量過字元數

【沒有先訂字元上限】
AI 產出（節錄）：
「主要按鈕：立即開始使用服務」

→ 讀起來完整、語意清楚。問題是：
→ 這句話 8 個字，中文版量測沒問題，但同一顆按鈕如果之後要出英文版「Start Using the Service Now」，字數暴增超過三倍，手機版按鈕會直接爆版或被截斷。
→ 沒有人在產文案的當下量過寬度，等到設計走查或使用者回報才發現。

【先訂字元上限，逐條標字數】
AI 產出（節錄）：
「主要按鈕：立即開始（4字，符合中文≤6字上限）
斷行預覽：不斷行
英文版建議：Get Started（符合對照的字元寬度規格，而非逐字直譯）」

→ 每一條文案都附字數，超過上限的會被標出來，不會等到上線後才發現。
→ 中英文版分開驗證，不是假設兩者字數會一樣。

【差別在哪】
第一種在寫「這句話讀起來順不順」，第二種在寫「這句話量過了沒有」。介面文案要面對的是真實的按鈕寬度與螢幕尺寸，讀起來順不等於放得下。

| 元件/狀態 | 文案 | 字數 | 斷行預覽(360px) | CTA動詞 | 下一步/說明 | 原因佐證 | 備註 |
|---|---|---|---|---|---|---|---|
| 按鈕/預設 | 送出預約 | 4 | 不斷行 | 送出 | - | - | 英文版需另擬短版 |
| 按鈕/已達上限 | 候補登記 | 5 | 不斷行 | - | 加入候補名單 | - | 原「已滿，加入候補」超字已改短 |
| tooltip | 時段滿了可以先登記，有人取消會依順序通知你 | 19 | 兩行 | - | - | - | 符合20字上限 |
| 表單驗證 | 請輸入正確的電話號碼，例如0912345678 | 15 | 一行 | - | 依範例重新輸入 | - | 符合16字上限 |
| Error/送出失敗 | 預約沒有送出成功，請稍後再試或來電服務台 | 21 | 兩行 | 重試 | 稍後再試/來電服務台 | 通用話術，無對照(500) | 不得改寫具體原因 |
| Empty State | 這個月的時段都已預約滿，你可以先加入候補或選下個月時段 | 24 | 三行 | - | 加入候補/選下月 | - | - |

08工具怎麼挑

這幾支都做得到——差別在你手上有哪一支、資料能不能外流。標「起手」的是不知道從哪支開始時的建議，不是限定。

09會卡住與會做錯的地方

會卡住的地方（流程困難點）

按鈕文字沒設上限

中文版量測沒事，換成英文動詞或長一點的品牌用詞，同一顆按鈕在手機版直接爆版或擠成兩行。

CTA 只寫「確定」「送出」

使用者不知道按下去實際會發生什麼——是送出付款、還是刪除資料——空詞在高風險操作上特別危險。

Error 只講「發生錯誤」

沒有下一步、沒有原因，使用者只能重新整理或放棄，客服單反而變多。

AI 幫 Error 編了個聽起來合理的原因

系統其實只回傳一個通用 500，AI 卻寫成「因為您的網路不穩定」，這句話沒有任何佐證，是編造。

會做錯的地方（常見失敗方式）

其他注意事項

• 按鈕沒設字元上限，中文版量測正常，英文或長一點的動詞版直接爆版。
• AI 會幫 Error 編一個聽起來合理的原因，例如系統只回傳通用 500，AI 卻寫成「可能是您的網路不穩定」，這句話沒有任何佐證。
• CTA 全部寫「確定」「送出」，高風險操作（付款、刪除）使用者不知道按下去會發生什麼。

10人工把關與安全限制

AI／Agent／Tool 介入在哪幾步

這幾關不下放

元件清單有沒有漏

AI 只會處理你列出來的元件，漏列的狀態（例如 loading 中）不會自動被生出來。

字元上限是否套進真的畫面稿

AI 給的斷行預覽是估算，最終要貼進實際畫面或 Canva 稿件用真字型量一次。

Error 原因是否真的有錯誤碼佐證

這是最重要的一關——AI 寫的每個「已知原因」都要回頭核對錯誤碼對照表，沒有佐證的打回去改通用話術。

多語言版本是否重新量過長度

英文、日文字數膨脹不同，不能只驗中文版。

CTA 動詞是否偏離白名單

新造的動詞由人決定要不要正式收進白名單，不是 AI 用了就算數。

安全與權限限制

Error message 不要洩漏系統內部細節

「資料庫連線逾時」「SQL 執行失敗」這類訊息會暴露架構，對使用者也沒有意義，一律轉譯成使用者能懂的通用話術。

驗證提示不要暗示帳號是否存在

「此帳號不存在」與「密碼錯誤」分開寫，等於幫外部人測帳號清單，登入類錯誤要合併成一句「帳號或密碼不正確」。

畫面清單如含真實使用者資料要先代稱

截圖或範例文字裡若有真實姓名、電話、案號，上傳前先替換成假資料。

錯誤碼對照表屬於系統資訊，分享範圍要設對

這份表交給 AI 或放進共用助手時，確認不會被更廣的對象看到。

11Checklist 與驗收標準

做的時候逐項打勾

• 每個元件與狀態都有對應文案，清單沒有遺漏
• 每條文案標注實際字數，且未超過字元上限
• CTA 動詞都在白名單內，且能讓使用者知道按下去的後果
• Error 文案一律包含發生什麼、能怎麼做、去哪找協助三段
• Error 的具體原因都對照得到已知錯誤碼，沒有佐證的已改成通用話術
• 對照表已套進實際畫面稿驗證過斷行

做完了才檢查：全部成立才算完成

1. 每個元件與每個狀態都有對應文案，清單沒有遺漏。
2. 每條文案標注實際字數，且未超過該元件的字元上限。
3. CTA 動詞都在白名單內，且能讓使用者知道按下去的後果。
4. Error 文案一律包含發生了什麼、能怎麼做、需要協助去哪三段。
5. Error 的具體原因都能對照到已知錯誤碼，沒有佐證的原因已改成通用話術。
6. Empty State 包含可能的原因（如果系統知道）與使用者的第一個可行動作。
7. 至少一種非中文語言版本已檢查過斷行與長度膨脹。
8. 對照表已套進實際畫面稿或版型驗證斷行。
9. UX Microcopy Table 放在共用位置，並交給工程與 QA 核對上線內容。

12實際案例

13相關方法與下一步

可直接使用RELATED PROMPTS