上篇写了微信小程序设计 Skill，有人问：B 端是不是太复杂了，感觉怎么做效果都不理想？
* * *
## 先回答这个问题
B 端规范确实更重——组件更多、状态更复杂、业务差异更大。
但复杂不等于难做。**B 端设计规范本身就有结构，结构清晰的东西反而更适合做成 Skill。**
难的不是做，是得知道该装什么，还得知道怎么验证它真的好用。
这是设计skill的设计逻辑图，我们先来看看了解一下
基于上面这个设计逻辑，接下来看如何做才能设计好B端产品的设计Skill
* * *
## 01
## B 端 Skill 必须包含两大部分
很多人做 Skill 容易走两个极端——要么只堆规范文档，要么只放几个页面截图。这两种都不够用。
只有基础规范，AI 知道”应该怎样”，但不知道”实际长什么样”，生成出来的东西会很空。只有案例，没有规范底层，AI 输出会飘，换个场景就不对了。
**两部分缺一不可。**
**第一部分：完整基础设计规范**
这是 Skill 的地基，必须覆盖：
— 品牌色 / 功能色体系 — 字体层级 — 图标体系 — 间距与栅格 — 圆角与阴影 — 基础控件 / 组件规则 — 交互状态规范（默认、hover、选中、禁用、加载、错误、空态）
交互状态这一条尤其重要，B 端页面状态多，这块写不清楚，AI 生成的界面会缺胳膊少腿。
**第二部分：落地业务模板与案例**
这是 Skill 的血肉：
— 基于基础规范衍生的页面模板（列表页、详情页、表单页、数据看板……） — 审批流、权限管理、消息通知等业务专属模板 — 真实历史项目案例截图与说明
这部分 AI 帮不了太多，需要自己沉淀。但也正因为如此，它是 B 端 Skill 最有壁垒的地方。
* * *
## Skill 的完整文件结构长这样
做之前先看清楚要做什么。一套完整的 B 端 Skill，文件结构是这样的：
`skill/├── SKILL.md # 主文档入口，预设人设 Prompt├── tokens/ # 设计 Token（色彩、字体、间距等基础变量）├── components/ # 组件规范（按钮、输入框、表格等）├── patterns/ # 设计模式（列表页、详情页、表单页等）├── templates/ # 业务场景模板（审批流、权限管理等）├── examples/ # 真实历史案例截图与说明├── rules/ # 强制规则与禁忌清单├── scripts/ # 验证脚本└── prompts/ # 场景化 Prompt`
每一层都有明确的职责——tokens 是变量，components 是组件，patterns 是页面结构，templates 是业务场景，examples 是真实案例，rules 是红线，prompts 是激活方式。
结构清晰了，AI 读起来更准，生成质量更稳定。
* * *
## 02
## 接下来，我们五步做出来
### 第一步：整理现有规范文档
Figma 组件库、设计规范文档、历史设计评审记录等等都可以——把手头有的都翻出来。
不需要完美，不需要等所有东西都齐了再开始。**够用就可以喂给 AI，缺的后面迭代补。**
* * *
### 第二步：借助 AI 结构化成 Skill 文档
把整理好的内容喂给 AI，让它按 Skill 标准格式输出。每个模块统一结构：
`【组件/场景】：【适用场景】：【规范说明】：【尺寸/参数】：【交互规则】：【强制要求】：【禁止设计】：【最佳实践】：`
格式统一，AI 后续读起来更准，生成质量更稳定。
### 第三步：补充业务模板和历史案例
基础规范部分 AI 能帮你快速跑完，业务模板和 examples 这两部分需要自己来。
**业务模板**——列表页、详情页、表单页、数据看板、审批流、权限管理……把你们产品里最高频的页面结构整理进 patterns/ 和 templates/。
**历史案例**——把过去做过的典型项目截图放进 examples/，写好设计说明：用了哪些规范、有哪些特殊处理、为什么这样决策。
这部分是你们公司业务积累下来的设计决策，AI 无法替代。**这部分越完整，Skill 的壁垒越高，越值钱。**
* * *
### 第四步：用历史案例验证，反复迭代到满意
这一步是 B 端 Skill 质量的真正保障，最容易被跳过，但不能省。
**做法：**
拿过往真实项目的业务场景，让 AI 直接用做好的 Skill 生成界面原型——比如”用这套 Skill 给我生成一个物流管理系统的订单列表页”。
然后对着生成结果逐项检查：布局对不对？组件用法符合规范吗？交互状态有没有全覆盖？信息层级清不清晰？
**哪里不满意，就回头改 Skill 对应的规范描述，改完再生成，再对比。**
反复跑，直到生成出来的原型你自己看了满意——这才算 Skill 真正可用。
这个过程的本质是：**Skill 和原型互相校准。**生成效果不好，说明 Skill 里某个规则写得不够准，或者漏掉了某个场景。改到生成效果稳定了，Skill 的质量才真正落地。
* * *
有团队成员用下来之后跟我说：
> 以前接到一个新需求，光是画原型就要一周——先看 PRD、理清楚业务逻辑、翻设计规范、一个页面一个页面搭。
>
>
> 现在的流程变了：把 PRD 直接丢给 AI，让它分析需求、拆解页面结构，再调用 Skill 生成对应的界面原型，哪里不对直接告诉 AI 修改，来回几轮就出来了。
>
>
> **一天之内搞定，剩下的时间全部用来打磨细节和跟产品对齐。**
这个变化不是”快了一点”，是整个工作节奏变了。**从手工搭积木，变成 AI 出草稿、人来决策。**
设计师的价值没有被替代，而是从”执行规范”转移到了”判断对不对”上。
* * *
### 第五步：打包
验证满意之后，直接告诉 AI：
> “帮我把这个 Skill 打包到桌面。”
它会自动把所有文件按目录结构打包好，放到桌面，发给团队或者存档都行。
* * *
## 03
## 推荐一个 GitHub 上的开源 Skill
做自己的 B 端 Skill 之前，可以先看看别人怎么做的，省去很多摸索。
GitHub 上有一个开源项目值得参考：**ui-ux-pro-max**地址：github.com/nextlevelbuilder/ui-ux-pro-max-skill
支持 Claude、Cursor、Copilot 等主流 AI 工具，能自动生成完整设计系统，覆盖色彩、字体、间距、组件规范，针对不同行业和产品类型给出专属设计建议，目前已经有 7000+ Star。
对 B 端设计师来说，它的价值不是直接拿来用，而是**拆开看它怎么组织规范结构**——Skill 该分几层、每个模块该写哪些字段、怎么让 AI 读得更准，思路可以直接借鉴。
* * *
## 04
## 看看B 端和 C 端，做法有什么不同
C 端（如小程序）B 端
规范来源 官方文档齐全，AI 直接整理 需结合公司自有规范
业务模板 场景相对通用 业务差异大，需自己沉淀
验证方式 AI 自我校验 历史案例生成原型，反复迭代
Skill 壁垒 较低，容易复用 高，是公司真正的设计资产
能否开源 可以 通常不行
* * *
写在最后
一套做好的企业内部 B 端设计 Skill，就是公司的设计资产，能有效提升交付效率。
真正好用的 B 端 Skill，一定是结合了你们公司自己的业务积累、产品特性、历史案例做出来的，别人的版本永远替代不了这部分。
所以接下来不如自己动手做一套试试~
**我把这套方法整理成了一个可以直接上手的 Skill 包——包含完整的 token 文件、组件规范、三个可运行的 HTML 页面模板（列表页 / 表单页 / 详情页）、验收 Checklist 和激活 Prompt，解压即用，替换品牌色就能跑起来。**
