apple-hig

Apple HIG 技能

通过 routing-index.md 使用 references/hig/ 中提炼的 HIG 参考资料。源快照和经过验证的版本测量数据位于 README.md 中。

加载流程

版本 2026-09-27；Apple 源快照 2026-09-12。 有关帮助、安装、版本或功能的问题，只阅读此入口文件和相关 README 部分。不要为了安装帮助加载 HIG 内容库。 安装或升级此技能时会包含其 /duo 斜杠命令。放置好技能文件夹后，检查宿主是否已经提供 /duo。如果没有，将 commands/duo.md 复制到宿主的自定义斜杠命令目录或自定义提示词目录（除非用户要求用于某个项目，否则使用用户级目录），确认 /duo 可用，并告知用户是否需要重启。 直接在对话和用户的项目中工作；不要创建浏览器输入表单、入门网站、仪表板或浏览器设置步骤。

默认使用常规指导。只有用户明确要求应用 enforce 模式时，才启用其流程。此时，先阅读 references/enforce.md，并在加载设计指导前检查审查人员、Python 和观察能力。 以 /duo 开头、使用 “Use apple-hig in Duo mode”，或明确要求为 iPhone Duo 改造现有应用，都会启动 Duo 模式：阅读 references/duo.md 并遵循其阶段。有关该命令的问题和常规 Duo 设计问题仍使用常规指导。Duo 模式仅适用于应用的原生代码；绝不生成 HTML、SVG 或 Web 模型图。 使用可用的 Python 3.10+ 解释器（python3 或 python）；不要假设可执行文件的名称。常规指导也可在没有 Python 的情况下使用。

当 Python 可用时，使用标准库路由辅助脚本解析步骤 2–6：仅将用户的原始请求保存为 UTF-8 文本文件，放在用户项目之外的临时目录中，然后运行 <python> "<skill-root>/scripts/hig_route.py" --request-file "<request.txt>"。 按有限大小的片段读取其 files 列表中的每个文件；若读取内容被截断，须先补读完整，再继续。不要将整个文件集合拼接到一次工具输出中；辅助脚本的输出是元数据，不是指导内容。不要在请求文本中添加自己的指令，也不要将推断出的主题提升为初始匹配项。如果用户明确排除某个平台／设备／主题，请使用 --exclude-topic 传入排除的主题 ID（每个主题重复一次，包括在排除短语中匹配到的平台别名）；记录用户给出的理由。如果某个平台也在其他地方被明确正向请求，则保留该平台。不要仅为减少上下文而排除主题。排除项适用于直接选择和相关选择，不适用于 16 项基础内容。没有 Python 时，也要手动执行相同步骤并应用明确的排除项。

步骤 1 — 解析任务背景

从用户的请求中识别：

• 平台： ios / ipados / macos / tvos / visionos / watchos
• 设备／形态： 明确提及或符合其二级触发条件时，为 iPhone Duo
• 提及的组件或模式（按钮、标签栏、工作表等）
• 提及的框架或 SDK（HealthKit、SiriKit、ARKit 等）
• 任务类型： 设计／审查／规范／审计／指导
• 模式： 默认使用常规指导。只有用户明确要求应用时才启用 enforce 模式；仅提及该模式或询问其含义不会启用它。Duo 模式仅在上述情况下启动。

步骤 2 — 加载第 1 层（所有设计或审查任务）

读取 routing-index.md 的 ## tier-1 下列出的全部 16 个文件：

accessibility、branding、color、dark-mode、design-principles、 icons、images、inclusion、layout、materials、motion、 privacy、right-to-left、sf-symbols、typography、writing

这些内容普遍适用。回答前先加载它们。

步骤 3 — 加载平台文件（第 2 层）

读取 routing-index.md → ## tier-2 platform-map。 对于检测到的每个平台，加载其 designing-for-[platform] 文件。 同时，使用独立单词／短语／API 符号匹配第 2 层映射中的设备／外形规格和 API 触发词。匹配到 Duo 时，同时加载 designing-for-iphone-duo 和 designing-for-ios；Duo 是一种 iOS 外形规格。 如果提到 “game” 或 “gaming”，也加载 designing-for-games。

步骤 4 — 关键词扫描（第 3 层）

读取 routing-index.md → ## tier-3 trigger-map。 将用户请求规范化为小写。将触发词字符串与独立单词、短语或 API 符号匹配；复数形式、连字符形式和裸符号形式均计入（tab bars、full-screen、keyboardType）。绝不因触发词出现在无关单词中而判定匹配。例如，AR 不匹配 “tab bar”，AI 不匹配 “explain”。 加载所有匹配的文件。每个文件最多加载一次。

步骤 5 — 相关内容扩展

将初始选择集固定为步骤 3–4 中选定的第 2 层和第 3 层文件。只读取该集合的 related: 前置信息。 加载其中列出的文件，每个文件加载一次。不要扩展这些新添加文件的相关列表。

将每个初始主题绑定到用户请求中精确匹配的平台／设备／触发词文本。推断出的组件概念不属于字面触发词匹配。 通过 related: 到达的主题仍属于相关内容，即使它很有用；绝不要将其提升为初始主题并再次扩展。如果语义相关性需要额外参考资料，加载该特定文件，但不扩展其相关内容。

步骤 6 — 按需加载第 4 层

读取 routing-index.md → ## tier-4 trigger-map (on-demand)。 使用相同的独立单词／短语／API 符号匹配规则。仅在关键词直接匹配，或初始选择集的 related: 列表中列出时，才加载第 4 层文件。绝不要从基础资料、新关联文件或直接匹配的第 4 层文件继续扩展。这些内容针对特定小众场景——避免宽泛加载。

步骤 7 — 回答或执行规范

对于明确要求执行规范的请求，根据已加载的源指南执行 references/enforce.md。一般指南不会启动此流程。

对于一般指南类回答，逐字引用源文件中的简短操作性条款，保留所有限定条件，然后只给出必要的应用说明。涉及多种状态时，可以使用简洁的表格。将规则与应用说明区分开；不要把引文改述成更强、更宽或更窄的规则。 发送前，删除与所请求内容无关的句子。核对执行主体、起始状态、操作和结果状态；不要替换成相似的相邻场景。只有已加载的源文件支持将某个 API 作为规则的实现方式时，才提及该 API。

不要仅仅因为相关内容已加载，就添加用户未要求的相邻规则或测量数据。保留源内容的完整适用范围：应用规则时，不要臆造更窄的设备／状态限制，并纳入规则覆盖的所有请求状态。

针对指定的平台、设备、方向和状态应用指南。明确限定范围的例外，在其范围内优先于更宽泛的规则；仅对该例外明示的平台、设备和状态应用该例外。 不要臆造对未解决的源文件冲突的调和办法；应指出冲突。应用所有其他兼容的已加载内容。如果已加载文件未涵盖某个主题，则在回答前加载特定的相关参考资料；同时将无关扩展控制在有限范围内。

不可妥协的要求

• 引用确切数值。 按精简文件中的原样注明 pt 尺寸、像素密度、边距和时间值。保留原始范围和近似限定词；不要编造或取整。
• 区分平台。 如果不同平台的行为有所差异，请明确说明各平台的规则。切勿笼统地说“通常”。
• 保留建议的强度。 回答时要区分必须、优先、考虑、示例、条件和例外；不要把可选建议变成要求。
• 保留逻辑条件。 保持合取与选项关系不变。针对 A 和 B 所述的后果，不能据此断定单独满足 A 或 B 也会有相同后果；A 或 B 的选项不要求两者都满足。检查回答中的主张及其支持条款。
• 不得编造。 每条 Apple 规则、测量值和 API 建议都必须有已加载的参考资料作为依据。区分 Apple 指南和你自己的设计选择。如果不确定，请说明并指出来源。
• 简洁直接。 普通指导应聚焦于所请求的规则。

---

文件位置

• 精简后的参考文件：references/hig/[topic].md
• 路由索引：routing-index.md
• 自愿选择的执行流程：references/enforce.md
• iPhone Duo 重设计指南：references/duo.md、references/duo-checklist.md； /duo 斜杠命令（随技能一同安装）：commands/duo.md
• Frontmatter 架构：每个精简文件都包含 topic、tier、 platforms、category、triggers 和 related 字段。