馒猫子那篇《时代的眼泪，前端的落寞》发出去之后，后台和评论区聊得最热闹的并不是“前端到底惨不惨”，而是另一个特别具体的疑问：你总说AI生成代码效率高，那真有本事让它30分钟给你生成一个能看的原生页面吗？带着这个问题，我上个月特意做了一次实验，在一个“故意不使用任何框架”的轻量需求里，把整个流程完整跑了一遍。结论是：能，而且过程中踩的坑比我预想中少，但需要人盯着的地方也比以前多得多。
我挑选的目标场景，是一个竖屏数据看板，中央放一个罗盘式时钟，旁边环绕当日任务状态，底部再挂三张实时指标卡片。听起来不复杂，纯HTML、CSS、JavaScript三件套就能搞定，但要做得好用、耐看，并不是简单堆代码的事。这篇文章就把这次从0到1的过程拆开来讲，包括怎么向AI描述需求、怎么把AI给的零散代码整合成可维护的小项目，以及整个过程中哪些地方最容易翻车。如果你是那种想在工作中真正把AI用起来、而不是仅仅拿来写Demo的前端，这篇应该能给你一些参考。
1. 为什么我又回头折腾“原生三件套”
1.1 一个被低配环境逼回原点的需求
先说这个需求的来源。团队内部要办一个持续整个月的线上运营活动，需要在活动页上展示每天的数据完成度。活动的周期短、访问量不大、也没有复杂的角色权限。本来这种需求，放在三年前我肯定直接上Vue或React，然后拉一个组件库，配置脚手架，前后端联调后再部署。但这一次不行，因为服务器很旧，内存很小，不能指望上面常驻Node服务，也不允许为一个小活动页引入一堆依赖和构建链路。最稳妥的交付物，就变成一个扔到静态服务器上直接能打开的HTML文件。
一开始我是有点抗拒的，毕竟“只会写原生页面”在现在的面试和业务里都不是什么加分项。但重新冷静下来想，页面结构其实很清晰：一个罗盘核心区，一圈刻度标记，三块数据卡片，一组刷新定时器。如果用原生三件套实现，代码量撑死几百行，问题只是如何快速写出一个还没有太多Bug的初稿。这时我想，为什么不干脆把生成工作交给大模型，自己专注做最该做的拆解和校验工作。事实证明，这个方向是敞亮的，但敞亮不等于能闭眼狂奔，后面踩的坑就集中说明了一点：AI不是不会犯低级错误，而是会用很自信的语气犯低级错误。
1.2 “原生页面”和“AI生成”为什么天然合拍
再说说为什么我坚持选原生，而不是让AI生成一个带Vue单文件组件或React函数组件的项目。最关键的原因是：AI生成的代码未必符合你团队现有的工程规范，但你让它生成一个自包含的HTML文件时，几乎不会触碰框架选型、依赖版本、模块化规范这些问题。
原生页面的三大件之间边界足够清楚：HTML管结构、CSS管样式、JavaScript管交互。大模型对这种分离结构的训练语料极其充足，生成出来的代码往往结构完整、注释丰富，甚至比很多初级工程师写得更有条理。而且因为不涉及构建系统，它的运行结果就是所见即所得，你打开文件就能看到真实效果，省掉了“跑npm install五分钟、查依赖报错十分钟”的时间和情绪消耗。所以，用AI生成原生页面，本质上是一次信息还原度很高的“提效实验”：需求清晰、边界简单、结果可验证。
当然，这也意味着如果你需求描述得含糊，AI就会靠猜来填内容。实际做的时候我发现，AI能不能在第一步就生成让人满意的骨架，取决于我能不能把“信息架构”讲清楚，而不是把“画面感”讲清楚。这可能是整个流程里最容易被低估的一环。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 30分钟落地一个原生页面的完整实操过程
2.1 需求描述不是“画面想象”，而是“信息架构”
很多人让AI写页面，习惯是“帮我生成一个好看的罗盘时钟页面”。这种描述对AI来说太抽象了，因为没有告诉她什么是“好看”，也没告诉她不同区块的优先级。我这次试下来，最有效的办法是像写产品文档一样，把页面从大到小拆成“区块、状态、样式关键词”三层。
给AI的需求描述可以分为五个要素：
- 页面类型和屏幕方向：竖屏数据看板，适合手机端查看
- 页面结构：上半区是罗盘时钟，下半区是三张指标卡片
- 数据来源：先使用模拟数据，后续会替换为接口
- 交互状态：每秒更新指针角度，每5秒刷新一次指标
- 视觉关键词：深色背景、霓虹色点缀、简洁不留过多阴影
下面是我用的实际prompt（经过简化）：
帮我生成一个竖屏数据看板页面，适合手机屏幕，不要使用第三方库。页面主背景使用深蓝色渐变，中央放置一个罗盘时钟，罗盘有60个刻度，12个主刻度，主刻度上标注1到12的数字。中心有一根指针，每秒旋转6度，表示当前秒数。罗盘下方放三张指标卡片，分别显示“今日完成数”“进行中”“异常数”，卡片底部有更新时间。数据先写死在JavaScript里，不要发请求。整体偏深色，文字和指针用青色或亮橙色强调。
把这段话发给AI后，第一次返回就基本搭出了结构和配色。不用在后面去指挥“不要给我用React，不要让我安装依赖”，因为在一开始就声明了“不使用第三方库”，整个对话往下走时，大多数模型会顺着这个约束来。这里有一个很实用的经验：AI是基于对话上下文做续写的，头一轮的需求约束比后面追加的修正更容易被执行，后面再补约束只会让它当成“局部修改”，很难系统性重来。
2.2 让AI按“先静后动、先布局后效果”的顺序产出
第一轮生成的页面已经能看了，但离“可用”还差得很远。指针在页面上是静止的、卡片也没有渐变色、边缘细节也缺。这个阶段的处理方式很关键：不要让AI一次性把所有复杂功能都加上，而是让它在同一个对话里做增量迭代。
我习惯遵循的顺序是“静态布局 -> 配色与字体 -> 核心JS逻辑 -> 过渡与动画 -> 响应式适配”。每一步只提一两个具体改动，例如第二轮prompt这样写：
在现有代码基础上做以下调整：把指针改成用CSS变量控制颜色，并用JavaScript的requestAnimationFrame驱动旋转，而不是setInterval，确保长时间运行的功耗更好。另外，把罗盘底部分成12个扇形区域，用半透明线条区分，不要修改现有的HTML层级。
同一对话里逐轮发这样的指令，AI生成的代码风格一致性很高，也更容易定位问题。如果中途换了一个新对话，让AI“接着写”，它通常只能基于你对已有代码的描述来猜，风格极容易跑偏，甚至会为了凑结构把原来的代码大改一遍。所以建议做整页或多组件效果时，尽量保持同一个会话。
2.3 本地合并、调试和视觉校准
AI给出的代码再好，它也是在“想象”中完成渲染，不能真的替你在浏览器里跑一遍。所以等几个主要功能都加完后，我就把代码粘贴到本地一个HTML文件里，用浏览器打开。这一步的坑一点都不少。
首先是控制台报错。AI写JavaScript时，偶尔会出现变量没有被定义就使用的情况，尤其当它在同一段代码里多次改动后，状态变量容易丢失。调试这类问题并不难，看控制台的报错行定位，再补一条prompt让它修正即可。真正麻烦的是那些不报错，但效果不对的逻辑：指针角度反了、刻度总是少一格、卡片的实时时间不会变化。这些通常要通过开发者工具里的元素面板去看当前DOM的实际状态。
另外，AI生成的代码很容易把全局样式写得到处都是，比如.container、.box这种类名会出现在不同区块里，互相污染。这个问题我在下一章会单独展开。
在视觉校准上，我的方法是：先把截图发给AI，问它“这里的圆角半径是不是偏大了，左右两边的留白是不是不均衡，你帮我统一成CSS变量”。但由于模型看不到渲染图（至少普通对话模式不能精确看图），通常只能靠它根据CSS去推。所以真正的一像素级校准，还是得自己在开发者工具里量出来，再写进代码。我一般会把字体大小、间距、圆角、主色等抽成CSS自定义属性，后续无论手动改还是让AI改，都高效得多。
2.4 零散代码变成可维护小项目的收尾
页面跑通之后，不能直接把几百行代码留在那个临时HTML里作为最终交付，尤其项目还要给同事做数据接入。我建议把代码拆成三件套文件，保持目录结构清晰：
text复制task-compass/
index.html
css/
style.css
js/
data.js
render.js
main.js
这一步是我在浏览社区时学到的习惯，很有用：让AI生成数据模拟层跟渲染层分离的代码。后续如果真的要接后端接口，只需要改动data.js这个文件，不需要动任何DOM操作逻辑。这也是我推荐所有AI辅助前端项目的做法，哪怕最终交付只是一个小页面，分离数据、模板、逻辑也能极大降低后续维护成本。
3. AI碰原生代码时，最容易翻车的四个边界
3.1 视觉层：布局看着对，细节差口气
AI对CSS布局的掌握，在过去两三年里进步非常明显，栅格布局和Flexbox都能用得比较顺手。但从实际操作结果看，它更擅长“按照训练数据里的常见模板来写”，而不是真正理解你在屏幕上看到的像素偏差。
我遇到的一个典型问题是：卡片标题和副标题之间的上下间距看着不舒服，可AI给的margin-bottom: 16px和margin-top: 8px在大部分屏幕上就是会显得头重脚轻。也不是错，但就是差点意思。原因在于语言模型学习的是海量代码之间的统计规律，它没有视觉系统去确认“这样渲染出来到底好不好看”。所以当AI代码能跑、但视觉细节不过关时，别指望用“再优化一下视觉”这种模糊指令解决，那只会让它在原地打转。
最有效的方式，是把页面的设计参数固化下来，做成一份设计令牌（design token）清单。比如主色、告警色、文字层级、圆角规范。下面是我给AI局部重构时常用的基础变量：
css复制:root {
--color-bg: #0b1026;
--color-card: rgba(255, 255, 255, 0.06);
--color-primary: #00e5ff;
--color-warning: #ffb020;
--color-danger: #ff5c68;
--radius-card: 14px;
--space-unit: 8px;
}
有了这些变量后，后续再让AI调整间距，效果会稳定很多。本质上，这相当于把“审美”的一部分转换成可计算、可复用的规则，AI反而更容易理解。
3.2 逻辑层：AI会写正常流程，但不会主动考虑异常
如果说视觉细节只是“不够好”，那逻辑层的边界情况就是真正的“雷区”。AI生成核心渲染逻辑时，如果prompt里没有明确要求异常处理，它生成出来的代码会默认一切正常：接口永远返回数据、用户永远不切后台、网络永远稳定。
我这次的需求里有一个模拟数据刷新模块。第一次生成的代码是：
javascript复制function updateMetrics() {
const data = getMockData();
document.getElementById('task-count').textContent = data.completed;
document.getElementById('task-fail').textContent = data.failed;
}
这段代码看起来完全正常，但只要getMockData返回的数据里有任何字段缺失，页面就会直接显示undefined。放到真实接口里，断网、超时、返回异常结构，都是大概率事件。AI不会主动帮你处理这些，因为它训练的语料里，示例代码通常只会展示“happy path”，不会把一个生产环境的防御性编程逻辑写得特别繁琐。
解决办法是在prompt里显式追加“异常处理”的要求。我试过这样补：
请修改updateMetrics函数：如果getMockData返回的数据为空，或缺少completed字段，不要修改页面上的DOM内容，并在控制台输出警告信息。
这样补完之后，AI会给出带有if (!data || typeof data.completed === 'undefined')之类的判断逻辑，代码的健壮性立刻上一个台阶。还有一个心得可以分享：我经常要求AI把所有对外的数据请求都包一层统一的错误处理，避免每一处都写重复的兜底。AI在这种“增加一层封装但不改变公共接口”的任务上表现不错。
3.3 工程层：全局样式污染与通用命名
AI生成的原生页面，最容易让有工程洁癖的开发者抓狂的，就是类名和全局样式。为了保证页面完整可用，大模型倾向于使用大量通用类名，比如.container、.header、.item、.box。页面一复杂，这些类名控制的元素可能分布在完全不相干的两个区块里，一旦你想微调某一个，会连带着把另一个也改坏。
我在实际操作中做了一次全局重构，把罗盘区域里的元素加上了compass-前缀，指标卡片区域里的元素加上了metrics-前缀。例如将.hand改成.compass-hand，将.card-item改成.metrics-item。听起来简单，但在几百行CSS里手动改还是很费时间的，所以我采用了另一种更省事的办法：让AI按“前缀化”要求整体重写一遍class。
code复制请把整个项目的CSS类名按照区块前缀重写：罗盘区域统一以compass-开头，指标区域统一以metrics-开头，不要改变结构和样式效果。
这轮prompt的执行成功率很高，因为模型能识别出类名和样式之间的绑定关系，批量替换时不会像正则那样容易误伤。但替换后仍然要自己摸一遍页面，确认没有残留的旧类名导致样式失效。
3.4 兼容层：最新CSS特性一用就废
第三方框架的价值之一，会主动处理许多兼容性问题。但AI生成原生页面时，没有这种保障，它可能满心欢喜地给你上一个backdrop-filter做毛玻璃效果，或者用aspect-ratio轻松控制卡片比例，看起来非常现代，但放在部分老版本浏览器里就会直接失去效果或导致布局错乱。
我这次的目标用户里，有一些人使用公司统一配置的旧版本浏览器，内核更新很慢。为了不出现样式大面积崩溃，我在需求描述阶段加了一句非常有效的约束：
兼容Chrome 80及以上版本，不要使用backdrop-filter、容器查询等较新的CSS特性。
只要把这一句前置，AI在生成CSS时就会自动选择兼容性更好的方案。比如它会把毛玻璃效果用半透明背景色加模拟渐变替代，而不是直接依赖backdrop-filter。所以，用户如果对兼容性有硬性要求，一定要在最初的需求描述里说清楚，而不是等样式已经写完后再来补救，不然后期“既要效果又要兼容”的返工成本非常高。
4. 页面以外：这次实验让我看到的前端工作流变化
4.1 “写代码”的核心正在向“审代码”迁移
做完这个小项目后我有一个很实际的感受：30分钟里，我自己手写的核心代码可能不超过20行，但所有关键决策都是我做的，比如“指针旋转用requestAnimationFrame而不是setInterval”“把数据层和渲染层拆开”“给类名加前缀”。AI真正帮我替代的，是那些以前需要花大量时间的样板代码和“把脑子里的布局翻译成CSS”的过程。
这带来的最大变化是，个人核心能力从“写代码”变成了“评审和修正代码”。面对AI生成的结果，我需要一眼看出哪个函数逻辑有潜在问题，哪段CSS会有全局污染风险，哪个JS交互没有兜底。这其实比手写逻辑更考验对底层原理的理解。因为没有这些底层知识，你连“让AI改哪里”都不知道，更别说在它给出一段看起来很专业、其实是错误代码的时候把它拦住。
这个趋势也直接影响前端招聘。我在团队里的模拟面试中，已经开始尝试让候选人现场搭配AI实现一个小功能，比如把一份静态设计稿用一种组件化思路拆分成多个可复用部分，然后要求候选人指出AI生成代码中“性能比较差或逻辑不够健壮”的地方。结果比单纯问八股文更能看出真实水平。
4.2 轻量级AI协作工具链分享
很多人以为“AI写页面”必须上一套很重的AI IDE或插件全家桶。实际我这次做下来，最轻量的工具组合反而是最丝滑的，包括：
- 一个大语言模型对话窗口，用来生成和局部调整代码
- 一个浏览器，用于直接打开本地HTML文件做效果验证
- 浏览器开发者工具，用来定位样式和逻辑的问题
- 文本编辑器的代码格式化功能，生成结果先格式化再看
- Git本地仓库，每次大改之前先提交一个版本，方便回退
这套组合对原生三件套项目来说足够了。它没有任何复杂的调试链路，也不需要专门的AI辅助插件，几乎零学习成本。核心在于工作流的节奏要清晰：生成一段，验证一段，提交一段。不要让AI连续改五六个需求后再一次性验证，那样出了问题根本不知道是哪个改动引起的。
我一直觉得，工具的选择不是越多越好，而是越贴合需求越好。像这种纯前端静态页面，工具链越复杂，反而会放大AI生成代码和真实运行环境之间的误差，有些问题根本不会出现在构建前的源码层，只会在构建后的产物里冒出来，到时候排查起来更费劲。
4.3 前端面试和团队分工正在被重新定义
顺着前面的变化继续说，前端岗位的面试和分工逻辑也会被重新定义。现在很多前端面试题仍然在考“手写防抖节流”“实现一个深拷贝”“分析一段代码的闭包应用”，这些能力并非完全无用，但它们的考察比例会越来越低，因为现代开发里AI完全可以帮你生成这些工具函数，还能给出好几种实现方案。真正需要人判断的是“这个工具函数放在项目的什么位置”“它和别的模块如何交互”“它的异常分支够不够健全”。
大型团队里，可能会有“初级开发人员用AI完成页面与原型的快速产出，高级开发人员负责体系架构和数据设计”的分工。中小团队则会更依赖一专多能的成员，一个人把AI生成、代码检查、部署上线全部包圆。无论哪种分工，有一点是确定的：前端从业者如果只把自己定位成人肉编译器，那确实非常危险；但把自己定位成“能用AI快速试错、并保证工程质量的人”，职业价值反而会走高。
5. 与其说“前端落寞”，不如说“原生页面正在换一种活法”
5.1 框架、组件库、原生三件套各自的新位置
这不是第一次有人讨论“前端技术是不是过时了”，每过几年，前端总会出现一次类似的反思潮。但有一个事实不太容易被注意到：原生三件套是所有这些技术的底层基础，不管多复杂的Vue应用和React应用，编译到浏览器后运行的还是HTML、CSS和JavaScript。所以原生页面不会消失，只是它不再是写业务代码时的唯一选择。
框架和组件库也不会被AI取代，因为它们解决的关键问题是状态管理和团队协作复用，并不是“能不能生成一个页面”。一个带有大量交互状态的后台系统，AI再厉害，也不可能替你把几十个组件之间的数据流和业务边界都理清。框架的价值在长周期的项目管理里依然很大。
但从另一个角度看，AI的普及会让“简单展示型页面”越来越多地绕开重型框架。很多内部工具页、活动页、文档页直接用一个或多个HTML文件就能交付。这给原生三件套留出了一个新的生态位：轻量、快速、免构建、易部署。它不一定适合所有场景，但在合适的场景下，它的效率优势非常明显。
5.2 当非前端角色也开始“自己做页面”，真正的护城河在哪
30分钟生成一个原生页面的能力，并不只属于前端开发。只要需求描述得足够清晰，产品经理、设计师、运营人员同样可以借助AI生成一个还不错的静态页面。这意味着，纯“把图切出来变成网页”的工作将进一步贬值。
那前端的护城河在哪里？我观察到的是，像模块划分、性能优化、异常兜底、工程化规范、可访问性适配、安全风险规避这些非功能性问题，目前仍是专业前端最不可替代的部分。一个页面从“能打开”到“高可用”，中间隔着大量只有通过真实工程经验才能建立起来的判断力。
比如AI生成一个会滚动吸顶的导航条，也许它只会简单地监听window滚动事件，而不会考虑使用IntersectionObserver去获得更好的性能；AI生成一个图片懒加载，通常不会主动去处理布局偏移和加载失败的兜底图。这些小细节，不是靠漂亮代码能体现的，但它们恰恰是决定产品体验是否专业的分界线。
5.3 我给自己定的三条AI协作开发守则
经过这次实验，我结合此前多次用AI写页面和组件的经历，给自己定了三条硬性守则，也分享给想加速工作效率的开发者：
- 需求阶段先讲信息架构和约束条件，再讲视觉效果和风格偏好。
- 代码生成后，先做一次技术评审，重点看异常处理、全局命名和兼容性问题，不要急着跑效果。
- 超过三百行或需要长期维护的AI生成代码，必须做模块拆分和命名重构之后，才能提交到仓库。
兜了大半圈，还是要承认这次的标题确实带着一种“行业的眼泪”的味道。我做了这么多年前端，也曾经很依赖框架和组件库带来的安全感，但真正回过头来写原生页面时，发现许多基本功并没有过时，反而因为AI的出现，让它们的价值变得更加纯粹和清晰。代码没有冷掉，冷掉的是那些只会复制粘贴而不再理解原理的开发方式；前端也没有落寞，只是以前要拼手速的地方，现在要拼的是判断力。AI能在30分钟内生成一个漂亮的页面，但它暂时还不能替代一个能把页面做“稳”的人。如果你也正纠结要不要在AI时代继续深挖底层基础，我的建议是：放心去挖，这波技术浪潮里，能理解底层逻辑的人永远不会被拍在沙滩上。