Apple Design Skill 是一套给 Agent 用的界面审查规则，底稿来自 Apple 开发者网站上的 Human Interface Guidelines。维护者是 dickwu，仓库把 123 页 HIG 整理成可按需加载的参考文件，再把 Apple 的界面词汇翻译到 Flutter、React Native、Tauri、Electron、SwiftUI、UIKit 和 AppKit 上。
审查依据不是几句风格口诀
不少“苹果风”提示词只留下圆角、毛玻璃和 SF 字体，遇到桌面窗口、键盘操作或无障碍就失去判断。这套 Skill 先读对应的 guideline 文件，再按八条设计原则、无障碍、平台惯例、视觉工艺、交互、文案六个方向检查。每条结论要求写出问题、依据和修复方式，其中依据要引用具体的 guideline 文件与标题，修复则用目标框架的写法给出。
从界面到代码的检查项
内置模式覆盖 App 图标、深色模式、Liquid Glass、导航结构、Apple Pay、表单和权限引导，也包括 iPhone Duo 的双屏布局。代码审查模式不需要截图，会搜索 Apple Pay 按钮是否由 Apple 绘制、Liquid Glass 是否叠在内容上、固定宽度是否妨碍折叠屏适配，并以 path:line 标出位置。改进模式还会先规划色板、字体角色和布局，再按无障碍优先的顺序安排修改。
无障碍部分会给出可核对的数值，例如文字缩放、对比度、控件尺寸，而不是泛泛建议“注意可读性”。平台惯例按手机与桌面分开：移动端看标签栏、工具栏、sheet、搜索和安全区，桌面端看菜单栏、窗口、侧边栏、快捷键和设置页。视觉部分还会追问设计有没有观点，是否落进生成式界面常见的模板外观。
安装与调用
通过 skills CLI 安装：
npx skills add dickwu/apple-design-skill |
只装给 Claude Code 可加 -a claude-code，全局安装加 -g。也可以把仓库 clone 到 ~/.claude/skills/apple-design，在 Claude Code 里用 /apple-design 调用。之后直接提出“按 Apple HIG 审查这个 Flutter 首页”“检查这个 Tauri 设置页的可访问性”这类请求。参考文件会随 Apple 更新，仓库提供 node scripts/pull-hig.mjs 重新抓取，要求 Node 18 以上。
一个 Flutter 双端项目的审查场景
假设团队用 Flutter 做 macOS 与 iOS 双端应用，界面能跑，但设置页看起来像网页套壳。把页面截图或源码交给 Agent，要求先审平台惯例和无障碍，再处理视觉。输出会指出侧栏、工具栏、快捷键和控件尺寸分别偏离了哪条规则，而不是只说“不够苹果”。同一套检查也可以用在发布前：核对权限引导、空状态、错误提示和深色模式是否一致。审查前最好限定范围，例如只查设置页或只查支付流程；一次读太多文件，结论会散，也不容易复核。
和直接读 HIG 的差别
直接翻上百页文档成本高，通用审查提示词又容易凭印象给建议。Apple Design Skill 的价值在于把原文、路由和跨框架译名预先装好，让结论可追溯。它不替代设计师：品牌是否该走 Apple 风格、平台差异如何取舍，仍要产品自己决定。把它当成一位熟悉 HIG 的审查员，比当成自动改 UI 的工具更合适。
报告里的修复项可以按无障碍、平台惯例、视觉和文案排序。先处理会阻断发布的项，再处理观感问题。若团队使用 Cursor 或 Codex，安装时选对应 Agent 即可，规则文件相同；跨工具协作时，以仓库中的 SKILL.md 为准。这样不同成员拿到的判断标准一致，讨论也能回到具体条款，而不是各自争论“像不像苹果”。
限制与适用人群
Apple HIG 本身会修订，仓库同步时间决定规则新旧；iPhone Duo 等新形态的指导也可能变化。它不是 Apple 官方产品，指南文字版权归 Apple，项目也不保证每条建议都适合 Android 或 Web。适合正在做 Apple 平台应用、需要把审查过程留痕的团队；如果产品已有成熟设计系统，或目标平台不是 Apple，收益会小很多。
入口
仓库：https://github.com/dickwu/apple-design-skill 。README 提供各 Agent 的安装方式，未提供独立在线 Demo。许可证以仓库为准。本文按官方 README 和仓库元数据整理，未在本机完整实测。