B 端产品设计 Skill 怎么做？结构对了，比你想的简单

上篇写了微信小程序设计 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

04 看看B 端和 C 端，做法有什么不同

	C 端（如小程序）	B 端
规范来源	官方文档齐全，AI 直接整理	需结合公司自有规范
业务模板	场景相对通用	业务差异大，需自己沉淀
验证方式	AI 自我校验	历史案例生成原型，反复迭代
Skill 壁垒	较低，容易复用	高，是公司真正的设计资产
能否开源	可以	通常不行