hig-components-search

hig-components-search 技能概觀

hig-components-search 是一個 Apple HIG 技能，用來設計以搜尋為核心、且需要處理導覽關係的介面中的搜尋欄位、頁面控制與路徑控制。當你需要回答「我的 App 裡搜尋應該怎麼運作」、「分頁控制應該放在哪裡」、或「我要怎麼呈現階層結構又不讓使用者混淆」這類實際問題時，hig-components-search 技能就很適合。對 UI 設計師、產品團隊，以及需要 HIG 對齊建議的代理來說，它特別有用，尤其是在搜尋 UX、搜尋範圍、搜尋建議與目錄式導覽這些情境。

這個技能最適合處理什麼

這個技能最擅長的是元件行為、放置位置與使用者預期的問題，而不只是單純的視覺樣式。它能幫你判斷該用搜尋欄位、頁面控制，還是路徑控制，以及每種元件在真實介面中應該如何表現。

為什麼值得安裝

hig-components-search install 的主要價值在於決策支援：它能減少「搜尋要不要即時更新」、「什麼時候適合用範圍切換」、「頁面控制或路徑控制何時其實不合適」這些判斷上的猜測。這讓它比一般通用提示詞更有用，因為它會把輸出錨定在 Apple HIG 的導覽模式上。

什麼情況下很適合使用

如果你的輸入包含搜尋發現、篩選後結果、分頁內容、麵包屑、檔案階層，或祖先節點導覽，請選擇 hig-components-search for UI Design。對於有清單、資料庫、目錄、設定頁、檔案瀏覽器，或任何使用者需要在結構化內容中尋找或移動的介面來說，它都很適合。

如何使用 hig-components-search 技能

安裝並載入技能上下文

先把 hig-components-search 安裝到你的代理環境中，再在提出設計建議前，把模型指向這個技能上下文。典型的 hig-components-search usage 流程，是先用一段簡短的產品簡介呼叫技能，接著讓它把 HIG 規則套用到你指定的畫面或功能上。

提供正確的輸入

這個技能在你描述以下內容時效果最好：內容類型、使用者目標、導覽模型，以及限制條件。舉例來說，不要只說「設計搜尋」，而是請它為「一個大型文件資料庫的搜尋欄位，支援即時結果、可選類別篩選，且不需要進階查詢語法」提供建議。這樣能給技能足夠脈絡，去判斷該用搜尋欄位、範圍、標籤 token，或空狀態行為。

先讀這些檔案

先從 skills/hig-components-search/SKILL.md 開始，再開啟 references/search-fields.md、references/page-controls.md 和 references/path-controls.md。這三個檔案是最快理解 hig-components-search guide 背後實際指引的方法，也能避免把搜尋模式過度延伸到分頁或階層式使用情境。

一個有效的提示詞模式

提示詞要明確點出介面、內容，以及你要做的決策。範例：Apply hig-components-search to a macOS file browser. Recommend the search placement, whether to use scopes, and whether a path control should be standard or pop-up. 這比含糊的請求更有力，因為它會迫使技能回覆元件層級的建議，而不是泛泛的 UX 意見。

hig-components-search 技能 FAQ

hig-components-search 只跟搜尋欄位有關嗎？

不是。hig-components-search skill 也涵蓋頁面控制與路徑控制，所以當你的問題是導覽結構，而不只是查詢輸入時，它同樣派得上用場。這在團隊把搜尋、分頁與階層顯示混為一談時尤其重要。

如果我會自己寫一般提示詞，還需要這個嗎？

如果你已經熟悉 HIG 規則，且只需要快速提醒，也許不一定需要。但當你想要更可靠、可安裝、而且始終維持 Apple 導覽元件慣例的建議，並避開常見誤用時，就適合安裝 hig-components-search，例如把頁面控制誤當成階層式導覽來用。

這適合新手設計師嗎？

適合，只要你的目標是快速做出第一個正確判斷。這個技能對不確定何時該用搜尋建議、範圍控制或路徑控制的新手特別有幫助，因為它提供的是具體框架，而不是要他們自己去猜模式。

什麼情況下不該用？

不要把 hig-components-search 用在品牌設計、視覺裝飾，或一般版面配置系統上。若你的產品需要高度客製化的搜尋邏輯、企業級篩選分類法，或刻意偏離 Apple HIG 模式的行為，它也不是理想選擇。

如何改善 hig-components-search 技能

先把決策脈絡交代清楚

最好的結果通常來自包含平台、內容密度，以及使用者是在搜尋、瀏覽還是做階層導覽的輸入。例如：iPad app, 20,000 items, live search, optional scope buttons, results list updates as the user types. 這比「讓搜尋更好用」更有效，因為它能讓技能選對互動模型。

針對限制與不適配點要講清楚

如果介面無法即時更新、範圍選項有限，或階層深度很淺，都要明講。這些限制會改變 hig-components-search 應該建議即時搜尋、token，還是更簡單的模式。你前面說得越完整，輸出就越不會建立在假設上。

從一個具體畫面開始迭代

第一次輸出後，請技能針對單一畫面修正，而不是整個產品。很好的後續追問會像這樣：Revise this for empty states, default scope, and ancestor navigation on macOS. 這樣能縮小問題範圍，通常也會讓建議更具實作價值。

注意常見失誤模式

最常見的錯誤是過度使用搜尋範圍、把頁面控制拿去做非扁平式導覽，以及沒有清楚說明空狀態或結果回饋。如果第一次答案看起來太泛，請用確切的內容模型、結果數量，以及使用者下一步最可能的動作，重新跑一次 hig-components-search。