UI 设计规范生成 Skill v1.20

将产品需求转化为完整、结构化的设计规范文档，并可按需适配到具体设计工具。

前置：快速分流判断

按表格从上到下匹配，命中第一条即停止：

前置依赖检查

> 询问用户："为了更好地完成 UI 设计，是否需要先使用 product-analysis skill 帮您梳理业务流程和功能架构？"

• 回答"需要" → 优先执行 product-analysis skill，将其输出作为本 skill 上游输入，再进入第一步 1.1
• 回答"不需要" → 直接进入第一步 1.2，逐字段询问缺失信息后继续

第一步：解析输入 + 确认方向

1.1 上游文档处理

若用户提供了 product-analysis skill 输出文档，从中提取产品名称、核心功能、目标用户、业务流程。与实时描述冲突时以文档为准，差异项在确认点 #1 中列出。差异超 3 项时建议用户先对齐。

1.2 最小输入要求

1.3 产品类型识别

多类型叠加时，第一优先级组件取并集，在确认点 #1 中列出供用户确认。

1.4 设计风格探索（可选）

风格描述模糊时（如"高级感"、"好看"）：使用 web_search 搜索 "[产品类型] UI design trends 2026" 和竞品案例，整理 2-3 个代表案例展示给用户确认偏好。此步骤在确认点 #1 之前执行。

1.5 规模判断矩阵

以下规则按优先级从高到低匹配，命中第一条即停止。规则 5 仅在确认点 #1 之前生效；确认点 #1 确认后用户再提出降档，需重新展示确认点 #1。

1.6 平台类型识别

平台类型与业务类型（1.3）是两个独立维度，必须同时确认才能加载正确的平台规范文件。

根据用户描述自动识别平台，在确认点 #1 请用户确认：

多端识别规则：
- 用户明确列出两个以上平台（如"Web + App"）→ 自动标记为多端，额外读取 cross-platform.md
- 仅说"多平台"但未指定 → 在确认点 #1 中询问具体平台组合

平台规范文件加载时机：确认点 #1 通过后，在创建输出文件夹的同时读取对应平台规范文件，workflow 执行时作为参照。

✅ 确认点 #1

向用户展示以下内容，确认后再继续：

产品定位：[2-3 句话]
业务类型：[类型；多类型时列出并集组件]
平台类型：[Web 响应式 / iOS App / Android App / iOS+Android / 微信小程序 / 桌面客户端 / 多端组合]
          平台规范：[将读取的规范文件名]
设计风格：[用户指定 或 1.4 探索确认的风格]
执行路径：[精简 / 标准 / 完整] 模式（原因：[功能数 + 页面数]）
暗色模式：[是 / 否]
上游文档差异：[若有则列出；无则省略此行]

导出格式：请选择（可多选，E 可与 B 或 D 组合）
  A. Pencil.dev MCP 指令（前置：需在 MCP 客户端配置 Pencil.dev server）
  B. Design Tokens JSON（兼容 Figma Tokens / Style Dictionary）
  C. React 组件描述（Props 接口 + 使用示例）
  D. Markdown 规范文档（默认）
  E. Stitch MCP 生成（前置：需配置 Stitch MCP server 并完成 Google Cloud 认证）

> 若用户未指定，默认选 D。E 可与 B 或 D 组合：E+D 同时生成 HTML 原型和规范文档，E+B 同时生成 HTML 原型和 Design Tokens。

用户要求修改某项 → 仅更新该项后重新展示完整确认点 #1，直到明确确认。若执行路径变更（如标准→精简），需重新读取对应 workflow 文件。

输出文件夹创建

确认点 #1 通过后，在执行任何模式步骤之前，先创建本次调用的专属输出文件夹：

格式：outputs/[product-slug]-[YYYYMMDD]/
示例：outputs/edu-20260321/
       outputs/crm-20260321/

• product-slug：取产品名英文缩写或关键词，2-6 个字符小写（同命名规则章节）
• YYYYMMDD：当前日期，8 位数字
• 同一产品同日多次运行时，在日期后追加序号：edu-20260321-2/
• 用 bash 工具执行：mkdir -p outputs/[slug]-[date]/

后续所有输出文件均写入此文件夹，以下用 $OUT 代指该路径。

模式执行

输出文件夹创建后，根据判定模式读取对应 workflow 文件执行：

• 精简模式 → 读取 workflows/mode-simple.md
• 标准模式 → 读取 workflows/mode-standard.md
• 完整模式 → 读取 workflows/mode-full.md

模式执行完成后（$OUT/[slug]-design-spec.md 已生成），进入输出质量验证，通过后再进入导出适配器。

输出质量验证

$OUT/[slug]-design-spec.md 写入后、进入导出适配器前，用 bash 工具执行以下检查。所有 ❌ 必须通过才能继续交付。

必须通过项

条件验证项（按用户选择触发）

验证流程

# Q6 示例
grep -n "适当\|合适\|适中\|较大\|较小\|一定程度" $OUT/[slug]-design-spec.md

结果处理：

• 全部 ✅ → 直接进入导出适配器
• 存在 ❌ → AI 自动修复（补充缺失 hex 值 / 删除模糊词替换为具体数值），修复后重新执行一次验证
• 二次验证仍有 ❌ → 向用户列出具体问题行，请求确认后继续

导出适配器

根据确认点 #1 的格式选择执行。多选时按以下顺序执行：D → B → C → A → E（文档类先于工具类，E 最后因依赖 design-spec.md）。

选项 A：Pencil.dev MCP 指令
读取 references/pencil-mcp-guide.md，将设计规范转化为 Pencil 可执行的自然语言指令集。
结构：项目初始化 → 设计系统变量 → 组件创建 → 页面布局 → 交互实现
输出文件：$OUT/[slug]-pencil-instructions.md

选项 B：Design Tokens JSON
输出标准化 Design Tokens 格式（W3C 规范），兼容 Figma Tokens 插件、Style Dictionary。

• 单色模式：输出 $OUT/[slug]-design-tokens.json
• 暗色模式：输出 $OUT/[slug]-tokens-light.json 和 $OUT/[slug]-tokens-dark.json（不再输出单色版，以双文件为准）

选项 C：React 组件描述
读取 assets/react-component-spec-format.md 获取每个组件的输出结构规范，按该格式为所有组件生成 Props 接口描述 + 使用示例（不生成可运行代码）。

组件规格拆分规则（统一在此定义，workflow 文件不重复）：
- 标准/完整模式：组件规格已在 Step 3 生成为 $OUT/[slug]-component-spec.md，选项 C 直接按 react-component-spec-format.md 格式重写该文件
- 精简模式：组件规格内嵌在 $OUT/[slug]-design-spec.md 中，选项 C 需将其拆出为独立 $OUT/[slug]-component-spec.md，其余内容保留在 [slug]-design-spec.md

选项 D：Markdown 规范文档
$OUT/[slug]-design-spec.md 即为此输出，无需额外处理。

选项 E：Stitch MCP 生成
读取 references/stitch-mcp-guide.md 获取工具清单和 prompt 规范，再读取 workflows/mode-stitch-export.md 执行三阶段生成流程。
前提：$OUT/[slug]-design-spec.md 已生成。
输出：$OUT/screens/[slug]-[page].html + $OUT/[slug]-stitch-manifest.json

输出物命名规则

所有输出文件统一写入本次调用创建的专属文件夹 $OUT（格式见「输出文件夹创建」章节），命名遵循以下规则：

基础规则

含产品名的文件命名

每个输出文件名均加上产品 slug 前缀，与文件夹名中的 slug 保持一致：

$OUT  = outputs/edu-20260321/
文件  = edu-design-spec.md（slug 前缀 + 标准文件名）
完整路径 = outputs/edu-20260321/edu-design-spec.md

标准文件名对照表

Stitch 页面文件命名（$OUT/screens/）

页面名称统一转为 kebab-case 英文，由 AI 在生成时执行转换：

> 无明确英文对应词时，使用功能描述（如 user-dashboard.html、order-history.html）。

版本化（可选）

需保留历史版本时，在扩展名前加版本号后缀：

design-spec-v1.md  →  design-spec-v2.md
design-tokens-v1.json  →  design-tokens-v2.json

日常迭代时直接覆盖同名文件，仅在需要对比版本时启用版本后缀。

最终交付

所有文件写入 $OUT/（本次调用专属文件夹），执行结束后通过文件分享工具交付整个文件夹：

关键原则

1. 按需加载：workflow 和模板文件在需要时才读取，不预加载
2. 不强绑定工具：核心输出是设计规范，工具适配是可选层
3. 规模自适应：小项目不走完整流程，避免过度设计
4. 确认最小化：精简模式 2 次确认（#1 + Step 2 轻量确认），标准/完整模式 2 次确认（#1 + #2）
5. 数值具体化：所有设计决策必须有明确数值，不输出模糊描述
6. 产品类型驱动：根据识别的产品类型动态调整组件优先级清单
7. 风格探索优先：风格不明确时主动搜索参考案例
8. 导出可组合：选项 E 可与 B 或 D 组合，多选时按 D→B→C→A→E 顺序执行

参考文件索引