路线设计技能

设计技能

设计技能是设计相关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 作为简洁的最终检查清单。

为什么优先填充很重要：它仅在维度实际为空时加载约束—— 仅当未提供图标时读取图标约束，仅当未提供颜色时读取颜色约束。 这使技能保持轻量，而不是每次倾泻所有规则。

成熟系统回退

对于接口 / 受约束的场景（产品原型、仪表盘、管理面板、网页工具、设置/表单/引导/结账、数据密集型界面、通用企业/通知页面），依赖成熟系统而非自由品味——无论用户是否给出了感觉词。将场景（以及任何感觉词）解析为 design-systems/style-skills 中的条目（通过其 mood 标签），并将其作为UI基础。接口成熟度是目标；真实系统能提供结构、组件纪律、间距节奏、状态行为和交互惯例。

不要将其应用于创意 / 表达性场景：

• social-card.md
• content-page.md
• 社论/文学页面
• portfolio.md
• landing-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>（从情绪标签匹配）"，或如果命名了品牌，则 "偏向 <brand> 从 brand-inspiration"。默认为成熟系统；不要从零发明UI。
• 创意场景（着陆页、作品集、活动、卡片、内容）：要么 "参考 <system> 的 <character>，原创布局"，要么 "原创方向：<一行>"。两者都有效——"原创"是合法来源；关键是考虑了库。
• 任何场景 + 命名品牌 → "偏向 <brand> 从 brand-inspiration"。

然后分类场景；对于表达性场景，承诺具体的视觉计划

• 表达性（品牌网站、活动/促销、作品集、产品着陆页英雄、编辑/文化专题、社交封面）：视觉冲击是工作的一部分；正确但安全居中的页面是失败的。
• 受约束（仪表盘、管理、内部工具、表单、政府通知、报告、数据表、规格）：清晰和冷静是工作；保持动效最小、布局规整，跳过下面的视觉承诺。

对于表达性场景，在编码前静默承诺——每一项是具体元素+操作，永远不是形容词（禁止使用"大胆/高级/惊喜/动态"，因为它们不约束任何东西）：

视觉承诺（仅限表达性场景）
1. hero_subject:   被放大/突出的一个元素  （例如，产品名称 '桂花酪酪' 占视口1/3，金色+朱红）
2. entrance:       哪些元素以何种方式动画进入       （例如，标题字符交错淡入 + 花瓣从上落下）
3. break_symmetry: 布局在哪里打破中心/网格      （例如，价格标签倾斜右下；印章溢出边缘）
4. focal_contrast: 什么使眼睛首先着陆        （英雄周围的尺寸跳跃 / 色彩块 / 留白）

完全居中、对称、无主导元素的静态页面是默认-平庸的结果——对于表达性场景，这意味着承诺未被兑现。执行每个承诺的项目。动效细节 → horizontal-craft/animation-discipline.md。

示例（内联）

"做一个 GLM-5.1 模型介绍网站" → 定位：推理/执行基础设施，不是通用AI页面；first_impression: 冷静、精确、技术性；anti_default: 避免通用AI-SaaS英雄+功能卡片模板。场景：表达性 → hero_subject: "GLM-5.1" 超大字号带单一强调；entrance: 标题+标语交错淡入；break_symmetry: 规格数字偏向一侧；focal_contrast: 大号文字与深色负空间形成对比。

第一阶段产品假设

假设大多数用户不提供高级设计上下文——不是 Figma 文件/MCP、成熟设计系统、令牌、组件库、品牌指南