Note: This page does not support English, using the default language version
9 月 15 日，shadcn/ui 的团队发布了一个新工具：@shadcn/lint。名字很朴素，定位却很明确——agent-first 的 Tailwind 设计系统检查器。
如果你正在用 AI 写博客主题、改前端、做落地页，这个东西值得花十分钟了解一下。
现在用 Claude、Cursor、v0 之类的工具写页面，最大的问题从来不是写不出来，而是写出来太随便。
按钮的 padding 它随手给一个 px-[13px]，颜色它直接写 #3b82f6，间距它用一堆非标准的任意值，class 名有时候干脆是拼错的。页面能跑，看着也还行，但整个站的视觉规范已经悄悄散架了。
这些毛病 TypeScript 一个都管不了——类型系统约束的是对象属性，管不了一串 Tailwind class 字符串。这也正是过去 AI 生成前端最尴尬的地方：语法全对，规范全错，而且没人能自动发现。
@shadcn/lint 的核心思路是：把「设计系统」从一份文档，变成一组可执行、可报错、带修正建议的规则。
内置规则里有几条很实用：no-restyle 管组件外观的越权修改，no-raw-colors 强制走主题色而不是写死色值，no-arbitrary-values 阻止非标准间距，no-unknown-classes 抓无效的 Tailwind 类名。
更妙的是「组件契约」。你可以用正则给具体组件写策略，比如规定 Button 只允许加 w-full、mt-*、mb-* 这几类类名，其他一律不许碰。配置大概长这样：
"shadcn/no-restyle": ["error", {
"allow": ["layout"],
"contracts": [
{ "pattern": "^Button$", "allow": ["w-full", "mt-*", "mb-*"] }
]
}]它给 agent 的反馈不是冷冰冰的报错码，而是语义化的指引——比如「这里别自己加 padding，换成组件的 size 属性」。这一点很关键：AI 拿到的是「该怎么做」，而不是「你做错了」。所以官方在 150 多次任务测试里看到，编码代理基本一轮纠正就能把违规清零；把 lint 反馈喂给模型（比如 Claude）后，修复违规的成本比只给规则降低了 10% 到 48%。
门槛也不高：支持 Tailwind v4 项目，挂在 ESLint 9.30+ 或 Oxlint 1.80+ 上，npm 装完就能跑，不需要改组件 API。
9 月 6 日我在这写过 Vercel 的 design.md。同样是「让 AI 生成的页面别千站一面」，但两者的位置完全不同，放在一起看就是一整套闭环：
一个负责告诉 AI 像谁，一个负责管它不许乱来。我自己写站的经验是，只靠文档约束，模型大概能记住七成；剩下三成它会在你没盯着的地方偷偷发挥。这时候就需要一个能在 CI 里跑、能报错、能把它拽回正轨的东西。
第一，它绑在 Tailwind v4 生态上。如果你用的是原生 CSS、UnoCSS 或者别的方案，这套东西基本吃不到，得等社区移植或者自己造轮子。
第二，规则的前提是「你已经有规范」。很多个人博客其实谈不上什么设计系统，颜色是随手挑的，间距是凭感觉的。这种情况下装 lint 只会得到一个天天报错的工具，真正的第一步还是先把自己的设计语言写下来——哪怕只是「只允许三套灰阶、四种间距」。
AI 生成前端这两年，行业一直在纠结「怎么让它更好看」。我觉得方向可能错了，真正的解法是「怎么让它更守规矩」——好看是审美问题，守规矩是工程问题，而工程问题才有标准化答案。
从 design.md 到 @shadcn/lint，十来天里这一个子类连着出了两件正经事，信号挺清楚的：给 AI 的约束，正在像当年给开发者配的 ESLint 一样，变成每个站的标配。早点把规范写下来的人，会先吃到这套红利。
Loading comments...