案例解析难度 3⏱ 23 分钟对比
01爆款拆解：实战 Skill 精选
通过多个实战案例观察不同类型 Skill 的写法差异，帮助你形成更稳定的写作判断。
爆款 Skill案例实战精选
更新于 2026-04-11M05B-爆款拆解-实战Skill精选
拆解高质量热门 Skill 的结构和写法，理解优秀 Skill 为什么容易触发、容易复用。
内容摘要
> 模块5A：爆款拆解 — ui-ux-pro-max | 用时：约25分钟 | 目标：逐层拆解一个真实爆款 Skill，搞懂高手的信息架构思路
模块5A：爆款拆解 — ui-ux-pro-max | 用时：约25分钟 | 目标：逐层拆解一个真实爆款 Skill，搞懂高手的信息架构思路
说实话，上一个模块你从零写了一个 commit-message-writer，三轮迭代打磨出来了。但你心里肯定有个疑问：那些真正的高手写的 Skill 长什么样？跟我写的到底差在哪？
这一期我直接拆一个 GitHub 上的爆款给你看——ui-ux-pro-max。
你别说，这数字确实有点夸张：62.9k Stars，13 个技术栈全覆盖，67 种设计风格、96 套配色方案全塞在一个 Skill 里。听着很唬人对吧？但它确实跑得动，而且效果特别好。
拆它不是为了让你照抄。是让你看清楚一件事：高手写的 Skill，和新手的差距，根本不在代码量，而在信息架构。
说再多不如看一眼实际效果。
你说"做一个金融科技 SaaS 的 Landing Page"，AI 直接给你走完一整套流程——先判断产品类型是金融 SaaS，然后推荐适合的设计风格（可能是简约专业风），接着选配色（深蓝+白的信任感配色），再选字体搭配，最后生成完整的 HTML/Tailwind 代码。
你说"Review 这个按钮组件"，AI 按优先级检查：先看可访问性（对比度够不够、焦点状态有没有），再看触摸目标够不够大（至少 44x44px），再看动画性能（用的是 transform 还是 width），最后看对比度。
你说"帮我选一套暖色调的字体搭配"，它去自己的数据库里搜，57 组字体搭配里找最适合暖色调的那几组推荐给你。
你什么都不用解释。不需要说"对比度至少 4.5:1"，不需要说"触摸目标 44px"，不需要说"用 transform 别用 width"。这些规则已经写在这个 Skill 里了。
说白了，它把一个专业 UI 设计师脑子里那套东西，变成了 AI 可以直接执行的指令。
大部分新手写 Skill，就是一个 SKILL.md 文件，所有东西往里塞，写完拉倒。
但 ui-ux-pro-max 不是这么玩的。它是一个完整的能力包：
ui-ux-pro-max/
├── SKILL.md ← 378 行核心指令
├── scripts/
│ ├── core.py ← 核心数据加载引擎
│ ├── design_system.py ← 设计系统生成器
│ └── search.py ← CLI 搜索工具
└── data/
├── styles.csv ← 67 种设计风格
├── colors.csv ← 96 套配色方案
├── typography.csv ← 57 组字体搭配
├── charts.csv ← 25 种图表类型
├── products.csv ← 产品类型推荐
├── landing.csv ← 页面结构策略
├── ux-guidelines.csv ← 99 条 UX 规则
├── ui-reasoning.csv ← 推理决策规则
└── stacks/ ← 13 个技术栈指南
├── react.csv
├── vue.csv
├── nextjs.csv
├── svelte.csv
├── flutter.csv
├── swiftui.csv
├── react-native.csv
├── shadcn.csv
├── html-tailwind.csv
├── nuxtjs.csv
├── nuxt-ui.csv
├── jetpack-compose.csv
└── astro.csv
看出门道了吗？
新手写 Skill：一个文件，所有东西塞进去。
高手写 Skill：SKILL.md 只放核心指令（做什么、怎么做、不要做什么），具体数据放 data/，计算逻辑放 scripts/。分工明确，各管各的。
这不是"高级写法"和"低级写法"的区别，这是两种完全不同的设计思路。新手关心的是"怎么把话说清楚"，高手关心的是"怎么让 AI 只在需要的时候才加载需要的信息"。
后者省 token，也减少 AI 的认知负担。你别说，这设计太精妙了。
整个 Skill 最值得琢磨的部分，我认为是 description。不是因为它多复杂，恰恰是因为它看起来简单，但每个字都经过了精心设计。
先看原文：
description: "UI/UX design intelligence. 67 styles, 96 palettes, 57 font pairings,
25 charts, 13 stacks (React, Next.js, Vue, Svelte, SwiftUI, React Native,
Flutter, Tailwind, shadcn/ui). Actions: plan, build, create, design, implement,
review, fix, improve, optimize, enhance, refactor, check UI/UX code.
Projects: website, landing page, dashboard, admin panel, e-commerce, SaaS,
portfolio, blog, mobile app, .html, .tsx, .vue, .svelte. Elements: button,
modal, navbar, sidebar, card, table, form, chart. Styles: glassmorphism,
claymorphism, minimalism, brutalism, neumorphism, bento grid, dark mode,
responsive, skeuomorphism, flat design. Topics: color palette, accessibility,
animation, layout, typography, font pairing, spacing, hover, shadow, gradient.
Integrations: shadcn/ui MCP for component search and examples."
388 个字符。我逐段给你拆。
第一段说的是"能力概览"："UI/UX design intelligence. 67 styles, 96 palettes, 57 font pairings, 25 charts, 13 stacks"。干什么的？告诉 AI 和用户：这个东西覆盖面有多广。67 种风格、96 套配色、57 组字体——数据量本身就是说服力。用户看到这些数字，心里大概就有数了："哦，这东西挺全的。"
第二段堆的是"动词"："Actions: plan, build, create, design, implement, review, fix, improve, optimize, enhance, refactor, check"。为什么要列这么多动词？因为用户说的动作五花八门。"帮我设计一个页面"、"review 一下这个组件"、"优化一下配色"、"修一下这个布局"——每种说法对应不同的动词。你漏了一个动词，就可能漏掉一类触发。
换句话说，这些动词不是给用户看的，是给 AI 的匹配机制看的。AI 判断"该不该加载这个 Skill"的时候，就是拿用户的话和 description 做语义匹配。动词覆盖得越全，命中率越高。
第三段堆的是"项目类型"："Projects: website, landing page, dashboard, admin panel, e-commerce, SaaS, portfolio, blog, mobile app"。同理。用户可能说"做一个 SaaS 后台"，也可能说"搭一个 Landing Page"，也可能说"写个电商网站"。每种说法都要能命中。
第四段堆的是"组件名"："Elements: button, modal, navbar, sidebar, card, table, form, chart"。这些是 UI 里最常见的组件。用户说"帮我做个卡片组件"，命中 card。说"写一个表单"，命中 form。
第五段堆的是"设计风格"："Styles: glassmorphism, claymorphism, minimalism, brutalism, neumorphism, bento grid, dark mode"。当下流行的设计风格全在里面了。用户说"我要一个毛玻璃效果"，命中 glassmorphism。
第六段堆的是"设计话题"："Topics: color palette, accessibility, animation, layout, typography, font pairing, spacing"。设计讨论中的常见话题。
你发现规律了吗？这六段不是随便排的。编排顺序是：能力概览 -> 动词 -> 项目 -> 组件 -> 风格 -> 话题 -> 集成。从大到小，从宽到窄，层次非常清楚。AI 读到这段 description，立刻就知道这是一个覆盖面极广的 UI/UX 设计 Skill。
说白了，这就是模块 3 里讲的**"触发词轰炸"策略的教科书级应用**。作为一个通用型 Skill，它不能漏匹配。宁可多命中也不能漏掉。388 个字符的额度，它几乎用满了。
SKILL.md 正文有 378 行。不是随便写的 378 行——每一段都有明确的功能定位。我拆出 4 个最值得学的核心设计。
正文最开头的部分是一张优先级表：
Priority 1: Accessibility — CRITICAL
Priority 2: Touch & Interaction — CRITICAL
Priority 3: Performance — HIGH
Priority 4: Layout & Responsive — HIGH
Priority 5: Typography & Color — MEDIUM
Priority 6: Animation — MEDIUM
Priority 7: Style Selection — MEDIUM
Priority 8: Charts & Data — LOW
这张表解决了什么问题？它告诉 AI：检查 UI 的时候，先看可访问性（最严重），再看交互，再看性能，最后才看配色和动画。
你想想如果没有这张表会怎样。AI 可能先看配色好不好看，再看看动画流不流畅，最后才想起检查对比度够不够。本末倒置。一个按钮连焦点状态都没有（Accessibility CRITICAL），配色再好看也没用。
有了这张表，AI 就知道：先把 CRITICAL 的问题解决了，再看 HIGH 的，最后处理 MEDIUM 和 LOW 的。不是什么都同等重要，是有层次的。
这个设计你完全可以借鉴。不管你的 Skill 是做什么的，只要你需要 AI 按重要程度做事，就可以用 CRITICAL / HIGH / MEDIUM / LOW 这套分级。不是照抄内容，是照抄这个思路。
正文里有一个明确的 4 步流程：
Step 1: Analyze User Requirements（分析用户需求）
Step 2: Generate Design System（生成设计系统）— REQUIRED
Step 3: Supplement with Detailed Searches（补充详细搜索）
Step 4: Stack Guidelines（技术栈指南）
注意 Step 2 后面标了 REQUIRED。这不是随便标的——它告诉 AI，不管用户的请求多简单，都必须先跑一遍设计系统生成。因为设计系统包含风格、配色、字体、效果的完整推荐，这是后续所有工作的基础。
而且每一步都写了具体的命令。Step 2 里直接给出了 CLI 命令模板：
python3 skills/ui-ux-pro-max/scripts/search.py "<product_type> <industry> <keywords>" --design-system [-p "Project Name"]
AI 读到这一步就知道：我要执行这条命令，把用户的需求翻译成参数填进去。不用猜，不用想，照做就行。
这就是**"固定步骤"的写法**——模块 3 里讲过的，对高风险或流程性强的任务，步骤要写死，不留发挥空间。你给 AI 留发挥空间，AI 就给你发挥到沟里去。
正文里有大量这样的表格：
Rule: No emoji icons
Do: Use SVG icons (Heroicons, Lucide, Simple Icons)
Don't: Use emojis like 🎨 🚀 ⚙️ as UI icons
Rule: Stable hover states
Do: Use color/opacity transitions on hover
Don't: Use scale transforms that shift layout
Rule: Cursor pointer
Do: Add cursor-pointer to all clickable elements
Don't: Leave default cursor on interactive elements
每一条规则都分"该做什么"和"不该做什么"。这比单纯说"注意交互体验"有效一万倍。
为什么？因为 AI 有自己的默认行为。你不明确告诉它"不要做什么"，它就按默认来。比如 AI 默认喜欢在 UI 里用 emoji，因为看起来"生动"。但专业设计里 UI 图标要用 SVG，不能混 emoji。你不说，它就不知道。
这种 Do/Don't 的写法，本质上是给 AI 画边界。正面告诉它方向在哪，反面告诉它红线在哪。两边都给了，AI 就不会用自己的默认判断来"发挥"。
正文末尾有一个检查清单：
Before delivering UI code, verify:
- [ ] No emojis used as icons (use SVG instead)
- [ ] All icons from consistent icon set
- [ ] All clickable elements have cursor-pointer
- [ ] Hover states provide clear visual feedback
- [ ] Transitions are smooth (150-300ms)
- [ ] Focus states visible for keyboard navigation
- [ ] Light mode text has sufficient contrast (4.5:1)
- [ ] Responsive at 375px, 768px, 1024px, 1440px
这个清单的作用是什么？让 AI 在输出之前"自我审查"一遍。相当于告诉 AI：你可以发挥，但交作业之前先对着这个清单检查一遍，有不符合的就改了再交。
效果特别好。因为 AI 生成 UI 代码的时候，经常会"忘记"一些细节——忘了加 cursor-pointer、忘了处理移动端适配、忘了做焦点状态。有了检查清单，AI 在输出之前会再看一遍，把漏掉的补上。
我自己的 Skill 后来也加了这个设计。每条规则都是我曾经在 AI 输出中发现过的遗漏项。你用过一段时间也会发现 AI 经常在哪些地方"偷懒"——把那些偷懒的地方列成清单，就是你的 Pre-Delivery Checklist。
整个 Skill 里，我认为最值得学的架构决策就是这一条：大数据用脚本处理，不塞进正文。
ui-ux-pro-max 有 67 种设计风格、96 套配色方案、57 组字体搭配、99 条 UX 规则。这些数据如果全部写进 SKILL.md 正文，你猜会占多少 token？至少 20000+。20000 token 意味着什么？AI 的上下文窗口直接被吃掉 10%。
但这个 Skill 聪明在哪——它把这些数据全部放到了 data/ 目录的 CSV 文件里，然后用 Python 脚本按需检索。
SKILL.md 里只写了"什么时候调用脚本"和"怎么调用"：
python3 skills/ui-ux-pro-max/scripts/search.py "beauty spa wellness" --design-system
AI 读到这条指令，执行脚本，脚本去 CSV 里搜，返回结果。AI 拿到结果再做分析和输出。
这样做的效果是什么？SKILL.md 正文本身只有 378 行，大约 5000-6000 token。触发这个 Skill 时只加载这么多。至于那 67 种风格、96 套配色，AI 不需要的时候根本不会加载。
这就是模块 2 里讲的**"渐进式披露"的实际应用**。第一层加载 name + description（约 100 token）。第二层加载 SKILL.md 正文（约 5000 token）。第三层按需执行脚本检索数据（按实际使用量计算）。三层加载，层层递进，不浪费一点上下文空间。
如果你自己要做一个需要大量数据的 Skill——比如你做了个"菜谱生成器"，里面有 500 道菜的数据——就学它：数据放 data/，检索用 scripts/，SKILL.md 只放流程指令。
光看结构不够直观。我模拟三个真实场景，让你看看这套架构在实战中是怎么跑的。
你说："帮我做一个卖手工皂的 Landing Page，风格要温暖自然。"
AI 收到请求后，按 Skill 的工作流走：
第一步，分析需求。产品类型是电商（手工皂），风格关键词是温暖自然，行业是美妆/手工艺，技术栈没指定，默认用 html-tailwind。
第二步，生成设计系统。AI 执行脚本命令：
python3 scripts/search.py "beauty handmade soap natural warm" --design-system -p "Handmade Soap"
脚本返回一整套推荐：适合手工艺品的风格（可能是 organic 或 rustic），配色方案（可能是米白+深棕+橄榄绿），字体搭配（可能是 Playfair Display 做标题 + Lato 做正文），效果建议（可能是柔和阴影+圆角）。
第三步，补充搜索。如果 AI 觉得配色方案不够，或者想看看更多 UX 规则，会再做几次搜索。
第四步，技术栈指南。默认 html-tailwind，AI 会去查 Tailwind 的最佳实践——怎么写响应式布局、怎么处理图片懒加载、怎么用 Tailwind 的颜色系统。
然后 AI 把这些信息综合起来，输出完整的 HTML/Tailwind 代码。代码里已经包含了推荐的设计风格、配色、字体、布局策略。而且输出之前 AI 会过一遍 Pre-Delivery Checklist：有没有用 emoji 当图标？cursor-pointer 加了没？移动端适配做了没？
整个过程你可能就说了那一句话。AI 帮你做了 5 步专业工作。
你说："帮我 review 一下这个 Button 组件的 UI 代码。"
AI 不会上来就改代码。它会按优先级来：
先看 CRITICAL 级别——可访问性。这个按钮有没有焦点状态？有没有 aria-label？对比度够不够 4.5:1？
再看 CRITICAL 级别——交互。触摸目标够不够 44x44px？有没有 loading 状态？点击后按钮有没有 disable？
然后看 HIGH 级别——性能。hover 动画用的是 transform/opacity 还是 width/height（前者性能好，后者会触发回流）。
接着看 MEDIUM 级别——配色和字体。颜色选得合不合适，行高是不是在 1.5-1.75 之间。
最后看 LOW 级别——有没有可以用图表优化的地方（如果是数据展示类组件）。
每一级都检查完了，才给出审查报告。报告里会标明问题级别（CRITICAL / HIGH / MEDIUM / LOW），给出具体修改建议，甚至给出修改后的代码。
这种分级审查的方式，比直接说"帮我看看代码好不好"有效得多。因为它确保了最重要的问题最先被发现。换句话说，不是所有问题都值得花同样的时间，CRITICAL 的问题一个都不能漏，LOW 的问题可以慢慢来。
你说："我在做一个医疗健康类的 App，帮我选一套配色和字体。"
AI 执行脚本：
python3 scripts/search.py "healthcare medical app" --design-system
python3 scripts/search.py "clean professional trust" --domain color
python3 scripts/search.py "medical clean readable" --domain typography
脚本会从 96 套配色方案里找出适合医疗行业的——可能是蓝白配色（信任感+干净感），从 57 组字体里找可读性高的——可能是 Inter 或 Roboto 这种无衬线字体。
这里有一个关键点：AI 不是"凭感觉"推荐的。它是从数据库里检索的。96 套配色是专业整理的，不是 AI 拍脑袋想的。这也是用 scripts/ + data/ 的好处——数据质量可控，AI 不会推荐一套"看起来好看但不符合行业规范"的配色。
我把这个 Skill 里的设计决策提炼成了 7 个通用模式。这些模式不限于 UI/UX 领域，你在任何 Skill 里都能用。
适合谁：你的 Skill 适用范围广，用户可能用各种说法来触发。
怎么做：description 里把所有可能的触发词都写上。动词（plan/build/design）、名词（website/dashboard）、风格（glassmorphism/minimalism）、组件（button/modal/card）全部堆进去。宁多勿少。
不适合谁：你的 Skill 功能非常单一，比如"只生成 Docker Compose 文件"。这种情况用"精准狙击"策略更好——写清楚做什么，再写清楚不做什么。
适合谁：你的 Skill 有多个检查维度或多个任务，需要按重要程度排序。
怎么做：用 CRITICAL / HIGH / MEDIUM / LOW 标注每个维度的严重程度。让 AI 知道什么是红线、什么是建议、什么是锦上添花。
适合谁：你的 Skill 有明确的操作流程，AI 不能跳步或乱序。
怎么做：写清楚 Step 1、Step 2、Step 3……每一步做什么，给出具体的命令或指令。重要的步骤标上 REQUIRED。
适合谁：你的 Skill 容易输出"方向对但细节错"的结果。
怎么做：每条规则都写"该做什么"和"不该做什么"两列。正面和负面指令都要有。
适合谁：你的 Skill 输出需要质量控制，AI 经常在某些细节上"偷懒"。
怎么做：在正文末尾加一个检查清单，列出所有容易遗漏的检查项。AI 输出之前会过一遍清单。
适合谁：你的 Skill 需要大量参考数据（几十上百种选项），不可能全写进正文。
怎么做：数据放 data/ 目录（CSV、JSON 都行），用 scripts/ 里的 Python 脚本按需检索。SKILL.md 只写"什么时候调用脚本"和"怎么调用"。
适合谁：你的 Skill 需要支持多个框架、多个平台、多个版本，每个有不同的规范。
怎么做：每个场景一个独立文件（如 react.csv、vue.csv），AI 根据用户的技术选型加载对应的文件。不用的不加载。
正文里有一个很巧妙的**"Master + Overrides"设计**，我单独拿出来讲，因为很多人会忽略它。
当你用 --design-system --persist 参数执行脚本时，它会在你的项目里创建两个东西：
design-system/MASTER.md——全局的设计规范，所有页面都遵循。design-system/pages/ 目录——每个页面可以有自己的覆盖规则。比如你的项目整体用的是简约风格（写在 MASTER.md 里），但"促销活动页"需要活泼一点的风格（写在 pages/promo.md 里）。AI 在做促销页面的时候会先看 pages/promo.md，有覆盖规则就用覆盖的，没有就用 MASTER.md 里的默认规则。
这个设计解决了什么问题？大型项目通常有统一的设计规范，但某些特殊页面需要打破规范。如果只有一套规则，要么特殊页面也被规范限制死了，要么规范本身被搞得一团糟。Master + Overrides 让通用规则和特殊规则各管各的，互不干扰。
你想想，这个思路是不是很像编程里的"默认配置 + 局部覆盖"？CSS 的 cascade，VS Code 的 settings.json 和 workspace settings，都是这个思路。
这个模式你也可以借鉴。如果你的 Skill 需要处理"默认行为 + 特殊情况"的场景——比如你做一个"代码生成器"，大部分代码遵循公司规范，但某些老项目有自己的规范——就可以用 Master + Overrides 的思路。
最后聊聊它为什么会爆火。不是因为技术多牛，是因为它准确命中了一个真实的、高频的、让人头疼的痛点。
开发者最怕什么？不是写逻辑，不是调 bug，是做 UI。配色配不好，字体选不对，布局不协调，动画太生硬。这些事需要专业的设计知识，但大部分开发者不是设计师。你让他们选一套"适合金融 SaaS 的配色"，他们大概率选不出来。
ui-ux-pro-max 解决的就是这个问题。它把专业设计师的知识打包成了一个 Skill——67 种风格、96 套配色、57 组字体、99 条 UX 规则。你不需要懂设计理论，输入需求就能得到专业方案。
说几个它火的原因：
痛点真实且高频。 设计类需求是开发者搜索最多的类别之一。"精美软件架构图"搜了 34 次、"UI" 17 次——这不是我编的，是真实的搜索数据。说明什么？说明开发者真的需要设计方面的帮助，而且经常需要。
覆盖面极广。 13 个技术栈意味着不管你用什么框架都能用，没有"不适合我的技术栈"这个借口。你用 React？有。用 Vue？有。用 Flutter？有。连 Astro 都有。
数据驱动，不是 AI 瞎编。 67 种风格、96 套配色是从数据库检索的，不是 AI 拍脑袋想的。推荐结果更可靠。这一点特别关键——用户用几次发现推荐确实靠谱，就会一直用下去。
即装即用。 复制文件夹就生效，零配置。有 Python 环境就行，脚本会自动检查和提示安装。
ui-ux-pro-max 的架构不只能用于设计。任何"有大量选项需要检索"的场景都能用同样的思路。
举个例子。假设你是一个律师助理，经常要写法律文书。不同案件类型（民事、刑事、行政）有不同的文书模板和法规引用。你可以做一个 legal-doc-helper：
legal-doc-helper/
├── SKILL.md ← 写清楚：先判断案件类型，再检索模板，再填充内容
├── scripts/
│ └── search.py ← 根据案件类型和关键词检索法规和模板
└── data/
├── civil.csv ← 民事案件模板和法规
├── criminal.csv ← 刑事案件模板和法规
└── administrative.csv ← 行政案件模板和法规
SKILL.md 正文里写优先级分层：先确认案件类型（CRITICAL），再核对法规时效性（HIGH），再检查文书格式（MEDIUM），最后润色措辞（LOW）。加 Do/Don't 反模式表格。加 Pre-Delivery Checklist。
整个架构和 ui-ux-pro-max 一模一样，只是领域从"设计"换成了"法律"。
再举个例子。假设你是一个健身教练，经常要给学员定制训练计划。不同目标（增肌、减脂、康复）有不同的动作库和计划模板。你可以做一个 fitness-planner：
fitness-planner/
├── SKILL.md
├── scripts/
│ └── search.py ← 根据目标和条件检索动作和计划
└── data/
├── exercises.csv ← 动作库（名称、目标肌群、难度、器材）
├── plans.csv ← 计划模板
└── nutrition.csv ← 营养建议
同样的架构，同样的逻辑。关键是你要有足够多的数据（动作、模板、建议），然后用脚本做检索，SKILL.md 做调度。
这就是**"通用模式"的价值**——学会一个案例，你能举一反三到任何领域。不是学它的内容，是学它的骨架。
这个 Skill 用到了前面几个模块里讲过的几乎所有技巧。帮你对照一下，看看是不是都串起来了。
模块 1 讲了"选择正确的存放位置"。ui-ux-pro-max 是一个通用的设计工具，不管你在哪个项目里都能用，所以它适合放在用户级目录 ~/.claude/skills/ 下。如果你做了一个只给特定项目用的设计 Skill（比如只给你公司的设计系统），就放项目级 .claude/skills/。
模块 2 讲了"渐进式披露"。这个 Skill 就是最好的例子。启动时只加载 name + description（388 字符，约 100 token）。触发时加载 SKILL.md 正文（378 行，约 5000 token）。执行脚本时才去读 data/ 里的 CSV 文件。三层加载，按需取用。
模块 3 讲了"description 两种策略"。这个 Skill 用的是"触发词轰炸"策略，因为它是通用型 Skill，需要覆盖尽可能多的触发场景。如果你的 Skill 是专用的（比如"只生成 Docker Compose 文件"），就用"精准狙击"策略——写清楚做什么，再写清楚不做什么。
模块 3 还讲了"正文三要素"——操作步骤、输出格式、反模式。这个 Skill 三个都有。操作步骤是 4 步工作流，输出格式是 design system 的结构，反模式是 Do/Don't 表格。
模块 4 讲了"纯指令型 vs 带脚本型"。这个 Skill 是典型的带脚本型——数据量大（67 种风格、96 套配色），需要精确检索，用脚本比用自然语言靠谱得多。
你看，前面学的所有东西，在一个真实的高质量 Skill 里都用上了。这就是为什么我要把这个案例放在模块 5——它是一个集大成的例子。
Q：我没有 Python 环境，能用这种带脚本的 Skill 吗？
需要安装 Python。SKILL.md 里有 Prerequisites 部分，说明了怎么检查和安装。Windows 用 winget install Python.Python.3.12，macOS 用 brew install python3，Ubuntu 用 sudo apt install python3。脚本不需要任何第三方库，只用 Python 标准库。
Q：我可以参考这个 Skill 的结构写自己的吗？
完全可以。参考它的优先级分层、Do/Don't 反模式表格、Pre-Delivery Checklist、分步工作流这些设计模式，但把数据和内容换成你自己领域的。比如你做一个"菜谱 Skill"，数据文件就放菜谱、食材、调料配比，脚本做检索，正文里写工作流和规则。
Q：67 种设计风格是从哪来的？
从 data/styles.csv 文件里检索的。这些数据是作者从专业设计资源中整理的，不是 AI 生成的。你也可以为自己的领域创建类似的数据文件——比如你做营销领域，可以整理 50 种营销框架、30 种文案模板，放到 data/ 里用脚本检索。
Q：Pre-Delivery Checklist 里的检查项怎么确定？
从实际使用中发现的遗漏项。你用一段时间就会发现 AI 经常在某些地方"偷懒"——忘了加 cursor-pointer、忘了处理移动端、忘了做焦点状态。把这些经常遗漏的项列成清单，就是你的 Pre-Delivery Checklist。建议你先跑一周，收集 AI 的常见遗漏，再回头写清单。
Q：为什么它把 13 个技术栈做成独立文件而不是全写进正文？
因为每个框架的最佳实践不同。React 的性能优化是 memo、useCallback，Vue 的是 computed、watch。如果全写进正文，378 行会变成 3000+ 行，触发时就要加载 3000+ 行的上下文，浪费 token。拆成独立文件后，AI 只在用户用 React 时加载 react.csv，用 Vue 时加载 vue.csv。不用的不加载，省空间。
Q：这个 Skill 的脚本安全吗？怎么确认？
安全。我审查过它的 scripts/ 目录。core.py 只用了 csv 和 os 模块读取本地 CSV 文件，search.py 只用了 argparse 和 subprocess 来调用 core.py，design_system.py 只做数据聚合和格式化。没有任何 requests.post、os.system、eval 这些危险调用。也没有读取环境变量。如果你安装任何第三方 Skill，建议你也做同样的审查——模块 6 里有完整的安全审查方法。
Q：我想做一个类似的多数据 Skill，但数据是中文的，能用 CSV 存吗？
完全没问题。CSV 文件支持 UTF-8 编码，中文数据正常存储和检索。脚本里用 open(file, 'r', encoding='utf-8') 打开就行。数据格式你可以自己定义列名——比如你做一个菜谱 Skill，列名可以是"菜名、菜系、难度、食材、步骤"。脚本根据用户的关键词匹配列名做检索，和这个 Skill 搜索"beauty spa"的逻辑一模一样。
看完拆解，你可能想做一个类似的。给你一个 checklist：
这个 Skill 最值得学的不是它的技术实现，而是它的信息架构——怎么把大量的专业知识组织成一个结构清晰、按需加载的能力包。这个思路适用于任何需要大量数据的 Skill。
拆解完 ui-ux-pro-max，我对"什么是好的 Skill"有了更深的理解。好的 Skill 不是代码写得多的 Skill，而是信息架构做得好的 Skill。
378 行的 SKILL.md，没有一个字是废话。每一段都有明确的功能：优先级表让 AI 知道什么最重要，工作流让 AI 知道按什么顺序做事，Do/Don't 让 AI 知道边界在哪，检查清单让 AI 在输出前自我审查。数据全部外置到 data/ 目录，检索交给 scripts/，SKILL.md 只管"调度"。
这种**"瘦正文、胖数据"**的架构，和你写代码时的"薄 Controller、厚 Model"是同一个思路。核心逻辑保持简洁清晰，具体数据独立维护按需加载。
我后来写自己的 Skill 时，经常会回来看这个案例。不是因为我要抄它的设计，而是它提醒我：Skill 的价值不在于 AI 多聪明，而在于你把专业知识组织得多好。
上一个模块你看到了 ui-ux-pro-max 的完整拆解——优先级分层、Do/Don't 反模式表格、Pre-Delivery Checklist、瘦正文胖数据的架构。但一个案例不够。你还需要看更多不同类型的 Skill，才能理解"高手写法"不是一个套路，而是有多种形态。
下一个模块我再拆几个不同类型的 Skill——有官方出品的极简 Skill，有多平台工作流的编排型 Skill，还有 139 个小 Skill 组成的合集。每个都有不同的设计思路，每个都能给你不同的启发。
优先展示同分类且标签更接近的内容，方便继续串联学习。
通过多个实战案例观察不同类型 Skill 的写法差异，帮助你形成更稳定的写作判断。
按不同用户群体整理 Skill 模板，帮助你快速找到更适合自己场景的起步方式。