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