用 impeccable clarify 打磨界面文案從“用戶看不懂”到“發生了什么、為什么、下一步做什么”【免費下載鏈接】impeccableThe design language that makes your AI harness better at design.項目地址: https://gitcode.com/GitHub_Trending/im/impeccable本文是一份面向 AI Agent 與前端開發者的 UX 文案microcopy / interface copy實操指南講解 Impeccable 設計技能中clarify命令Fix/修復類目的方法論與執行規范。它回答的是界面中一個高頻真實問題當錯誤信息、表單校驗、空狀態、按鈕標簽讓用戶產生困惑、焦慮或誤操作時如何在不改變產品事實與品牌語氣的約束下把文案改寫成“用戶能立刻理解發生了什么、什么重要、下一步該做什么”的清晰語言。讀完本文你將掌握一條可復用的四步文案手術流程——全路徑語言審計、信息層級決策、按功能分類重寫、系統化驗證——并了解它如何在 Impeccable 命令體系中與audit、polish、onboard、harden等命令銜接協作。一、clarify 是什么它在 Impeccable 技能體系中的位置Impeccable 是一個面向前端界面設計工作的 Agent 技能包倉庫根目錄的 skill/SKILL.src.md 是其主入口。它把復雜的設計工作組織成一組以斜杠命令觸發的子命令按類目劃分為 Build構建、Evaluate評估、Refine精修、Enhance增強、Fix修復、Iterate迭代等。其中clarify屬于Fix 類目官方描述為clarify [target]— Fix — Improve UX copy, labels, and error messages改進 UX 文案、標簽和錯誤信息在 skill/scripts/command-metadata.json 的命令元數據里它的觸發場景被擴展得更完整Improve unclear UX copy, error messages, microcopy, labels, and instructions to make interfaces easier to understand. Use when the user mentions confusing text, unclear labels, bad error messages, hard-to-follow instructions, or wanting better UX writing.也就是說當用戶提到“這段文案很繞”“這個報錯看不懂”“標簽不清不楚”“說明很難照做”或明確要求“更好的 UX 寫作”時Agent 就應當路由到clarify。而在 scripts/lib/skill-categories.js 的分類實現里clarify與distill同屬 SIMPLIFY - reduce and clarify簡化——刪減與澄清語義簇說明它的本質目標不是“寫得更花哨”而是通過刪減歧義與冗余讓界面信息變簡單、可理解。clarify的參考文檔在倉庫中有多處鏡像副本——因為 Impeccable 會把同一套參考文檔同步到各 AI 工具各自的技能目錄詳見 scripts/build.js 中的同步邏輯與 deprecated skill 清理表例如 skill/reference/clarify.md本體、.trae-cn/skills/impeccable/reference/clarify.mdTrae 中文目錄鏡像與 plugin/skills/impeccable/reference/clarify.md共享插件子樹。它們內容一致本文即基于這份參考文檔展開。觸發與調用方式根據 skill/SKILL.src.md 的路由規則clarify是帶[target]參數的子命令可用npx impeccable clarify [target]、/impeccable clarify [target]或對應工具前綴如{{command_prefix}}impeccable clarify觸發。參考文檔開頭的元信息 **Additional context needed**: audience knowledge and emotional state.點明了執行此命令前的兩個必補上下文受眾知識audience knowledge這條界面文案寫給誰目標用戶對產品領域、術語、技術背景有多少既有認知情緒狀態emotional state用戶此刻處于什么情境是首次試用、提交失敗、即將執行不可逆刪除還是剛完成一次成功操作缺少這兩項輸入任何“改寫”都是盲改——因為同一條文案在不同受眾與情緒下的最優寫法可能截然相反。一條清晰的工作流把clarify.md與相鄰參考文檔對照可以看到它的執行邊界與上下游銜接上游發現audit技術質量檢查見 skill/reference/audit.md負責從無障礙、性能、響應式等維度掃出“文案是否可達”而clarify接手的是“文案是否可懂、可行動”這一語義層。執行主體clarify只在文案語義層作業不負責把按鈕做更大或重排布局那是layout/adapt的事。下游收尾參考文檔最后一句明確要求——當文案讀起來已經干凈清晰后交給/impeccable polishskill/reference/polish.md做最終的質量把關alignment、spacing、一致性等視覺與微細節層面。二、核心前提先讀懂用戶再動筆改文案參考文檔給出的總綱值得逐字拆解Rewrite unclear interface text so users understand what happened, what matters, and what to do next. Preserve factual meaning, product terminology, and brand voice.重寫不清晰的界面文本讓用戶理解發生了什么、什么重要、接下來做什么。保留事實含義、產品術語與品牌語氣。這一定義設置了三條不可逾越的改寫紅線也是 Agent 判斷“該不該動這句話”的邊界紅線含義違反后果示例Preserve factual meaning事實性含義必須保留不得增刪或歪曲把“每 24 小時同步一次”寫成“實時同步”Preserve product terminology產品術語要保持原樣不能為通俗而犧牲準確把用戶已學會的“工作區Workspace”換成“文件夾”Preserve brand voice品牌語氣要延續不能因追求“友好”而風格跳變嚴肅的財務工具突然出現網絡流行語參考文檔同時給了兜底條款“Infer audience and task from product context and surrounding UI.Ask before changing factual claims, legal meaning, or a term that may be domain-specific.”從產品上下文與周邊界面推斷受眾與任務在改動事實性陳述、法律含義或可能屬于領域專有的術語之前必須先詢問用戶。這與 skill/reference/polish.md 中“Ask before changing claims”改動任何聲明前先詢問的口徑完全一致——澄清的任務是讓表達變清楚不是替產品團隊做事實決策。三、第一步審計語言——讀全路徑而非孤立字符串參考文檔的核心方法論第一條是Read the entire interaction path, not isolated strings.閱讀完整交互路徑而不是孤立的字符串。UI 文案的歧義往往不在單句內部而在句子與句子、狀態與狀態之間。一個“刪除成功”的 toast 本身沒問題但如果它前面是“確認刪除這個項目”的確認框、按鈕叫“確定”整條路徑的語義就是脫節的。執行審計時需逐項排查以下語言病灶即“要找出什么”模糊的名詞、動詞與動作如“項目”“處理”“更新”這類在不同上下文里指代不同的詞內部黑話與隱含知識代碼層術語直接裸露到界面如把 API 狀態碼“401”“配額超限”當主消息展示或默認用戶了解產品內部機制含糊的標簽、結果與系統狀態看不出“這個開關控制什么”“現在系統處于什么階段”缺失的后果、恢復路徑或時間信息報錯只說“失敗”不說是否已回滾、數據是否安全、何時能重試術語與大小寫不一致同一概念在導航、標題、按鈕、正文里叫法不一如 “Login / Sign in / 登錄”混用冗余的標題、引言、幫助文本與確認標題已經把狀態說清楚了正文又來復述一遍確認框已經寫清動作按鈕卻只寫“是”在真實寬度或翻譯環境下會斷裂的文本未考慮按鈕寬度放不下、德語/俄語等語言的超長詞導致布局破裂忽視壓力、風險、成功或緊迫性的語氣刪除賬戶與點贊成功用同一語氣就是語氣失當。判斷“模糊”的依據不是文案作者的主觀喜好而是周圍 UI 與產品上下文共同揭示的受眾與任務——這也再次呼應了開頭“需要受眾知識與情緒狀態”兩個輸入項。四、第二步建立信息層級——每個狀態只回答四個問題在動筆改寫之前clarify要求先為每一個界面狀態做一次信息優先級決策。參考文檔給出四層金字塔用戶此刻需要知道的唯一事實The one fact the user needs now——最高優先級下一步可用的動作The action available next會改變決策的支撐性上下文Supporting context that changes the decision——只有真正影響判斷的細節才該出現適合此刻的語氣The appropriate tone for this moment。配套的寫作紀律是Say each idea once.每個想法只說一遍。若標題已經說明了狀態如“無法連接到服務器”那么引言要么補充新信息如“我們會在 30 秒后自動重試”要么干脆消失。這正是信息層級思維與“堆文案”的分水嶺層疊冗余的說明不產生信息量只增加認知負擔。這一點同樣體現在 Impeccable 相鄰命令的理念里——skill/reference/distill.md 的精簡準則同樣強調 “No headers restating intros, no repeated explanations, say it once”clarify在做語義澄清distill在做整體刪減二者共享“一次只表達一遍”的核心紀律。五、第三步按功能分類重寫——五類界面文案的手術規范參考文檔把界面文案按功能角色拆成五類每一類都有獨立的改寫規范。這是整份文檔里實操密度最高的部分。5.1 動作與導航Actions and navigation當結果并非不言自明時使用具體的“動詞 賓語”。標簽要描述“點擊后會發生什么”而不是描述觸發它的手勢或隱喻。例如 “下一步”不如“保存并繼續”“點擊這里”應改為對動作本身的描述。同一概念在產品內保持同一組名詞與動詞——這是術語一致性的最小單位。破壞性動作必須點名對象與后果明確寫出被刪的對象和不可逆的代價如“刪除 23 個未同步的草稿記錄”而非“刪除”。安全前提下優先用 Undo 而非二次確認可恢復的操作提供“撤銷”按鈕的價值高于讓用戶再點一次彈窗。確有必要確認時消息和按鈕上都要寫清動作名稱而不是用通用的Yes/No/OK/Submit。按鈕文字應與確認內容一致消息說“刪除項目”按鈕就應是“刪除項目”而不是“確定”從而形成語義閉環。5.2 表單Forms使用常駐標簽persistent labelsplaceholder 只是示例不能替代標簽——一旦用戶開始輸入placeholder 就消失了若它還承載字段說明等于讓用戶失憶。格式與資格要求要在提交之前給出如密碼位數、文件類型、命名規則而不是等用戶填錯提交后再用校驗報錯告知。僅在信息用途不明顯時才解釋“為什么收集它”如詢問手機號時說明“用于接收驗證碼”。必填與選填的處理必須一致同一種視覺約定全站統一不要讓用戶在一處習慣、在另一處迷惑。校驗信息的寫法指出需要關注什么 如何修正且不指責用戶不說“你填錯了”而說“密碼至少需要 8 位當前為 5 位”。相關指導文本放在字段附近錯誤要以無障礙可宣告的方式被讀屏軟件獲知詳見第七節。5.3 錯誤與權限Errors and permissions一條“可行動的錯誤消息”必須回答三個問題這也是 Agent 重寫報錯時的固定檢查項什么失敗了what failed為什么——當原因已知且有用時why, when known and useful如何恢復或還有什么替代方案how to recover or what alternative remains。配套的硬性紀律包括不要把內部錯誤碼當作主消息暴露給用戶“Error 0x80070057”不能是正文最多作為技術附注不要承諾系統其實無法知曉的原因或解決方案——比如不確定時不要寫“您的網絡有問題”寫“無法連接到服務器請稍后重試”即可對待隱私、支付、刪除、訪問權丟失與被阻塞的工作要嚴肅語氣可以溫暖但不能開玩笑。這類場景用戶處于高壓力情緒任何俏皮話都會被誤讀為輕慢。5.4 加載、空狀態與成功狀態Loading, empty, and success states加載文案要說出真實操作名“正在上傳第 2 份文件”而非“請稍候”并在等待確有意義時設定誠實預期。有確定進度就展示進度條絕不虛構進度比如系統實際無法估算時不要偽造“還剩 10 秒”。空狀態要先分辨它是哪種“空”首次使用first use、無搜索結果no results、被篩選清空filters、無權限permissions還是出錯failure。不同原因要給出不同解釋與下一步動作——例如“暫無搜索結果”應跟“換個關鍵詞試試”或“清除篩選條件”而“首次使用”應引導去創建第一個對象。這與 skill/reference/onboard.md 對 first-run / empty-state 的設計指導相互印證clarity 負責把“現在是什么狀態、接下來能做什么”寫清楚onboard 負責把整個首次體驗流程設計對。成功狀態要確認已完成的結果只有當“下一個后果會改變用戶該做什么”時才提及它例如“已保存。您的更改將在 2 小時內對所有訪問者生效。”。日常性的成功應保持簡短——把每個操作都慶祝一遍會稀釋真正重要時刻的信號。5.5 幫助與說明性文本Help and instructional text幫助文本應回答一個隱含的問題而不是復述控件本身輸入框旁寫“用于登錄郵箱”而非“郵箱”。不常見或很深的細節用**漸進披露progressive disclosure**承載——默認折疊成“了解更多”需要時再展開避免常態界面信息過載。鏈接文本離開上下文也要能獨立成義“了解定價方案”好于“點此/了解更多”這種懸空鏈接。純圖標控件需要無障礙可訪問名稱accessible name不能只有視覺圖形。六、Voice、無障礙與本地化把文案寫成可翻譯、可朗讀、可縮放的語言這一節把界面的語氣voice、無障礙accessibility與國際化localization擰成一套可執行規則。Voice 與語氣分層Voice品牌一貫的聲音保持穩定Tone面對當下情境的語氣隨之調整——這是回扣“情緒狀態”輸入項的關鍵。始終使用平實語言但不要為了“通俗”而抹平用戶真正掌握的領域術語——術語是被信任的專業性不是敵人。面向翻譯i18n與無障礙的四條硬性寫法寫完整、可翻譯的整句消息而不是拼接的碎片。Hello, name , you have count messages在英語里勉強能讀但在詞序不同的語言里根本無法翻譯應寫成帶占位符的完整模板如You have {count} new messages.。把變量與數字結構化成翻譯者可以重排的形式結構化占位符而非硬拼接讓譯者按目標語言的自然語序自由擺放。允許文本擴展不要過早縮寫。界面文案要為本地化后的長度增長預留空間德語、俄語、芬蘭語通常比英語長 30% 以上并在第七節驗證里在 200% 縮放下實測。alt 文本要傳達圖片承載的信息純裝飾性圖片用空 altalt避免讀屏用戶被噪聲打斷。無障礙與信息呈現的三條紅線讀屏名稱與可見標簽、結果保持一致——用戶聽到的控件名必須和看到的按鈕字一模一樣不能一個是“刪除項目”一個是“OK”不要依賴標點、顏色或圖標單獨承載信息——色弱用戶看不出“紅色錯誤”只靠 ? 也無法表意必須搭配文字成功/錯誤等狀態變化要能被無障礙地宣告如通過 aria-live 區域讓讀屏實時播報不能只在視覺上悄悄變化。最后當術語不一致已經蔓延到整個產品時維護一份簡短的術語表terminology glossary界面不是文學創作不要為了“文學效果”在同一概念上變換用詞——變化制造不確定。七、第四步驗證——在上下文里重讀而不是逐行重讀改完不等于改對。參考文檔要求在流程上下文中in context重讀文案并對下列維度逐項測試無需隱藏產品知識即可理解comprehension without hidden product knowledge——把文案拿給“不知情讀者”視角檢查能否看懂錯誤態、空態與決策點的可行動性actionability——用戶在每個停頓點是否知道下一步點哪里事實準確與術語一致factual accuracy and consistent terminology——沒有在重寫中偷換事實目標寬度與 200% 縮放下的可掃讀性scanability at target widths and 200% zoom——放大兩倍后是否換行破碎、信息是否仍能一眼掃到重點長名稱、本地化擴展、復數形式與動態值——1 filesvs1 file、多語言數字格式、超長用戶名截斷等邊界可訪問名稱與狀態變化宣告與后果和情緒情境相匹配的語氣。驗證的收斂判據是一句可執行的標尺The final copy is as short as it can be without removing meaning or recovery.最終文案應短到——在不刪除意義或恢復路徑的前提下——不能再短。這條判據說明clarify的產出不是“最短”而是“恰好短”刪到仍能傳達意義、仍能給出恢復辦法為止。寫完后再回頭讀一遍交互路徑確認每個狀態仍然四問齊全事實 → 動作 → 支撐上下文 → 語氣。八、收尾何時結束 clarify何時交給 polish參考文檔的最終工作流指令非常明確當文案讀起來已經順暢清晰the language reads cleanly時交給/impeccable polish做最后一道檢查。這條交接邊界與 Impeccable 的整體哲學一致——在 skill/SKILL.src.md 的開篇原則里寫著 “Verify in bounded passes, not a loop”構建完整、批量檢查一次、修復、最多再確認一輪然后停止打磨。clarify只處理文案語義層polish則在其后把界面在視覺、對齊、間距、術語大小寫與最終一致性上收口參考 skill/reference/polish.md 中 “Keep terminology, capitalization, punctuation, and factual copy consistent” 的檢查項。兩個命令各司其職、有明確的交接點而不是在同一個文件上無限疊加編輯輪次。九、一頁紙速查把 clarify 方法論固化成清單是否已明確受眾知識與情緒狀態高風險/高壓力場景刪除、支付、隱私優先于常規場景處理。是否讀了完整交互路徑而非單個字符串標題、按鈕、toast、空態、后續頁是否語義連續每個狀態是否回答四問現在的事實 → 可用動作 → 會改變決策的上下文 → 恰當語氣破壞性動作是否點名對象與后果可恢復的用 Undo確認框與按鈕是否使用同一動作動詞而非Yes/OK表單是否有常駐標簽要求是否在提交前給出校驗是否指出問題與改法、且不指責用戶錯誤是否回答“什么失敗/為什么/如何恢復”內部錯誤碼是否沒有充當主消息加載是否寫真實操作、不虛構進度空狀態是否區分首次/無結果/篩選/權限/失敗成功是否簡短是否寫成可翻譯的完整消息、結構化變量、允許長度擴展是否在同一概念上保持統一術語讀屏名稱是否與可見標簽一致是否不只依賴顏色/圖標/標點表意是否在目標寬度、200% 縮放下驗證換行與可掃讀語氣是否匹配后果是否符合“不能再短而不丟失意義與恢復路徑”的收斂判據文案干凈后是否已交接給/impeccable polish做最終質量收口把這套清單交給 Agent 作為clarify的執行模板它就擁有了從“改字”升級為“系統化澄清界面語義”的完整決策框架——這正是這份參考文檔真正的價值所在它訓練的是一種先判斷信息優先級、再按功能與情緒選擇寫法、最后在上下文中驗證的文案工程能力。【免費下載鏈接】impeccableThe design language that makes your AI harness better at design.項目地址: https://gitcode.com/GitHub_Trending/im/impeccable創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考 用 impeccable clarify 打磨界面文案：從“用戶看不懂”到“發生了什么、為什么、下一步做什么”
用 impeccable clarify 打磨界面文案從“用戶看不懂”到“發生了什么、為什么、下一步做什么”【免費下載鏈接】impeccableThe design language that makes your AI harness better at design.項目地址: https://gitcode.com/GitHub_Trending/im/impeccable本文是一份面向 AI Agent 與前端開發者的 UX 文案microcopy / interface copy實操指南講解 Impeccable 設計技能中clarify命令Fix/修復類目的方法論與執行規范。它回答的是界面中一個高頻真實問題當錯誤信息、表單校驗、空狀態、按鈕標簽讓用戶產生困惑、焦慮或誤操作時如何在不改變產品事實與品牌語氣的約束下把文案改寫成“用戶能立刻理解發生了什么、什么重要、下一步該做什么”的清晰語言。讀完本文你將掌握一條可復用的四步文案手術流程——全路徑語言審計、信息層級決策、按功能分類重寫、系統化驗證——并了解它如何在 Impeccable 命令體系中與audit、polish、onboard、harden等命令銜接協作。一、clarify 是什么它在 Impeccable 技能體系中的位置Impeccable 是一個面向前端界面設計工作的 Agent 技能包倉庫根目錄的 skill/SKILL.src.md 是其主入口。它把復雜的設計工作組織成一組以斜杠命令觸發的子命令按類目劃分為 Build構建、Evaluate評估、Refine精修、Enhance增強、Fix修復、Iterate迭代等。其中clarify屬于Fix 類目官方描述為clarify [target]— Fix — Improve UX copy, labels, and error messages改進 UX 文案、標簽和錯誤信息在 skill/scripts/command-metadata.json 的命令元數據里它的觸發場景被擴展得更完整Improve unclear UX copy, error messages, microcopy, labels, and instructions to make interfaces easier to understand. Use when the user mentions confusing text, unclear labels, bad error messages, hard-to-follow instructions, or wanting better UX writing.也就是說當用戶提到“這段文案很繞”“這個報錯看不懂”“標簽不清不楚”“說明很難照做”或明確要求“更好的 UX 寫作”時Agent 就應當路由到clarify。而在 scripts/lib/skill-categories.js 的分類實現里clarify與distill同屬 SIMPLIFY - reduce and clarify簡化——刪減與澄清語義簇說明它的本質目標不是“寫得更花哨”而是通過刪減歧義與冗余讓界面信息變簡單、可理解。clarify的參考文檔在倉庫中有多處鏡像副本——因為 Impeccable 會把同一套參考文檔同步到各 AI 工具各自的技能目錄詳見 scripts/build.js 中的同步邏輯與 deprecated skill 清理表例如 skill/reference/clarify.md本體、.trae-cn/skills/impeccable/reference/clarify.mdTrae 中文目錄鏡像與 plugin/skills/impeccable/reference/clarify.md共享插件子樹。它們內容一致本文即基于這份參考文檔展開。觸發與調用方式根據 skill/SKILL.src.md 的路由規則clarify是帶[target]參數的子命令可用npx impeccable clarify [target]、/impeccable clarify [target]或對應工具前綴如{{command_prefix}}impeccable clarify觸發。參考文檔開頭的元信息 **Additional context needed**: audience knowledge and emotional state.點明了執行此命令前的兩個必補上下文受眾知識audience knowledge這條界面文案寫給誰目標用戶對產品領域、術語、技術背景有多少既有認知情緒狀態emotional state用戶此刻處于什么情境是首次試用、提交失敗、即將執行不可逆刪除還是剛完成一次成功操作缺少這兩項輸入任何“改寫”都是盲改——因為同一條文案在不同受眾與情緒下的最優寫法可能截然相反。一條清晰的工作流把clarify.md與相鄰參考文檔對照可以看到它的執行邊界與上下游銜接上游發現audit技術質量檢查見 skill/reference/audit.md負責從無障礙、性能、響應式等維度掃出“文案是否可達”而clarify接手的是“文案是否可懂、可行動”這一語義層。執行主體clarify只在文案語義層作業不負責把按鈕做更大或重排布局那是layout/adapt的事。下游收尾參考文檔最后一句明確要求——當文案讀起來已經干凈清晰后交給/impeccable polishskill/reference/polish.md做最終的質量把關alignment、spacing、一致性等視覺與微細節層面。二、核心前提先讀懂用戶再動筆改文案參考文檔給出的總綱值得逐字拆解Rewrite unclear interface text so users understand what happened, what matters, and what to do next. Preserve factual meaning, product terminology, and brand voice.重寫不清晰的界面文本讓用戶理解發生了什么、什么重要、接下來做什么。保留事實含義、產品術語與品牌語氣。這一定義設置了三條不可逾越的改寫紅線也是 Agent 判斷“該不該動這句話”的邊界紅線含義違反后果示例Preserve factual meaning事實性含義必須保留不得增刪或歪曲把“每 24 小時同步一次”寫成“實時同步”Preserve product terminology產品術語要保持原樣不能為通俗而犧牲準確把用戶已學會的“工作區Workspace”換成“文件夾”Preserve brand voice品牌語氣要延續不能因追求“友好”而風格跳變嚴肅的財務工具突然出現網絡流行語參考文檔同時給了兜底條款“Infer audience and task from product context and surrounding UI.Ask before changing factual claims, legal meaning, or a term that may be domain-specific.”從產品上下文與周邊界面推斷受眾與任務在改動事實性陳述、法律含義或可能屬于領域專有的術語之前必須先詢問用戶。這與 skill/reference/polish.md 中“Ask before changing claims”改動任何聲明前先詢問的口徑完全一致——澄清的任務是讓表達變清楚不是替產品團隊做事實決策。三、第一步審計語言——讀全路徑而非孤立字符串參考文檔的核心方法論第一條是Read the entire interaction path, not isolated strings.閱讀完整交互路徑而不是孤立的字符串。UI 文案的歧義往往不在單句內部而在句子與句子、狀態與狀態之間。一個“刪除成功”的 toast 本身沒問題但如果它前面是“確認刪除這個項目”的確認框、按鈕叫“確定”整條路徑的語義就是脫節的。執行審計時需逐項排查以下語言病灶即“要找出什么”模糊的名詞、動詞與動作如“項目”“處理”“更新”這類在不同上下文里指代不同的詞內部黑話與隱含知識代碼層術語直接裸露到界面如把 API 狀態碼“401”“配額超限”當主消息展示或默認用戶了解產品內部機制含糊的標簽、結果與系統狀態看不出“這個開關控制什么”“現在系統處于什么階段”缺失的后果、恢復路徑或時間信息報錯只說“失敗”不說是否已回滾、數據是否安全、何時能重試術語與大小寫不一致同一概念在導航、標題、按鈕、正文里叫法不一如 “Login / Sign in / 登錄”混用冗余的標題、引言、幫助文本與確認標題已經把狀態說清楚了正文又來復述一遍確認框已經寫清動作按鈕卻只寫“是”在真實寬度或翻譯環境下會斷裂的文本未考慮按鈕寬度放不下、德語/俄語等語言的超長詞導致布局破裂忽視壓力、風險、成功或緊迫性的語氣刪除賬戶與點贊成功用同一語氣就是語氣失當。判斷“模糊”的依據不是文案作者的主觀喜好而是周圍 UI 與產品上下文共同揭示的受眾與任務——這也再次呼應了開頭“需要受眾知識與情緒狀態”兩個輸入項。四、第二步建立信息層級——每個狀態只回答四個問題在動筆改寫之前clarify要求先為每一個界面狀態做一次信息優先級決策。參考文檔給出四層金字塔用戶此刻需要知道的唯一事實The one fact the user needs now——最高優先級下一步可用的動作The action available next會改變決策的支撐性上下文Supporting context that changes the decision——只有真正影響判斷的細節才該出現適合此刻的語氣The appropriate tone for this moment。配套的寫作紀律是Say each idea once.每個想法只說一遍。若標題已經說明了狀態如“無法連接到服務器”那么引言要么補充新信息如“我們會在 30 秒后自動重試”要么干脆消失。這正是信息層級思維與“堆文案”的分水嶺層疊冗余的說明不產生信息量只增加認知負擔。這一點同樣體現在 Impeccable 相鄰命令的理念里——skill/reference/distill.md 的精簡準則同樣強調 “No headers restating intros, no repeated explanations, say it once”clarify在做語義澄清distill在做整體刪減二者共享“一次只表達一遍”的核心紀律。五、第三步按功能分類重寫——五類界面文案的手術規范參考文檔把界面文案按功能角色拆成五類每一類都有獨立的改寫規范。這是整份文檔里實操密度最高的部分。5.1 動作與導航Actions and navigation當結果并非不言自明時使用具體的“動詞 賓語”。標簽要描述“點擊后會發生什么”而不是描述觸發它的手勢或隱喻。例如 “下一步”不如“保存并繼續”“點擊這里”應改為對動作本身的描述。同一概念在產品內保持同一組名詞與動詞——這是術語一致性的最小單位。破壞性動作必須點名對象與后果明確寫出被刪的對象和不可逆的代價如“刪除 23 個未同步的草稿記錄”而非“刪除”。安全前提下優先用 Undo 而非二次確認可恢復的操作提供“撤銷”按鈕的價值高于讓用戶再點一次彈窗。確有必要確認時消息和按鈕上都要寫清動作名稱而不是用通用的Yes/No/OK/Submit。按鈕文字應與確認內容一致消息說“刪除項目”按鈕就應是“刪除項目”而不是“確定”從而形成語義閉環。5.2 表單Forms使用常駐標簽persistent labelsplaceholder 只是示例不能替代標簽——一旦用戶開始輸入placeholder 就消失了若它還承載字段說明等于讓用戶失憶。格式與資格要求要在提交之前給出如密碼位數、文件類型、命名規則而不是等用戶填錯提交后再用校驗報錯告知。僅在信息用途不明顯時才解釋“為什么收集它”如詢問手機號時說明“用于接收驗證碼”。必填與選填的處理必須一致同一種視覺約定全站統一不要讓用戶在一處習慣、在另一處迷惑。校驗信息的寫法指出需要關注什么 如何修正且不指責用戶不說“你填錯了”而說“密碼至少需要 8 位當前為 5 位”。相關指導文本放在字段附近錯誤要以無障礙可宣告的方式被讀屏軟件獲知詳見第七節。5.3 錯誤與權限Errors and permissions一條“可行動的錯誤消息”必須回答三個問題這也是 Agent 重寫報錯時的固定檢查項什么失敗了what failed為什么——當原因已知且有用時why, when known and useful如何恢復或還有什么替代方案how to recover or what alternative remains。配套的硬性紀律包括不要把內部錯誤碼當作主消息暴露給用戶“Error 0x80070057”不能是正文最多作為技術附注不要承諾系統其實無法知曉的原因或解決方案——比如不確定時不要寫“您的網絡有問題”寫“無法連接到服務器請稍后重試”即可對待隱私、支付、刪除、訪問權丟失與被阻塞的工作要嚴肅語氣可以溫暖但不能開玩笑。這類場景用戶處于高壓力情緒任何俏皮話都會被誤讀為輕慢。5.4 加載、空狀態與成功狀態Loading, empty, and success states加載文案要說出真實操作名“正在上傳第 2 份文件”而非“請稍候”并在等待確有意義時設定誠實預期。有確定進度就展示進度條絕不虛構進度比如系統實際無法估算時不要偽造“還剩 10 秒”。空狀態要先分辨它是哪種“空”首次使用first use、無搜索結果no results、被篩選清空filters、無權限permissions還是出錯failure。不同原因要給出不同解釋與下一步動作——例如“暫無搜索結果”應跟“換個關鍵詞試試”或“清除篩選條件”而“首次使用”應引導去創建第一個對象。這與 skill/reference/onboard.md 對 first-run / empty-state 的設計指導相互印證clarity 負責把“現在是什么狀態、接下來能做什么”寫清楚onboard 負責把整個首次體驗流程設計對。成功狀態要確認已完成的結果只有當“下一個后果會改變用戶該做什么”時才提及它例如“已保存。您的更改將在 2 小時內對所有訪問者生效。”。日常性的成功應保持簡短——把每個操作都慶祝一遍會稀釋真正重要時刻的信號。5.5 幫助與說明性文本Help and instructional text幫助文本應回答一個隱含的問題而不是復述控件本身輸入框旁寫“用于登錄郵箱”而非“郵箱”。不常見或很深的細節用**漸進披露progressive disclosure**承載——默認折疊成“了解更多”需要時再展開避免常態界面信息過載。鏈接文本離開上下文也要能獨立成義“了解定價方案”好于“點此/了解更多”這種懸空鏈接。純圖標控件需要無障礙可訪問名稱accessible name不能只有視覺圖形。六、Voice、無障礙與本地化把文案寫成可翻譯、可朗讀、可縮放的語言這一節把界面的語氣voice、無障礙accessibility與國際化localization擰成一套可執行規則。Voice 與語氣分層Voice品牌一貫的聲音保持穩定Tone面對當下情境的語氣隨之調整——這是回扣“情緒狀態”輸入項的關鍵。始終使用平實語言但不要為了“通俗”而抹平用戶真正掌握的領域術語——術語是被信任的專業性不是敵人。面向翻譯i18n與無障礙的四條硬性寫法寫完整、可翻譯的整句消息而不是拼接的碎片。Hello, name , you have count messages在英語里勉強能讀但在詞序不同的語言里根本無法翻譯應寫成帶占位符的完整模板如You have {count} new messages.。把變量與數字結構化成翻譯者可以重排的形式結構化占位符而非硬拼接讓譯者按目標語言的自然語序自由擺放。允許文本擴展不要過早縮寫。界面文案要為本地化后的長度增長預留空間德語、俄語、芬蘭語通常比英語長 30% 以上并在第七節驗證里在 200% 縮放下實測。alt 文本要傳達圖片承載的信息純裝飾性圖片用空 altalt避免讀屏用戶被噪聲打斷。無障礙與信息呈現的三條紅線讀屏名稱與可見標簽、結果保持一致——用戶聽到的控件名必須和看到的按鈕字一模一樣不能一個是“刪除項目”一個是“OK”不要依賴標點、顏色或圖標單獨承載信息——色弱用戶看不出“紅色錯誤”只靠 ? 也無法表意必須搭配文字成功/錯誤等狀態變化要能被無障礙地宣告如通過 aria-live 區域讓讀屏實時播報不能只在視覺上悄悄變化。最后當術語不一致已經蔓延到整個產品時維護一份簡短的術語表terminology glossary界面不是文學創作不要為了“文學效果”在同一概念上變換用詞——變化制造不確定。七、第四步驗證——在上下文里重讀而不是逐行重讀改完不等于改對。參考文檔要求在流程上下文中in context重讀文案并對下列維度逐項測試無需隱藏產品知識即可理解comprehension without hidden product knowledge——把文案拿給“不知情讀者”視角檢查能否看懂錯誤態、空態與決策點的可行動性actionability——用戶在每個停頓點是否知道下一步點哪里事實準確與術語一致factual accuracy and consistent terminology——沒有在重寫中偷換事實目標寬度與 200% 縮放下的可掃讀性scanability at target widths and 200% zoom——放大兩倍后是否換行破碎、信息是否仍能一眼掃到重點長名稱、本地化擴展、復數形式與動態值——1 filesvs1 file、多語言數字格式、超長用戶名截斷等邊界可訪問名稱與狀態變化宣告與后果和情緒情境相匹配的語氣。驗證的收斂判據是一句可執行的標尺The final copy is as short as it can be without removing meaning or recovery.最終文案應短到——在不刪除意義或恢復路徑的前提下——不能再短。這條判據說明clarify的產出不是“最短”而是“恰好短”刪到仍能傳達意義、仍能給出恢復辦法為止。寫完后再回頭讀一遍交互路徑確認每個狀態仍然四問齊全事實 → 動作 → 支撐上下文 → 語氣。八、收尾何時結束 clarify何時交給 polish參考文檔的最終工作流指令非常明確當文案讀起來已經順暢清晰the language reads cleanly時交給/impeccable polish做最后一道檢查。這條交接邊界與 Impeccable 的整體哲學一致——在 skill/SKILL.src.md 的開篇原則里寫著 “Verify in bounded passes, not a loop”構建完整、批量檢查一次、修復、最多再確認一輪然后停止打磨。clarify只處理文案語義層polish則在其后把界面在視覺、對齊、間距、術語大小寫與最終一致性上收口參考 skill/reference/polish.md 中 “Keep terminology, capitalization, punctuation, and factual copy consistent” 的檢查項。兩個命令各司其職、有明確的交接點而不是在同一個文件上無限疊加編輯輪次。九、一頁紙速查把 clarify 方法論固化成清單是否已明確受眾知識與情緒狀態高風險/高壓力場景刪除、支付、隱私優先于常規場景處理。是否讀了完整交互路徑而非單個字符串標題、按鈕、toast、空態、后續頁是否語義連續每個狀態是否回答四問現在的事實 → 可用動作 → 會改變決策的上下文 → 恰當語氣破壞性動作是否點名對象與后果可恢復的用 Undo確認框與按鈕是否使用同一動作動詞而非Yes/OK表單是否有常駐標簽要求是否在提交前給出校驗是否指出問題與改法、且不指責用戶錯誤是否回答“什么失敗/為什么/如何恢復”內部錯誤碼是否沒有充當主消息加載是否寫真實操作、不虛構進度空狀態是否區分首次/無結果/篩選/權限/失敗成功是否簡短是否寫成可翻譯的完整消息、結構化變量、允許長度擴展是否在同一概念上保持統一術語讀屏名稱是否與可見標簽一致是否不只依賴顏色/圖標/標點表意是否在目標寬度、200% 縮放下驗證換行與可掃讀語氣是否匹配后果是否符合“不能再短而不丟失意義與恢復路徑”的收斂判據文案干凈后是否已交接給/impeccable polish做最終質量收口把這套清單交給 Agent 作為clarify的執行模板它就擁有了從“改字”升級為“系統化澄清界面語義”的完整決策框架——這正是這份參考文檔真正的價值所在它訓練的是一種先判斷信息優先級、再按功能與情緒選擇寫法、最后在上下文中驗證的文案工程能力。【免費下載鏈接】impeccableThe design language that makes your AI harness better at design.項目地址: https://gitcode.com/GitHub_Trending/im/impeccable創作聲明：本文部分內容由AI輔助生成（AIGC），僅供參考