从 CSS 演变史看 AI 时代：框架还需要解决什么？

假设你请 AI 制作一组产品卡片。第一版有图片、价格、购买按钮，桌面上排成三栏，手机上变成一栏。接着，设计师要求更换品牌色，同一张卡片也要放进侧栏，原有的键盘焦点与售罄状态必须保留。

第二次修改开始暴露问题：哪些蓝色代表品牌，哪些代表信息提示？卡片该依窗口还是所在容器改变布局？AI 调整按钮时，有没有一并改掉其他页面的交互状态？

以下沿用这个假设案例。我想讨论的是：当 AI 降低部分样式实现成本，框架还能替我们降低哪些修改、验证与协作成本？ 回顾 CSS 的演变，能帮助我们辨认工具真正承担的责任，也让对未来的预测有可检查的依据。

CSS 的起点，就包含了控制权的分配

1994 年，Håkon Wium Lie 提出 CSS，Bert Bos 随后参与；CSS1 在 1996 年成为 W3C Recommendation，CSS2 则在 1998 年接续发布。CSS 的关键设计包含 cascade：作者、用户与浏览器的呈现需求，需要在同一套规则中协调。W3C 历史回顾

这个起点值得放回今天的讨论。样式表可以表达作者的意图，最终呈现仍受可用空间、字体与用户设置影响。把画面写成声明，并不代表每一个像素都能由作者单方面决定。

早期浏览器对标准的实现也不一致。写下合法 CSS，和不同浏览器得到可接受的结果，是两件事。团队累积的兼容性知识因而成为工具价值的一部分：把反复遇到的差异收在共同做法里，用户便不必每次重新处理。

后来，页面要适应更多尺寸。Ethan Marcotte 在 2010 年提出的响应式网页设计，把流动网格、可伸缩图片与 media queries 组合成一种工作方式。它要求设计师描述版面如何随条件变化，也让断点与布局规则成为团队需要共同维护的资产。原始文章、出版日期回顾

从这里看，CSS 的困难一直包含两部分：浏览器如何解读规则，以及人如何组织规则。前者进步，后者不会自动完成。

工具长出来，是因为团队需要共同的做法

网站规模增加后，问题逐渐转向重复、命名与变更范围。Sass 让变量、mixin、模块与运算在构建时整理成 CSS；团队可以把品牌设置与共用规则集中管理。它增加了一个编译步骤，也提供了源代码的组织能力。Sass 指南

Bootstrap 则把选择推进到界面层。它在 Twitter 内部作为样式指南使用，于 2011 年公开发布；后续版本逐步纳入响应式设计、Flexbox 与自定义属性。采用这类框架，也是在采用一组既有组件与默认值，减少各个页面重新决定按钮、表单与网格的工作。Bootstrap 历史

另一条路线聚焦样式的归属。BEM 用 block、element、modifier 的命名约定表达结构与变体；CSS Modules 则默认将 class 与动画名称局部化，通过导入建立依赖。前者依赖共同纪律，后者让构建工具协助避免名称碰撞。两者都需要团队继续判断：哪些规则应该共用，哪些应该留在组件内。

组件化也带来了 CSS-in-JS。以 styled-components 为例，样式可以靠近组件，并依 props 改变；但这个大类并不只有一种执行模型。vanilla-extract 用 TypeScript 描述样式，在构建时输出静态 CSS。评估时应分别检查样式编写方式、产物与执行时机，不能把所有方案的成本算在一起。

utility-first 又把组合位置移到 markup。以 Tailwind 的做法来说，开发者组合小型 class、状态变体与设计尺度，能在使用处看见样式选择。重复组合仍需要整理，语义也仍可能由上层组件承担。

把这些路线放回时间轴，可以看见责任如何逐渐扩大。下表是脉络整理；同一时期的工具可以搭配使用。

这段历史对 AI 的启示是：写字速度只占工具价值的一部分。框架也保存了共同决定，让下一位维护者不用从零推理。

原生 CSS 接回能力，工具仍要重新定位

Flexbox 以一个维度分配空间，Grid 则直接描述行与列。当浏览器能承担更多排版工作，团队就能重新评估自己还需要多少网格封装。

自定义属性同样改变了分工。Sass 变量在编译时处理，CSS 自定义属性则留在输出中，可以依元素与 cascade 取得不同的值。切换品牌或主题时，这个差异比两者都叫「变量」更重要；它们可以配合，却不能只按语法逐字替换。Sass 的差异说明

原生 nesting 减少重复书写选择器，却不会替项目建立命名隔离；@layer 可以安排样式层的优先次序，仍需要团队决定哪些来源属于哪一层。规则同时存在时，仍须考虑来源、重要性、层、权重与顺序，不能简化成「后面写的都会赢」。

对开场的卡片，container size queries 尤其有意义：卡片可以依所在容器的宽度切换排列，不必只看 viewport。同一个桌面窗口里，主栏与侧栏也能各自成立。这是浏览器新增了表达能力；卡片何时应该换布局，仍是设计决定。

这些能力已有使用经验上的信号。State of CSS 2026 的 All Features 图表及其导出资料中，:has() 有 3,822 位回答者，其中 3,198 人曾使用，图表显示 83.7%；CSS Nesting 则是 3,820 人中的 2,695 人，显示 70.6%。分母是各功能题的回答者，百分比沿用官方显示精度；它们不代表网站覆盖率，也不表示生产项目持续使用的比例。

现代 CSS 也不是整包升级的单一版本。各模块分别演进，规范状态与浏览器采用程度需要分开判断。CSS Snapshot 2026也明确区分规范稳定性与浏览器普及情况。至于原生 @mixin，目前仍应作为实验性草案阅读；本站另有重用规则的导读，不能把它当成现成的 Sass 迁移保证。

框架也会利用原生能力。Tailwind v4 采用 CSS-first 设置、原生自定义属性与 cascade layers，并内置 container queries 支持。浏览器能力增加，可以让工具缩减某些补强工作，也能让它提供更完整的组合界面。

调查里的现在：工具并存，AI 也还没有接手一切

State of CSS 2026 询问「你使用哪些 CSS 框架？」。此题有 3,697 位回答者，以下是部分选项的人数；它是多选题，各列可能重叠，不能相加当成市场分配。工具调查

这张表容纳的是不同层次的选择。shadcn/ui 与 Tailwind 可以同时使用；None 也不能直接推论成「完全不用工具」。调查的分类方便收集回答，架构分析仍应区分样式生成、交互组件与代码分发。

同年的 CSS AI Code Generation 题目问的是「你产出的 CSS 有多少比例由 AI 生成？」。3,732 位回答者的自报比例，官方显示中位数约 13%；其中 980 人回答 0%，约占该题回答者的 26.3%。这个中位数描述每位回答者的比例，不能用来估算全世界 CSS 代码的生成量。

这使预测需要更精确的起点：AI 已进入部分人的工作流程，这份调查却不足以支持它已承担大多数 CSS 工作。受访留言对生成质量的评价也不是控制实验，不能据此声明模型普遍胜任或不胜任。

同样地，主办方将无框架选择与 LLM 联系起来的评论，是一种解读。这些数据没有排除项目类型、团队偏好或原生功能进步等因素，不能单独证明 AI 造成框架使用变化。本文据此提出假设，再用工程上的成立条件检查它。

第二次修改，考验的是规则能不能被辨认

回到产品卡片。下面是一段假设的初版 CSS，只呈现外框与留白：

.site-product-card {
  border: 1px solid #45687d;
  padding: 1.5rem;
}

要求「换品牌色」时，这段代码没有说明边框色的角色。即使 AI 能搜索整个项目，也得判断其他相同色值是否应该一起改；相同的值，不保证相同的意图。

如果需求已确认为「只有主打商品用品牌色边框，其他卡片保留中性边框」，可以把共同规则与变体写出来。以下取代上一段；假设卡片位于 .site-product-slot 里，主打卡片带有 data-featured 属性，品牌属性则放在外层祖先：

:root {
  --border-neutral: #777777;
  --accent-brand: #45687d;
  --space-card: 1.5rem;
}
 
[data-brand="forest"] {
  --accent-brand: #406b57;
}
 
.site-product-slot {
  container: product / inline-size;
}
 
.site-product-card {
  display: grid;
  gap: 1rem;
  padding: var(--space-card);
  border: 1px solid var(--border-neutral);
}
 
.site-product-card[data-featured] {
  border-color: var(--accent-brand);
}
 
@container product (width >= 30rem) {
  .site-product-card {
    grid-template-columns: minmax(0, 1fr) 2fr;
  }
}

这里假设卡片有图片区与内容区两个直接子元素；30rem 是案例选定的条件。查询的是外层容器，宽度不足时维持单栏。它只示范边框、间距与排列，按钮的焦点、售罄行为仍由既有组件负责。

若上层以组件组合产品，还可以提供更受限的接口。以下是假设的组件 API，不属于任何现成软件包：

<ProductCard
  product={product}
  emphasis="featured"
  availability="sold-out"
/>

这些名称有价值的前提，是实现确实把 emphasis 对应到样式，把 availability 对应到文案及操作行为。类型可以限制可传的值，仍不能证明售罄按钮、键盘操作与画面都正确。替任意值取名字，也只有在它代表稳定的共同决定时，才减少下一次修改的歧义。

原生 CSS、utility class 与组件库都能承载这些规则。AI 所需的上下文也不只是一份语法表，还包含哪些组件已存在、哪些组合合法，以及如何确认修改没有越界。

因此，我会把成本拆开看。编写成本可能降低；理解既有规则仍需要取得上下文；修改可能波及共用来源；验证必须涵盖主题、尺寸与状态；维护则还包括升级与例外。这是分析方法，并非本文实测得到的时间分配。若生成更快却让审阅更慢，团队仍得计算整段流程。

2026–2029：我会观察的三个变化

只靠缩短语法的采用理由，可能变弱

如果 AI 能可靠地产生并修改原生 CSS，额外语法所节省的手写时间，可能不再足以抵消学习与构建成本。功能单纯、设计差异大的网站，便更有理由评估较薄的工具组合。

但 utility-first 还包含局部组合、设计尺度与团队惯例。成熟工具也可能让 AI 更容易沿用现有示例。因此，我预测承受压力的是「只靠少写几个字」的理由，无法据此推导 Tailwind 或其他框架必然衰退。

可观察的信号是：完成相同需求与后续修改时，团队是否能用更少依赖维持相同质量，并减少人工修正。若原生方案仍需要更多上下文与回归处理，这项预测就应收敛；调查中 None 排名上升，本身不够。

设计约束与验证能力，可能取得更多价值

假如产生十种卡片变体变得容易，团队就更需要决定哪几种值得保留。token、合法变体、组件状态示例与回归检查，可以把「应该长怎样、怎样才算正确」变成可重复使用的依据。

这份价值不限于大型框架。小团队可能只需要一份清楚的 CSS、少量组件与检查流程；多品牌产品则可能需要更完整的设计系统。共同前提是规则必须贴近实际需求，并有人维护。

我会观察新增界面时，设计偏离与回归问题是否减少，以及审阅时间是否下降。若规则越来越多，例外却更难处理，或更新测试的成本超过收益，重型约束就未必值得。AI 也可能协助验证，让较轻量的方案已经足够。

框架会更重视 agent 如何找到并使用它

shadcn MCP 已提供查找、搜索与安装 registry 组件的接口，也可连接私有来源。这证明工具正在提供获取上下文的渠道；它并不保证 agent 会选对组件或正确修改。

我的预测是，工具作者会更重视版本明确的文档、可取得的源代码、组合示例与可执行的检查。评估一个工具，除了人是否容易上手，也会问 agent 能否找到正确版本、辨认使用限制，并把产物放回既有项目。

主流生态可能因默认集成而受益，但更好的即时检索，也可能让小型工具不必依靠模型既有知识。可观察的信号是工具接入后，错用 API、重造组件与人工返工是否下降；如果通用的代码理解已足够，专用接口的优势也可能缩小。

下一个框架选择，从要保留的责任开始

对工程师而言，理解 cascade、尺寸计算与布局仍然有用：生成结果偏离预期时，这些知识能把问题定位到规则本身。对框架作者而言，则可以重新说明自己的工具让哪一种变更更容易完成、又如何被验证。

既有项目还有迁移成本。即使新方案能少写代码，也应先用一段真实修改确认收益，再决定是否替换已经稳定运作的共同做法。

回到那张卡片，我希望第二次修改能清楚回答：品牌色改在哪里，侧栏布局由谁决定，售罄与焦点状态如何确认。只要这些责任仍需要被保存、传递与检查，工具就有发挥价值的空间。接下来值得竞争的，是谁能让一次修改更容易理解，也更容易证明它完成了需求。