本案例根据《用 AI 打造一套自己的组件库》整理，保留原作者三次尝试的先后关系。重点是设计规则与实现之间如何形成反馈，不将单个项目的完成时间推广成通用承诺。
问题不是“让 AI 多写几个组件”
原作者希望建立一套视觉规则由自己控制的组件库，为后续 Design Harness 打基础。组件能渲染只是起点：颜色、间距、尺寸和状态需要一致，改一个设计决定时，也要知道会影响哪些地方。
最初直接让 AI 修改现成组件，虽然很快能看到页面，但设计规则没有先定义清楚，后续就在不断叠加覆盖样式和重复解释需求。
三次尝试发生了什么
| 尝试 | 做法 | 遇到的问题或留下的成果 |
|---|---|---|
| 第一次 | 用 React、Vite 和 shadcn/ui 源码直接修改 | 预设视觉与目标不一致，自己的规则也不清晰，覆盖和维护负担增加 |
| 第二次 | 先在 Figma 定 styles、变量和基础组件，再让 AI 转成代码 | 沉淀了可复用设计资产，但自建预览环境需要持续维护 |
| 第三次 | 继承已有设计资产，采用 Base UI、语义变量和 Storybook | 在当时规划的范围内完成组件库，形成可观察、可修改的反馈回路 |
第三次不是从零开始。它复用了第二次已经整理好的视觉资产，所以不能将成功归因于“换一个库就自动完成设计”。
关键做法一：人决定视觉，AI 负责一致实现
作者在 Figma 中先确定颜色、层次、间距和基础样式。这些是人的设计判断，不让 AI 每次按印象重新猜。
AI 接手批量工作：将已确定的数值转成变量，把设计定义落实成代码，并补全重复结构。设计师在预览中发现问题后，能指向具体规则提出修改要求。
例如，“危险按钮的强调背景在悬停时再深一档”，比“让这个按钮更有感觉”更容易被检查，也更容易判断是否改到了正确位置。
关键做法二：用语义变量连接设计与组件
原文的变量分成三层：
- 基础色阶：保存红色、灰色等具体数值。
- 语义用途：定义文字、边框、背景、交互、表面等用途，以及危险和悬停等状态。
- 组件引用：组件使用用途明确的变量，不在每个地方独立挑选颜色。
这让设计决定有了可以指认的名字。调整危险动作的背景，不必逐个猜测哪些红色应该一起改。
但有变量文件不等于所有组件都自动遵守规则。作者仍需要检查实际引用，确认组件状态确实走了同一套定义。
关键做法三：复用视觉，不混淆交互语义
作者把一些组件按视觉结构归为同族。例如 Button、Tag、IconButton 都可能由背景、图标和文字组成，布局规则可以共享。
共享外观不代表它们应当成为同一个交互组件。按钮执行动作，标签展示信息；输入框、选择器和密码框即使边框一致，内部行为也不同。
原文特别提到 readonly 和 disabled：只写属性名不足以对齐预期，还需要明确能否聚焦、能否打开面板、能否修改值。规则说清以后，再检查具体实现是否符合约定。
关键做法四：在 Storybook 中逐个验收状态
第三次尝试用 Storybook 接替自行搭建的展示工作台。作者可以单独查看一个组件的一个状态，再让 AI 做具体修改，然后重新观察。
项目仍然使用 React 与 Vite；Storybook 替换的是需要额外维护的组件展示环境，不是把原有框架全部换掉。
这次采用的 Base UI 负责行为与可组合结构，视觉样式仍由作者控制。它也没有包办全部需求：原文中的分钟、秒、毫秒时间工具是项目自行开发的组件，不是拿来即用的内置能力。
最终得到什么
原文记录的结果，是在既定范围内完成了作者满意的组件库，并保留下可继承的设计变量、基础组件和状态预览方式。
完整的 Design Harness 仍是后续目标。现有成果是它的组件基础，不能将两者直接画等号。超出当时范围的组合控件和特殊行为，仍需单独设计与开发。
可复用检查清单
- 先定义颜色、尺寸、间距和状态规则，再批量生成组件。
- 区分基础数值与语义用途，检查组件是否使用正确变量。
- 视觉相近的组件仍保留正确的 HTML 语义与交互行为。
- 为默认、悬停、聚焦、只读、禁用等适用状态建立预览。
- 修改共享变量后检查多个组件，而不是只看当前一个。
- 把特殊需求单列范围，不假设底层库已经实现。
评论0