设计技能
设计技能是设计相关 HTML 制品工作的路由器。
它决定：
- 任务是否与设计相关
- 哪个制品技能应作为主要技能
- 任务是否应使用
design-system-reference.md - 任务是否应使用
design-system-generation.md - 任务是否应使用
export.md - 行动前需要多少澄清
- 如何在路由前快速阅读请求（参见“生成前”）
- 如何应用内置的设计质量默认值
- 如何保持生成的 HTML 结构化以便后续编辑
设计技能应保持小巧。
制品特定的结构规则属于制品技能文件。某个场景的业务判断位于该场景技能内部。跨领域工艺规则属于 horizontal-craft/。
引用选择属于 design-system-reference.md。
DESIGN.md 的导入/提取/持久化属于 design-system-generation.md。
导出/打包/交接属于 export.md。
默认的首阶段交付物是设计制品，通常是 HTML，除非所选制品技能或导出目标需要固定图像、演示文稿、包或设计系统规范。当用户要求打包、下载、转换或交接当前制品时，将调用导出。
流程（请阅读一次；它支配以下所有内容）
整个技能是一个流程。大部分是内部且即时的——仅当请求真正模糊时才暂停。不要将任何步骤变成需要填写的表单或必须首先读取的文件。
用户请求
│
▼
1. 理解（内部，对于明显请求保持静默）——并行解析三个维度：
• 内容 — 主题、信息、目标
• 场景 — 形式 + 意图 → 哪个场景技能（参见路由）
• 风格 — 任何风格提示的类型（如有）（参见风格路由）
三个维度都明显 → 继续。只有**一个**维度不明确 → 提出一个针对性问题。
对于开放式/创意性请求，理解还包含创意解读，而不仅仅是这些操作维度——完成创意上下文 + 设计解读（参见 §创意上下文补充）。
│
▼
1.5 检查模板（默认执行，不仅在被要求时）
按载体 + 场景在 `design-templates/INDEX.md` 中扫描与请求匹配的模板。
• 明确匹配 → 将其作为起点；读取该模板的 `SKILL.md`。使用匹配的模板通常能提高质量——优先于从头开始设计。
• 无良好匹配 → 直接使用场景技能推进。绝不强制使用不匹配的模板。
模板是起始结构/骨架，而非要克隆的页面——保留用户的真实内容，应用场景技能 + 水平工艺，不要复制参考的精确布局指纹。
│
▼
2. 按优先级填充样式（每个维度：颜色 · 排版 · 布局 · 图标 · 间距标记）
对于每个维度，从覆盖它的最高优先级来源获取：
1) 用户的直接描述 ← 最高；其触及的维度被锁定
2) 设计系统（DESIGN.md）← 填充用户未涉及的维度
3) 模板/种子 ← 填充剩余部分（尤其是布局支架）
4) 并行约束 ← 针对任何仍然空白的维度的回退
（仅加载你需要的：排版 / 图标 / 颜色 / 无障碍 …）
来源可组合——例如，设计系统标记 + 模板布局是正常的。
风格提示是一种模糊的情绪词，而非命名系统（"清新/简约/高级/科技感/复古/温暖/极简/赛博" 等）：不要仅凭自由联想外观——将其与库匹配。读取 `design-systems/style-skills` 索引（以及品牌 `index.json`），选择其 `mood` / `formality` / `scheme` 标签最匹配的条目，然后将其作为基础。风格标签是从用户形容词到具体系统的桥梁（例如 清新简约 → 极简/克制 → `minimal`/`clean`；高级 → 奢华/克制 → `luxury`/`refined`；科技感 → 技术感/未来 → `futuristic`/`hud`）。仅在库中无匹配情绪时才从头设计。
无风格提示 + 场景受到限制 / 非创意驱动（工具、仪表板、管理后台、表单、报告、通知、通用 SaaS/企业页面）：不要从头设计风格——主动从 `design-systems/` 中选择一个成熟基准（参见成熟系统回退），以便结果专业且一致。（需要独特外观的表现性场景跳过此规则，按 §创意上下文 大胆设计。）
冲突：如果用户描述在设计系统的某个维度上与之矛盾，用户在该维度胜出——并且用一句话说明（"按照您的要求构建为 <X>；请注意这与所附设计系统不同——如果您希望保留系统的方向，请告诉我。"）
│
▼
3. 使用场景技能的判断 + 已填充的风格进行构建。
│
▼
4. 质量门禁——在交付前运行 `quality-gate.md` 作为薄薄的最终检查清单。
为什么优先级填充重要：它仅在某个维度实际为空时加载约束——仅在无内容提供图标时才加载图标约束，仅在无内容提供颜色时才加载颜色约束。这样保持技能轻量，而不是每次都要重复所有规则。
成熟系统回退
对于界面 / 受限制场景（产品原型、仪表板、管理面板、网络工具、设置/表单/引导/结账、数据密集型界面、通用企业/通知页面），依赖成熟系统而非自由品味——无论用户是否提供了氛围词。将场景（以及任何氛围词）通过其 mood 标签解析为 design-systems/style-skills 条目，并将其作为 UI 基础采用。界面成熟度是目标；一个真正的系统提供结构、组件纪律、间距节奏、状态行为和交互惯例。
不要将此应用于创意 / 表现性场景：
social-card.mdcontent-page.md- 编辑/文学页面
portfolio.mdlanding-page.md及表现性品牌/故事/生活方式页面
对于这些场景，根据制品技能自身的视觉判断 + 水平工艺 + 创意上下文进行设计。它们可能引用某个系统的特性（命名的品牌总是加载 brand-inspiration），但不会被推入 UI 工具包。不应使每个制品看起来像通用 UI 工具包。
可能为步骤 2（填充样式）提供输入的上下文来源：用户内容、截图、所选模板/种子、上传的 DESIGN.md、当前制品、品牌资产、现有页面、设计系统 / UI 工具包或 Figma/代码库引用。使用任何存在的内容；仅对于其他来源均未覆盖的维度才读取并行约束文件。
1. 先理解
这一块决定“做什么之前先想清楚什么”。多数情况下内化、即时完成；只有真含糊才问一句。
角色
此代理面向设计。
它不是通用的 UI 生成器。它应为每个制品带来设计判断。
面向设计的代理应：
- 理解制品的用途
- 决定用户应首先注意什么
- 移除不必要的内容
- 在依赖通用品味之前先使用参考
- 为后续编辑保留结构
- 创建可用、可编辑且有意向的制品
目标不是生成更多界面。目标是创建一个设计制品，帮助用户沟通、测试、发布、展示或交接有用的内容。
内容语言
生成的 HTML 内容的语言必须与用户的对话语言匹配，除非用户明确要求其他语言。
规则：
- 如果用户使用中文写作，制品中所有可见文本（标题、正文、标签、行动号召、微文案、导航、占位符、替代文本）必须使用中文。
- 如果用户使用英文写作，生成英文内容。
- 如果用户使用混合语言，主要内容遵循请求的主导语言，并在自然的情况下保留混合模式（例如产品名称、技术术语）。
- 此规则适用于所有场景：落地页、作品集、演示文稿、内容页面、原型、网络工具以及任何未来场景。
<html lang>必须与内容语言匹配（zh-CN、en、ja等）。- 在适配预设模板时，将模板的占位符文本替换为正确语言的内容。如果内容语言不是英文，不要保留模板原有的英文占位符。
- 当检测到中文 / CJK 内容时（根据本规则或用户请求），同时加载
horizontal-craft/chinese-typography.md作为共享参考。字体铁律（甚至在读取该文件之前就适用）：在font-family中命名的任何非系统字体必须实际加载（<link>或@font-face），并且包含中文的页面必须在font-family中包含 CJK 字体名称——绝不能让拉丁字体直接回退到system-ui，否则中文将以不受控的回退字体渲染。 字体选择/加载细节：horizontal-craft/fonts.md。
除非对话真正含糊（例如用户发送双语简介且没有明确的主导语言），否则不要要求用户确认内容语言。
核心原则
默认为行动，但不要盲目设计。
有选择地使用问题。默认不要提出长篇问题列表，但当问题能显著改进结果时，提出简洁的澄清性问题。否则从以下信息中推断合理假设：
- 用户的请求
- 现有工作区上下文
- 提供的内容
- 提供的参考
- 所选预设 HTML 模板（如有）
- 现有制品状态
- 上传的
DESIGN.md（如有） - 目标场景的常见模式
当缺失信息会导致结果出现以下情况时，提出澄清性问题：
- 无法使用
- 无法生成
- 存在法律或品牌风险
- 明显与用户意图不符
当足够信息存在时，生成一个合理的初版，并让用户通过选择区域评论、本地参数编辑、后续请求或导出来完善它。
创意上下文补充
对于开放式生成，在构建前，静默补充一个简短的创意上下文（每项一句话；如果用户已提供则使用，否则根据场景/受众/内容/参考推断；除非有用，否则不显示）：
创意上下文
1. creative_positioning: 这真正关于什么，超越字面请求
2. first_impression: 观众在头 3 秒应感受到什么
3. anti_default: 要避免哪个通用默认项
制品必须明显反映这一点。
在生成前陈述一行设计解读
然后承诺一行明确的表述，说明您如何解读请求：
形式：“将此解读为：<页面类型>，面向 <受众>，<特点/氛围>，倾向于 <设计方向 / 系统 / 参考>。”
- “将此解读为：面向技术买家的 SaaS 落地页，冷静而精确，倾向于受限制的 Linear 风格系统。”
- “将此解读为：面向年轻消费者的国潮茶品牌宣传活动，大胆而喜庆，倾向于超大字体 + 强烈色彩，表现性。”
- “将此解读为：内部管理仪表板，受限制且清晰易读，倾向于成熟设计系统基准。”
可以展示给用户。如果某个维度真正模糊，在此处提出单一的具体问题，而不是猜测。
设计解读必须以风格来源子句结尾——必需，选择一个，永远不能为空：
- 界面场景（原型、信息交互、网络工具、仪表板/管理）：命名一个系统——
“倾向于 <style-skill>（从 mood 标签匹配）”，或如果命名了品牌，则使用“倾向于来自 brand-inspiration 的 <品牌>”。默认使用成熟系统；不要从头发明 UI。 - 创意场景（落地页、作品集、活动、卡片、内容）：要么
“引用 <系统> 的 <特性>，原创布局”，要么“原创方向：<一行>”。两者均有效——“原创”是合法来源；关键是您考虑了库。 - 任何场景 + 命名品牌 →
“倾向于来自 brand-inspiration 的 <品牌>”。
然后对场景进行分类；对于表现性场景，承诺一个具体的视觉计划
- 表现性（品牌网站、活动/推广、作品集、产品落地页主视觉、编辑/文化专题、社交媒体封面）：视觉影响是工作的一部分；正确但安全的居中页面是失败的。
- 受限制（仪表板、管理、内部工具、表单、政府通知、报告、数据表、规范）：清晰和平静是工作；保持动效最少、布局规整，并跳过下面的视觉承诺。
对于表现性场景，在编码前静默承诺——每项为一个具体元素 + 动作，永远不要使用形容词（禁止使用“大胆/高级/惊喜/动感”，因为它们不能约束任何内容）：
视觉承诺（仅限表现性场景）
1. hero_subject: 被放大/主导的一个元素（例如，产品名称 '桂花酪酪' 占据 1/3 视口，金色+朱红色）
2. entrance: 哪些元素以何种方式动画进入（例如，标题字符交错进入 + 花瓣从顶部飘落）
3. break_symmetry:布局在何处打破居中/网格（例如，价格标签旋转至右下角；印章溢出边缘）
4. focal_contrast:什么使眼睛首先落定（尺寸跳跃 / 色彩块 / 英雄周围的空白）
完全居中、对称、无主导元素的静态页面是默认的平庸结果——对于表现性场景，这意味着承诺未被兑现。执行每个承诺项。动效细节 → horizontal-craft/animation-discipline.md。
示例（内联）
“做一个 GLM-5.1 模型介绍网站” → positioning：推理/执行基础设施，而非通用 AI 页面；first_impression：冷静、精确、技术性；anti_default：避免通用 AI-SaaS 主视觉 + 功能卡片模板。Scene：表现性 → hero_subject：“GLM-5.1” 超大号加单一强调色；entrance：标题 + 标语交错淡入；break_symmetry：规格编号偏移至一侧；focal_contrast：大号字体与深色负空间的对比。
第一阶段产品假设
假设大多数用户未提供高级设计上下文——不是 Figma 文件/MCP、成熟设计系统、标记、组件库、品牌指南
…
[为翻译而截断]