hig-components-search

hig-components-search 技能概览

hig-components-search 是一项 Apple HIG 技能，专门用于设计导航密集型界面中的搜索字段、page controls 和 path controls。当你需要回答“我的 app 里的搜索应该怎么工作”“分页控件该放在哪里”或“如何在不让用户困惑的前提下展示层级关系”这类实际问题时，使用 hig-components-search 最合适。它尤其适合 UI 设计师、产品团队，以及需要符合 HIG 的搜索 UX、搜索范围（search scopes）、搜索建议和目录式导航指导的 agent。

这项技能最适合什么场景

这项技能最擅长处理的是组件行为、摆放位置和用户预期，而不只是视觉样式本身。它可以帮助你判断该用 search field、page control 还是 path control，以及每一种控件在真实界面中应该如何表现。

为什么值得安装

hig-components-search install 的核心价值在于决策支持：它能减少你在“搜索是否应该即时更新”“什么时候适合用 scopes”“page 或 path controls 什么时候其实并不合适”这些问题上的猜测。相比通用提示词，它更有价值，因为它会把输出锚定到 Apple HIG 的导航模式上。

什么时候适合使用

如果你的输入涉及搜索发现、过滤结果、分页内容、breadcrumbs、文件层级或祖先导航，那么就选 hig-components-search for UI Design。对于带有列表、资料库、目录、设置、文件浏览器，或者任何需要用户查找或穿行结构化内容的界面，它都是很合适的选择。

如何使用 hig-components-search 技能

安装并加载技能上下文

先在你的 agent 环境中安装 hig-components-search，然后在请求设计指导之前把模型指向该技能上下文。典型的 hig-components-search usage 流程是：先用简短的产品说明调用技能，再让它根据 HIG 规则去适配你的具体屏幕或功能。

提供合适的输入

这项技能最适合在你描述了内容类型、用户目标、导航模型和约束条件之后使用。比如，与其笼统地说“设计搜索”，不如明确提出：“为一个大型文档库设计一个带实时结果、可选分类过滤、且没有高级查询语法的 search field。” 这样，技能才有足够上下文来判断该用 search fields、scopes、tokens 还是空状态行为。

先阅读这些文件

先打开 skills/hig-components-search/SKILL.md，再查看 references/search-fields.md、references/page-controls.md 和 references/path-controls.md。这三份文件是理解 hig-components-search guide 背后实际指导、并避免把搜索模式过度延伸到分页或层级场景的最快方式。

一个好用的提示词模板

提示词要同时点明界面、内容和你要做的判断。例如：“把 hig-components-search 用到一个 macOS 文件浏览器中。请建议搜索位置、是否使用 scopes，以及 path control 应该用标准样式还是弹出样式。” 这比含糊的请求更有效，因为它会迫使技能给出组件级指导，而不是泛泛的 UX 建议。

hig-components-search 技能常见问题

hig-components-search 只和搜索字段有关吗？

不是。hig-components-search skill 还覆盖 page controls 和 path controls，因此当你的问题是导航结构而不只是查询输入时，它同样有用。这一点很重要，因为很多团队会把搜索、分页和层级展示混为一谈。

如果我能自己写普通提示词，还需要这个技能吗？

如果你已经很熟悉 HIG 规则，只是想快速回忆一下，那也许不一定需要。只有当你想要更可靠、可安装、并且始终贴合 Apple 导航组件规范的指导，同时避免常见误用——比如把 page controls 当成层级导航——时，才更值得安装 hig-components-search。

这适合新手设计师吗？

适合，只要你的目标是快速做出一个正确的初步判断。这个技能对新手尤其有帮助，因为他们常常不确定什么时候该用搜索建议、scope controls 或 path controls；它会给出一个具体框架，而不是让人自己去猜模式。

什么时候不该用它？

不要把 hig-components-search 用在品牌塑造、视觉装饰或通用布局系统上。如果你的产品需要高度定制的搜索逻辑、企业级过滤分类法，或者有意偏离 Apple HIG 模式的行为，它也不是合适的选择。

如何改进 hig-components-search 技能

一开始就把决策上下文说清楚

最好的结果来自包含平台、内容密度，以及用户是在搜索、浏览还是进行层级导航的输入。例如：“iPad app，2 万条内容，实时搜索，可选 scope buttons，结果列表会随着输入即时更新。” 这比“把搜索做得更好”更有用，因为它能让技能选择正确的交互模型。

明确说明约束和不适用之处

如果界面不能即时更新、scope 数量有限，或者层级深度很浅，一定要直接说明。这些约束会改变 hig-components-search 是否应该推荐即时搜索、tokens，还是更简单的模式。你前置说明得越充分，输出就越少依赖假设。

从一个具体屏幕开始迭代

第一次结果出来后，最好让技能针对某个具体屏幕继续细化，而不是整个产品。一个很好的追问是：“请把它改成适用于空状态、默认 scope 和 macOS 上的祖先导航。” 这样能缩小问题范围，通常也会提升建议的实用性。

注意常见失败模式

最常见的问题包括：过度使用 search scopes、把 page controls 用在非扁平导航中，以及对空状态或结果反馈说明不足。如果第一次答案显得过于泛泛，就用准确的内容模型、结果数量和用户下一步最可能的动作，重新运行 hig-components-search。