在 AI 编码代理时代，CSS 架构应如何演进？

Source: Dev.to

请提供您希望翻译的具体文本内容，我将为您翻译成简体中文。

引言

CSS 架构长期以来都是在假设代码由人类编写的前提下设计的。BEM/SMACSS 的命名约定以及 utility‑first 的设计理念都隐含地假设有人工作者。

AI coding agents are changing the assumption

AI 编码代理如 Claude Code、Cursor 和 Windsurf 正在成为 UI 实现的常规组成部分。在 Tailwind 生态系统中，llms.txt — 一个向 AI 提供项目规则和使用模式的文件 — 已成为引导 AI 输出的一种方法。

llms.txt 代表了一种“向 AI 教授规则”的方式。真正的问题是：我们能否设计出即使没有这种教学也不会崩溃的架构？

实用优先与 AI

实用优先常被认为与 AI 配合良好，因为类名直接对应样式，使 AI 更容易复现设计。然而，输出是否达到“生产质量”是另一个问题。例如：

• 卡片组件的 margin 应该归属于父元素还是子元素？
• 外观相同的元素应该共享还是复制？

即使使用实用优先，这些结构决策仍然存在。

基于约定的设计（BEM、SMACSS）面临相同的挑战

通过约定 + 评审来保持质量的模型，无论作者是人类还是 AI，都存在相同的弱点：

• 记忆约定（或向 AI 教授约定）需要成本。
• 决策具有主观性，评审标准往往会漂移。
• 随着团队规模的扩大，一致性会逐渐削弱。

即使你向 AI 提供一份冗长的指令文档来强制执行规则，随着上下文的增多，准确性也会下降。人类面临的同样问题会以不同的形式再次出现。

从“需要记忆的规则”到“反馈系统”

CSS 架构应从“需要记忆并遵循的规则”转向“反馈系统”。

受 TypeScript 的启发

TypeScript 的类型系统是一个有用的参考。你不需要记住类型规则——你编写代码，编译器会告诉你哪里出错以及如何修复。开发者只需遵循这些反馈，代码就会收敛到类型安全。

CSS 架构也需要同样的结构。不要在一开始就教授规则，而是让系统对所写内容作出“哪里出错”和“如何修复”的响应。人类阅读错误信息并修复问题；AI 代理可以解析 lint 输出并自行纠正——这是一种反馈循环，使设计无论由谁编写代码都能收敛。

SpiraCSS：反馈驱动的 CSS 架构

我在一家网页制作公司工作了超过 20 年，担任交互总监、技术总监和前端开发人员——在各种规模的项目中，从大型站点到活动着陆页，始终站在前端实现的第一线。基于这些经验，我创建了 SpiraCSS，一种我在实际生产中使用的 CSS 架构方法论。

• 可验证的组件结构 – SpiraCSS 通过 Stylelint 使组件结构和属性放置可验证，错误信息中包含修复指令，从而使 AI 代理仅凭 lint 输出即可自行纠正。
• 通过 lint 学习 – 理解属性职责分类（容器 / 项目 / 内部）可以教授 CSS 布局的基础知识。Lint 反馈充当老师；即使是缺乏经验的开发者，也会通过循环过程内化这些基础。在我的团队中，这套系统是新成员入职培训的基石。

系列概述

以下部分探讨在 AI 时代 CSS 架构应如何构建，以 SpiraCSS 为具体示例：

1. 第 2 部分： “弹性” 是什么意思？—— 定义漂移与不变量
2. 第 3 部分：反馈循环——设计能够告诉你该修复什么以及如何修复的 Lint 工具
3. 第 4 部分：SpiraCSS 核心原则与结构——父子职责与块分解
4. 第 5 部分：实际采纳——工具链集成与设置

接下来，我们将从具体定义 “弹性”——抗漂移——的含义开始。

社区讨论

你的团队如何保持 CSS 设计的一致性？
指南、审查、lint — 哪些有效，哪些出现问题？

资源

• SpiraCSS 网站 – https://spiracss.jp
• GitHub 仓库 – https://github.com/zetsubo-dev/spiracss