组件设计Skill 用法详解

组件设计Skill：用原子设计把 React/Vue 组件写成可复用的资产

它是什么：一个专门针对 React/Vue 组件设计的 AI 技能，把「原子设计分层 + 组合模式 + 类型接口 + 状态管理决策树」这套工程化方法论固化成可调用能力，技能英文名 component-design，技能 ID 为 11838。
它解决什么问题：组件名随意、层级混乱、Props 接口想到哪写到哪、状态管理乱用全局存储——这些「组件的隐性债务」由 AI 按统一规范一次性收敛。
核心能力：原子/分子/生物体/模板/页面五层划分、复合组件、渲染属性、自定义钩子三种组合模式、带注释的强类型 Props 接口、现成组件模板、状态管理选择决策树。
适合谁用：前端工程师、技术负责人、需要长期维护组件库的团队，以及正在从「能跑就行」升级到「可复用体系」的项目。
上手成本：安装后直接在对话里提需求即可，无需学习新语法，但需要使用者自己判断业务语义是否合理。

该技能叫什么？如何下载安装 AI 技能提升开发效率？

这个技能的中文名是组件设计Skill，英文名是 component-design，技能 ID 为 11838。从名称就能看出它的定位：不是帮你「写完一个按钮」，而是帮你「设计一套按钮」。

它要解决的是前端开发中最容易被忽视、却最消耗团队协作效率的问题：

层级混乱：同一个项目里，有人把搜索框当成原子，有人当成生物体，组件目录越堆越乱。
接口随意：ButtonProps 今天叫 type，明天叫 variant，后天又冒出 kind，调用方永远在猜。
组合方式不统一：有人写复合组件，有人写渲染属性，有人直接把逻辑塞进页面，复用性差。
状态管理拍脑袋：一个加载状态用上了全局 store，一个跨页面共享的数据却用 useState 传了五层 props。

为什么要走「一键安装」的路子？

传统做法是把《组件设计规范》写成文档，然后指望每个人都读完并遵守。现实是文档没人看、看了记不住、记住了执行不一致。AI 技能的思路是把规范变成可执行上下文：安装一次，之后每次让 AI 帮你写组件，它都会自动带上原子设计分层、组合模式参考、Props 接口约定和状态管理决策树，规范从「贴在墙上的纸」变成「长在流程里的手」。

安装前提：

使用支持「技能（Skill）」机制的 AI 编程助手或 IDE 插件环境，并确保该环境允许 AI 读取与写入项目文件（生成组件文件、读取 patterns/ 下的参考文档）。
项目已明确使用 React 或 Vue 技术栈，且能说明组件要放在哪个目录下。
建议项目里保留技能自带的 patterns/atomic-design.md、patterns/composition.md、patterns/state-management.md 与 templates/component-template.tsx 等参考文件，方便技能按图索骥。

安装步骤（通用路径）：

打开你所使用平台的技能市场 / 技能管理面板，在搜索框中输入技能名 component-design 或技能 ID 11838。
找到对应技能后点击安装或启用，将其加入当前项目或当前工作区。
若平台支持项目级配置，也可在项目的技能配置文件中登记该技能，使其在该项目的所有会话中默认生效。
具体的安装命令、配置字段与入口位置，以官方说明为准。

如何验证是否生效？

安装完成后，新建一次对话，输入类似这样的请求：

「我要做一个带图标的卡片组件，用 React + TypeScript，请按原子设计给我分层，并给出 Props 接口。」

如果回复中出现「原子 / 分子 / 生物体 / 模板 / 页面」这类层级判断、带有 JSDoc 注释的接口字段说明，或者引用状态管理决策树来建议状态放置位置，说明技能已经正常工作。反之，如果回复只是给了一段裸组件代码、没有任何分层与接口约定，则说明技能未被激活，需要回到技能面板确认启用状态。

该技能的主要功能和特点

1）原子设计五层级分层 技能内置原子设计的分层标准：原子（按钮、输入框、标签）→ 分子（表单字段、搜索框）→ 生物体（头部、表单、卡片）→ 模板（页面布局）→ 页面（特定实例）。当你描述一个组件时，它会先帮你判断「这东西应该落在哪一层」，再决定这个组件的职责边界与可复用范围。

2）三种组件组合模式 技能明确支持并给出示例：

复合组件：通过挂载子组件的形式提供灵活结构，示例为 Select 搭配 Select.Trigger、Select.Content、Select.Item 的组合写法，适合下拉、标签页、菜单这类「结构固定但内容可变」的组件。
渲染属性（Render Props）：把数据获取逻辑与渲染逻辑分离，示例为 DataFetcher 通过 url 拿到 data、loading 后由调用方决定怎么渲染，适合需要复用「取数行为」而不复用「界面」的场景。
自定义钩子：把状态与副作用抽离成 useUser 这类可复用函数，返回 { user, loading, error }，适合逻辑复用优先于界面复用的情况。

3）规范的 Props 接口约定 技能要求 Props 以 TypeScript 接口形式表达，并附带注释说明用途。示例中的 ButtonProps 定义了 variant（primary / secondary / ghost）、size（sm / md / lg）、disabled、onClick、children，每个字段都有中文注释。这带来的直接好处是：变体用联合类型收口，调用方写错值立刻报错，而不是上线后才发现样式没生效。

4）现成的组件模板 技能关联了 templates/component-template.tsx，生成新组件时可按统一骨架输出——文件头、接口定义、组件主体、导出方式保持一致，团队新人不必再纠结「这个文件该长什么样」。

5）状态管理决策树 技能给出五级判断顺序：仅 UI 状态用 useState；复杂本地状态用 useReducer；兄弟组件间共享则提升到父级；应用间共享用上下文或全局存储；服务器状态交给 React Query / SWR。这条决策树把「该不该上全局状态」从个人习惯变成可复述的规则。

和普通 AI 编程助手比强在哪？

普通助手擅长「局部正确」——给你一段语法正确的代码；这个技能擅长「体系正确」——它会追问层级归属、给出接口约定、指定组合模式、判断状态应该放在哪一层。前者产出的是代码片段，后者产出的是可以被下一个开发者接手的组件资产。

如何使用该技能？

以下是推荐的使用流程，可直接照做。

第 1 步：激活技能并说明技术栈 在对话开头交代清楚框架与语言，例如：「使用 React + TypeScript（或 Vue 3 + TypeScript），项目已启用 component-design 技能。」

第 2 步：描述组件用途与使用场景 不要只说「帮我写个搜索框」，而是说明「出现在表格页顶部，用户输入关键词后回车触发查询，需要支持清空」。信息越具体，分层判断越准确。

第 3 步：让技能先做层级归属判断 请求示例：

「这个搜索框是否应该先做成分子层？它由输入框和按钮两个原子组成，我打算在三个页面复用。」

技能会结合原子设计层级给出判断：输入框与按钮是原子，搜索框作为二者的组合属于分子层，页面级布局则放到模板层。

第 4 步：生成带注释的 Props 接口 请求示例：

「给出 SearchBar 的 Props 接口，变体、尺寸、是否禁用、回车回调都要覆盖，并加中文注释。」

输出会是类似 ButtonProps 风格的接口：用联合类型限定取值、每个字段一行注释、必填与可选区分清楚。

第 5 步：选择组合模式 根据复用目标选模式：

结构固定、内容可变 → 复合组件（参考 Select 写法）
逻辑复用、界面自定 → 渲染属性（参考 DataFetcher 写法）
只要逻辑、不管界面 → 自定义钩子（参考 useUser 写法）

第 6 步：确定状态放置位置 用决策树逐条对照：加载状态只是本组件 UI 用 → useState；多个步骤的表单状态互相依赖 → useReducer；两个兄弟组件都要读同一个筛选条件 → 提升到父级；整个应用都要读登录信息 → 上下文或全局存储；用户列表来自接口 → React Query / SWR。

第 7 步：基于组件模板产出文件 让技能按 templates/component-template.tsx 的结构输出完整文件内容，包括接口、组件主体与导出，随后写入项目对应目录。

第 8 步：按清单验收 确认四件事：层级归属是否合理、Props 联合类型是否收口、组合方式是否匹配复用场景、状态是否放在了决策树指定的那一层。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
组件设计Skill（component-design）	面向组件设计的 AI 技能，把方法论固化为可调用能力	原子设计五层分层、复合组件/渲染属性/自定义钩子、带注释 Props 接口、组件模板、状态管理决策树	在支持技能的 AI 环境中安装启用即可，无需额外依赖；具体入口以官方说明为准	从零搭组件库、重构存量组件、统一团队规范	优势：产出带体系与约定，规范可复述、可交接；不足：需使用者提供清晰的业务上下文，生成结果仍需人工评审
通用 AI 编程助手（未安装该技能）	通用代码生成	按描述直接输出组件代码	门槛最低，对话即用	一次性页面、临时脚本、快速验证想法	优势：即时、灵活；不足：缺乏分层与接口约定，容易出现命名与结构不一致，长期维护成本高
团队自写组件规范文档 + 人工评审	流程与制度约束	规范文本、评审清单	需要撰写与培训成本，依赖成员自觉	成熟团队、有前端负责人的组织	优势：贴近业务；不足：执行一致性差、反馈慢，规范容易被遗忘
成熟组件库（如 Ant Design、Element Plus 等）	开箱即用的 UI 组件集合	提供成体系的现成组件与主题能力	安装依赖即可使用	中后台管理系统的通用界面	优势：稳定、组件齐全；不足：难以覆盖业务私有组件，二次封装仍需自己定规范

从对比可以看出，这个技能并不与组件库竞争——组件库解决「通用控件有没有」，它解决「你自己的业务组件该怎么设计」。两者叠加使用效果最好。

该技能的典型应用场景与实际体验情况

场景一：中后台项目从零搭建业务组件 角色：前端工程师。痛点：项目刚起步，每次加组件都重新决定目录、命名和 Props 结构，三周后自己都记不清 Button 有几种变体。使用方式：每新建一个组件前先让技能判断层级并输出接口，再按模板落地。实际体验：上手几乎零成本，第一个组件就能感觉到差异——接口有联合类型收口，调用方写错立刻报错，不必靠翻旧代码猜参数。

场景二：存量组件重构与统一 角色：技术负责人。痛点：老项目里 Button、卡片、表单项各写各的，同一功能三份实现。使用方式：把一个组件丢给技能，要求按原子设计重新分层并给出统一接口，再对比旧实现做合并。实际体验：技能给出的分层判断比较贴合常规工程直觉，能快速发现「这个所谓的生物体其实只是一堆原子拼起来」。注意事项：重构涉及调用方改动，建议逐个组件切换，避免一次性改动过大。

场景三：多人协作的组件评审 角色：团队成员与评审者。痛点：PR 里争论「这里该用 Context 还是 props」，全靠谁嗓门大。使用方式：要求技能对照状态管理决策树逐条说明选择理由。实际体验：讨论从「我觉得」变成「按决策树第几条」，评审效率明显提升。注意：决策树是参考不是教条，边界情况仍需结合具体架构判断。

场景四：Vue 团队的设计思路对齐 角色：Vue 开发者。痛点：团队想参考 React 生态的组件分层思路，但不知道如何落到 Vue 的单文件组件上。使用方式：在请求中明确说明「Vue 3 + TypeScript + 单文件组件，按原子设计分层」，让技能给出对应的组合方式与 Props 定义。实际体验：原子设计分层与状态管理决策树是框架无关的，可以完整套用；复合组件与渲染属性示例需要按 Vue 的写法自行转换，交接时建议把这层转换说明写清楚。

该技能能为用户带来的价值

第一，把「经验」变成「流程」。 原子设计、组合模式、Props 接口约定、状态管理决策树，这些本来就是资深前端脑子里的隐性知识。技能把它们变成每次生成都会自动带上的显式规则，团队里经验较少的人也能产出结构合格、接口规范的组件。

第二，显著压缩沟通与返工成本。 过去一个组件的「层级归属、接口命名、状态放哪」往往要经过编码、评审、返工三轮讨论；现在这些问题在动手之前就能一次性确认，评审阶段更多聚焦在业务逻辑正确性上。

第三，提升组件的长期可复用性。 统一接口意味着组件可以被稳定复用于第二个、第三个页面；统一组合模式意味着新人接手时能看懂组件的组织方式；统一状态策略意味着不会出现「找一个状态要翻五个文件」的情况。

第四，降低规范落地的门槛。 不需要先写一篇几万字的前端规范，也不需要安排专门的培训，安装启用技能后，规范在每次对话中自然被应用。对个人开发者来说，这是用极低成本获得一套「架构顾问」；对团队来说，这是一次近乎零成本的规范基础设施投入。

长期价值在于资产积累：当组件库里的每个组件都有清晰的层级、稳定的接口和一致的组织方式时，组件库才真正成为可以复利增长的资产，而不是越堆越难删的历史包袱。

常见问题 FAQ

Q1：这个技能怎么安装？需要付费吗？ 在支持技能机制的 AI 编程助手中，打开技能市场搜索技能名 component-design 或技能 ID 11838，点击安装或启用即可。是否收费取决于所在平台的定价策略，具体以官方说明为准。安装后可先用一个小需求（如「按原子设计拆解一个卡片组件」）验证是否生效。

Q2：它支持 Vue 吗？还是只能写 React？ 技能描述中明确覆盖 React/Vue 组件的设计。原子设计分层与状态管理决策树本身是框架无关的，可以直接套用到 Vue；技能给出的复合组件、渲染属性、自定义钩子示例采用 React 写法，在 Vue 场景下需要在请求中说明技术栈，让 AI 转换成对应的组件写法。

Q3：它会不会直接改我的项目文件？ 这取决于你所使用工具的文件读写权限设置。技能本身提供的是设计方法与模板代码，是否落盘、写到哪个目录由你的环境配置和指令决定。建议首次使用时先让它只输出代码不写文件，确认无误后再执行写入。

Q4：它和 Ant Design、Element Plus 这类组件库是什么关系？ 互补关系。成熟组件库提供通用控件，解决「有没有」的问题；这个技能解决「你自己的业务组件该怎么设计、怎么组织、怎么暴露接口」的问题。实际项目中通常是「组件库打底 + 技能规范业务组件封装」的组合方式。

Q5：适合谁用？不太懂组件设计的新手能用吗？ 适合三类人：需要长期维护组件库的前端工程师、希望统一团队规范的负责人、以及想学习组件设计思路的新手。新手使用时建议先让它解释「为什么这么分层」，再让它输出代码，把它当成一个可以随时追问的设计顾问，而不是一个只吐代码的工具。