咖啡厅暖色设计系统指南

它解决的具体问题

当团队同时维护多个界面时，最常见的痛点不是「不够好看」，而是「说不清楚」。设计师说「再暖一点」，工程师该改的是 primary 还是 secondary？按钮在 disabled 状态下是否保留焦点样式？这类争论通常只有一个根源：缺少一份能被执行的规范。

这份技能把设计系统从截图和形容词，转写成可以在代码评审中逐条核对的文档。它不生成图片，也不替你做审美决策，而是把已有的品牌意图展开成令牌、组件规则与验收标准。

核心能力与工作步骤

核心能力： 以设计系统规范作者的身份输出实现就绪的指南，而不是营销文案。

关键步骤（遵循 SKILL.md 的撰写流程）：

1. 先用一句话重述设计意图，再展开具体规则
2. 先定义 design tokens 与基础约束，再谈组件
3. 写明组件的解剖结构、变体、状态与交互行为
4. 补充可测试的无障碍验收条件与内容写作要求
5. 给出反模式示例，以及旧界面迁移说明
6. 以一份能在 code review 中执行的 QA 清单收尾

硬性要求：

• 组件状态必须覆盖 default、hover、focus-visible、active、disabled、loading、error
• 规则禁止只依赖「柔和」「精致」这类模糊形容词，必须锚定令牌、阈值或具体示例
• 约束语言区分强制与推荐：must 表示不可协商，should 表示建议
• 无障碍声明必须可在实现中测试；审美与可访问性冲突时，优先可访问性

适用边界

• 它是写作与约束工具，不渲染界面、不生成视觉稿，最终视觉一致性仍需由实现方验证
• 不自动安装依赖、修改系统权限、创建持久化任务或执行下载内容
• 涉及发送、发布、删除、付款、部署等外部写入操作，需先展示目标与影响，并取得用户明确确认
• 凭据仅用于用户指定的官方服务，不回显、不记录、不转发到无关地址
• 命令与代码默认仅作参考，仅在用户明确要求且目标范围清楚时才执行