--- title: "爆款拆解：UI UX Pro Max" wiki: skills category: "案例解析" slug: M05A-爆款拆解-ui-ux-pro-max url: https://learnagent.wiki/skills/cards/M05A-爆款拆解-ui-ux-pro-max tags: ["爆款 Skill", "拆解", "UI", "UX"] last_updated: 2026-04-11 reading_time: 28 --- > > 模块5A：爆款拆解 — ui-ux-pro-max | 用时：约25分钟 | 目标：逐层拆解一个真实爆款 Skill，搞懂高手的信息架构思路 # 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 的认知负担。你别说，这设计太精妙了。 --- ## description 分析：388 个字符的触发词轰炸 整个 Skill 最值得琢磨的部分，我认为是 **description**。不是因为它多复杂，恰恰是因为它看起来简单，但**每个字都经过了精心设计**。 先看原文： ```yaml 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 个字符的额度，它几乎用满了。** --- ## 正文结构：378 行里藏着的 4 个设计模式 SKILL.md 正文有 **378 行**。不是随便写的 378 行——**每一段都有明确的功能定位**。我拆出 4 个最值得学的核心设计。 ### 设计一：优先级分层——让 AI 知道什么最重要 正文最开头的部分是一张优先级表： ``` 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 命令模板： ```bash python3 skills/ui-ux-pro-max/scripts/search.py " " --design-system [-p "Project Name"] ``` AI 读到这一步就知道：我要执行这条命令，把用户的需求翻译成参数填进去。不用猜，不用想，照做就行。 这就是**"固定步骤"的写法**——模块 3 里讲过的，对高风险或流程性强的任务，步骤要写死，不留发挥空间。你给 AI 留发挥空间，AI 就给你发挥到沟里去。 ### 设计三：Do/Don't 反模式表格——正反两面都给 正文里有大量这样的表格： ``` 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 就不会用自己的默认判断来"发挥"。 ### 设计四：Pre-Delivery Checklist——交付前的最后一道关 正文末尾有一个检查清单： ``` 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。 --- ## 为什么用 scripts/ 处理数据：最值得学的架构决策 整个 Skill 里，我认为**最值得学的架构决策**就是这一条：**大数据用脚本处理，不塞进正文**。 ui-ux-pro-max 有 **67 种设计风格、96 套配色方案、57 组字体搭配、99 条 UX 规则**。这些数据如果全部写进 SKILL.md 正文，你猜会占多少 token？**至少 20000+**。20000 token 意味着什么？AI 的上下文窗口直接被吃掉 10%。 但这个 Skill 聪明在哪——它把这些数据全部放到了 `data/` 目录的 CSV 文件里，然后用 Python 脚本按需检索。 SKILL.md 里只写了"什么时候调用脚本"和"怎么调用"： ```bash 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 你说："帮我做一个卖手工皂的 Landing Page，风格要温暖自然。" AI 收到请求后，按 Skill 的工作流走： **第一步，分析需求**。产品类型是电商（手工皂），风格关键词是温暖自然，行业是美妆/手工艺，技术栈没指定，默认用 html-tailwind。 **第二步，生成设计系统**。AI 执行脚本命令： ```bash 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 一个 React 组件 你说："帮我 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 配色 你说："我在做一个医疗健康类的 App，帮我选一套配色和字体。" AI 执行脚本： ```bash 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 不会推荐一套"看起来好看但不符合行业规范"的配色。 --- ## 7 个通用模式：你写自己的 Skill 时可以直接用 我把这个 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。 ### 模式四：Do/Don't 反模式表格 **适合谁**：你的 Skill 容易输出"方向对但细节错"的结果。 **怎么做**：每条规则都写"该做什么"和"不该做什么"两列。正面和负面指令都要有。 ### 模式五：Pre-Delivery 检查清单 **适合谁**：你的 Skill 输出需要质量控制，AI 经常在某些细节上"偷懒"。 **怎么做**：在正文末尾加一个检查清单，列出所有容易遗漏的检查项。AI 输出之前会过一遍清单。 ### 模式六：大数据用脚本处理 **适合谁**：你的 Skill 需要大量参考数据（几十上百种选项），不可能全写进正文。 **怎么做**：数据放 `data/` 目录（CSV、JSON 都行），用 `scripts/` 里的 Python 脚本按需检索。SKILL.md 只写"什么时候调用脚本"和"怎么调用"。 ### 模式七：多场景拆文件 **适合谁**：你的 Skill 需要支持多个框架、多个平台、多个版本，每个有不同的规范。 **怎么做**：每个场景一个独立文件（如 react.csv、vue.csv），AI 根据用户的技术选型加载对应的文件。不用的不加载。 --- ## Master + Overrides：一个容易被忽略的精妙设计 正文里有一个很巧妙的**"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 的思路。 --- ## 为什么这个 Skill 会火 最后聊聊它为什么会爆火。不是因为技术多牛，是因为它**准确命中了一个真实的、高频的、让人头疼的痛点**。 开发者最怕什么？不是写逻辑，不是调 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——它是一个**集大成的例子**。 --- ## FAQ **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"的逻辑一模一样。 --- ## 如果你做一个类似的 Skill 看完拆解，你可能想做一个类似的。给你一个 checklist： 1. **先想清楚你的 Skill 要覆盖多少"选项"**。如果超过 20 种，就用 data/ + scripts/ 的架构，别全塞进正文。 2. **description 用"触发词轰炸"策略**。通用型 Skill 的 description 越长越好，1024 字符的额度尽量用满。 3. **正文里加优先级分层**。让 AI 知道什么最重要。 4. **正文里加 Do/Don't 表格**。告诉 AI 该做什么、不该做什么。 5. **正文末尾加 Pre-Delivery Checklist**。让 AI 输出前自我审查。 6. **每个步骤给出具体的命令模板**。别让 AI 猜怎么执行。 7. **多场景的内容拆成独立文件**。不用的不加载。 这个 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 组成的合集。每个都有不同的设计思路，每个都能给你不同的启发。 --- *Source: https://learnagent.wiki/skills/cards/M05A-爆款拆解-ui-ux-pro-max* *Markdown mirror of https://learnagent.wiki, served as text/markdown for LLM ingestion.*