为什么 AI 写不好前端？一个被忽视的能力断层
最近 Hacker News 上一篇文章引发了热议：Why AI Sucks at Front End。作者 Adam Argyle（Google Chrome DevRel）毫不客气地指出 —— AI 在前端开发上的表现，远比大多数人想象的差。
这不是 AI 悲观论。这是一个值得认真对待的技术观察。
AI 擅长的：无聊的活
AI 在前端领域不是一无是处。脚手架搭建、token 迁移、功能清单罗列 —— 这些重复性高、模式明确的任务，AI 处理得相当顺手。本质上，它是一个极其高效的 copy-paste 加速器。
对于大量「well-worn patterns」，这已经足够有用了。
AI 崩溃的地方
问题出在你离开「标准模板」的那一刻。
当你要求 AI 处理复杂前端交互时，事情开始失控
作者列举了几个致命弱点：
定制交互：scroll-driven animations、微交互？AI 会发明一套 IE6 时代的 CSS 语法给你。
布局与间距：这需要对浏览器渲染引擎的动态计算有理解。AI 数学本来就差，更别说预测 intrinsic/extrinsic 属性了。
可访问性：它的策略是往墙上扔 aria-hidden="true"，祈祷能粘住。
性能：默认给你最重、最卡的方案，除非你明确要求优化。
组合状态：组件状态一复杂，AI 就哭了。
根本原因：四个结构性缺陷
1. 训练数据是过时的垃圾
互联网上充斥着过时的教程和模板代码。AI 训练在这些数据上，自然对现代 CSS（container queries、@layer、@scope）几乎无感。它的知识库偏向 2020 年以前的最佳实践。
2. 它看不见
LLM 不是渲染引擎。你给它截图，它也只是在「猜」。经典对话：
AI：”完成了！这是你完美的 UI。” 开发者：”图标位置有个大洞。” AI：”你说得对，让我修复一下。”
3. 它不理解「为什么」
AI 能写代码，但不理解架构决策背后的意图。SDD、BDD、状态机 —— 这些设计范式它并没有成对地训练过。它是文本预测器，不是设计思考者。
4. 零环境控制
后端代码跑在可预测、可锁定版本的环境里。前端呢？浏览器类型、窗口尺寸、输入方式、用户偏好 —— 全是动态变量。AI 无法控制这些，所以选择忽略它们。
我的看法
这篇文章说出了很多前端开发者的真实感受。AI coding 工具在后端、脚本、数据处理上的表现确实惊艳，但前端是一个本质上不同的战场。
前端的核心难点不在于「写对代码」，而在于「在不确定的环境中实现确定的视觉和交互效果」。这恰恰是当前 LLM 架构最不擅长的事。
但我不认为这是终局。几个可能的突破方向：
- 多模态反馈循环：让 AI 真正「看到」渲染结果并自我修正
- 浏览器环境模拟：在推理过程中引入真实的 DOM/CSS 计算
- 设计系统约束：用 design tokens 和组件规范缩小 AI 的决策空间
在那之前，前端开发者的核心价值 —— 对视觉细节的把控、对交互体验的直觉、对浏览器怪癖的理解 —— 依然不可替代。
AI 是个好工具，但离好的前端工程师还差得远。知道它的边界，比盲目信任它更重要。
如果你同时使用多个 AI 模型来辅助开发，像 OfoxAI（ofox.ai）这样的多模型聚合平台让切换成本几乎为零 —— 用不同模型处理前端和后端任务，各取所长。