AI 能写 React 之后,为什么 HTML 反而更重要了?

HTML1周前发布 admin
182 0

一个看似矛盾的现象

过去一年,几乎所有前端开发者都体验过同一件事:打开 AI 编程助手,描述一个需求,几秒钟内一个可以跑起来的 React 组件就生成好了。State 管理对了,Hooks 用得也不算离谱,样式基本能看。这在几年前是不可想象的效率提升。

但与此同时,一个反直觉的趋势也在发生:关于语义化 HTML、可访问性(a11y)、Web 标准原生能力的讨论,在前端社区里不是变少了,而是变多了。

很多资深工程师开始重新强调”少用 div,多用 header/main/nav”,重新审视自己项目里的 ARIA 属性是不是补全了。

这就带来一个问题:AI 都已经能写复杂的 React 组件了,为什么大家反而更在意底层那层”老掉牙”的 HTML 了?这不是复古情怀,而是有几个非常现实的技术原因。

原因一:AI 擅长”语法正确”,不擅长”语义正确”

大语言模型生成代码的方式,本质上是基于海量代码语料做模式匹配和续写。它对”这段 JSX 能不能编译通过、能不能跑起来”有很强的把握,因为这类正确性有明确的、可验证的反馈信号(编译器报错、运行时报错)。

但语义化是另一回事。一个 <div onClick={...}> 和一个 <button> 在功能上都能触发点击事件,编译器不会对前者报错,运行效果在视觉上也可能一模一样。

AI 没有强烈的动机去区分二者,除非提示词里明确要求。结果就是,AI 生成的组件里经常出现”div 套 div”的结构:该用 <nav> 的地方用了 <div className="nav">,该用 <button> 的地方用了带点击事件的 <span>

这类代码在浏览器里”看起来”没问题,但语义信息丢失了。而语义信息恰恰是留给”人类视觉之外的读者”看的——屏幕阅读器、搜索引擎爬虫,以及现在越来越多需要理解页面结构的 AI 系统。

原因二:HTML 是所有框架的最终产物

不管用 React、Vue 还是其他任何框架,浏览器最终解析、渲染的都是 HTML。框架只是生成 HTML 的一种手段,而不是替代品。这一点在框架抽象程度越来越高的今天反而容易被忽略——开发者盯着组件树、盯着 JSX,却很少去看最终渲染出来的 DOM 结构长什么样。

AI 辅助编程放大了这个问题。当写代码的门槛降低、生成速度变快之后,开发者审查代码的重心自然会从”逐行看实现细节”转向”看整体是否work”。

如果没有人专门去检查最终产出的 HTML 结构是否语义清晰,这一层质量就很容易被忽视。换句话说,AI 让”写出能跑的代码”变得容易了,但”写出结构良好的代码”这件事,责任并没有转移给 AI,依然落在开发者身上。

原因三:可访问性问题不会自动被发现

语义化 HTML 和 ARIA 属性的核心价值之一,是让辅助技术(比如屏幕阅读器)能正确理解页面结构,帮助视障用户等群体正常使用产品。

这类问题有一个特点:视觉正常的开发者用鼠标、键盘测试功能时,很难发现语义缺失带来的可访问性问题——页面看起来完全正常,只有用屏幕阅读器实际测试才会暴露出来。

AI 生成代码时同样如此。如果提示词里不特别强调可访问性,AI 大概率会生成”视觉正确、语义粗糙”的结构。

这种缺陷不会在开发和测试阶段被自然发现,而是会一直潜伏到用户投诉或合规审计时才暴露。因此,团队反而需要更主动地把语义化 HTML 和 a11y 检查纳入代码规范和 CI 流程,而不是指望 AI 自觉做好这件事。

原因四:搜索引擎和 AI 系统都在”读” HTML 结构

无论是传统搜索引擎爬虫,还是现在能够浏览网页、执行操作的 AI 智能体(比如可以打开浏览器完成任务的 AI 助手),它们理解一个网页的方式,很大程度上依赖于 HTML 的结构和语义,而不是渲染出来的像素。

一个用 <article><h1><h2> 层级、<nav> 组织清晰的页面,比一堆无差别的 <div> 更容易被准确解析、摘要和索引。

这意味着语义化 HTML 的价值正在从”对残障用户友好”和”对 SEO 友好”,扩展到”对能够自动浏览、操作网页的 AI 系统友好”。当越来越多的自动化流程需要”理解”网页而不只是”渲染”网页时,清晰的 HTML 结构相当于给这些系统提供了一份可读的地图,能显著降低它们出错、误操作或漏解析的概率。

原因五:Web 标准本身也在补齐能力

近几年,原生 HTML 和浏览器标准也在持续进化,<dialog><details><popover> 等原生元素承担了过去需要大量 JS 代码和第三方库才能实现的交互(比如模态框、折叠面板)。

这些原生能力自带了合理的默认语义和可访问性支持,不需要开发者手动补全键盘导航、焦点管理等细节。

对 AI 辅助开发来说,这其实是一个更稳妥的方向:让 AI 优先使用这些语义明确、行为标准化的原生元素,比让它现场”造轮子”实现一套自定义交互组件,出错概率更低,可维护性也更好。这也是为什么一些前端团队开始重新审视”是不是所有交互都需要一个 React 组件”,而不是默认用 JS 重新实现浏览器早就内置的能力。

结论:AI 降低了”写代码”的门槛,却提高了”写好代码”的价值

AI 能写 React,解决的是生产效率问题——把”从需求到可运行代码”的过程变快了。但它并没有替开发者做”结构是否语义化””是否可访问””是否面向未来的自动化系统友好”这些判断,这些判断依赖对 Web 平台本质的理解,而不是对某个框架 API 的熟练程度。

正因为生成代码这一步变得又快又便宜,那些无法被自动生成、需要经验和审美判断的部分——比如一份结构清晰、语义准确的 HTML——反而成了区分代码质量高低的关键因素。

这也是为什么在 AI 已经能写复杂前端组件的今天,重新理解和重视原生 HTML,不是开倒车,而是在新的开发方式下,守住那些真正决定产品质量和长期可维护性的基本功。

© 版权声明

相关文章

暂无评论

none
暂无评论...