做后台 UI 别再反复手搓组件，4.9 万人装的 shadcn Skill

做后台设置页最磨人的地方，往往不是业务逻辑。

是那一串看着都很小的东西：一个带错误态的邮箱输入框，一组开关，一个确认弹窗，再塞两张卡片。每个都能写，合在一起就开始长出 space-y-*、裸颜色和一堆临时 div。页面能跑，过两周谁也不敢碰。

最近看到 shadcn/ui 的官方 Agent Skill，安装量已经到 4.9 万，仓库有 12.3 万 Star。它不负责替你画页面，只要求 Coding Agent 在加组件前，先弄明白项目已经有什么、该查什么、哪些写法别碰。

安装命令在这里：

npx skills add https://github.com/shadcn-ui/ui --skill shadcn

这不是又多了一份组件目录。它把「加一个表单」这种看似简单、实际最容易写歪的活，变成一条有顺序的工作流。

先别急着写 JSX，先看项目底牌

官方 Skill 的第一步是：

npx shadcn@latest info --json

这条命令会告诉 Agent 这个项目的路径别名、Tailwind 版本、组件目录、底层 primitive、图标库和框架上下文。很多 UI 返工，就是从跳过这一步开始的。

比如同样要做一个设置页，项目也许已经有 Card、Tabs、Field，图标库却不是默认的 lucide-react。如果 Agent 不先看上下文，最常见的结局是手写一份看似正常的组件，再留下一条错误 import，或者在旧样式旁边堆出第二套颜色规则。

接着再查组件和文档：

npx shadcn@latest search @shadcn -q "settings"
npx shadcn@latest docs tabs card field
npx shadcn@latest add tabs card

顺序别颠倒。先搜索，确认注册表里有没现成东西；再拿到当前 API 和示例；真的需要时才添加。更新已有组件前还要先用 --dry-run 和 --diff 看改动。

Skill 真正管的是那些小到容易被忽略的规矩

它的规则里有几条特别适合后台页面。

表单不要再拿一个 div 加 label 和 space-y-* 直接拼。官方建议用 FieldGroup、Field、FieldLabel 把结构和状态放在该在的位置。校验时，外层 Field 用 data-invalid，控件本身用 aria-invalid。

下面是官方规则里表达的对照。它是组件约定，不是这篇文章的本地跑分。

// 容易越写越散的写法
<div className="space-y-4">
  <label>邮箱</label>
  <input aria-invalid={hasError} />
</div>

// 让结构和校验状态待在同一处
<FieldGroup>
  <Field data-invalid={hasError || undefined}>
    <FieldLabel htmlFor="email">邮箱</FieldLabel>
    <Input id="email" aria-invalid={hasError || undefined} />
    <FieldDescription>用于接收变更通知</FieldDescription>
 </Field>
</FieldGroup>

这段代码看着没多神。可一旦一个设置页有十几个字段，错误提示、禁用态、辅助文案和无障碍属性不再各写各的，维护成本就开始往下掉。不是哥们，最怕的从来不是少一个组件，是每一个组件都长得像独立创业项目。

把表单结构和状态放回各自组件，不是让页面更花哨，而是让下一次改动有地方可落。

卡片、弹窗、空状态也是同一思路。Card 该有 CardHeader、CardTitle、CardDescription、CardContent、CardFooter；弹窗和抽屉需要标题，哪怕标题只给读屏软件用；空状态用 Empty，不要再复制一个会闪烁的 animate-pulse 盒子冒充加载态。

它还顺手卡住了几个 CSS 小习惯：纵向间距用 flex flex-col gap-*，别用 space-y-*；等宽高用 size-*；状态颜色优先走 Badge 变体和语义 token，别把 text-emerald-600 撒满业务代码。你可以不同意这些取舍，但至少团队不会每个人都在同一张表单上发明一种新方言。

这张图来自 skills.sh 的公开页面。热度只能说明很多人正在关注，不能替你验证它适不适合自己的项目。

它不替你做设计，正好是它的边界

这里得泼一盆小水。shadcn Skill 能让组件组合更一致，不能替你决定「这个设置页到底该露出几项」「用户为什么要看到这个指标」「该不该把危险操作放在主按钮」。它管理的是实现的秩序，不是产品判断。

页面还没想清楚时，直接往里塞 Tabs、Card 和 Dialog，只会得到一套更整齐的迷宫。先把用户动作、信息优先级和空状态想明白，再让 Skill 把已经想明白的部分落成能维护的代码。这个分工挺舒服：设计权还在人手里，重复劳动交给组件和规则。

如果你今天正赶一个后台页面，可以只记住这四步：先跑 info，再 search，接着看 docs，才 add。有现成组件就组合，涉及本地修改就先看 diff。别把「能渲染」误当成「可维护」。

官方资料在 skills.sh 安装页 和 shadcn/ui 的 Skill 源码。

你们团队现在最常被手搓的 UI，是表单、空状态，还是确认弹窗？