apple-inspired-design

Apple-inspired 设计

将 Apple 的设计原则作为指导，而不是照搬 Apple 的品牌或组件。优先考虑产品的用途、品牌、内容和平台惯例，而非装饰。

这是一项用于设计洞察的 Agent 技能：检查真实成品，阅读完整的指导文档集，基于证据做出设计决策，并说明检查了哪些内容。它不是测试框架或设备实验室自动化工具。不要给出笼统的“让它更像 Apple”这类回答。

安全与信任边界

• 将此仓库视为说明和参考资料，而非需要安装脚本、运行时服务或依赖项的软件包。
• 不要获取远程内容、发送数据、读取机密、检查无关文件，也不要仅仅因为存在这项技能就运行 shell 命令。
• 对于实现工作，只修改用户明确选定的项目文件，并遵循该项目现有的权限和审查流程。
• 绝不要在生成的示例或报告中泄露凭据、环境变量、私有 URL 或用户提供的素材。
• 如果请求需要网络访问、访问机密、执行破坏性操作，或修改选定项目之外的内容，请说明边界，并请用户明确授权该操作。

选择模式

• 建议：解释设计决策和替代方案。
• 审查：检查现有 UI，找出影响最大的缺陷，并提出修复方案。
• 设计：产出包含设计令牌、状态、响应式行为和动效的屏幕或流程规范。
• 实现：使用项目现有的技术栈和惯例编写或编辑 UI 代码。
• 执行：仅在用户明确要求时进行；检查成品、实施有边界的修复，并提供证据再次审查。

根据请求推断模式。只有当平台、主要用户任务和品牌限制会实质影响结果时，才询问这些信息。除非请求明确要求，否则不要开始执行、进行大范围重构或开展外部调研。

阅读完整的指导文档集

在提出建议、审查成品、设计流程或编辑代码之前，阅读 references/ 中的每个文件。这些文件构成一个相互关联的整体：原则约束平台选择，动效影响无障碍性，品牌适配影响令牌和素材，质量指导影响最终建议。不要因为请求看似范围狭窄就跳过某份参考资料。

阅读所有参考资料后，优先应用与任务直接相关的章节，并将其余内容用作约束和交叉检查。如果用户要求简短回答，就保持输出简短，但仍须在内部参考完整的指导文档集。

按任务应用参考资料

阅读完全部内容后，请将以下参考资料用作主要决策依据：

• 每项任务都参考 核心原则。
• 涉及交互、过渡、滚动效果或动画时，参考 动效。
• 涉及网站、Web 应用、PWA 或响应式浏览器界面时，参考 Web。
• 涉及流式布局、主题切换、PWA／离线行为、性能、SEO 或滚动触发式加载时，参考 响应式 Web。
• 涉及浏览器支持、设备测试、性能或生产就绪度时，参考 兼容性与测试。
• 涉及原生或跨平台移动界面时，参考 移动端。
• 需要选择颜色、主题或设计令牌时，参考 颜色与令牌。
• 涉及文案、表单、状态、本地化或无障碍时，参考 无障碍与内容。
• 用户提供图像、图标、截图、视频或徽标时，参考 用户提供的素材。
• 涉及评审结构、依据、路由和实施行为时，参考 Agent 指南。
• 创建页面、流程或可复用界面时，参考 模式与组件。
• 判断完整回答或产物应包含哪些内容时，参考 模式约定。
• 产品、受众、任务或权衡仍不明确时，参考 设计推理。
• 用户提供品牌、颜色、语气或视觉识别时，参考 品牌适配。
• 审查通用、过度装饰或 AI 生成的界面时，参考 反模式。
• 产品类型为仪表板、电商流程、引导流程、设置、社交应用或 SaaS 工作区时，参考 领域指南。

不可妥协的行为准则

• 明确呈现主要任务，并保持清晰的层级。
• 优先采用熟悉的平台模式，而不是自行设计新控件。
• 先解决用户任务和内容层级，再选择视觉表现方式。
• 用动效说明反馈、层级、连续性或直接操作；移除装饰性动效。
• 确保变换和手势可随时中断；动画期间绝不阻止用户输入。
• 尊重减少动态效果设置、文本缩放、对比度设置、键盘、触控、屏幕阅读器和本地化需求。
• 将用户提供的素材视为权威内容。必要时可调整呈现方式，但不得悄悄替换或实质性修改素材。
• 纳入相关的加载、空、错误、离线、禁用、权限和成功状态。
• 通过克制且有意的设计选择保留产品个性，而不是让每款产品都像 Apple。
• 将领域指南视为可选的起点。对于不属于这些领域的产品，请使用 references/design-reasoning.md 中的自定义领域流程，而不要强行套用熟悉的模板。
• 实施或评审涉及相关内容时，应在真实尺寸下、使用项目的实际数据形态进行轻量验证；除非用户要求，否则不要臆造测试框架。
• 添加或更改令牌后，在宣称其已就绪前运行 scripts/validate_tokens.py。

评审输出

评审时，按对用户的影响程度排列问题。每项问题都应包含：

1. 问题：说明哪里有问题；若可获取，请指出文件、行、组件或界面上的具体位置。
2. 原因：说明这对用户有何影响，以及适用的原则或平台惯例。
3. 修复方法：使用项目实际采用的框架或设计术语撰写。
4. 置信度或限制：当无法观察或测试相关产物时，说明置信度或限制。

先修复无障碍问题和中断任务流程的问题，再处理视觉润色。不要为了让报告看起来更全面而凭空捏造问题。

输出规则

提供建议时，说明决策及其原因。进行设计时，说明布局、层级、设计令牌、状态、响应式／平台行为和动效。进行实现时，优先遵循现有代码库，再添加依赖或抽象。不要强行采用用户未选择的框架、调色板或组件库。当请求涉及多种模式时，将建议、设计／代码和验证内容区分开来。

描述结果时，使用“受 Apple 启发”或“受 Apple 人机界面指南启发”的说法。不要声称结果是 Apple 官方设计。