当 AI 能够生成复杂的 3D 世界、视频和图像，却在为简单的网页编写 CSS 时频频受挫，这种反差揭示了大型语言模型在前端工程领域的系统性缺陷。这些问题并非偶发现象，而是根植于 AI 的训练方式、能力边界以及前端开发本身的复杂性。
训练数据的结构性滞后
当前 AI 模型的核心问题在于其训练数据与实际开发需求之间存在显著的时间差。互联网上的前端代码充斥着大量过时模式，这些代码在 AI 的训练过程中被大量采样，导致模型对现代 CSS 特性的理解极为有限。Flexbox 和 Grid 布局中蕴含的细微差别、容器查询（Container Queries）的响应式逻辑、层叠层（@layer）的优先级控制 —— 这些现代特性在训练数据中的覆盖率极低。
结果是 AI 倾向于生成看似合理但实际上早已过时的解决方案。当开发者请求一个现代的响应式布局时，AI 常常退回到媒体查询和浮动清除的老路上，而不是使用容器查询或 CSS 逻辑属性。这种行为模式反映了模型对「常见模式」的路径依赖，而非对「最佳实践」的真正理解。
视觉渲染能力的根本性缺失
AI 作为文本预测模型，其核心机制与浏览器渲染引擎有着本质的不同。模型无法真正「看到」网页布局，也无法理解像素级的精度要求。当开发者要求 AI 创建「像素级完美」的界面时，模型实际上是在进行概率性猜测 —— 它基于训练数据中最常见的模式进行推断，而非基于对视觉输出的理解。
这种缺陷在处理图标缺失、间距不对称、布局错位等问题时表现得尤为明显。AI 会自信地声称完成了任务，但实际输出中可能出现图片占位符位置错误、间距计算错误、响应式断点失效等一系列问题。更关键的是，模型缺乏对自身错误的感知能力 —— 它无法主动验证渲染结果是否符合预期，只能依赖开发者的反馈来逐步修正。
布局与数学计算的双重困境
前端布局涉及复杂的数学计算：Flexbox 的弹性因子分配、Grid 的轨道尺寸计算、视口单位的动态转换、em 和 rem 的相对单位换算。这些计算在浏览器渲染引擎中是确定性的，但在 AI 的概率模型中却充满不确定性。
当开发者要求 AI 创建一个精确间距的网格布局时，模型需要理解容器可用空间、子元素数量、排列方向、间距分配策略等多个变量。这些变量之间的相互作用形成了一个复杂的计算场景，而 AI 缺乏对这种场景的精确推理能力。结果往往是生成的代码在特定情况下有效，但在边界条件下失效 —— 比如当容器宽度恰好处于某个临界值时，布局行为与预期不符。
环境变量的不可控性
前端代码运行在高度动态的环境中，这是 AI 难以应对的另一个核心挑战。代码必须在多种浏览器类型、浏览器版本、视口尺寸、输入方式、用户偏好设置下保持一致的行为。这些环境变量组合起来形成了近乎无限的可能场景，而 AI 只能基于训练数据中见过的模式进行推断。
具体而言，模型无法可靠地预测代码在不同浏览器中的兼容性差异，无法自动处理 CSS 逻辑属性与物理属性的选择，无法根据用户的无障碍偏好调整对比度和动画设置，也无法针对触摸设备和键盘交互分别优化焦点管理。这些环境敏感性要求开发者必须显式地指定大量上下文信息，而 AI 往往忽视了这些细节，除非被明确要求。
状态管理与复杂交互的推理障碍
前端组件往往具有多种状态：悬停、聚焦、激活、禁用、加载中、错误状态等。这些状态之间存在复杂的转换关系和视觉表现要求。当开发者要求 AI 修改某个组件的特定状态时，AI 常常难以定位到正确的选择器层级，也无法理解状态之间的优先级关系。
复杂交互场景对 AI 来说更是噩梦。滚动驱动的动画（Scroll-Driven Animations）、视图过渡（View Transitions）、自定义手势响应 —— 这些现代前端特性需要模型理解时间轴、状态机、事件序列等概念，而 AI 的训练数据中这类示例极为稀缺。模型更倾向于生成基于传统事件监听器的冗长实现，而非利用 CSS 原生特性简化代码。
可访问性处理的表面化
AI 在处理无障碍需求时表现出明显的形式化倾向。模型倾向于在所有元素上滥用 aria-hidden="true"，而忽视了语义化 HTML 结构、焦点管理、屏幕阅读器兼容性等更深层次的要求。这种处理方式源于训练数据中大量存在的错误示例 —— 开发者经常为了快速解决问题而采用最简单的 aria 标记，而非遵循最佳实践。
更根本的问题在于，AI 缺乏对用户多样性的理解。它无法主动考虑视觉障碍、运动障碍、认知障碍等不同用户群体的需求，也无法根据这些需求自动调整交互设计和内容呈现方式。这些决策需要开发者深入理解产品受众，并在设计层面做出权衡，而 AI 只能提供技术层面的实现方案。
工程实践中的参数建议
针对 AI 在前端工程中的这些局限性，以下是一些经过实践验证的工程参数和最佳实践：
在提示词层面，应当明确指定 CSS 方法论和约束条件。避免使用模糊的「美化一下」这类表述，而是具体到「使用 CSS 逻辑属性」「采用 BEM 命名规范」「优先使用 CSS 原生动画而非 JavaScript」。对于复杂布局，提供具体的网格结构草图或明确的约束条件。
在验收标准层面，AI 生成的代码需要经过明确的视觉验证。推荐设置自动化视觉回归测试来捕捉布局偏差，同时建立代码审查清单，重点检查选择器特异性、响应式断点、无障碍属性等关键项。
在增量开发层面，避免一次性生成完整的复杂组件。采取小步迭代的方式，每次只请求单一功能的实现，通过多次交互逐步完善。这种方式能够有效降低上下文丢失的风险，同时让开发者能够及时发现并修正 AI 的推理错误。
在技术选型层面，明确告诉 AI 目标环境的浏览器支持范围。例如「需要支持 Chrome 90+」「必须兼容 Safari 14」「使用 CSS 嵌套但避免 @property 以外的自定义属性」。这些约束条件能够帮助 AI 缩小解决方案的搜索空间。
结语
AI 在前端工程中的局限性并非不可逾越，而是需要开发者调整使用方式并建立合理的期望。它在处理通用模式、样板代码、代码转换等任务时表现出色，但在面对需要精确视觉理解、复杂数学计算、多状态管理的场景时仍需人类开发者的主导。随着多模态模型的发展和训练数据的逐步更新，这些限制有望得到改善，但在此之前，理解并接纳 AI 的能力边界是提升工程效率的关键。
资料来源：Adam Argyle 在 nerdy.dev 上的分析文章《Why AI Sucks At Front End》