从设计稿到组件库：一次完整的落地过程和踩过的坑

把一套设计稿变成可复用的组件库，中间的距离比想象中大。我把最近一次的完整流程写下来。 第一步，建立令牌层。颜色、字号、间距、圆角、阴影全部抽成变量，不要在组件里写死具体值。这一步是后面所有工作的基础，跳过它后面一定会返工。令牌的命名要有语义，用 primary、surface、border 这类描述用途，而不是 blue-500 这种描述外观。 第二步，确定组件的原子顺序。先做最基础的按钮、输入框、标签，再做组合型的卡片、列表项，最后做页面级的布局容器。顺序错了会反复重构，因为上层组件的接口会被下层的变化牵动。 第三步，每个组件写三种状态。默认、悬停或聚焦、禁用，外加错误态。这三种状态是最容易被漏掉的，漏掉的结果是上线后用户一交互就露馅。建议在组件文档里把状态逐列出来，作为验收清单。 第四步，可视化验证。这一步我用 MiMo Desktop 做，把所有组件和状态铺在一个预览页里，逐个点过去看。所有状态在一屏内可见，比在业务页面里逐个触发效率高得多。Claude Code 在这条链路上更适合做另一件事——写文档站的构建脚本和组件 API 的类型定义，这类结构化的活它做得很稳。 踩过的坑列一下： 一，深色模式最后才做，导致大量硬编码颜色要回头改。应该一开始就把两套令牌一起定义。 二，间距用了魔法数字，导致视觉不一致。坚持只用令牌里的间距刻度。 三，无障碍属性后补。按钮没有 aria 标签、图标没有文本替代，这些补起来零散又费时，不如一开始就写。 落地的判断标准很简单：新页面开发时，工程师不需要设计师介入就能拼出来，且拼出来的东西和设计稿一致。