clarify

clarify skill 概覽

clarify skill 的功能

clarify skill 專門改善不夠清楚的 UX 文案：例如標籤、輔助說明、空狀態、 onboarding 指引、確認訊息，尤其是錯誤訊息。它適合用在使用者感到困惑、但問題並不在於介面少了功能，而是在於文字讓產品更難理解的情境。

clarify for UI/UX Design 最適合誰

clarify for UI/UX Design 最適合產品設計師、UX writer、前端團隊、PM，以及在上線前檢查介面文字的 AI agents。它在畫面已經存在、工作重點是把措辭變得更清楚、更可執行、也更符合使用者當下情境時，特別有用。

使用 clarify skill 真正要解決的工作

使用者安裝 clarify，通常不只是為了「改寫文案」。更常見的是拿它來回答更實際的問題：為什麼某段訊息沒有效果、使用者最可能誤解什麼、需要補多少背景、當下該用什麼語氣，以及該怎麼改寫，才能讓人看完就知道下一步，不會猶豫。

clarify skill 與一般 prompt 的差異

clarify 最大的差異在於流程。它不是那種自由發揮的「把這段寫得更好看」prompt，而是會推動一套結構化檢查，涵蓋：

• 受眾的技術程度
• 使用者當下的心理狀態
• 使用者需要採取的行動
• 現有文字缺少了哪些情境資訊
• 具體的清晰度問題類型，例如術語過多、語意模糊、預設過多、語氣不合時宜

因此，當重點是功能理解是否到位，而不是單純潤飾風格時，clarify skill 會比鬆散的文案修飾 prompt 更實用。

導入 clarify skill 前的重要提醒

最大的阻礙在於它高度依賴前置設計脈絡。這個 skill 明確要求 /frontend-design，而如果目前還沒有任何設計脈絡，它也會要求你先執行 /teach-impeccable。所以 clarify install 在 skill 層面雖然不難，但輸出品質很仰賴你能否先提供產品、受眾與介面情境。

如何使用 clarify skill

clarify install 與呼叫方式

從 repository 片段來看，clarify 是可由使用者直接呼叫的 skill，帶有參數提示 [target]。實務上，請從 pbakaus/impeccable repository 安裝，並把 clarify 用在特定畫面、流程、元件或文案區塊，而不是丟一個模糊的整體產品需求。

一個實用的安裝模式是：

• 從 https://github.com/pbakaus/impeccable 加入這個 skill
• 用 clarify 指向明確目標，例如 modal、checkout error、onboarding step 或 settings page

如果你的環境支援具名 skill 安裝指令，就使用 repo URL 加上 clarify 的 skill 路徑；如果不支援，就匯入該 repository 的 skill set，然後直接呼叫 clarify。

先讀這個檔案

先看：

• SKILL.md

在目前提供的 tree 中，這個 skill 沒有看到額外的 README.md、metadata.json、rules 或 resource 資料夾。也就是說，大部分真正的使用方式與判斷邏輯，都集中在 SKILL.md，不像大型 skill 那樣有更深的隱藏實作層可供挖掘。

使用 clarify skill 前需要先準備的脈絡

在請 clarify 改寫任何內容之前，先整理好：

• 目前的原始文案
• 它出現在 UI 的哪個位置
• 受眾是誰
• 使用者在那一刻可能的心理狀態
• 使用者下一步應該做什麼
• 任何產品或領域限制

這很重要，因為這個 skill 評估的是「在情境中的清晰度」，不是孤立看一句話。即使改寫後技術上正確，只要忽略了急迫感、信任感或使用者能力差異，仍然可能失敗。

為什麼 frontend-design 相依性很重要

clarify usage 明確串接到 /frontend-design。這是一個很強的訊號，代表這個 skill 預期你先完成設計原則盤點與情境蒐集流程。若跳過這一步，輸出也許在語言上更乾淨，但仍可能不符合流程位置、資訊層級，或使用者目標。

如果目前還沒有設計脈絡，skill 會要求你先執行 /teach-impeccable。請把這視為必要前置設定，而不是可有可無的加分步驟。

哪種輸入最能讓 clarify skill 發揮效果

好的輸入要具體，而且範圍明確。例如你可以提供：

• current text: “Authentication failed”
• surface: login form error under password field
• audience: non-technical SaaS users
• mental state: frustrated, trying to get back into work quickly
• desired action: retry password, reset if needed
• constraint: do not imply the email is wrong for security reasons

這樣的輸入，會比下面這種說法產出更好的結果：

• “Improve this error message”

把模糊需求改成好用的 clarify prompt

較弱的寫法：

• “Make our onboarding copy clearer.”

較好的寫法：

• “Use clarify on step 2 of onboarding. Current copy: ‘Configure your workspace for enhanced collaboration efficiency.’ Audience: first-time small business users with low technical confidence. Mental state: curious but impatient. Goal: get them to invite teammates. Constraint: keep headline under 8 words and body under 20 words.”

後者提供了足夠資訊，讓 clarify skill 可以判斷術語問題、缺少的情境、行動是否清楚，以及語氣是否合適。

clarify skill 可能會檢查哪些面向

根據 SKILL.md，這個 skill 會系統性檢查：

• 使用者可能看不懂的術語
• 語意模糊或可被多重解讀的地方
• 會隱藏主體責任的被動語態
• 文案太長或太短
• 對使用者知識的過度預設
• 缺少「發生了什麼」或「下一步該做什麼」的情境資訊
• 不符合當下情境的語氣

這很有價值，因為它直接告訴你這個 skill 最擅長抓哪一類問題。

建議的 clarify usage 工作流程

一個實際可行的流程是：

1. 先執行 /frontend-design 並蒐集脈絡。
2. 一次只選一個目標介面，不要丟整個 app。
3. 貼上目前的原始文案。
4. 說明受眾、心理狀態，以及希望的下一步行動。
5. 先要求診斷，再要求改寫。
6. 依照 UI 空間與產品限制檢查輸出。
7. 把修訂後的文字放回相鄰狀態一起測，例如 success、loading 和 failure。

比起一開始就直接要改寫、不先做診斷，這個流程通常更容易做出正確決策。

先請 clarify skill 做診斷，再定稿改寫

若想讓 clarify guide 發揮更高價值，建議先問：

• 哪裡不清楚
• 使用者可能會誤解什麼
• 缺少了哪些情境資訊
• 語氣是否符合當下時機

之後再要求提供替代版本。這能避免過早改寫，也有助於判斷真正的問題到底是措辭、資訊架構，還是系統回饋不足。

clarify for UI/UX Design 最適合的使用情境

這個 skill 特別適合處理：

• 沒有說清楚發生什麼、也沒交代下一步的錯誤訊息
• 依賴內部術語的標籤
• 預設使用者已有先備知識的 onboarding 指引
• 指示模糊或沒有幫助的空狀態
• 技術上正確、但讀起來難懂的設定說明
• 無法帶來安心感的確認訊息與成功訊息

clarify skill 不適合處理的情況

不要期待 clarify 解決以下問題：

• 更深層的 UX flow 問題，例如介面結構本身就讓人困惑
• 無法實質修改的法律或合規文案
• 已經很清楚、只是想進一步雕琢品牌語氣的需求
• 想直接拿去做在地化、卻沒有另外檢查翻譯限制的文字

如果問題出在互動設計，而不是措辭，應該先修正 flow，再使用 clarify。

clarify skill 常見問題

clarify skill 對新手友善嗎？

算是友善，只要你能提供目前文案和基本情境。不過新手最常略過的，正是最關鍵的部分：受眾描述與使用者狀態。少了這些，clarify 還是能改善句子表面，但不一定能穩定提升可用性。

使用 clarify 一定要整個 impeccable repo 都裝嗎？

你主要需要的是 clarify 這個 skill，以及它所依賴的情境前置 skill。由於目前可見的 tree 裡，這個 skill 只露出 SKILL.md，所以不需要先額外研究很多 repo 內容。真正的關鍵，是你能使用 /frontend-design，以及必要時的 /teach-impeccable。

clarify skill 和直接叫 AI 改寫文案有什麼不同？

一般 prompt 通常優先追求「寫得更漂亮」。但 clarify skill 更適合在你需要 AI 檢查理解風險時使用，例如術語、預設前提、語意模糊、缺少下一步，以及在真實使用情境下語氣是否適合。

clarify 很適合處理錯誤訊息嗎？

是的。錯誤狀態正是它最強的使用情境之一，因為這個 skill 明確要求你提供使用者的心理狀態與下一步行動。這通常會比一般「幫我寫個友善的錯誤訊息」prompt 產出更有用的改寫。

clarify skill 只適合 microcopy 嗎？

不只。它也能協助處理簡短指引與介面說明。不過它最適合的是範圍明確的 UI 文字，而不是長篇行銷頁面或完整內容設計系統。

什麼情況下不該安裝 clarify？

如果你的主要需求是視覺設計評論、資訊架構重整，或長文件的內容策略，就不適合 clarify install。當真正的瓶頸是產品介面中的文字清晰度時，再安裝它最有價值。

如何改進 clarify skill 的使用效果

給 clarify skill 更好的脈絡，不是更多文字

想最快提升 clarify 輸出品質，重點是提供更好的限制條件：

• 精確的 UI 位置
• 字數限制
• 受眾熟悉程度
• 情緒狀態
• 期望的下一步行動
• 不可出現的說法或法律限制

只有在額外上下文真的會改變解讀時，提供更多周邊文案才有幫助。

把診斷和改寫拆開

先請 clarify 列出簡短的問題清單，再要求最終文案。這樣可以先看出問題到底是語意模糊、情境不足，還是語氣不對。當失敗模式先被點名，後續修訂通常會更好。

明確說出目前發生了什麼，以及希望使用者下一步做什麼

很多品質不佳的輸出，都是因為模型不知道使用者下一步該怎麼做。請同時提供：

• 剛剛發生了什麼
• 使用者現在應該做什麼

例如，“payment failed” 本身資訊不足；除非 skill 知道正確動作是 retry、update card、contact support 或 wait，否則很難改出真正有用的文字。

明確寫出使用者心理狀態

這個 skill 對使用者心理狀態的權重特別高，而這也是它最實用的槓桿之一。像是「使用者現在壓力很大，而且被流程卡住」就應該產出和「使用者只是輕鬆探索設定」完全不同的文案。如果你省略這點，語氣很容易變成一種泛泛的友善，而不是實際有幫助。

要求多個版本，並比較取捨

可以要求提供 2 到 4 個版本，並讓每個版本有不同優先順序，例如：

• 最精簡版本
• 最能安撫使用者的版本
• 最導向行動的版本
• 最白話、適合非技術使用者的版本

這樣你能比較不同清晰度取捨，而不是把單一改寫直接當成定案。

留意 clarify skill 常見失誤

clarify skill 仍可能表現不佳的常見方式包括：

• 只把句子修順，卻沒補上缺失的情境
• 把文案寫得更友善，卻變得不夠具體
• 移除其實使用者需要知道的技術名詞
• 產出超出 UI 元件可容納長度的文字
• 只改寫單一句子，卻和相鄰狀態不一致

這些通常是輸入問題，不只是模型本身的問題。

迭代時帶入真實 UI 限制

第一輪之後，就應該把需求收得更精準，例如：

• “Keep label under 24 characters”
• “Do not mention internal system names”
• “Must be understandable at 8th-grade reading level”
• “Should not blame the user”
• “Preserve security ambiguity around account existence”

這一步是讓 clarify guide 從編輯建議提升到可正式落地的關鍵。

把 clarify 與相鄰畫面一起檢查

如果使用者會連續遇到一串訊息，就不要只單獨優化其中一句。應該把觸發條件、訊息本身，以及下一步一起看。就算錯誤訊息那一行已經很清楚，只要 CTA label 或周邊 helper text 仍然含糊，整體體驗還是可能失敗。

建立可重複使用的 clarify prompt 範本

若團隊會反覆使用 clarify for UI/UX Design，建議建立一個固定範本，包含：

• target surface
• current copy
• audience
• mental state
• desired action
• constraints
• ask: diagnose first, then rewrite

這能降低不同審查者之間的不一致，也會讓這個 skill 更容易被正確使用。

用真實使用者證據提升 clarify 輸出品質

如果你手上有 support tickets、usability notes，或使用者實際誤讀這段文字的案例，請一併提供。當 clarify 能根據已觀察到的困惑來改寫，而不是只針對假設中的困惑調整時，效果通常會明顯更好。