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