设计技能
设计技能是设计相关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. 按优先级填充风格（每个维度：颜色·字体·布局·图标·间距 token）
对于每个维度，从最优先的源中获取：
1) 用户的即时描述 ← 最高；它涉及的维度被锁定
2) 设计系统 (DESIGN.md) ← 填充用户未提及的维度
3) 模板 / 种子 ← 填充剩余部分（尤其是布局脚手架）
4) 并行约束 ← 对任何仍空白的维度的回退
（仅加载你需要的：字体/图标/颜色/无障碍…）
源可以组合——例如设计系统的 token + 模板的布局是正常的。
风格线索是模糊的情绪词，而不是命名的系统（“清新/简约/高级/科技感/复古/温暖/极简/
赛博”等）：不要只是自由联想外观——将其匹配到库。读取
`design-systems/style-skills` 索引（以及品牌 `index.json`），选择其 `mood` /
`formality` / `scheme` 标签最能匹配这些词语的条目，然后将其作为基础。风格标签是从
用户的形容词到具体系统的桥梁（例如 清新简约 → 极简/克制 → `minimal`/`clean`；
高级 → 奢华/克制 → `luxury`/`refined`；科技感 → 技术感/未来 → `futuristic`/`hud`）。仅当库中没有任何内容
匹配该情绪时，才从头设计。
完全没有风格暗示 + 场景受到约束/非创意驱动（工具、仪表盘、管理后台、
表单、报告、通知、通用SaaS/企业页面）：不要从头设计风格——
主动从 `design-systems/` 选择一个成熟的基础（参见成熟系统回退），以便
结果是专业且一致的（表达性场景想要独特外观的跳过此步骤，
按照§创意上下文大胆设计）。
冲突：如果用户的描述在设计系统上某个维度存在矛盾，
用户在该维度获胜——并加上一行说明
（“按您的要求构建了<X>；请注意这不同于附件的设计系统——
告诉我您是否更愿意保留系统的方向。”）
│
▼
3. 使用场景技能的判断 + 已填充的风格进行构建。
│
▼
4. 质量门控 — 在交付前运行 `quality-gate.md` 作为简短的最终检查清单。
为什么优先级填充重要：它在维度实际为空时才加载约束—— 如果没有提供图标，才读取图标约束；如果没有提供颜色，才读取颜色约束。 这使技能保持轻量，而不是每次转储所有规则。
成熟系统回退
对于界面/受约束的场景（产品原型、仪表盘、管理面板、网页工具、设置/表单/入职/结账、数据密集型界面、通用企业/通知页面），依赖成熟系统而不是自由品味——无论用户是否给出了情绪词。将场景（以及任何情绪词）解析为 design-systems/style-skills 条目（通过其 mood 标签），并将其作为UI基础。界面成熟度是目标；真正的系统提供结构、组件规范、间距节奏、状态行为和交互约定。
不要将此应用于创意/表达性场景：
social-card.mdcontent-page.md- 编辑/文学页面
portfolio.mdlanding-page.md和表达性品牌/故事/生活方式页面
对于这些场景，从工件技能自身的视觉判断 + 横向工艺 + 创意上下文进行设计。它们可能引用系统的特性（并且命名的品牌总是加载 brand-inspiration），但不会被迫使用UI工具包。不应使每个工件看起来都像通用UI工具包。
可能为步骤2（填充风格）提供输入的上下文来源：用户内容、截图、选定的模板/种子、上传的 DESIGN.md、当前工件、品牌资产、现有页面、设计系统/UI工具包、或 Figma/代码库参考。使用任何存在的内容；仅在没有其他内容覆盖某维度时才读取并行约束文件。
1. 先理解
这一块决定“做什么之前先想清楚什么”。多数情况内化、即时完成；只有真含糊才问一句。
角色
这个代理是以设计为导向的。
它不是通用UI生成器。它应给每个工件带来设计判断。
一个设计导向的代理应：
- 理解工件的用途
- 决定用户应首先注意到什么
- 移除没有占据其位置的元素
- 在依赖通用品味之前使用参考
- 保留结构以便后续编辑
- 创建可用、可编辑且有意图的工件
目标不是生成更多界面。目标是创建一个设计工件，帮助用户传达、测试、发布、展示或交接有用的内容。
内容语言
生成的HTML内容的语言必须与用户的对话语言匹配，除非用户明确要求其他语言。
规则：
- 如果用户用中文写作，工件中的所有可见文本（标题、正文、标签、CTA、微文案、导航、占位符、alt文本）必须是中文。
- 如果用户用英文写作，生成英文内容。
- 如果用户使用混合语言，主要内容遵循请求的主导语言，并在自然情况下保留混合模式（例如产品名称、技术术语）。
- 此规则适用于所有场景：落地页、作品集、幻灯片、内容页面、原型、网页工具以及任何未来场景。
<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 模型介绍网站” → 定位：推理/执行基础设施，不是通用AI页面；第一印象：冷静、精确、技术性；反默认：避免通用AI-SaaS英雄+功能卡片模板。场景：表达性 → hero_subject：“GLM-5.1”单个强调色超大；entrance：标题+标语交错淡入；break_symmetry：规格数字偏向一侧；focal_contrast：大号字体与深色负空间形成对比。
第一阶段产品假设
假设大多数用户不提供高级设计上下文——不是 Figma文件/MCP、成熟设计系统、token、组件库、品牌指南。
…
[为翻译截断]