当AI学会写CSS，性能的账该算在谁头上

一个写了十年CSS的前端工程师跟我吐槽过一件事：他让AI生成一个商品列表卡片，代码拿过来一看，样式写得有模有样，圆角、阴影、hover态一应俱全。上线之后Lighthouse一跑，CLS（累计布局偏移）飙红。原因很简单，AI给图片标签写了个width: 100%，但没给宽高比，也没预留占位空间。图片加载完成的那一刻，整个列表往下弹了一下。

这个场景几乎概括了“高性能CSS结合AI”的全部张力所在：AI能写出好看的样式，但不一定写得出不拖累性能的样式。而这两件事之间的差距，恰好是性能工程存在的理由。

AI写CSS的盲区，恰好是性能的命门

Google Chrome工程师Addy Osmani在2026年出版的《人工智能时代的网络性能工程》里专门用一章讨论了这个问题。他的观察很直接：AI生成的代码在核心网页指标（Core Web Vitals）上存在系统性缺陷。LCP方面，AI可能不压缩图片、预加载过多非关键资源、未能优先处理关键CSS。INP方面，AI写的低效循环或大型同步JSON解析会阻塞主线程。CLS方面，未指定尺寸的图片和动态注入的列表是重灾区。

这些问题的共同特征是什么？AI在生成CSS时，优化目标往往是“视觉正确”，而不是“渲染高效”。它知道一个卡片应该长什么样，但它不知道一张没有aspect-ratio的图片会让浏览器在布局阶段多做多少功。它知道阴影好看，但不知道box-shadow在一个长列表的每个条目上重复触发重绘意味着什么。

Chrome的Adam Argyle在一期播客里说得更不客气：AI在CSS方面表现不佳的根源之一是它“看不见”。它没有渲染引擎，没有布局计算，没有合成层的概念。它是在文本空间里预测下一个token，而不是在像素空间里权衡每一次重排的代价。

另一条路：给AI装上“性能的尺子”

问题摆在这里，但解法也在冒出来。有意思的是，最务实的进展不是让AI“学会”性能直觉，而是把性能约束变成AI必须遵守的规则。

一个叫good-css的Agent Skill项目体现了这个思路。它的做法很简单：把现代CSS的最佳实践打包成一个智能体技能，当AI写样式时，强制它优先使用那些本身就更高效的声明。比如，能用一行clamp()解决的响应式字号，就不要写三个断点的媒体查询；能用CSS Grid的auto-fit实现的布局，就不要用JavaScript计算列数。这个技能的核心逻辑不是教AI“思考性能”，而是让它没机会写出低效的写法。

另一个叫shadcn-aesthetic的技能走的是设计系统路线。它让Claude生成的CSS默认使用CSS变量、HSL色彩体系、统一的间距刻度、focus-visible焦点态和GPU友好的过渡属性。这里面最值得注意的细节是transition的写法：AI默认生成的往往是transition: all 0.3s ease，而这个技能强制使用具体的属性名和150ms的短时长。transition: all是性能的隐形杀手，它会让浏览器监听元素上每一个可能变化的属性，哪怕你只是想改个背景色。

这些技能的共同点在于：它们不指望AI自己悟出性能原则，而是把原则编码成AI无法绕开的生成约束。效果比在prompt里写“请写出高性能的CSS”好得多。

一个更根本的转向：从“生成”到“审查”

ClawStorm这个工具代表了另一种思路，可能更接近大多数团队的实际需求。它不负责从零生成样式，而是扫描你代码库里实际用到的每一个class名，用AST解析提取出来，再让Mistral AI为这些class生成CSS。它的卖点之一是体积：整个工具依赖的node_modules大约8MB，而Tailwind加PostCSS的管道大约50MB。

体积小不直接等于运行时性能好，但ClawStorm的AST解析方式确实有一个性能相关的优势：它生成的CSS只包含代码里真实存在的class。这意味着没有“可能用到但没用上”的规则被塞进样式表，浏览器解析和匹配的选择器数量被压到了最低。相比之下，传统工具类框架的purge机制依赖正则扫描，容易漏掉动态拼接的class名，开发者为了保险往往会多写规则，最终产物里就多了一堆死代码。

但ClawStorm也有一个值得警惕的设计：它的设计语言用自然语言写在clawstorm.md里，每次构建时注入AI prompt。这很灵活，但也意味着CSS的输出存在不确定性。同一个class名，两次构建生成的结果理论上可能不同。对于需要精确控制渲染行为的性能关键路径来说，这种不确定性是需要人盯着的东西。

被低估的变量：AI生成的CSS，谁来验证

有一个场景几乎没有人讨论，但它可能是“AI+CSS+性能”这个三角关系里最现实的问题：当AI修改了你的样式，你怎么知道性能没有退步。

Bernie Sumption在GitNation的演讲里提到了一个很具体的困境。他想把AI发现性能问题这件事变成CI里可重复的检查，但CI环境本身就不稳定。同一份代码在不同机器上跑，Lighthouse的分数可能差出10%。他最终的解法很“土”：搞一台固定机器，每次发布前在上面手动跑一遍对比。这跟AI没有关系，这是性能测试本身的方法论问题。但AI的介入让这个问题变得更紧迫，因为AI修改CSS的速度远快于人工，而每一次修改都是一次潜在的性能回归风险。

一个可行的方向是把AI从“生成者”变成“审查者”。DEV社区上有人分享了用AI做CSS重构时踩过的坑：AI把position: absolute改成了relative，理由是“简化”，结果一个覆盖层的位置彻底跑偏。这个案例的教训不是“AI不可靠”，而是AI需要被约束在特定的优化目标里。如果你告诉AI“只做三件事：合并重复规则、移除未使用的声明、把transition: all替换为具体属性”，它做的改动就是可审查的、可回滚的。如果你说“帮我优化一下CSS”，你得到的东西可能连你自己都看不懂。

结语

高性能CSS和AI的结合，目前最诚实的描述大概是：AI是一个产能放大器，但它放大的东西里，有好的也有坏的。

它能在一秒钟内写出一个视觉上挑不出毛病的组件，也能在一秒钟内引入三个CLS隐患和两个主线程阻塞点。它能帮你在大型代码库里做机械性的重构，也能在你没注意的时候把will-change加到一个根本不需要合成层的元素上。

真正让这个组合产生正面效果的，不是AI本身变聪明了，而是围绕AI建立起来的约束体系：技能层面的强制最佳实践、审查层面的性能指标回归、以及人层面的“我知道该看哪里”。Argyle在播客里说的那句话值得放在结尾：AI让好学生和懒学生的差距变大了。好学生用它当耐心无限的导师，懒学生用它当答案生成器。CSS性能这件事，从来就不存在一键答案。AI只是让那个“知道该问什么问题”的人，跑得更快了一点。