design-for-ai

运用《Design for Hackers》中的视觉设计原则。每条建议都必须对应一条具体原则——不能只说“看起来更好”而不解释原因。

预检

使用任何模式前，都要先了解背景：

1. 扫描代码库——查找 CSS／样式文件、现有字体、颜色标记、组件库、PRODUCT.md、DESIGN.md，或 CLAUDE.md 中的 ## Design Context 部分。
2. 判断类型——该界面属于品牌型（设计本身就是产品：落地页、营销页面、作品集），还是产品型（设计服务于产品：应用 UI、仪表板、工具）？判断依据包括路由结构、组件类型和内容密度。
3. 记录现有内容——已加载的字体、已定义的颜色、正在使用的间距比例。各种模式都应基于现有内容构建，而不是从头开始。

如果没有设计背景，且用户未指定模式，则先进入 design 模式。

规则

所有模式都必须遵守以下规则。将这些规则与模式工作流程分开列出，避免它们被忽略。

• 界面类型决定建议方向。 品牌型界面采用更醒目的排版、明确的配色策略和入场动效。产品型界面采用系统字体、克制的配色，以及仅用于状态变化的动效。
• DESIGN.md 一旦定稿，就是准则。 项目中存在 DESIGN.md 时，在任何实现或审查之前都要重新阅读。要偏离时，先修改 DESIGN.md，再改代码。audit 和 polish 应将与其不符之处视为 Major。
• 注明原则出处。 每条建议都要指出来源：“眯眼测试（ch03）”“主次关系（ch06）”“暖色前进，冷色后退（ch09）”。不得提出无来源的主观意见。
• 严重程度等级（audit／polish）：Critical（破坏用途／可读性／无障碍性）· Major（影响明显）· Minor（错失优化机会）。
• 访谈节奏：每轮提出 2–3 个问题。等待用户回答后再继续。切勿一次性列出所有问题。
• 范围边界：如果请求涉及工具、框架或实现机制，而非视觉设计，请说明这一点，并建议用户转而查阅其他资料。

路由

根据用户的描述判断他们的需求。

模式	用户可能会说
design	“开始一个项目”／“什么方向”／“这是给谁用的”／“目的”／“独特设计”／“新的设计系统”／“让它看起来不像 AI 生成的”（从头开始）
surface	“为电视／手表／汽车／自助终端／语音设计”／“10 英尺 UI”／“这种设备该用什么布局”／“设备类型”／“让它适配 ”／“电子墨水”
fonts	“挑选字体”／“排版”／“字号比例”／“字体搭配”／“字体”／“选择一种字体”
color	“颜色”／“调色板”／“配色方案”／“颜色太多”／“构建调色板”
audit	“感觉不对劲”／“看看这个”／“哪里有问题”／“检查”／“审查”／“重新设计”／“改进”／“修复”／“没有层次感”／“没有视觉焦点”／“为什么看起来像 AI 生成的”／“诊断”
enhance	“提升我的网站”／“添加动效”／“该用哪个动画库”／“我该用 GSAP / three.js / Lenis 吗”／“滚动动画”／“让它鲜活起来”／“有哪些库”／“添加 3D 主视觉”／“粒子效果”
polish	“快完成了”／“最后检查一遍”／“动效”／“响应式”／“让它不那么普通”／“添加状态”／“交互”

无法明确判断模式 → 询问用户的需求，并展示该表格。

如果符合 audit 的触发条件，但代码库中没有现有的设计成果，建议先运行 design，以建立基础。

enhance 与 polish 的区别：enhance 决定该使用什么——哪个层级或库能实现所需效果，同时考虑适用场景和成本。polish 则是对已有动效／交互／响应式设计进行质量检查。“该用哪个动画库／添加 3D 主视觉” → enhance。“现有动效是否合适” → polish。

surface 与 polish 中的 responsive：surface 为输入方式、观看距离或注意力需求不同的设备类别选择模式和设计令牌（电视、手表、车载、语音、电子墨水）。polish 中的响应式检查则处理屏幕与 Web 连续范围内的宽度变化。设备类型不同 → surface。同一输入类别、宽度不同 → responsive/polish。

---

支柱技能

此技能是多技能 design-foundations 系统的视觉／美学 + 表层核心。它负责外观（设计基因、字体、颜色）、表层／设备类别，以及质量检查环节（审查、增强、润色）。其他设计支柱是同级技能——各自独立，会根据自身描述触发；如果工作涉及以下关注点，而非视觉外观，请转交给相应技能。（每个支柱都会引用可用性的法则，反之则不会——引用只向下，不形成循环。规范：docs/foundations-standards.md；完整映射：docs/pillar-taxonomy.md。）

同级支柱	在工作涉及以下内容时使用……
usability	用户是否能操作它——启发式评估（Nielsen）、UX 法则（Fitts/Hick/Miller）、可供性、认知负荷、导航／表单／表格／反馈模式。（audit 模式会调用其启发式评估。）
content-design	作为界面的文字——UX 文案、微文案、错误／空状态／按钮文案、语气与风格。不是视觉字体（那属于 fonts）。
data-viz	如实编码数据——图表选择、仪表板、数据墨水、图表垃圾、图表无障碍性。不是品牌配色（那属于 color）。
deceptive-patterns	影响的伦理——暗黑模式禁用清单；它是 ai-tells 的结构性对应项。
behavioral	用户为何采取行动／回来／转化——说服、习惯循环、情感化设计。它探讨正当机制；其暗黑版本是 deceptive-patterns。
journey	用户如何随时间推进——JTBD、旅程地图、IA／站点地图、流程、页面规格、落地页说服主线（附带 JOURNEY.md）。
design-systems	一种外观 → 一台生成外观的机器——令牌层级、组件、治理。它扩展 DESIGN.md，而非取代它。
ai-native	Agent／LLM 界面设计——生成式 UI、无固定屏幕的界面（尚无定论；由原则推导）。

这些支柱会逐步编写；尚未提供的同级技能表示其阶段尚未发布。无需中央路由器——Claude Code 会根据每项技能自身的描述触发它。

---

design

所需背景：用户正在构建什么，以及目标用户是谁。

确立基础，然后生成独特的设计基因——由原型驱动，在不同美学风格间重新混搭，绝不采用分布中的默认方案。

先阅读：

• ${CLAUDE_SKILL_DIR}/references/chapter-01-why-design-matters.md
• ${CLAUDE_SKILL_DIR}/references/chapter-02-purpose-of-design.md
• ${CLAUDE_SKILL_DIR}/references/foundations.md

1. 访谈

通过对话收集信息（每轮提出 2-3 个问题，然后等待回答）：

第 1 轮： 你在构建什么？目标受众是谁？它解决了什么问题？

第 2 轮： 用 3 个词描述个性／感受。主要使用场景是什么——主要在哪种设备上使用（手机、桌面、电视、手表、车载设备、自助终端、语音）？有哪些限制——框架、无障碍要求、现有品牌素材？

第 3 轮： 参考网站（希望呈现这种感觉）和反面参考（不要像这样）。

像协作者一样提问，而不是像填写表格一样：

• 围绕假设思考。 根据对方的回答，提出 2-3 个合理方向；问一个最能区分这些方向的问题。
• 具体胜过抽象。 提供能区分方向的示例——“面向运维工程师时，风格会显得信息密集、技术性强；面向高管时，则会更疏朗、更注重叙事”——让对方根据可观察到的效果来选择。
• 当用户回答简短时切换到确认模式（比如“都行”“随便”，或只回答一个词）：给出你的最佳判断，让对方提出异议。“听起来目标受众是运维工程师，所以我会把信息密集度当作一个优点——如果目标受众是高管，请告诉我。”
• 询问意图和品味（对方的专业知识）。所有视觉设计都由你推导（这是你的工作）。

关卡：继续之前，必须明确用途、目标受众、个性词、主要使用场景和定位（品牌／产品）。

如果主要使用场景不是网页屏幕（电视、手表、汽车、语音、电子墨水），或者用户需要设备类别的布局模式，那么在确定设计 DNA 之前，运行 surface（或阅读 ${CLAUDE_SKILL_DIR}/references/surfaces.md）——使用场景会限制哪些布局和令牌可用。

2. 原型

阅读 ${CLAUDE_SKILL_DIR}/references/archetypes.md。

将访谈内容映射到 2-3 个候选品牌原型（C 部分：个性词表，按内容压力筛选）。用一个确认性问题进行确认——先给出你的建议及理由：“这听起来像 Sage——沉稳、以证据为导向。还是你希望它更像 Hero？”

3. 设计 DNA——3 个候选方案

阅读 ${CLAUDE_SKILL_DIR}/references/design-dna.md 并遵循其中的流程：

1. 根据混搭规则构建 3 个候选方案——稳妥默认方案、张力方案、黑马方案。种子色相应来自内容；除非品牌素材限定了色相，否则各方案色相至少相差 60°。
2. 在展示之前，为每个候选方案运行调色板脚本，确保色板是实际生成且经过对比度检查的十六进制颜色： node ${CLAUDE_SKILL_DIR}/scripts/palette.mjs --seed <hue|#hex> --chroma <muted|balanced|vivid> --harmony <mono|analogous|complementary|split|triadic|tetradic> --scheme light （--scheme light 可缩小预览；第 4 步的最终运行使用 --scheme both。）
3. 使用 AskUserQuestion 展示，每个候选方案附一个预览（格式见 design-dna.md）。明确邀请对方回答“这些都不合适”。

4. DESIGN.md——决策关卡

选定候选方案后：

1. 使用 --scheme both 运行调色板脚本；将令牌输出和对比度报告粘贴到项目根目录的 DESIGN.md 中（模板见 design-dna.md）。
2. 使用 AskUserQuestion 确认：“就定这个？”／“调整”。确定之前不要编写任何 UI 代码。
3. 在项目的 CLAUDE.md 中添加简短的 ## Design Context 区块，指向 DESIGN.md：

## Design Context
- **Register**: product
- **Purpose**: help home cooks discover and save recipes
- **Audience**: busy parents, 30-45, cooking 4x/week, phone-first
- **Personality**: warm, practical, unhurried
- **DNA**: Warm Editorial + type voice from Editorial Minimalism — see DESIGN.md
- **Constraints**: React, WCAG AA, mobile-first

建议下一步——选定字体以确定字号层级，或直接参照 DESIGN.md 开始实现。

---

surface

所需上下文：设计面向的主要界面（设备类别），以及必须支持的其他界面。

确定适合目标界面的布局模式和样式令牌——手机、平板电脑、桌面设备、超宽屏、电视／10 英尺、手表、汽车、中控台、AR／空间计算、语音或电子墨水设备。界面的物理限制（视口、输入方式、观看距离、注意力）决定了哪些方案有效；此模式会选择适合的模式，并根据限制调整令牌。与库和框架无关——原则优先。

阅读：

• ${CLAUDE_SKILL_DIR}/references/surfaces.md
• ${CLAUDE_SKILL_DIR}/references/responsive.md（每种选定模式在屏幕 Web 界面中的宽度缩放规则）

如果存在 DESIGN.md，请先重新阅读——设计体系和现有令牌会限制表达方式。

按照 surfaces.md 中的步骤操作：

1. 指出主要界面；注明必须支持的其他界面。
2. 阅读其限制配置——会淘汰模式的那项是硬性限制。
3. 选择适用的第 1 层模式；注明每种模式在其他界面上的降级形式（该降级形式就是响应式方案，按照 responsive.md 逐步构建）。
4. 应用第 2 层样式差异——基础字体、目标尺寸、密度、动效预算、对比度策略。
5. 叠加设计体系——在界面允许的范围内体现品牌／产品风格。
6. 验证跨界面适配——每种主要模式在每个次要界面上都必须有明确的降级形式。

输出：所选界面、模式选择（模式 → 适合此界面的原因，并引用相关限制）、界面令牌差异表，以及发现的任何界面不匹配警示。如果尚无设计基因，建议使用 design 建立；若要对已构建的成果进行质量检查，则建议使用 polish。

---

fonts

所需上下文：呈现媒介（屏幕／印刷品）、目标设备、预期氛围。

阅读：

• ${CLAUDE_SKILL_DIR}/references/chapter-03-typography.md
• ${CLAUDE_SKILL_DIR}/references/appendix-fonts-and-typography.md

参考 ${CLAUDE_SKILL_DIR}/references/checklists.md 中的字体决策树。

依次完成：

1. 媒介——屏幕还是印刷品？分辨率／设备？
2. 正文字体——根据媒介与形式的关系进行选择
3. “n”测试——识别字母结构（人文主义、几何主义、写实主义）
4. 搭配——选择结构相近的字体以求协调，或采用强烈对比
5. 字号比例——建立比例字号级数。阅读 ${CLAUDE_SKILL_DIR}/references/chapter-05-proportions.md 了解比例。
6. 行高——正文使用 1.2–1.4em
7. 字符——使用弯引号、正确的破折号，不要伪造粗体／斜体

设计体系会调整建议：品牌使用展示字体和流体 clamp() 缩放；产品使用系统字体和固定 rem 缩放。

输出：字体栈、字号级数、CSS 自定义属性，以及每项选择的理由。

---

色彩

所需背景：目标氛围、内容密度、现有品牌色（如有）。

阅读：

• ${CLAUDE_SKILL_DIR}/references/chapter-08-color-science.md
• ${CLAUDE_SKILL_DIR}/references/chapter-09-color-theory.md

参阅 ${CLAUDE_SKILL_DIR}/references/checklists.md 中的色彩决策树。

逐步分析：

1. 氛围 — 设计应带来怎样的感受？
2. 背景 — 根据内容密度选择合适的背景
3. 基色色相 — 与氛围和文化背景相匹配
4. 配色方案 — 根据色轮构建（单色、类似色、互补色等）
5. 功能色 — 错误用红色，成功用绿色，链接用蓝色，CTA 使用最大对比度
6. 深度 — 运用冷暖关系（暖色前进，冷色后退）
7. 阴影 — 使用偏移色相，而非纯黑色
8. 无障碍 — 测试色盲适用性，并提供冗余提示

品牌类设计可采用坚定或浓郁的色彩策略。产品类设计默认采用克制策略。

使用随附脚本生成设计令牌——不要手动编造十六进制色阶： node ${CLAUDE_SKILL_DIR}/scripts/palette.mjs --seed <hue|#hex> --chroma <muted|balanced|vivid> --harmony <rule> --scheme both 脚本会生成 12 阶中性色与强调色阶、协调色、功能色和 WCAG 对比度报告（通过构造方式确保对比度达标）。调整种子并重新运行，不要手动编辑十六进制颜色。

输出：色彩令牌（脚本生成的 CSS 自定义属性）、无障碍说明、设计依据。

---

审查

所需背景：要审查的代码库或设计文件。

系统化设计审查。此模式负责视觉审查——字体排印、色彩、构图、层级和视觉识别。如果发现的问题涉及用户能否操作界面（启发式评估、UX 定律、可供性、认知负荷、模式适配），则应调用 usability 同级技能并运行其启发式评估（Nielsen 的 10 项原则 + 0–4 严重程度量表，依据其 references/usability-principles.md）；将其发现整合进同一张按严重程度排序的表格。以下视觉审查内容保持不变——这里只引用可用性审查，不将其内容移入此处。

阅读 ${CLAUDE_SKILL_DIR}/references/checklists.md，查看完整的视觉检查清单和决策树。

逐一检查每个部分。针对问题最严重的 2–3 个部分，加载相应章节参考文件，为诊断提供依据：

部分	参考文件
目的与基础	chapter-01-why-design-matters.md、chapter-02-purpose-of-design.md
字体排印	chapter-03-typography.md、appendix-fonts-and-typography.md
比例与布局	chapter-05-proportions.md
构图	chapter-06-composition.md
视觉层级	chapter-07-visual-hierarchy.md
色彩	chapter-08-color-science.md、chapter-09-color-theory.md
SEO 与可发现性	chapter-04-technology-and-culture.md
动效与交互	motion.md、interaction.md
响应式设计	responsive.md
设计识别	ai-tells.md
可用性与启发式原则（可操作性）	→ usability 技能（Nielsen 10 项原则 + 严重程度量表；不对应本地参考文件）

所有章节和参考文件路径均相对于 ${CLAUDE_SKILL_DIR}/references/；可用性一行会调用同级技能。

对于跨领域问题，参阅 ${CLAUDE_SKILL_DIR}/references/techniques.md，了解转换模式。

输出：按严重程度排列的发现表格。示例行：

严重程度	问题	原则	修复方案
严重	正文在屏幕上使用 14px 的 Garamond	中等篇幅与字体不匹配（ch03）：低 ppi 下斜轴会模糊	改用 Georgia 或 Source Serif Pro；最小字号提高到 16px

然后建议使用合适的模式修复每个问题。

---

enhance

所需上下文：用户想要的效果、项目的设计风格（如果存在 DESIGN.md，则参考其中内容），以及正在运行的网站／代码库。

确定要用什么来提升网站——哪种库能实现想要的效果。默认选择库；它能更快带来更好的结果。推荐类别和当前示例工具，不要固定依赖清单。设计 DNA 让网站与众不同；这些库只是实现它的工具。

阅读：

• ${CLAUDE_SKILL_DIR}/references/libraries.md
• ${CLAUDE_SKILL_DIR}/references/motion.md（每项动效建议都必须遵循的 prefers-reduced-motion、GPU 合成和时序规则）

如果存在 DESIGN.md，先重新阅读——设计风格和现有动效语言会限制哪些方案合适。

遵循 libraries.md 中的流程，该流程体现了三项原则：

1. 默认使用库 — 具体说明效果（先把含糊的“让它更出彩”转化为真正的效果），找到对应类别，并选择领先的库。不要手写库已经能出色实现的效果。
2. 权重取决于情境 — 在普通带宽下使用普通手机时，几十 KB 几乎感觉不到；直接使用即可。只有在传输受限时，才降级到基于 CSS 的层级（Animate.css、Tailwind animate、AutoAnimate）：例如卫星／2G／按流量计费的网络、嵌入式场景，以及对字节数敏感的广告／小组件界面。
3. 3D 才是真正的成本 — 这是唯一在任何情况下都很沉重的效果（字节数 + GPU／电池）。投入之前，先确认体验确实需要 3D。

列出当前示例以供核实，不要固定版本。任何动效建议都要附上 prefers-reduced-motion 要求。

输出：推荐表（效果 → 类别 → 库 → 当前待核实示例 → 权重说明）、无障碍说明，以及提醒：让网站与众不同的是设计 DNA，而不是库。建议在效果构建完成后接着进行 polish，以检查动效质量。

---

polish

所需上下文：需要审查的运行中界面或已构建代码。

发布前的最终质量检查。

先运行以下检查清单。然后，仅针对包含 WARN 或 FAIL 项的部分加载参考文件：

• ${CLAUDE_SKILL_DIR}/references/motion.md
• ${CLAUDE_SKILL_DIR}/references/interaction.md
• ${CLAUDE_SKILL_DIR}/references/responsive.md
• ${CLAUDE_SKILL_DIR}/references/ai-tells.md

每项标记为：PASS、WARN 或 FAIL，并说明理由。

动效

• 动画用途明确（引导注意力、状态变化、反馈）
• 时序：微动效 100ms、标准动效 300ms、复杂动效 500ms
• 缓动：进入时使用 ease-out，退出时使用 ease-in，使用指数曲线
• 不使用弹跳／弹性效果，不为布局属性添加动画
• 遵循 prefers-reduced-motion

交互

• 涵盖所有 8 种状态：默认、悬停、焦点、激活、禁用、加载、错误、成功
• 使用 :focus-visible，绝不移除焦点环
• 表单：标签、失焦时验证、错误使用 aria-describedby
• 加载时：乐观 UI > 骨架屏 > 加载旋转图标

响应式

• 移动优先，使用 min-width 查询
• 断点由内容决定
• 触控目标至少为 44x44px
• 使用 clamp() 实现流畅的排版／间距
• 根据使用情境调整，而不只是缩小尺寸

身份

• 美学风格有意为之，而非默认／千篇一律
• 不出现 AI 痕迹（深色背景搭配青色、所有内容都放进卡片、玻璃拟态、弹跳缓动、间距一成不变）
• 令人难忘的特征能追溯到设计目的

如果发现身份问题，还要阅读 ${CLAUDE_SKILL_DIR}/references/chapter-01-why-design-matters.md 和 ${CLAUDE_SKILL_DIR}/references/chapter-04-technology-and-culture.md。

输出：按部分列出的评分卡，以及针对 WARN／FAIL 项的修复方案。