atomic-design-molecules（原子设计：分子组件）Skill 是什么？

原子设计：分子组件：把原子拼装成可复用的 UI 功能单元

定位清晰：该技能专注于原子设计（Atomic Design）中的「分子（Molecules）」层级——由多个原子组合而成、只做一件事的最小功能单元，例如表单字段、搜索栏、卡片头部。
规则先行：它不只是帮你写组件，更强制约束「分子只能由原子组成、不能嵌套其他分子、不承载业务逻辑」，从源头上防止组件体系腐化。
开箱即用的模式库：内置表单分子、导航分子、显示分子、操作分子四大类常见分子形态，并给出 FormField、SearchForm、MediaObject、NavItem、CardHeader、ListItem、ButtonGroup、Stat 的完整实现范例。
配套最佳实践与反模式：明确列出「分子套分子」「分子内做 API 请求」「过度抽象」等必须避免的写法，并给出正确替代方案。
上手门槛低：以自然语言描述需求即可驱动，配合文件读写与代码检索能力，直接在项目目录中生成符合原子设计规范的组件文件。

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

技能基本信息

项目	内容
中文名	原子设计：分子组件
英文名	atomic-design-molecules
技能ID	14096
允许使用的工具	Bash、读取、写入、编辑、Glob、Grep

它解决什么问题？

在前端团队落地设计系统时，最常见的困境并不是「原子做不出来」，而是原子做出来之后没人正确地组合它们：有人把搜索框、筛选器、结果列表全塞进一个组件；有人在一个「表单字段」里调用了接口；还有人让分子去 import 另一个分子，最终形成一张无法维护的依赖网。该技能把「分子」这一层的定义、边界、实现模板和反模式固化成可被 AI 调用的知识，让模型生成组件时天然遵守原子设计纪律。

「一键安装」的思路与步骤

所谓「一键安装」，本质是把该技能挂载到你的 AI 编码环境中，让模型在处理组件开发任务时自动加载这套方法论，而不是每次靠你在提示词里重复粘贴规范。通用流程如下：

确认安装前提：你的 AI 编码工具需要支持技能（Skill）机制，并具备文件读写与命令执行能力——该技能声明的工具集为 Bash、读取、写入、编辑、Glob、Grep，说明它需要在真实工程目录中检索与创建文件。具体支持的客户端与版本要求，以官方说明为准。
通过技能入口安装：在技能市场 / 技能管理页面搜索技能名 atomic-design-molecules 或技能ID 14096，点击安装或启用。若你的环境使用命令行方式管理技能，安装命令与参数请以官方说明为准。
在项目中设置作用范围：建议将技能绑定到前端组件目录（如 src/components），这样模型在生成或修改分子组件时会自动遵循「仅从 atoms 导入」的约束。
验证是否生效：在对话中提出一个典型请求，例如「帮我创建一个 SearchForm 分子，由 Input 和 Button 两个原子组成，包含加载态和清除按钮」。如果返回结果满足以下三点，说明技能已正确加载：
- 组件只 import @/components/atoms/... 下的原子，没有 import 其他 molecules；
- 组件内部不包含 fetch / axios 等数据请求逻辑，只暴露 onSubmit 这类回调；
- 组件带有明确单一职责与最小化的内部状态（如仅保存输入值）。
长期生效建议：把技能产出的分子目录结构与命名约定写入团队规范文档，后续新成员用同一技能即可保持风格一致。

该技能的主要功能和特点

分子层级的知识锚定：清晰定义分子的五大特征——仅由原子组成、单一目的、功能单元、可重用、最小内部状态，避免「什么算分子」的长期争论。
四大类分子模式库：覆盖表单分子（表单字段、搜索表单、切换组、日期选择器、文件上传器）、导航分子（导航项、面包屑项、分页控件、标签项）、显示分子（媒体对象、卡片头部、列表项、统计显示）、操作分子（按钮组、下拉触发器、图标按钮、操作菜单）。
可直接落地的 TypeScript 实现模板：每个示例都包含 Props 接口定义、forwardRef 转发、displayName 设置、ARIA 可访问性属性（aria-describedby、aria-required、aria-current、aria-pressed）以及配套 CSS Module，复制即可改造。
可访问性内建：FormField 会自动关联 helpText 与 error 的 aria-describedby，出错时使用 role="alert"；NavItem 会自动标记 aria-current="page"；ButtonGroup 使用 role="group" 与 aria-pressed。这些细节在纯手写时极易被遗漏。
反模式清单：明确禁止「分子导入分子」「分子内写业务逻辑与 API 调用」「为单个原子套一层无意义包装（过度抽象）」，并给出应提升到 organism 层的正确做法。
属性设计指导：推荐「清晰的属性转发」（如 inputProps?: Partial<InputProps>），反对无休止铺开的 inputPlaceholder、inputDisabled、inputSize 式命名。
与其他原子设计技能联动：可与 atomic-design-fundamentals（方法论）、atomic-design-atoms（原子）、atomic-design-organisms（生物）配合形成完整链路。

和普通工具比强在哪？ 普通 AI 编码助手擅长「写出能跑的组件」，但不一定「写得符合设计系统分层」。该技能的价值在于约束——它让模型在生成代码时主动拒绝跨层依赖和职责越界。

如何使用该技能？

以下为典型使用流程，全部以自然语言驱动即可。

第 1 步：明确你要做的分子属于哪一类

先用一句话定位，例如「我要做一个显示类的媒体对象分子：左侧头像，右侧标题 + 副标题 + 元信息，最右侧放一个操作按钮」。

第 2 步：告知已有的原子清单

技能依赖原子，因此需要让模型知道项目里有哪些原子可用。可直接说：「本项目原子位于 @/components/atoms，现有 Label、Input、Typing（Typography）、Icon、Button、Badge、Avatar、Checkbox」。

第 3 步：提出生成请求（输入示例）

使用原子设计分子技能，在 src/components/molecules/FormField 下创建一个 FormField 分子：

由 Label、Input、Text 三个原子组成；

支持 label、name、helpText、error、required 属性；

有 error 时不显示 helpText，并让输入框带上错误态；

需要 forwardRef 转发到 input，并补全 aria 关联。

第 4 步：检查输出（输出说明）

预期会得到类似结构的文件：FormField.tsx + FormField.module.css。核心逻辑应包括——

通过 id || \field-${name}`生成唯一fieldId`；
分别计算 helpTextId、errorId，合并为 describedBy 传给 Input 的 aria-describedby；
有 error 时渲染 role="alert" 的错误文本，无错误时才渲染帮助文本；
样式层用 flex-direction: column; gap: 6px 保证标签、输入、提示纵向排列。

第 5 步：补充状态类需求

对于带交互的分子（如 SearchForm、ButtonGroup），明确告诉模型「内部状态只保留输入值或选中值，提交逻辑通过 onSubmit / onChange 回调交给父级」。例如 SearchForm 的预期行为是：用 useState 持有 query，handleClear 清空并触发 onChange('')，提交时 onSubmit(query.trim())。

第 6 步：做一次分层自检

生成后用一句话让模型自查：「请检查这个分子是否 import 了其他分子、是否包含数据请求、是否属性命名过长」。若命中反模式，模型会按技能规则改为委托父级或提升到 organism 层。

第 7 步：复用与沉淀

同一类分子只需生成一次，后续通过属性组合复用（如 ButtonGroup 支持 multiple 多选、size 尺寸变体），避免为每个页面重写一遍。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
原子设计：分子组件（本技能）	面向设计系统分层规范的 AI 组件生成技能	分子定义、四类模式库、TypeScript 实现模板、可访问性内建、反模式清单	需支持技能机制的 AI 编码环境，安装方式以官方说明为准；无需额外依赖	已有原子层、需要规模化生产分子组件的团队	优势：约束严格、开箱即用、可访问性细节完备；不足：需项目已有原子层，纯新项目需先补原子
通用 AI 编码助手（无技能约束）	通用代码生成	按描述生成任意组件代码	门槛低，插件式安装	一次性页面开发、原型验证	优势：灵活、上手快；不足：不保证分层正确，容易产出跨层依赖与业务逻辑混入的组件
成熟组件库（如 Ant Design、MUI 等）	成品 UI 组件集合	提供现成的输入框、按钮、卡片等组件	需引入依赖并按主题定制，具体版本与许可以官方说明为准	追求交付速度、定制需求少的项目	优势：稳定、生态完善；不足：组件粒度由库决定，难以严格映射自家原子/分子分层，深度定制成本高
设计工具 + 设计系统插件	设计侧的组件规范管理	在设计稿中维护组件变体与规范	需要设计团队协作维护	设计与研发协同、规范沉淀	优势：视觉规范统一；不足：不产出可直接使用的代码，仍需研发二次实现

如何选择？ 若你的团队已经在推原子设计、痛点是「分层混乱、组件重复」，本技能最对症；若只是快速出页面，成品组件库更省事；若连规范都还没定，建议先补 atomic-design-fundamentals 与 atomic-design-atoms。

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

场景一：中后台表单页面的高频字段

角色：前端工程师，负责一套内部管理系统的表单。
痛点：每个页面都手写「标签 + 输入框 + 错误提示」，错误提示与输入框的 aria 关联几乎没人写全，无障碍审计屡屡扣分。
使用方式：用本技能一次性生成 FormField 分子，之后所有表单页面复用它，只需传入 label、name、error、helpText。
实际体验：生成代码的完成度高，describedBy 合并、错误态优先级的处理都已内建，基本不需要二次修改。注意：需要确认项目里的 Text 原子是否支持 size、color 等属性，属性名不一致时要先对齐原子接口。

场景二：列表页的搜索与筛选区域

角色：业务前端，负责数据列表页。
痛点：搜索框常被写成「输入框 + 按钮 + 清除图标 + 加载态 + 请求逻辑」的混合体，导致无法复用。
使用方式：让技能生成 SearchForm 分子，明确要求请求逻辑放在父级，组件只接收 onSubmit、onChange、isLoading。
实际体验：技能会主动把 fetch 逻辑剥离，符合「分子不承载业务」的原则。清除按钮的 aria-label="清除搜索" 也已补上。注意：实时搜索的防抖属于业务逻辑，应放在父级或自定义 Hook 中，不要塞回分子。

场景三：导航与侧边栏

角色：设计系统维护者。
痛点：导航项在不同产品线里样式与行为不一致，激活态、徽标数、禁用态各写各的。
使用方式：生成 NavItem 分子，统一 icon、label、href、isActive、badge、disabled 六个属性，徽标超过 99 自动显示 99+。
实际体验：属性收敛效果好，配合 ButtonGroup、Stat 等分子可快速拼出侧边栏与数据看板。注意：若项目使用路由框架，href 需替换为路由组件，这一点技能本身不涉及，需人工接入。

场景四：卡片与列表的头部结构

角色：多产品线共用组件库的团队。
痛点：卡片头部在每处都重新写一遍标题层级、图标、操作按钮，导致标题 level 混乱、可访问性不一致。
使用方式：用 CardHeader 分子统一 title、subtitle、icon、actionLabel、onAction。
实际体验：Heading level={3}、次按钮 variant="tertiary" 等细节被固化下来，风格统一性明显提升。注意：当需求出现「卡片头部 + 折叠 + 更多菜单」时，说明已经超出分子边界，应提升为 organism。

整体上手难度：低。只要能描述清楚「这个分子由哪些原子组成、要做哪一件事」，就能得到可用代码。最需要留心的是前提条件——项目里必须已有可用的原子层，否则技能会陷入「无原子可组合」的尴尬。

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

效率提升：过去一个表单分子从设计到对齐命名、补可访问性、写样式，往往需要半天；用技能模板化生成后，多数场景可在十几分钟内完成并进入联调，重复字段类组件几乎零成本复用。
降低规范落地门槛：原子设计的文档通常「写起来厚、用起来薄」。该技能把规范变成可执行约束，新成员无需通读文档，也能产出符合分层的组件。
减少架构腐化成本：通过明确禁止「分子套分子」和「分子内写业务逻辑」，把组件依赖控制在「分子 → 原子」两层，长期看显著降低重构成本——这类腐化问题往往在项目半年后集中爆发，修复代价远高于事前约束。
可访问性基线统一：ARIA 关联、role="alert"、aria-current、aria-pressed 等细节被写进模板，避免每个组件各写一套，也降低合规审计风险。
协作语言统一：设计师、前端、测试可以共用「分子」这一粒度沟通需求，减少「这个算组件吗」的反复确认。
长期资产沉淀：生成的分子目录结构、Props 命名、样式方案天然一致，随着分子库增长，会逐步形成团队自己的设计系统资产，而不是一堆一次性组件。

常见问题 FAQ

Q1：这个技能怎么安装？需要额外依赖吗？

A：在支持技能机制的 AI 编码环境中，搜索技能名 atomic-design-molecules 或技能ID 14096 安装启用即可。它本身声明的工具为 Bash、读取、写入、编辑、Glob、Grep，属于对工程目录的操作能力，不引入运行时依赖。具体的安装命令、客户端支持范围与版本要求，以官方说明为准。

Q2：使用这个技能收费吗？

A：技能本身的费用与获取方式取决于你所使用的技能平台与账户套餐，本文无法给出确定价格，请以官方说明为准。需要区分的是：技能只是生成代码的方法论与模板，它不会给项目引入额外的商业组件库授权成本。

Q3：这个技能适合谁用？新项目能直接用吗？

A：最适合已经采用或计划采用原子设计的前端团队、设计系统维护者、以及需要批量产出表单与列表组件的业务开发者。新项目需要先具备原子层——因为分子的定义就是「仅由原子组成」，如果项目里没有 Label、Input、Button、Icon 这些原子，建议先配套使用 atomic-design-atoms，再来做分子。

Q4：它和直接用现成组件库（如 Ant Design）冲突吗？

A：不冲突，但定位不同。组件库给你成品组件，粒度和分层由库决定；本技能给你「如何组织自家组件」的规范与模板。如果团队需要严格的分层与深度定制，用技能自建分子更合适；如果只是快速交付，组件库更省事。两者也可以并存，例如内部原子封装组件库的底层实现，分子层由本技能生成。

Q5：生成的分子里带了接口请求，算不算正常？

A：不正常，这正是该技能明确列出的反模式之一。分子不应包含 API 调用与业务逻辑，正确做法是通过 onSubmit、onChange 等回调把逻辑委托给父级组件，或在父级用 Hook 处理。若发现生成结果越界，直接指出「请按原子设计分子规范，把数据请求移到父级」即可纠正。同理，若一个分子 import 了其他分子，说明它应该提升到 organism 层。